Code Change Impact

---
name: code-change-impact
description: 代码修改影响分析（通用）：判断改动是否解决了它该解决的问题、会牵连哪些调用方/页面/数据消费方、引入哪些回归风险；按改动性质分流策略（缺陷修复 / 行为等价优化 / 能力新增 / 契约变更 / 数据与状态变更）。触发："分析这个 bug 的影响"、"这个修复会影响什么"、"评估修复风险"、"这次改动会影响谁"、"改了这里要连带改什么"、"code change impact"、"bug impact analysis"。
---

# 代码修改影响分析（Code Change Impact）

## AI 说明

**目的**：对**任何**代码改动做系统性影响分析，回答两件事——这次改动**是否解决了它该解决的问题**、它**会牵连谁**。**不判代码质量与规范**（那是 `code-review`），**不做运行时取证与修复实施**（那是 `debug`）。

**功能**：先按改动性质分流策略（缺陷修复 / 行为等价优化 / 能力新增 / 契约变更 / 数据与状态变更），再定位改动的意图与根因，然后用统一的四维影响面（调用链 / 条件路径 / 数据流 / 执行场景）叠加策略专属增量，产出影响面清单、回归风险分级与测试建议。

**使用场景**：用户提供改动（diff / commit / 已合入代码）要求评估风险时；修复合入前需要影响面与回归风险背书时；被 `debug` 调用做修复前方案评估或修复后影响质检时；被 `code-review` / `challenger` 调用补齐影响面清单时；被 `auto-review` 的「影响面缺口」出口提示时（契约面改动 / 被改符号 ≥3 处引用 / 跨 ≥2 模块——此入口只提示不自动执行）。

## 核心原则

- **先定改动性质，再定分析重点**：同一个四维骨架，不同性质的改动要加压的地方不同——不区分就会"用查 Bug 的力气查重构"
- **意图与影响优先**：先搞清"它想解决什么"，再判断"解决了吗"；局部正确不代表安全，判断关键在"会影响什么"
- **横向+纵向双重覆盖**：纵向追溯调用链（谁调用了被改的代码），横向展开条件路径（不同参数/状态下是否都安全）
- **假设可验证**：每个影响结论都要给出可验证手段（跑哪个测试、查哪个模块、复现哪个场景）
- **最小化交互**：自主推理影响面，仅在关键信息缺失时提问
- **专家资产复用**：分析前主动查询专家团与解决方案，复用已知坑、实现导航加速诊断
- **证据不足转排错**：静态推理不足以支撑根因或影响结论时，转 `debug` 用运行时证据取证，不凭推理定罪（详见「与 debug 的互引」）
- **容错迭代**：用户纠正后快速更新分析

## 策略路由

**五类策略，可多选叠加**（一次改动常混合多类，如"新增接口 + 改表" = 能力新增 + 数据与状态变更）。

| 策略 | 启用信号（命中即启用） | 策略文件 |
|------|----------------------|----------|
| **缺陷修复** | issue / bug / 缺陷 / 故障 / 崩溃 / 异常 / 报错 / 回归 / 修复 | [strategies/defect-fix.md](strategies/defect-fix.md) |
| **行为等价优化** | 性能优化 / 重构 / 提取 / 合并 / 拆分 / 简化 / 清理 / 精简 / 依赖升级 / 降级依赖 / 换实现 | [strategies/behavior-equivalent.md](strategies/behavior-equivalent.md) |
| **能力新增** | 新增 / 增加 / 支持 / 上线 / 新接口 / 新字段 / 新页面 / 新配置 / 开关 / 灰度 / **下线 / 移除（页面、入口、开关）** | [strategies/capability-add.md](strategies/capability-add.md) |
| **契约变更** | 签名 / 参数 / 返回值 / 异常类型 / API 路由 / DTO / 事件格式 / 公共类 / 中间件 / **删除 / 移除 / 下线 / 废弃（接口、方法、字段、事件、配置项）** | [strategies/contract-change.md](strategies/contract-change.md) |
| **数据与状态变更** | 表结构 / 字段 / 索引 / 迁移 / 缓存键 / 枚举 / 状态机 / 配置默认值 / **删表 / 删列 / 字段废弃** | [strategies/data-state.md](strategies/data-state.md) |

**识别规则**：

