Claude Code自检不可信？三验证器回路拦截15%漏网Bug

一次代码修改，通过了所有入参测试，部署后却让页面加载时间暴增40倍。Claude Code的自检报告里看不出任何异常，测试用例一个都没红——直到有个人决定不再相信这份自信的报告，而是引入一套专门拆台的机制。

这位开发者的操作过程被整理成一篇Dev.to技术笔记，成了Claude Code重度用户圈子里的热门读物。核心动作简单得不像话：不再依赖Claude Code的内置构建代理自己检查自己的输出，而是在每次修改完成后，派出三个持完全不同视角的验证器，用具体复现案例来反驳刚才的改动。只有当三位验证者中的多数无法证伪时，代码才能继续往前走。整个过程被严令三回合内终止。

这件事之所以引起共鸣，是它直击了一个藏在所有AI编码助手底层的认知陷阱：自信不代表正确。该代理真心相信自己完成了工作——就像人很难觉察自己的错别字一样。把模型换得更聪明并不能根除这种盲区，因为问题不在能力，而在审视自身产物时的结构性缺陷。作者给出的解法不是追求更强的模型，而是创造一个专为“证明主代理错了”而存在的第二组代理。

为什么常规测试会漏掉这些 bug？笔记里列了几种典型失效模式，每一种都精确击中了传统验证的薄弱地带。第一种是只在第二页之后才暴露的差一错误。这类偏移不会在首屏的数据里显现，却会在翻页时让每一页末尾丢失一条记录。测试环境通常只取第一页做校验，自然一路绿灯。第二种是被“修复”的竞态条件只是把触发窗口挪了个位置。原来的高频暴露路径被堵上了，但在一种更低频的组合下，锁仍然会失效。现有测试回归跑几十次也很难命中这个新窗口。

第三种失效模式更常见：一次重构把某个代码分支完全移除，或者更换了实现路径，但对应的测试用例从未覆盖过这个分支。重构后的代码跑原来的测试集当然没问题，因为那些曾经保护业务的用例，压根没执行到改过的逻辑。最后一种伤害最大，却是纯性能退化，比如每次读取数据时都会清空缓存，导致原本毫秒级的访问变成了多次全量查询，页面打开耗时膨胀几十倍。这类退化在单元测试里毫无痕迹，功能表现完全一致，只有在对立视角下尝试“重现声称行为”时才会被抓到——让一个验证器从零构建调用来观察响应时间，远比让编写代理自己报告内存占用更可能暴露问题。

作者实测的数据让这件事从“理论上说得通”变成了“现在就值得集成”。对于绝大多数改动，验证回路在一到两个回合内就能终止，并不会陷入无休止的争吵。真正的收益在于，大约15%的有害更改会在合入之前被拦截下来，而且每次都附带一个可复现的具体案例，而不是模糊的“感觉不对劲”。这15%里，就藏着那些测试覆盖不到、自检报告也不会提及的隐式故障。

要在自己的Claude Code工作流里复现这套机制，可以照着一个清晰的模式逐步搭建。第一步是准备一段验证器提示词。让主代理完成修改后，启动一个验证器，给它一个充满对抗意识的角色设定：“你是一个怀疑论者。尝试通过[正确性|安全性|复现]的视角推翻这次更改。返回一个具体的失败案例。如果你无法证明更改是安全的，把 refuted 设为 true。无法证明安全时，默认拒绝。” 这套提示词的核心就是强制输出证明，不能只给文字性判断。验证器必须给出一个确定的输入组合或者系统状态，来演示这个改动会在什么条件下出问题。没有这一步，它就和之前的自检没有本质区别。

第二步是给验证器套上结构化裁决，而不是让它写一段散文。定义一个 Verdict 类型，强制返回 refuted 布尔量、failingCase 字符串或空值、观察视角的 lens 枚举以及置信度数字。这种结构化输出不是为了机器可读的仪式感，而是为了阻止验证器退回到“看起来基本没问题”的自然语言敷衍。当它必须在一个明确的字段里填上能复现的错误案例时，模糊的自我感觉就再也藏不住了。如果 failingCase 为 null，它就必须在置信度里表现出犹豫，而这些犹豫正是后续多数投票机制要利用的信号。

第三步是整个设计的核心：三个验证器并行运行，但各自分配不同的视角。一个紧盯逻辑正确性，专门寻找边界条件和差一错误；一个专攻安全和输入验证漏洞，测试所有可被注构的输入点；第三个尝试从零重现主代理声称的功能，核对实际行为是否与描述一致。三者取多数票，只有两个或以上明确拒绝时，才触发修复回合。这种方法让偶然的误判被平均掉，同时让系统性偏见——比如编写代理倾向于忽略的某个边界条件——至少有两个不同角度的验证器会撞上。

必须给这个回路设上限，否则它就可能变成一种更昂贵的死锁方式。作者建议三回合为限：主代理修复一轮，验证器否决一轮，如此最多三轮。如果三轮内无法达成共识，就放弃改动并通知开发者。这个硬性截止让对抗不是无限争吵，而是快速收敛的证伪实验。