结构化代码审查

要解决什么问题

PR 或本地改动一多，review 很容易变成「顺手改命名、整文件格式化」的扩 scope 讨论，或者泛泛而谈、找不到对应 diff 行。更麻烦的是：任务只要求改 A，却静默破坏了 B 的兼容逻辑——这类需求外影响往往在 merge 后才暴露。

本技能把 review 约束在可验证的边界上：有 仅变更代码 与 全量（仍优先本次改动） 两种模式；没有 diff 时先收集变更，不凭空点评。

工作方式

1. 收集变更：并行确定 review 边界（base 分支、变更文件、hunk 增删改、任务目标）。
2. 理解需求边界：明确「要求改什么」与「理论上不应动什么」，后续结论都对照这条线。
3. 三项核心检查（按优先级扫 diff 每一处）：

- A. 需求外影响：是否超出任务描述、动了公共 API/鉴权/错误契约、引入行为回归等；疑似越界时标出 hunk 并说明风险。
- B. 冗余：重复逻辑、死代码、与现有工具重复的实现、可用更小 diff 达成的写法。
- C. 逻辑漏洞：边界条件、分支与状态、错误传播、数据流与安全类问题。

1. 输出报告：每条发现必须引用文件 + 行号或 diff hunk，避免空泛结论。

适用边界

• 默认只读 review，除非你明确要求修复。
• 仅变更代码模式下，不对未改动代码提「顺便可以改」类建议（除非与本次 bug 直接相关）。
• 需要上下文时只读理解变更意图所需的最小范围，结论仍只针对 diff 中的行。