1. **契约变更优先级最高**：只要签名、返回值、异常类型、API 路由、事件格式变了，无论改动动机是什么，**必须同时启用契约变更**——它决定调用方语义是否还成立，漏掉就是漏掉整条调用链
2. **未命中任何策略** → 按通用四维（3.1~3.4）全量执行，不额外加压
3. **策略只改"增量必查项"与"维度优先级"，不改流程骨架**：禁止把策略写成另一套步骤——分析仍是 Step 0~7 的既有流程，策略文件只回答"这类改动额外必查什么、哪些维度要升级、不做什么"
4. **删除类信号按对象分流**：`删除 / 移除 / 下线 / 废弃` 不是契约变更的专属——删接口/方法/字段/事件 → **契约变更**；删表/列/缓存键/枚举值 → **数据与状态变更**；删页面/入口/开关 → **能力新增**（按"旧路径未破坏"反向核）。一次删除常需并发启用其中两项以上

**输出**（Step 0 末尾给出，让用户可纠偏）：

```text
🎯 启用策略
━━━━━━━━━━━━━━━━
- ✅ 契约变更（命中：方法签名新增必填参数）
- ✅ 数据与状态变更（命中：orders 表新增 status 字段）
- ➖ 未启用：缺陷修复 / 行为等价优化 / 能力新增
- 顺序：契约变更优先（决定调用方语义），再数据与状态变更
```

## 执行流程

### Step 0：上下文收集

1. **改动描述**：用户报告的现象 / 需求 / 优化动机（有复现步骤、报错日志、需求 ID 更好）
2. **改动代码**：git diff、commit hash、或直接粘贴
3. **被改代码上下文**：读取被修改文件的完整内容，理解函数/类/模块的完整职责
4. **影响面取数准备**：确认数据来源可用（代码索引是否存在、符号查询是否可用），取数规则见 3.0；**实际取数在 Step 3 执行**。若上游（`code-review` / `debug` / `challenger`）已给出影响面清单，**直接复用并只补缺口，不重推**
5. **策略识别**：按上面的策略路由表判定，可多选；输出启用策略
6. **资产复用查询（专家团 + 解决方案）**：调用 `use_skill("expert-solution-workflow")` 查询被修改模块的相关经验、解决方案或记忆（如业务专家资产包；查询失败或不可用，忽略此步骤继续）。如有，加载相关资产（已知坑、实现导航、架构知识）——"已知坑"助快速定位根因，"实现导航"助理解影响范围
7. **强关联关系查询**：调用 `use_skill("ki-memory-lookup")` 检索被改模块的强关联关系（跨模块契约/业务耦合），识别"改这里牵动了哪些其他模块"（查询失败或无可用记录，忽略继续）
8. **决策记忆查询**：调用 `use_skill("ki-memory-lookup")` 的决策记忆策略查被改模块的历史决策，核对其「重新评估触发条件」是否已满足；满足则说明该决策应重新评估，作为影响面分析的补充输入（查询失败或无可用记录，忽略继续）

**如果只有改动描述没有代码**，先进入 Step 1 做意图与根因诊断，帮助定位后再对方案做影响分析；若定位需要运行时证据，调用 `use_skill("debug")` 取证并修复——其 Step 4 根因结论可直接作为本 skill Step 1 输入，完成后回到本 skill 做质检。全部转交时机见「与 debug 的互引」。

### Step 1：改动意图与根因分析

先回答"这次改动想解决什么"。不同策略的落点不同：

| 策略 | 本步要产出什么 |
|------|----------------|
| 缺陷修复 | **根因链**：现象 → 直接原因 → 间接原因 → 根本原因 |
| 行为等价优化 | **等价性目标**：改前外部行为是什么、哪些允许变、哪些必须不变 |
| 能力新增 | **意图与覆盖**：新增能力要满足的需求、与既有能力的边界 |
| 契约变更 | **旧契约与新契约**：调用方此前依赖的语义（类型/空值/异常/时序） |
| 数据与状态变更 | **数据语义**：字段/状态的含义、合法值域、历史数据的迁移口径 |

#### 1.1 定位核心问题

- 直接原因是什么？（如：空指针、类型错误、边界条件遗漏、契约不匹配）
- 为什么会出现？（如：缺少校验、设计遗漏、外部依赖变化、需求未覆盖）
- 链条：直接原因 ← 间接原因 ← 根本原因，一层层往下挖，不满足于第一层

#### 1.2 评估根因的严重度

