AI 自纠错循环：Builder/Judge/Manager 三角色架构，让模型自己发现错误

📝

CyrilXBT 提出的极简三角色自纠错架构：Builder 产出、Judge 对照「地面真相」逐项裁定、Manager 硬逻辑路由。别再问「你确定吗」——同一模型同一对话里回顾自己，只会得到辩护而非纠错。关键是把产出和判断拆开，给判断一个独立参照物，把停止条件写成硬代码而不是软 prompt。

原文链接：AI 自纠错循环：一个三角色架构，让模型自己发现错误
作者：seebin
思想来源：CyrilXBT 的 X Article

你每天都在替 AI 干一件它应该自己干的事——抓错。

让 Claude 写段代码，你逐行审。让它写篇文章，你逐句改。让它做个调研，你得验证每条引用是不是它瞎编的。你是验证层，手动的，每一次，每一个任务。

CyrilXBT 最近发了一篇 X Article，把这件事讲透了。核心观点只有一句：

别再问「你确定吗」了，那只会得到安慰，不会得到纠错。

他给了一个极简的三角色循环架构，一下午就能搭完。不是又一个需要团队和基建的多 agent 流水线，而是一个骨架——把「你替 AI 抓错」这件事，变成「AI 替自己抓错」。

为什么「再看一遍」没用

大多数人的第一反应是：让模型自己检查一遍。”Review what you just wrote and fix any mistakes.”

有点用，但不多。原因不是 prompt 写得不好，是结构上有问题。

一个模型在同一段对话里、用同一套推理逻辑、回顾自己刚生成的内容——它会倾向于为自己的输出辩护，而不是真正审视它。这不是某个模型的缺陷，是结构性的。从内部看，一个「听起来合理」的答案不会因为再问一次就突然变得「听起来不对」。

「你确定吗？」这个问题，得到的回答绝大多数时候是「我确定」。

CyrilXBT 给的解法不是问得更好，是拆得更开——把「产出答案」和「判断答案」分开，用不同的 prompt、不同的视角，甚至不同的模型，让判断不受产出方的盲点污染。

三角色骨架：Builder、Judge、Manager

不管什么任务，自纠错循环都拆成三个角色。

Builder（建造者）——干活的。写代码、写文章、做调研，给它最大的自由度、最少的约束。它的任务是产出第一版，不是产出完美版。
Judge（裁判）——不干活，只评判。它的唯一工作是拿 Builder 的输出跟一个具体标准做对比。代码能不能跑通测试？文章有没有匹配 brief？调研能不能追溯到原始来源？
Manager（管理者）——读 Judge 的裁定，决定下一步。打回给 Builder 并附上具体反馈？升级给人类？还是标记完成？

三个角色之间传递的不是对话，是结构化的 handoff——Builder 输出交付物加不确定性声明，Judge 返回逐项通过/失败的结构化裁定，Manager 根据裁定路由到下一步。

为什么非得结构化？因为散文式的反馈会让接收方猜哪个问题最重要。结构化 handoff 的代价是前期多写点定义，但换来的是第 100 次运行和第 1 次表现一样。

Judge 必须有「地面真相」

这是整个系统里最关键的一条原则，也是最容易搞错的。

一个只看 Builder 输出、没有独立参照物的 Judge，只能判断「内部一致性」——这个回答看起来是不是连贯的、格式对不对。它判断不了「正确性」——这个回答到底对不对、到底有没有解决真正的问题。

一个自信但错误的回答，格式漂亮、逻辑自洽，没有参照物的 Judge 每次都会放过去。

不同任务的「地面真相」不同：

任务类型	地面真相	错误检查方式	正确检查方式
代码任务	测试套件	「这段代码看起来对吗」	「跑起来测试过没过」
内容任务	原始素材 + 原始 brief	「这篇文章读起来顺吗」	「每个事实能不能追溯到源头」
调研任务	实际搜索结果和源文档	「这个总结听起来权威吗」	「每个主张能不能追溯到具体来源」

如果你说不清 Judge 的地面真相是什么，你还没有自纠错循环。你有的是一个「改述循环」——Builder 的自信错误被 Judge 用另一种方式自信地重新表述了一遍。

停止条件不是可选项

最常见的翻车方式：没有显式的停止条件，Builder 和 Judge 无限循环，成本飙升，没人发现，直到账单来了。

一个真实的停止条件需要三块，全部写成硬逻辑，不能是 prompt 里的软指令：

最大迭代次数——超过 N 轮修订后，不管 Judge 满不满意，强制升级给人类，附上完整的修订历史。
可度量的质量门槛——「差不多了」不是停止条件，是建议。测试全部通过、brief 的五项需求全部满足，才是停止条件，因为它可以机械验证，不用每次都主观判断。
成本/时间上限——绝对预算，不管任务进行到什么状态，到了就停。这是最后一道护栏，防的是最坏情况——一个根本解不了的问题循环到天荒地老。

