一次右侧抽屉改造中，生成 Agent 交付了代码，复核脚本逐项检查位置、宽度和挂载状态，全部通过。截图却显示标题重复出现、遮罩层未被清除。
两个环节都没有给出错误信号。它们共享同一套证据来源，这比模型强弱更关键。程序化断言覆盖了组件是否挂载、宽度是否达标，却遗漏了用户实际看到的界面结果。复核一旦沿用生成环节给出的“完成”定义，原有盲区就会被完整保留。
相同输入无法产生独立复核
当 reviewer 只读取同一份 diff、同一组测试和生成 Agent 的完成摘要时，它仍在生成者划定的范围内判断。更换模型可以改变推理路径，却无法补出从未采集的页面状态。复核材料没有真正改变，模型能力也就无法覆盖缺失的信息。
OpenCodeReview 的公开实现采用了更清晰的分工：文件筛选、规则匹配和评论定位交给确定性程序；完整文件阅读、代码搜索和跨文件风险判断交给 Agent。模型负责判断，系统负责边界。
让验收条件先于 Reviewer 存在
回到抽屉问题，reviewer 启动前，CI 应先准备原始 Issue 和团队锁定的验收项。它们不经过生成 Agent 转述，也不能在审查过程中被删改。生成者可以解释实现，reviewer 可以补充检查，但二者都不能把失败标准改成容易通过的版本。
这组约束可以直接进入 PR 模板：
acceptance:
- title_count == 1
- overlay == absent
required_evidence:
- test_result
- runtime_screenshot
模型完成代码检查后，另一条运行链路重放打开和关闭抽屉的动作，再回读 DOM、Console 与截图。标题仍出现两次，或遮罩仍未消失，流水线就阻断合并。接口改动也遵循同一原则：除单元测试外，再核对契约、真实响应与服务日志。
最小工程改动只有三项：reviewer 直接读取原始问题；验收项由团队规则维护；最终结论必须包含来自另一条运行链路的证据。只有输入、验收权和运行证据彼此独立，第二个模型才构成真正的第二道审查。