> 本小节**仅启用缺陷修复策略时必填**（含外部依赖变化导致的缺陷）；纯能力新增、行为等价优化、数据变更没有"根因"可挖，跳过本表，在 1.3 把「根因类型」改写为**改动性质**（新增 / 等价变更 / 数据迁移）。

| 根因类型 | 风险等级 | 说明 |
|----------|----------|------|
| **系统性缺陷** | 🔴 高 | 设计层面问题（如缺少错误处理机制、接口契约不明确），同类问题可能广泛存在 |
| **实现遗漏** | 🟡 中 | 某个边界条件或异常路径未覆盖 |
| **外部依赖变化** | 🟡 中 | 上游接口/数据格式变更导致 |
| **单点疏忽** | 🟢 低 | 纯编码疏忽（如拼写错误、类型写错） |

**关键判断**：根因是系统性的还是单点的？系统性缺陷意味着**同类问题可能存在于其他位置**，必须标记出来。

**证据不足时转交**：若静态推理无法唯一定位根因（多假设难定夺），或结论缺运行时支撑，调用 `use_skill("debug")` 取证，拿到证据后回填本 Step，不凭推理定罪。

#### 1.3 输出

```markdown
## 🔍 改动意图与根因

**改动类型**：[启用的策略]

**意图链（🕸 文字树，自上而下）**：
现象 / 动机：[用户看到的问题，或要达成的目标]
│
▼
直接原因 / 直接手段：[什么代码行为导致了这个现象]
│
▼
间接原因 / 间接影响：[B]
│
▼
根本原因 / 根本目标：[C]　← 根因（缺陷修复）/ ← 目标（其余策略）

**根因类型**：[系统性缺陷 / 实现遗漏 / 外部依赖变化 / 单点疏忽]
（非缺陷修复类改动，此行改写为 **改动性质**：能力新增 / 等价变更 / 数据迁移）

**同类风险排查**（仅系统性缺陷时）：

- 同样的模式在哪些地方也存在？
- [列出可能受同类问题影响的位置]
```

**🕸 文字树语法**：**不另造**，沿用 `performance-analysis/reference.md` §9.4.3 的「最小共享语法（4 条）」（骨架 `│`+`▼` / 分支 `├─` `└─`；节点挂状态与数字；并行串行不混标；只画结构类信息、节点 ≤15、层级 ≤4、不画决策路径与审批流）。本 skill 的领域标记词：`← 根因` / `← ❌ 确定受影响` / `← ⚠️ 需检查` / `← 待验证`。清单与判定仍用表格。

### Step 2：改动方案评估

有了意图与根因，评估这次改动是否对症。

#### 2.1 评估维度

| 检查维度 | 问自己 |
|----------|--------|
| **意图达成** | 改动是否解决了它声称要解决的问题，还是只处理了表面症状？ |
| **覆盖完整性** | 是否覆盖了所有触发场景？（缺陷：所有触发路径；新增：所有需要贯通的链路） |
| **方案级别** | 是"打补丁"还是"修正设计"？ |
| **改动范围** | 有没有搭车变更（顺手做的优化/清理/重构）？这些是否被意图授权？ |

#### 2.2 判定四档

**情况 A：对症**
> 解决了根因/达成了意图，方案合理，范围与意图匹配。

**情况 B：治标不治本**
> 只处理了表象，根因仍在。建议：_更根本的思路_。

**情况 C：改动过度**
> 引入了不必要的复杂度，或改变了不应改变的行为（含未授权的搭车变更）。建议简化/拆分。

**情况 D：改动不足**
> 该改的没改全——如新增字段没有消费方、改了写入没改读取、修了主路径没修异常路径。建议补齐清单。

```markdown
## 🩹 改动方案评估

**改动内容**：[简述做了什么]

**判定**：[A / B / C / D]

**理由**：[为什么这样判断]

**如果是 B / C / D**：
- 根因 / 意图：[XXX]
- 建议的调整：[YYY]
- 当前改动的局限：[ZZZ]
```

**B / D 的落地**：更深层或补齐性的实施**默认交** `use_skill("debug")` 走最小修复闭环（修复 + 回归验证），完成后回到本 skill 质检——本 skill 只给出思路与缺口清单；由本 skill 直接落地的唯一例外见 Step 7 选择 1。

### Step 3：影响范围分析（核心步骤）

#### 3.0 取数要求

**不满足取数要求的结论，最高只能标 ⚠️ / `[需确认]`，不得标 ✅ / ❌。**