写进 Manager 的实际逻辑里，不要写成一段长 prompt 里的软指令。模型在压力下会说服自己绕过软指令，但绕不过一个硬编码的计数器。

两个实战案例

内容生产

Builder 拿到素材和 brief，产出初稿，附上置信度声明和不确定清单——哪个数字没完全确认、哪句话是推断而非原文。
Judge 拿初稿和原始素材并排对比，逐项检查：每个事实主张能否追溯到素材？brief 的每项需求有没有被满足？核心论点有没有被稀释？每项独立返回 pass/fail。
Manager 读结构化裁定。全部 pass → 进入输出队列。事实核查失败 → 打回给 Builder，直接标注哪条主张没验证过。brief 不合规 → 标注缺了哪项需求。同一项检查连续三轮失败 → 停止循环，升级给人类，附完整历史。

代码开发

Builder 不只产出代码 diff，还要把实际运行结果打包进 handoff——测试输出、lint 结果、构建状态。一个产出代码但从不执行的 Builder 不算真正填了 Builder 的角色，因为语法正确但测试跑不过的代码比没写还糟——它看起来完成了但其实没有。
Judge 检查三件事：改完之后现有测试有没有全过（且测试本身没被悄悄改掉）、lint 和静态分析有没有干净、diff 解决的是不是分配的那个问题而不是 Builder 自己觉得更有意思的相关问题。每项独立 pass/fail。
Manager 根据哪项失败来路由：测试不过 → 抓回 Builder 附上具体失败输出；范围偏移（解决的不是分配的问题）→ 直接升级给人类，因为这是判断失误不是机械缺陷，循环解决不了。

两个案例的骨架一模一样：Builder 产出并附证据 → Judge 对照具体标准逐项裁定 → Manager 根据具体失败项路由。一旦骨架对了，换个任务类型只是给 Judge 写一份新的检查清单，不用从头设计架构。

四个压力测试

搭完之后、信任它之前，跑这四遍。大多数在真实使用中翻车的循环，都过不了其中至少一个。

不可解任务测试——故意给一个完成不了的任务。Manager 是正确触发停止条件升级给人类，还是无限循环烧钱？
自信但错误测试——给 Judge 一个你已知有微妙错误的输出。Judge 有没有真的抓住？如果放过了，说明你的地面真相参照物没有被真正检查，或者检查太浅。
同模型盲点测试——如果 Builder 和 Judge 用同一个模型，专门喂一个该模型特征性的错误模式。如果 Judge 放行了，说明你的循环共享了盲点，拆角色等于没拆。考虑 Judge 用不同的模型，或者至少用一个完全不同角度的 prompt。
成本失控测试——算出最坏路径：最大迭代次数 × 最贵的模型调用 × 最长的内容长度。如果这个数字出现在真实账单上你会心慌，说明停止条件还不够紧。

常见翻车方式

即使骨架对了，这几个坑还是会悄悄毁掉整个设计：

Judge 只看 Builder 的输出，没有独立参照物。 这是最常见的错误，把正确性检查悄悄降级成了连贯性检查。
每个角色用同一个模型，只靠一层薄薄的 prompt 区分。 如果 Judge 和 Builder 底层是同一个推理过程、同一套盲点，换一顶帽子并不会带来真正的独立性。预算允许的话，Judge 用一个不同的模型。
Manager 没有记忆。 一个看不到之前尝试过什么的 Manager，会把同一份失败的反馈原封不动发回给 Builder 第二遍、第三遍，产出一模一样的失败结果。
停止条件写成软指令。 「差不多了就停」是建议，不是条件。硬编码的迭代计数器才是条件。

从一个任务开始

不要第一次就搭一个通用的自纠错系统。

挑一个你反复在做的、有明确标准的、窄的任务。先把 Judge 的检查清单写下来——不是写 Builder 的 prompt，是写标准。标准还没写清楚，说明你对这个任务的「正确」定义还不够自动化检查，这个发现比搭什么都重要。

跑完四个压力测试再信任它。停止条件从第一版就写成硬逻辑，不要等翻车了再补。

一个循环跑稳了——你不再需要盯它的输出、它持续在抓真正的错误、该停的时候干净地停——第二个循环会快很多。不是因为 prompt 能直接复用（通常要重写），而是因为你已经理解了问题的真正形状：

把产出和判断拆开，给判断一个真实的参照物，把停止条件写成逻辑而不是希望。

这个形状才是整个方法论。剩下的只是把它套到你手头的任务上。