AI 产出 Diff 审查工作流
一句话定义
AI 产出的审查对象是 Diff 而非对话过程——用「小步生成 → 人先自审 → 让 AI 自评 → 测试兜底 → 清单放行」的五步流程，把审查控制在人类 10 分钟可承受的粒度。
为什么重要
AI 把写代码的成本降到极低，于是审查成为新的瓶颈：大而全的 diff 没人愿意认真读，「反正测试过了」直接合并，缺陷与风险随之入库。审查工作流的目标不是「更努力地读代码」，而是用流程控制 diff 的形状（小步、可预期、带自评），使人始终保持有效审查状态。这条工作流是本库质量体系的中枢：上游工作流（spec/TDD）决定 diff 的形状，下游清单（kp-021）决定审查的深度。
前置知识
kp-011（spec 驱动开发——diff 应与规格条目一一对应）。
核心概念
- 小步生成：一次一个行为/一个规格条目，diff 保持在百行以内；超出就拆任务。
- 两轮审查：第一轮人自审（先于任何工具），第二轮 AI 红队自评（让生成者扮演批评者），人终审。
- 审查锚点：spec 条目（这条 diff 是否只做了规格内的事）、测试（新行为有对应测试吗）、禁区（有没有越界改动）。
- 放行门槛：测试全绿 + 清单（kp-021）逐项过 + 无未解释的越界文件。
五步流程：
① 小步生成（一次一个行为）
② 人自审：先通读 diff，标出疑问（不看 AI 解释先形成自己的判断）
③ AI 红队自评：让它按清单挑毛病 + 说明每处改动理由
④ 测试与静态检查兜底
⑤ 清单放行，按 kp-016 拆提交原理与机制
人自审先行利用了「先形成独立判断再听解释」的评审规律：先读 AI 的自评会被其叙述锚定，漏掉它没提到的区域。AI 红队自评有效的原因是视角切换——生成时模型优化「看起来正确」，被要求攻击自己的产出时会系统性检查边界、错误处理与不一致。两轮之外，「diff 形状」本身是最强的风控：小 diff 的缺陷密度可预估、评审负荷可控，且出问题时回滚代价小（与 kp-016 的提交粒度呼应）。
实例或案例
红队自评提示模板：
以下是你刚产出的 diff。现在切换为严格评审者：
1. 逐个 hunk 说明它实现了规格哪一条（引用条目号）。
2. 按以下维度各挑至少一个问题，没有问题就明说"已检查无"：
边界与空值 / 错误处理 / 与既有代码不一致 / 潜在性能 / 安全。
3. 列出本 diff 未覆盖但规格要求的行为。
不要修改代码，只输出评审意见。操作步骤：
- 生成前声明 diff 边界：「只改 services/order.py，预计 80 行内」。
- 收到 diff 先自己读 3 分钟，写下 2-3 个疑问。
- 发红队自评提示，对比它是否发现了你的疑问；都没发现说明该区域是真盲区，重点查。
- 跑测试与 lint。
- 按 kp-021 清单逐项过，再按 kp-016 组织提交。
排错清单：
- diff 大到不想读 → 回到生成端拆小，不要试图「认真读一个大 diff」。
- AI 自评流于形式（全说没问题） → 给它指定攻击面（「专查并发与空值」）再评一轮。
- 自评与你的判断冲突 → 以测试与规格为准，不采信任何一方的「口才」。
- 发现越界改动 → 一律回滚该 hunk，无论看起来多合理。
公式或模型
本节不适用：评审质量无可靠量化，以「线上缺陷溯源到 AI diff 的比例」做长期观测。
图示
生成(小步) → 人自审(先判断) → AI红队自评(再听解释) → 测试兜底 → 清单放行
│ │
└── 形状控制 ────────────────────────── 内容把关 ──────────┘直观类比
像海关查验：一次只过一件行李（小步），先自己开箱看（人自审），再让报关员逐项申报（AI 自评），最后过扫描仪（测试）放行。
常见误区
- 「测试过了就可以合并」：测试只覆盖你想到的边界，清单覆盖你想不到的。
- 先读 AI 解释再读代码：被叙述锚定，审查退化为形式。
- 放行大 diff：审查质量随 diff 体积超线性下降，宁拆不硬读。
与其他知识点的关系
kp-021 提供审查的具体清单（本节提供流程）；kp-016 把放行后的 diff 组织成提交；kp-015 的迁移流水线是本流程的批量化变体。
自测题
要点：小步生成→人自审→AI 红队自评→测试→清单放行；先形成独立判断避免被叙述锚定。
要点：小 diff 缺陷密度可预估、评审负荷可控、回滚代价小，从源头决定审查可行性。
- 五步流程是什么？为什么人自审要在 AI 自评之前？
- diff 形状为什么是最强风控？
延伸阅读
《Code Complete（第2版）》Steve McConnell——评审与构建质量的传统基线，AI 时代依然适用。