1. **清单必须来自真实查询**：调用方、被调方、受影响模块、受影响页面，一律来自符号查询与代码索引，**禁止从 diff 目测推断**。查询手段按仓库既有规则执行，本 skill 不重复规定工具选择
2. **索引优先**（仓库有 `.fe-index/` 时最省）：`use_skill("index-lookup")` 读 `.fe-index/INDEX.md` 匹配被改文件——后端查 `tables.md`（表 → 模块反向）与 `modules/*.md`（被依赖 + 事件/命令耦合），前端查 `apis/*.md`（接口 → 页面）。**索引给的是候选影响面清单，逐条仍要回源码确认**（无索引 / 未命中 / 过期 → 按原流程，不阻塞）
3. **回源码确认**：查询结果一律视为候选，逐条读源码确认后才可定级
4. **覆盖不全必须补齐**：查询结果明显少于源码所见（如只返回 1 个调用方但 grep 见到 5 处）时，视为覆盖不全，用 grep 补齐；**禁止据此断言"没有影响"**

#### 3.1 纵向影响：调用链分析

沿调用链向上追溯，分析改动对每个调用方的影响：

| 调用方 | 调用位置 | 调用方式 | 是否受影响 | 影响说明 |
|--------|----------|----------|------------|----------|
| `function_A()` | `file_a.py:42` | 直接调用 | ✅/⚠️/❌ | [改动对调用方的影响] |
| `function_B()` | `file_b.py:100` | 间接调用 | ✅/⚠️/❌ | [二级调用方是否受影响] |
| `ClassName.method()` | `file_c.py:88` | 继承覆盖 | ✅/⚠️/❌ | [子类实现是否受影响] |

**影响级别**：

- ✅ 无影响：调用方不依赖被修改的行为
- ⚠️ 需检查：可能受影响，建议人工确认（含取数不完整的项）
- ❌ 确定受影响：调用方行为会因改动而改变，**必须相应调整**

#### 3.2 横向影响：条件路径分析

**参数空间枚举**：

| 参数/条件组合 | 改动前行为 | 改动后行为 | 语义是否一致 |
|--------------|------------|------------|--------------|
| `param=A` | [原行为] | [新行为] | ✅/⚠️/❌ |
| `param=B`（边界） | [原行为] | [新行为] | ✅/⚠️/❌ |
| `param=空/None` | [原行为] | [新行为] | ✅/⚠️/❌ |
| `param=异常值` | [原行为] | [新行为] | ✅/⚠️/❌ |

**关键问题**：

- 是否在某些路径上改变了返回值语义（类型、含义、空值处理）？
- 是否在正常路径生效但异常路径不生效（或相反）？
- 是否改变了副作用（日志、缓存更新、状态变更）？

#### 3.3 深度影响：数据流分析

| 检查维度 | 分析内容 |
|----------|----------|
| **返回值变化** | 类型/空值/含义是否变化？调用方是否按旧语义消费？ |
| **副作用变化** | 是否新增/移除 I/O、缓存写入、状态变更、事件触发？ |
| **异常传播** | 异常类型或抛出时机是否变化？调用方处理是否匹配？ |
| **全局状态** | 是否影响全局变量、配置项、单例状态？ |

#### 3.4 执行场景分析

| 场景 | 改动前行为 | 改动后行为 | 语义一致性 |
|------|------------|------------|------------|
| 正常执行 | [行为] | [行为] | ✅/⚠️/❌ |
| 首次执行/初始化 | [行为] | [行为] | ✅/⚠️/❌ |
| 重复执行 | [行为] | [行为] | ✅/⚠️/❌ |
| 高并发执行 | [行为] | [行为] | ✅/⚠️/❌ |
| 降级/容错 | [行为] | [行为] | ✅/⚠️/❌ |
| 外部依赖失败 | [行为] | [行为] | ✅/⚠️/❌ |

#### 3.5 叠加策略增量

四维的**默认优先级**：调用链（3.1）🔴、条件路径（3.2）🟡、数据流（3.3）🟡、执行场景（3.4）🟡——无策略加压时按此执行。

四维跑完后，按 Step 0 启用的策略，逐个套用其「增量必查」表（见 `strategies/*.md`），把结论并入对应表格。策略文件的「维度优先级调整」表**只列需要说明的维度**（升降必须标出；标「不变」表示该项本策略无需额外加压、仅作确认）；标为 🔴 的维度必须给出明确结论，不得留空。

