确认偏误对模型比对人更严重#

人也有确认偏误，但人还有一条相反的压力：不愿意为错误的结论继续投入。被派去复核的模型没有这条压力，它的生成目标是给出与上下文连贯的回答，而顺着已有结论往下写，天然比推翻它更连贯。

有两个独立的放大机制。

第一是交付压力。派一个模型去找问题，它几乎不会返回空结果。没有真问题时，它会把有意为之的设计、把「可以写得更好」的地方报成缺陷。典型比例是报二十条、真问题三条，人工筛选的成本吃掉全部收益。

第二是锚定。把上一轮的结论作为前提交给它看，它就不再独立读代码，而是去寻找支持这个前提的片段。多数人会把自己的判断当作事实说给模型听，于是拿到的不是验证，是附和。

问题不在于模型是否诚实，而在于任务的默认答案是什么。要求确认，默认答案就是「成立」；要求推翻，默认答案才变成「不成立」。

举证责任倒置，并且弃权算否#

我在两类任务上用了同一套结构，指令写法几乎一致：

• 代码评审：每条发现单独派给新的模型，「实际读代码尝试驳倒它：可能是误读、代码里已有处理、或属于已知设计差异。不确定时倾向 isReal=false」；
• 调研核事实：每条 claim 派三个独立验证者，开场是「Be SKEPTICAL. Try to REFUTE this claim. ≥2/3 refutations kill it.」

关键设计都落在默认值上。默认立场是「这条站不住脚」，判据不是「证明它是真问题」，而是「证明不了它是假的，才允许留下」；弃权算否，验证者说不确定就计为一张反驳票。

为什么阈值定在三票里的两票：一票无法区分「确实被推翻」和「这个验证者读漏了」，两票要求两个独立上下文得出同一个反驳理由，巧合概率显著更低。取半数以上而不是全票，是因为全票等价于把否决权交给最乐观的那个验证者，等于退回确认模式。

投票者必须处在独立上下文。让同一个模型自我复核没有意义——它要反驳的内容已经作为前提存在于它自己的上下文里。

推翻同样要有凭据，否则只是换个方向的幻觉#

默认值翻过来之后会出现新的失败模式：验证者为了完成「推翻」这个任务而编造反证。所以反驳也要受证据约束，我按三档要求：

配套一条硬性交付要求：结论必须按确认 / 推断 / 未确认分开标注，拿不出证据的一律写未确认。这条防的是模型把合理推测写成陈述句——例如从名字里带 fast、或者响应确实变快了，推断出计费倍率更低。验证者指令里还有一句「认真努力过之后它仍然成立，才算 refuted=false」，排除的是敷衍的反驳。

这套结构有过真实收获。一次根因定位中，十五个子代理里有四个给出 refuted=true，确实推翻了我的主结论，指出的问题分别是时间线顺序反了、归因到了错误的分支、报错原文对不上。其中一个验证者还提前写出了最终正确答案的判定方法：拿另一组已知有效的身份打同一个接口，通了就是数据问题，同样失败才是代码缺陷。这条判定实验比它反驳的那条结论更有价值。

已有硬证据的结论不需要投票#

这套结构会被过度编排，我自己越过那条线一次。审一份跨多个仓库的改造方案时，第一层按五个视角各派一个模型找问题，拿到约二十八条发现；第二层给每条发现配三个反驳者，合计八十四个子代理。后果是撞上用量上限、任务中途被迫中断、汇总报告只能手工整理。

问题不在结构，在于编排规模没有匹配不确定性。那二十八条里真正关键的几条，我已经在集群上拿到了硬证据，日志、实际返回和复现步骤都在。对一条被实测确认过的结论再投三票不会改变任何决策，只是把一个确定的事实重新降级成概率问题。

所以触发条件要写明确：

• 值得对抗验证：结论来自模型的阅读与推理、没有独立证据；判错代价高；多条发现互相不独立，需要逐条剥离。
• 不值得：已有可复现的实测证据；结论只影响文档措辞；人工一分钟就能核实的事实。

对抗验证的成本随发现条数线性增长，它能消除的不确定性却随独立证据的出现迅速趋近于零。这两条曲线交叉的位置就是该停下的地方。如何分阶段取得那些独立证据，我写在给 AI 的分阶段验证。