做法：默认立场写死「这条不成立」#

派反驳者时，提示词里写死这几条：

• 每条发现单独派一个新模型，它看不到前面的调查过程，只拿到结论原文
• 反驳者的默认立场是「这条站不住脚」，证据够才放行
• 三种视角分开派：核代码事实（行号对不对、符号在不在）、核后果是否真的成立、核差异归类是否正确
• 不确定算一张反驳票
• 三票里两票推翻，这条就丢掉

「不确定算反驳票」是冲着一个具体毛病去的：AI 评审爱编缺陷，找不到问题也要凑几条来交差。把默认值设成有罪，要证明的就是发现本身，代码不必自证清白。

只给结论原文、不给调查过程，是同一个意思。调查过程里全是「我是这么推的」，给了反驳者，它就顺着那条路再走一遍，然后点头。

推翻确实发生了#

一次线上报错的根因调查，我拆成两阶段 15 个子代理：第一阶段 5 路并行查证据，第二阶段给每条结论各配审查员，其中一个明确要求「尝试推翻它，不是确认它」。

结构化输出里 4 个给了 refuted=true。指出来的三件事：

• 时间线顺序反了
• 归因到了错误的分支
• 报错原文和结论引用的对不上

主结论就是这么没的。

更有用的是其中一个审查员顺手写的一句：「只需一个判定实验：拿另一组已知有效的身份打同一接口，通了就是数据问题，一样 401 才是代码缺陷。」

最后的正确答案就是这么确定的，比它写出这句话晚了三轮。

好的反驳意见长这个样子——指出因果链断在哪一环，再给一个能把两种假设分开的最小实验。笼统说「我觉得不太对」的那种没有信息量，和点头一样便宜。

84 个子代理那次#

另一次是审一份跨多个仓库的改造方案。

第一层按 5 个视角各派一个模型独立找问题：数据安全、并发、契约、上线流程、文档与代码一致性。拿到约 28 条发现。

第二层给每条配 3 个反驳者。28 × 3 = 84。

中途触及用量上限，任务断掉，汇总那一步只能我自己手工做。

第二层的规模是拿发现条数直接乘出来的：28 乘 3。这个乘法里没有任何一项代表「这条有多不确定」。

那 28 条里真正要紧的几条，我已经在集群上拿到了硬证据——日志、接口实际返回、能复现的步骤。给一条已经实测确认的结论投三票，三票怎么投都不改变我下一步做什么。这笔调用量买回来的，是把一件已经查实的事重新变成待定。

剩下的多数属于「文档写 A、代码做了 B，但语义等价」，改一行文档的事。配三个反驳者，验证它比改它贵。

还有一项我当时没算进去：84 份反驳输出最后要人读。任务一断，汇总就从脚本变成手工活，花掉的是我自己的时间。

什么时候值得派#

值得：

• 结论来自模型推理，没有独立证据撑着
• 判错的代价高——要改架构、要动线上、要发给别人看

不值得：

• 已经有可复现的实测证据
• 只影响文档措辞
• 我一分钟能自己核实

现在的做法是先把发现分两堆：带实测证据的直接进结论，只有推理的才进第二层。同样是 28 条，进第二层的一般不到 10 条。