**待验证项的运行时验证**：标注 `[需确认]` 或 ⚠️ 的项，建议调用 `use_skill("debug")` 用运行时证据验证（构造复现/插桩观察）。凡能用复现验证的影响结论，不凭静态推理定论。

#### 3.6 输出影响分析报告

````markdown
## 📊 影响范围分析

### 调用链影响

**🕸 影响链文字树**（树看结构：谁牵动谁、几层；**判定与说明仍看下方表**，树的级别标记须与表一致；调用方 ≥2 或有二级调用方时必画）：

```text
`update_status()`（被改动函数）
├─ `handler()`（api.py:42）　← ❌ 确定受影响
│  └─ `dispatch()`（router.py:88）　← ⚠️ 需检查
└─ `scheduler()`（cron.py:100）　← ⚠️ 需检查
   └─ （无下游）
```

| # | 调用方 | 位置 | 影响级别 | 说明 |
|---|--------|------|----------|------|
| 1 | `handler()` | `api.py:42` | ❌ 确定受影响 | 返回值从 `dict` 变为 `dict 或 None`，调用方需增加判空 |
| 2 | `scheduler()` | `cron.py:100` | ⚠️ 需检查 | 使用了返回值，但已有判空 |
| 3 | `test_foo()` | `test_api.py:55` | ✅ 无影响 | 测试直接调用，无依赖 |

### 条件路径影响

| 参数条件 | 改动前 | 改动后 | 一致性 | 说明 |
|----------|--------|--------|--------|------|
| `user_type="admin"` | 返回全量 | 返回全量 | ✅ | 行为不变 |
| `user_type=None` | 抛 TypeError | 返回空列表 | ⚠️ | 语义变化，调用方可能依赖旧行为 |

### 数据流影响

- **返回值**：[变化及影响]
- **副作用**：[变化及影响]
- **异常传播**：[变化及影响]
- **全局状态**：[变化及影响]

### 场景覆盖

| 场景 | 影响 | 说明 |
|------|------|------|
| 正常执行 | ✅ | 行为符合预期 |
| 高并发 | ⚠️ | 移除了锁检查，并发下可能出问题 |

### 策略增量结论

