ai-code-review-skilllisted

# Pre-Merge Review 审查目标不是"挑出所有能挑的毛病"，而是回答一个问题：**这段改动合进去，会不会出线上问题。** ## 与常规 code review 的分工 常规 review 的方法论已经成熟，本流程**不重复它**，而是补上针对 AI 生成代码的部分。 > AI 写的新增代码通常语法正确、结构清晰。**风险集中在三处：它删掉了什么、它声称了什么、它多做了什么。** 人做重构会本能地问"这段代码为什么在这儿"，AI 默认不问——它看到的是可以被更优雅结构替代的类，看不到它背后的事故工单。 | 常规 review 重心 | 本流程额外重心 | |---|---| | 新增 `+` 行写得对不对 | **被删 `-` 行为什么可以删**（阶段 A） | | 代码是否符合规范 | **注释与提交说明里的断言是否成立**（阶段 C） | | 功能是否实现 | **是否只实现了要求的功能**（过度设计 / 重复造轮子，B2） | | 读完 diff 即结束 | **把产品真的用一遍**（阶段 D） | ## 铁律 1. **先分清"本次引入"还是"本来就有"，再下任何结论。** 把 pre-existing 问题报成新增，会让作者失去对整份报告的信任；放过真回归则是事故。每条结论必须标注归属。 2. **不看 diff 之外的代码，不下"有问题/没问题"的结论。** 被删的保护是否有别处兜底、注释声称的机制是否成立——都在 diff 之外。 3. **区分事实与推断。** 每条要么给出可复现失败路径（`文件:行` + 触发条件 → 后果），要么明说"这是推断，需确认 X"。不允许用断言语气写猜测。 4. **不确定就去查，查不动就明说。** 查不出根因是合法结论，编一个机制不是。 5. **找的时候尽量捞，砍在验证环节。** 在寻找阶段就丢掉半信半疑的候选，是漏报的头号原因——它绕过了验证。 6. **不人工审查机器能管的事。** 格式化、import 排序、lint 违规、拼写——交给工具。注意力留给逻辑、安全、架构。 --- ## 执行流程 六阶段顺序执行。详细规程在 `references/` 下，**按需加载，不要一次性全读**。 ### 阶段 0 · 准备 **0a · 能力自检** —— 本流程的价值高度依赖能否读到 diff 之外的代码： | 能力 | 缺失后果 | |---|---| | 读仓库任意文件 + 全局搜索 | 阶段 A4、C2、B1 角度 C/D 失效，退化为普通 diff 点评 | | 读版本历史（旧版文件、提交说明） | 无法判定归属，铁律 1 失效 | | 执行命令（跑测试、起服务） | 阶段 D 只能列出待验证路径 | **只拿到一段 diff 文本时**：明确声明"本次仅能做 diff 内审查，A4/C2/D 无法执���"，列出这些阶段该问的问题交给对方。**不要假装跑完了整个流程。** **0b · 采集意图与前置状态** 1. 读 commit message / PR 描述 / 关联工单，写下一句话：**这次改动声称要做什么。** 阶段 B3 和 C 都拿它做基准��—实现超出声称范围的部分即候选风险。 2. **改动规模**：超过 400 行的 diff，先建议拆分再审——超出这个量级，人和模型的检出率都会断崖下跌。确实无法拆分时升到"彻底"档并说明。 大 diff 可先跑复杂度分诊：`git diff <range> | python3 sc