AI 写的代码，为什么不能只交给另一个 AI 审

一次右侧抽屉改造中，生成 Agent 交付了代码，复核脚本逐项检查位置、宽度和挂载状态，全部通过。截图却显示标题重复出现、遮罩层未被清除。

两个环节都没有给出错误信号。它们共享同一套证据来源，这比模型强弱更关键。程序化断言覆盖了组件是否挂载、宽度是否达标，却遗漏了用户实际看到的界面结果。复核一旦沿用生成环节给出的“完成”定义，原有盲区就会被完整保留。

相同输入无法产生独立复核

当 reviewer 只读取同一份 diff、同一组测试和生成 Agent 的完成摘要时，它仍在生成者划定的范围内判断。更换模型可以改变推理路径，却无法补出从未采集的页面状态。复核材料没有真正改变，模型能力也就无法覆盖缺失的信息。

OpenCodeReview 的公开实现采用了更清晰的分工：文件筛选、规则匹配和评论定位交给确定性程序；完整文件阅读、代码搜索和跨文件风险判断交给 Agent。模型负责判断，系统负责边界。

AI 代码审查的三层分工

让验收条件先于 Reviewer 存在

回到抽屉问题，reviewer 启动前，CI 应先准备原始 Issue 和团队锁定的验收项。它们不经过生成 Agent 转述，也不能在审查过程中被删改。生成者可以解释实现，reviewer 可以补充检查，但二者都不能把失败标准改成容易通过的版本。

这组约束可以直接进入 PR 模板：

acceptance:
- title_count == 1
- overlay == absent
required_evidence:
- test_result
- runtime_screenshot

模型完成代码检查后，另一条运行链路重放打开和关闭抽屉的动作，再回读 DOM、Console 与截图。标题仍出现两次，或遮罩仍未消失，流水线就阻断合并。接口改动也遵循同一原则：除单元测试外，再核对契约、真实响应与服务日志。

最小工程改动只有三项：reviewer 直接读取原始问题；验收项由团队规则维护；最终结论必须包含来自另一条运行链路的证据。只有输入、验收权和运行证据彼此独立，第二个模型才构成真正的第二道审查。