[按启用策略，逐条列出 strategies/*.md 要求的增量必查项及结论]
````

### Step 4：回归风险评估

**影响级别 → 风险等级的映射**（同一影响项只计一次，不重复计数）：

| 影响级别（Step 3） | 风险等级（本步） | 含义 |
|-------------------|-----------------|------|
| ❌ 确定受影响 | 🔴 高危 | 确定会导致其他功能异常，合入前必须处理 |
| ⚠️ 需检查（含取数不全） | 🟡 中危 | 可能影响，需人工确认或运行时验证 |
| ✅ 无影响 | 🟢 低危 | 几乎无影响 |

```markdown
## 🚨 回归风险评估

### 风险总览

| 风险等级 | 数量 | 说明 |
|----------|------|------|
| 🔴 高危 | N | 确定会导致其他功能异常 |
| 🟡 中危 | N | 可能影响，需人工确认 |
| 🟢 低危 | N | 几乎无影响 |

### 高危风险详情

**[R1] 风险名称**
- 影响范围：[受影响的功能/模块]
- 触发条件：[什么时候会出问题]
- 影响表现：[用户会看到什么]
- 修复建议：[如何避免这个回归]

### 未被覆盖的同类风险

如果根因是系统性的（或策略为契约变更 / 数据与状态变更），列出**本次改动未覆盖的同类问题**：

- `file_x.py:line_y`：同样的模式，同样的风险
- `module_z/xxx.py`：相同的外部依赖处理，可能同样有问题

**同类风险的确认**：上述位置是否真被触发，交 `use_skill("debug")` 逐个复现确认；**未确证的只标「疑似同类」**，不计入确定风险。
```

### Step 5：测试建议

```markdown
## 🧪 测试建议

### 必须补充的测试

| 测试场景 | 优先级 | 原因 | 建议测试类型 |
|----------|--------|------|--------------|
| [场景1] | P0 | [没有这个测试，回归风险高] | 单元/集成/E2E |
| [场景2] | P1 | [建议补充以提升覆盖] | 单元/集成/E2E |

### 回归测试检查清单

- [ ] 调用方 `function_A()` 的现有测试是否仍然通过？
- [ ] 边界条件 `param=None` 是否被测试覆盖？
- [ ] 异常路径 `xxx_fails` 是否被测试覆盖？
- [ ] 并发场景下的行为是否被验证？
- [ ] [按策略追加，见 strategies/*.md 的必测清单]
```

> 本节只到"该测什么、为什么"；需要**用例、断言与落盘位置都齐的结构化测试计划**时交 `test-planner`。

### Step 6：输出完整报告

```markdown
# 代码修改影响分析报告

## 📋 基本信息
- **改动描述**：[用户原始描述 / 需求 ID]
- **启用策略**：[缺陷修复 / 行为等价优化 / 能力新增 / 契约变更 / 数据与状态变更]
- **改动内容**：[摘要]
- **影响文件**：[文件列表]
- **分析时间**：[时间]

## 🔍 改动意图与根因
[Step 1 输出]

## 🩹 改动方案评估
[Step 2 输出]

## 📊 影响范围分析
[Step 3 输出，逐节填入下列子节]
### 调用链影响
### 条件路径影响
### 数据流影响
### 场景覆盖
### 策略增量结论

## 🚨 回归风险评估
[Step 4 输出]

## 🧪 测试建议
[Step 5 输出]

## 📝 总结与行动项

| 优先级 | 行动项 | 关联影响 |
|--------|--------|----------|
| P0 | [必须做的事] | R1, R2 |
| P1 | [建议做的事] | C1 |
| P2 | [可选的增强] | - |

## ⚖️ 结论
- **意图达成**：是 / 否 / 部分
- **合入建议**：可合入 / 补齐后合入 / 建议重做
```

### Step 7：后续步骤

```text
分析报告已完成，请选择后续步骤：

1. 🩹 实施修复/补齐 — 默认交 debug 走最小修复闭环（修复 + 回归验证）；单点封闭改动可由本 skill 直接落地
2. 🔬 转 debug 取证 — 影响项标注 [需确认]、同类风险待复现确认，或根因缺运行时证据
3. 🧪 发起 challenger 质疑 — 对分析报告本身做二次审查，检查遗漏或误判
4. 🔎 转 code-review — 需要评代码质量、规范、架构（本 skill 只判意图与影响面，不做质量评审）

请选择 [1 / 2 / 3 / 4 / 无需后续]
```

**选择 1：实施修复 / 补齐**
- 默认交 `use_skill("debug")` 走最小修复闭环，完成后回到本 skill 复检影响面
- **例外**：改动单点、影响面封闭（无跨模块调用方）、且用户明确要求由本 skill 直接落地时，可实施；实施后仍须回本 skill 复检
- 修复完成后自动进入 writing-pipeline（auto-review → 视复杂度触发 challenger）

**选择 2：转 debug 取证**
- 调用 `use_skill("debug")`，把待验证项（复现条件/插桩点/需确认的调用方）交给它取证
- 取证结论回填报告，更新风险等级与测试建议后，再让用户选择是否修复

**选择 3：发起 challenger 质疑**
- 调用 `use_skill("challenger")` 对本次分析报告做二次审查
- 质疑聚焦：根因是否找对、影响面是否遗漏、风险评估是否过度/不足、策略是否选错
- 质疑结果反馈后，用户可选择更新报告或直接进入修复

**选择 4：转 code-review**
- 调用 `use_skill("code-review")`：本 skill 已给出"会牵连谁"，code-review 补"改得对不对"
- 两边都做过时，把影响面清单作为 code-review 的输入，避免它重复推导

## 与 code-review 的分工（并列 · 双向指认）

两个 skill 都能回答"改了什么会影响什么"，分工按**问句**切，不按工具切：

| | `code-review` | 本 skill |
|---|---|---|
| 回答的问题 | 这次改得**对不对、够不够好** | 这次改**会牵连谁** |
| 影响面的用法 | **服务于发现问题**的抽样推理（维度 0.6~0.9） | **交付本身**的穷举清单 |
| 输出 | 分级问题清单（P0/P1/P2） | 影响面清单 + 回归风险分级 + 测试建议 |
| 触发时机 | 拿到 diff 求评审 | 改动已定/已合入，求风险背书 |
| 不做 | 不产出穷举影响面清单（抽查为主） | 不判代码质量、不给重构与规范建议 |

- **互补不重复**：一次任务既要评审又要影响面时，先 `code-review`（发现问题）再本 skill（划定影响）；或并行，但影响面清单只由本 skill 产出
- **可互相转交**：本 skill 发现"质量本身有问题"→ 转 `code-review`；`code-review` 发现"影响面超出抽样范围"→ 转本 skill 补齐清单

## 与 debug 的互引（取证与落地）

> 完整分工与双向接力全景以 `debug` skill 为 SSOT，本节只定义本 skill 转交 debug 的场景。

| 时机 | 触发条件 | 动作 |
|------|----------|------|
| 无改动代码 | 只有描述，且定位意图/根因需运行时证据 | 转 debug 取证修复；其 Step 4 根因结论直接作为本 skill Step 1 输入 |
| Step 1 证据不足 | 静态推理无法唯一定位根因，或多假设难定夺 | 转 debug 复现/插桩取证，证据回填后再继续 |
| Step 2 情况 B / D | 更深层修复或补齐清单需要落地 | 实施交 debug 最小修复闭环，完成后回本 skill 复检 |
| Step 3 影响项待验证 | 标注 `[需确认]` 或 ⚠️ 需检查 | 转 debug 用运行时证据验证，不凭静态推理定论 |
| Step 4 同类风险 | 列出的同类位置是否被真实触发 | 逐个交 debug 复现确认；未确证只标「疑似同类」 |

**方向不对称提示**：debug 修复完成后**默认**可转本 skill 质检（单向强依赖）；本 skill 转 debug 是**条件触发**——仅当结论缺运行时证据、或需要落地修复时才转，静态可定论的不转，避免无谓的排错开销。

**互转终止规则**：同一问题在两侧往返各限一次（`本 skill → debug → 本 skill` 后停止互转），输出「阻塞清单」请用户补充信息或人工介入。完整规则以 `debug` skill 为 SSOT。

## 行为边界

- **分析阶段不改代码**：分析过程只输出报告；仅当用户在 Step 7 明确选择"实施修复/补齐"后，方可按该节的例外条件落地
- **修改权**：修复/补齐实施**默认交 `debug`**；仅"单点 + 影响面封闭 + 用户明确要求"时由本 skill 落地，落地后必须复检
- **不判代码质量与规范**：代码质量、规范、架构合理性交 `code-review`；本 skill 只判"意图是否达成、范围是否匹配、会牵连谁"——Step 2 的判定是影响分析的基准，不是质量评审
- **不做需求完整性**：新增能力的"该不该有、需求覆盖全不全"交 `requirement-mining` / `negative-requirement`；本 skill 只查"新增的东西链路走通了吗、有人消费吗"
- **不替代测试**：测试建议用于指导，实际测试仍需编写和执行
- **推理可追溯**：每个影响结论必须关联到具体调用链、条件路径或数据流推理
- **不确定性标注**：无法确认的影响标 `[需确认]`，取数不全的标 ⚠️
- **意图与影响优先**：分析影响前必须先找到改动意图与根因，否则影响分析缺乏基准
- **专家资产优先**：专家团存在相关模块资产时，优先利用已知坑与实现导航，减少重复调研
- **不编造调用关系**：调用关系必须来自实际查询并回源码确认，不允许凭空推测

## 需求管理集成

当项目配置了 `.requirements/config` 且 `storage_path` 指向有效目录时，**独立使用**的分析完成后自动执行集成操作（被其他 skill 调用时跳过，由调用方统一集成）：

1. **获取需求上下文**：分析前，如果关联了 REQ-ID，先读取需求信息作为参照：

```bash
req list --id {REQ-NNN} --deps
```

2. **写入分析报告**到需求目录后，调用 `req update` 注册文档关联：

```bash
req update {REQ-NNN} \
  --docs add review/code-change-impact.md,review --changelog "完成代码修改影响分析"
```

3. **错误处理**：
   - 需求 ID 不存在或未关联 REQ → 跳过集成，不影响分析本身
   - 文件锁超时 → 自动重试 1 次，仍失败则告知用户

**存储路径映射**：

| 产出物 | 存储路径 | docs 类型 |
|--------|----------|-----------|
| 代码修改影响分析报告 | `review/code-change-impact.md` | `review` |

> **兼容旧路径**：本 skill 重命名前为 `bug-impact-analysis`，历史报告位于 `review/bug-impact-analysis.md`。**同一需求内只保留一份报告、路径保持一致**——新需求一律写 `review/code-change-impact.md` 并登记该路径；若该需求已有旧路径文档，则在**旧路径上追加**并登记旧路径，不改名、不新开第二份。