AI 协作工程化 04：三道质量门，设计审查、实现审查与验收审查
“审查通过”常被当作一个模糊的总开关。但设计可读、代码可编译、测试可通过，仍可能得到一个不满足用户目标的功能。把所有检查压缩成一次 Review，会让审查者在同一时间承担相互冲突的职责：既要理解需求，又要判断方案，又要检查 diff，还要代替用户做验收。
更可靠的设计是把质量门拆成三道，每一道都试图推翻一种不同的结论。
三道门分别在证明什么
| 质量门 | 待推翻的结论 | 主要证据 | 失败后的正确去向 |
|---|---|---|---|
| 设计审查 | “按这个计划实施就能达成目标” | 需求、现状、方案、任务、验证设计 | 回 Designer |
| 实现审查 | “这些代码与提交已正确实现计划” | 真实 diff、调用点、提交边界、验证记录 | 回 Developer |
| 验收审查 | “当前有效范围已经实现用户目标” | 目标、场景、执行与审查链、结果证据 | 按根因回设计或开发 |
三者共享“找反例”的态度，但不共享判断对象。有关对抗性审查的通用方法，可以先阅读本站的对抗性原理。
设计审查：攻击“看起来完整”的方案
设计审查不是格式检查。它要主动构造“即使严格按计划实施，需求仍会失败”的反例，重点检查：目标是否被偷换、当前代码事实是否成立、外部前置是否缺失、任务是否可以独立提交、验证点是否覆盖关键边界。
例如，计划说“新增一个查询接口并展示状态”。设计审查需要继续问：状态从哪里产生？失败状态是否可见？权限不同的用户是否看到不同结果？接口契约变化是否影响旧调用方？这些问题未必要求立刻写代码，但必须在开发前变成已确认的设计事实或明确待确认项。
实现审查：相信 diff，不相信摘要
Developer 的开发记录很重要，但它是解释，不是代码事实。实现审查应从真实提交和调用点开始，建立一条最小追溯：
代码或符号 -> 提交 / 无提交原因 -> TASK -> RP -> 计划设计 -> 验证证据这一步专门防止三类假通过：
- 提交存在，但真实入口仍在调用旧逻辑。
- 验证通过，但测试的是错误入口或过期实现。
- 一个提交混入另一个任务的改动，导致审查和回滚范围失控。
实现审查也不应该直接替 Designer 重写方案。它可以指出“当前计划缺少某个关键决策”，但应把事实交回 Developer，由 Developer 判断是否还能在现有计划内修复；只有计划失效时，才走设计回交。
验收审查：把“实现正确”与“目标达成”分开
验收审查关注的是用户可观察的结果。它不能因为实现审查通过，就假设需求已经完成。验收者需要从有效需求点出发，检查主路径、关键边界、失败行为、权限、兼容和跨任务组合效果。
一个容易遗漏的规则是全量闭合：验收完成前，不能只审入站的一小批实现审查行，而要扫描所有仍有效的需求、任务、执行和通过审查链。否则一个旧任务因为追加改动而失去适用审查，也可能被静默遗漏。
对抗性不是“挑刺”
三道质量门很容易走向另一个极端：把审查变成无边界的否定。对抗性审查的要求不是“必须发现问题”，而是“提出的问题必须有证据、影响对象和最小处理目标”。
因此，一条合格的 finding 至少要包含：
- 位置与依据：问题落在哪个事实或代码证据上。
- 影响范围：哪些需求点、任务或执行受影响。
- 根因分类：是设计缺口，还是实现偏差。
- 最小修复集合：下游真正需要行动的对象。
风格偏好、范围外优化和无法举证的猜测不应成为阻塞项。严格不等于扩大权力。
小结
三道质量门不是把同一审查看三遍，而是让每一层只对一种结论负责：计划是否足够、实现是否一致、目标是否达成。职责越清晰，打回就越准确，真正的通过也越可信。
下一篇讨论这些质量门如何处理返工：发现问题后，怎样让回路保留证据又不把所有任务重新做一遍。
系列导航：