两个模型互审：合并前必须有第二意见

AI 写代码越来越快，人的 review 带宽却是一个常数。一天下来，十几个提交、几个 PR，我不可能每一行都看。

我现在的规则是：合并前必须有第二意见——由另一个模型，或者至少是一个独立的新会话，把改动审一遍。这条规则已经写进了我提 PR 前的检查流程里，不靠记得。

但这件事比「让另一个 AI 看看」复杂。下面是我踩出来的做法。

一、评审会以两种方式失效

失效	表现	代价
假阳性（幻觉）	报了一个不存在的问题	浪费一轮；更糟的是把正确的代码「修」坏
假阴性（漏报）	真问题没报出来	缺陷直接进主干

直觉只会防前者，因为它显眼。但后者更贵。我遇到过一次整页崩溃上线：类型检查、单元测试、构建三道门禁全绿，没有一道检查文案有没有对应的译文。

所以协议要两头都堵。 只防幻觉，等于只防了便宜的那一半。

二、评审方选谁：参与不等于评审

组合	独立性
跨模型交叉：A 写 B 审，B 写 A 审	强，两套先验
同模型新会话	弱，会一起漏同一类问题
同会话自评	无，不算评审

只有一个模型可用时，退到同模型新会话，但绝不喂实现时的上下文，只给 diff 和要检查的清单。喂了上下文，它会顺着实现者的思路复述一遍。

有一条看起来是废话、实际栽过的规则：本轮的执行方不能当本轮的评审方。 有一批任务，另一个模型全程在当执行方写代码，收活时「这批有它参与」被顺手读成了「独立评审跑过了」。写代码的模型对自己的实现有立场，它复查自己就是自评。

独立性来自两套先验，不来自换个进程、换个会话、换个提示词。

三、不是每个改动都要审

全量评审在数学上就是失效的：AI 产出的速度在涨，人的验证带宽不涨。预算要投向失败不可逆的那一小部分。我的触发条件是满足任意一条：

• 改动文件多或行数多；
• 碰了钱、权限、数据完整性，或者对外不可撤回的动作；
• 改了公共契约：对外路由、共享组件、类型定义、文案目录；
• 跨两个以上模块。

小改动直接走正常门禁。

四、提示词怎么写：给补集，不要问「有没有问题」

开放式地问「这段代码有没有问题」，会得到一堆风格意见。有用的提示词有五个部分：

1. 范围。 哪些文件在范围内、哪些不在；明确写「只评审，不许改任何文件」——评审模型有写工具，不说它就会用。
2. 改动想做什么。 写意图，不复述 diff。它能读 diff，读不到你的思路。
3. 必须验证的硬规则。 项目里的不变量，比如「某类数据只能从后端来，前端不许写死」。这是第二个模型最能发挥价值的地方。
4. 我刻意没做的事，以及原因。 请它攻击这些决定。评审者默认夸已有的东西，不会主动质疑缺失的东西。
5. 具体问题。 编号，每条都能用「文件:行号」回答。

再加两条：

• 主门禁已经跑过的，告诉它不用再查。 让它只看门禁抓不到的东西：用户可见文案的全语种覆盖、跨刷新的状态保持、并发下的一致性。
• 结尾强制一问：「你没检查哪些方面？哪些地方你看了但没把握？」 这一问专治假阴性。它的回答就是下一轮的工作项，往往比它报出来的问题更值钱。

一个工具层面的坑：命令行工具自带的 review 子命令通常只审未提交的改动。如果这批改动已经全部提交，工作树是干净的，它会回答「没有可评审的变更」并且正常退出——又一种看起来像成功的失败。 我改成普通的一次性执行，在提示词里把比较范围写死，比如 origin/main...HEAD。

五、拿到结论后：逐条验证，不读论证

评审报告也是自述。我的处理方式：

不读它的论证，直接读它指的代码。 它说「某文件某行有某问题」，我就打开那几行自己判断。读论证会被它的叙述带着走——一段自洽的错误推理，读起来比一段正确但枯燥的事实更有说服力。这正是幻觉传染的路径。

硬判据：能不能写成一条会失败的测试。 能写成红测的，是真问题，写下来它还顺便成了回归护栏；写不成红测的，多半是幻觉，或者只是风格意见。

每条三态裁定：

裁定	要求
确认	有复现步骤或红测，进待办
驳回	必须附反证：代码行、测试输出、契约原文。「我觉得不对」不算
存疑	进待办，不当场改。存疑的东西改下去就是在赌

驳回要留痕。 不留痕，下一轮评审会报同一条，你会以为是新发现，再验一遍。

确认的问题不在当轮顺手改。 它们是新的工作项，走正常的流程。在收尾时顺手改，等于绕过了所有门禁。

六、两个红旗

• 「评审说没问题，那就过了」——评审报告也是自述。
• 「它报了三条，我都改了」——改之前逐条验了吗？改错的代价比不改高。

收束

第二意见的价值，不在于另一个模型更聪明，而在于它带着另一套先验。

用好它要三件事：选一个真正独立的评审方；给它补集而不是开放问题；拿到结论后读代码而不是读论证。 合并按钮仍然在人手里——第二意见是帮人把有限的注意力放到对的地方。