byted-volcengine-topology-change-impact

变更风险分析 Skill

能力定位

这个 Skill 负责把“变更描述”转成一份可执行的静态风险分析结果。

• 输入通常是自然语言变更单，也可以是简短的代码/配置变更说明
• 分析基础是已有的 topology.json，不是运行时监控或实时健康状态
• 关注三类结果：风险等级、影响范围、上下游影响描述
• 第一版优先覆盖“服务/组件”和“云资源”两类对象

这个 Skill 不直接构建拓扑；如果当前工作区还没有 business_topologies/<business>/topology.json，应先使用 topology-graph-builder 生成底层数据。

依赖：本 Skill 只需要 topology-graph-builder 生成的 topology.json 作为数据输入。同时依赖 references/risk_assessment_rules.md 中的指南进行风险推断。

输入前提

默认在当前工作区寻找：

business_topologies/
  <business>/
    topology.json
    topology.md

如果工作区中存在 .trae/business_topologies/，也可以直接复用。

静态风险分析的前提是：用户至少提供下面两类信息中的大部分。

• 变更动作：例如“修改配置”“开放 80 端口”“把副本数从 4 缩到 2”“切换入口 CLB”
• 变更对象：例如服务名、组件名、ECS、CLB、EIP、安全组、子网、VPC

如果用户只说“帮我评估这个变更”，但没有说明目标对象，要先追问。

标准流程

1. 提炼变更卡片

先把用户输入整理成一张简化的变更卡片：

• change_type：代码变更 / 配置变更 / 扩容 / 缩容 / 网络策略 / 入口切换 / 其他
• target：目标服务、组件或云资源
• action：新增 / 删除 / 修改 / 替换 / 放开 / 收紧 / 扩 / 缩
• scope：如果用户给了业务、环境、地域，要一并带上
• assumption：缺失信息要显式标记为假设

如果用户给的是代码变更或配置变更，但没有直接出现资源 ID，要先抽取最可能的服务名、组件名、应用名、网关名、配置项名或资源关键词，再去拓扑里做候选匹配。

2. 优先用脚本做结构化分析

不要直接肉眼扫 topology.json。优先执行当前 Skill 自带的脚本：

python3 ./skills/byted-volcengine-topology-change-impact/scripts/change_risk_from_topology.py \
  --node "<target>" \
  --output markdown

其中 --node 是变更目标。脚本只负责查询出结构化的拓扑数据和受影响的 ECS。

如果用户已经明确给了业务：

python3 ./skills/byted-volcengine-topology-change-impact/scripts/change_risk_from_topology.py \
  --business "<business>" \
  --node "<target>" \
  --output markdown

脚本内部直接读取 topology.json 进行节点匹配和图分析，自动拿到：

• 命中目标和基础信息
• 受影响的下游 ECS
• 关联资源和入口链路
• 文字化的上下游结构描述

3. 阅读指南并由大模型推断风险

核心要求：脚本不会输出任何“风险等级”或“风险结论”。你（大模型）必须：

1. 阅读本 skill 目录下的 references/risk_assessment_rules.md。
2. 结合用户的原始变更描述（动作）和脚本输出的结构化数据（受影响资源），基于指南中的原则，自主推理出本次变更的风险等级、风险结论和影响边界。

4. 多候选时先控风险

如果返回多个候选：

• id:exact、public_ip:exact 这类高置信命中，可以以第一候选为主继续分析
• 如果只是 name:fuzzy、metadata:fuzzy，先把候选列表给用户确认
• 如果服务名和资源名混在一起，要明确说明“当前是基于拓扑字段和元数据做静态匹配”

不要在低置信命中下直接下结论。

回答原则

1. 先结论，再证据