# How to Build a Self-Correcting AI Loop That Catches Its Own Mistakes Before You See Them
**作者**: CyrilXBT
**日期**: 2026-07-16T18:45:36.000Z
**来源**: [https://x.com/cyrilXBT/status/2077827005777588266](https://x.com/cyrilXBT/status/2077827005777588266)
---
There is a specific moment that separates someone using AI casually from someone actually running it as a system.
It is the moment they stop being the one who catches the mistake.
Right now, for most people, the loop looks like this. Ask Claude for something. Read the output. Notice something is wrong. Point it out. Get a corrected version. Read that. Notice something else. Point it out again. You are the verification layer, manually, every single time, for every single task.
A self-correcting loop removes you from that position entirely. The system generates, checks its own work against a real standard, catches what it got wrong, fixes it, and only then shows you the result. By the time you see the output, the obvious mistakes have already been caught and handled. What is left for you is judgment on the things that genuinely need a human, not proofreading a machine's first draft.
This is the complete build. By the end you will have the exact architecture, the exact prompts, and the exact failure modes to test for before you trust this with anything that matters.
## Why This Is Not The Same As Just Asking Twice
The obvious first instinct is to just ask the model to check its own work in the same conversation. "Review what you just wrote and fix any mistakes." This helps a little. It does not build a real self-correcting loop, and understanding why is the entire foundation of what follows.
A model reviewing its own output in the same context, with the same reasoning that produced the mistake in the first place, tends to defend its own work rather than genuinely scrutinize it. This is not a flaw specific to any one model. It is a structural problem. The same pass that generated a plausible-sounding but wrong answer is not well positioned to notice it is wrong, because from the inside, the answer still sounds plausible. Asking "are you sure?" produces reassurance more often than it produces genuine re-examination.
The fix is not asking better. It is architecture. A real self-correcting loop separates the work of producing an answer from the work of judging it, using a different pass, a different prompt, and ideally a different frame of reference entirely, so the judgment is not contaminated by the same blind spots that created the mistake.
## The Three Roles Every Self-Correcting Loop Needs
Every working self-correcting system, regardless of the specific task, reduces to three distinct roles. Understanding these roles clearly is more important than any specific prompt below, because once you see them, you can build a loop for almost any task by filling in the specifics.
The Builder. Produces the actual output. Writes the code, drafts the content, does the research, executes the task. This role should be given the most creative latitude and the least constraint, because its job is to produce a first attempt, not a perfect one.
The Judge. Does not build anything. Its only job is to evaluate the Builder's output against a specific, written standard, not a vague sense of quality. Does the code pass its tests. Does the draft match the brief. Does the research actually answer the question asked. The Judge should ideally have access to something the Builder does not, the original source material, the test suite, the actual requirements document, so it has independent ground truth to check against rather than just re-reading the same output and forming a fresh opinion.
The Manager. Reads the Judge's verdict and decides what happens next. Send it back to the Builder with specific feedback. Escalate to a human. Mark the task complete. This is also where your stop condition lives, the rule that prevents the loop from running forever when something cannot actually be fixed automatically.
The critical design principle across all three roles: verification needs to reference something outside the Builder's own reasoning. A test suite. An original source document. A written checklist. A second AI call with a genuinely different framing. Anything that is not simply "the same model, asked again, in the same breath."
## Building The Handoffs
The actual engineering work in a self-correcting loop is not clever prompts for each role. It is the structure of what passes between them, and this is the part most people building their first loop skip entirely, then wonder why the system behaves unpredictably.
A handoff needs three properties to work reliably. A defined format, so the receiving role is not parsing loose prose and guessing at what matters. A defined trigger, so the Builder is not the one deciding when it is finished. And a defined failure path, so that when something does not go cleanly, there is a specified next step instead of the system silently breaking or looping forever.
In practice, this means the Builder should output something structured, not just conversational text. A clear deliverable plus an explicit statement of what it is uncertain about. The Judge then evaluates that structured output against a written standard and returns its own structured verdict, not a paragraph of hedged prose, but a clear pass, fail, or needs-revision, with the specific reason attached. The Manager reads that structured verdict, not the raw content, and decides the next action based on rules established in advance, not by improvising a judgment call in the moment.
Here is a template structure that works across most tasks, whether the underlying work is writing, code, or research:
```
BUILDER OUTPUT FORMAT
Deliverable: [the actual output]
Confidence: [high / medium / low]
Known uncertainties: [anything you are unsure about, stated explicitly]
Assumptions made: [anything you assumed without being told]
JUDGE VERDICT FORMAT
Verdict: [PASS / FAIL / NEEDS REVISION]
Checked against: [the specific standard used, e.g. the original brief,
the test suite, the source document]
Specific issues found: [exact problems, not a general impression]
Confidence in this verdict: [high / medium / low]
MANAGER ACTION
If PASS: mark complete, deliver to user.
If FAIL or NEEDS REVISION: send back to Builder with the Judge's
specific issues attached. Increment the revision counter.
If revision counter exceeds [N]: stop looping, escalate to human
with full history of what was tried and why it failed.
```
This looks like more structure than a casual back-and-forth conversation, and it is. That upfront cost is what buys you a system that behaves the same way on the hundredth run as it did on the first one, instead of drifting unpredictably as context accumulates.
## The Judge Needs Ground Truth, Not Just An Opinion
This is the single most important principle in the entire system, and it is worth its own section because getting it wrong quietly undermines everything else.
A Judge that only sees the Builder's output, with no independent reference to check against, can only evaluate internal consistency, whether the output seems coherent and well formatted. It cannot evaluate correctness, whether the output actually matches what was asked for or actually solves the real problem. A confidently wrong answer, well formatted and internally consistent, will sail past a Judge with no ground truth every single time.
For coding tasks, ground truth is the test suite, the actual output of running the code, the lint results, the build status. Not "does this code look right," but "did it actually pass when executed."
For content tasks, ground truth is the original source material and the original brief, side by side with the draft. Not "does this read well," but "does every specific claim in this draft trace back to something actually in the source, and does the piece actually satisfy every requirement in the brief."
For research tasks, ground truth is the actual search results and source documents the research was supposed to be based on. Not "does this summary sound authoritative," but "can every claim be traced to a specific source, and were the sources that were searched actually the relevant ones."
If you cannot articulate what the Judge's ground truth is for your specific task, you do not have a self-correcting loop yet. You have a rephrasing loop, where the Builder's confident mistake gets confidently rephrased by the Judge instead of actually being caught.
## The Stop Condition Is Not Optional
The most common way a self-correcting loop becomes an expensive, out-of-control mess is the absence of an explicit, hard stop condition. Without one, a Builder and Judge can cycle indefinitely, each revision triggering another evaluation, each evaluation triggering another revision, while cost climbs and nobody notices until the bill arrives.
A real stop condition needs three components, and all three should be enforced as explicit logic, not left to the model's judgment in the moment.
A maximum iteration count. A hard ceiling on revision cycles, after which the Manager is forced to escalate to a human regardless of whether the Judge is satisfied yet.
A quality threshold that is actually measurable, not aspirational. "Good enough" as an instruction inside a prompt is not a stop condition, because it is a suggestion the model can and will eventually ignore under the right pressure. A specific, checkable bar, all eleven test cases pass, or the draft matches all five stated brief requirements, is a stop condition, because it can be verified mechanically rather than judged subjectively each time.
A cost or time ceiling. An absolute budget the task cannot exceed regardless of what state it is in when that ceiling hits. This is the guardrail that protects you specifically from the worst case scenario, a genuinely unsolvable task looping until someone notices the invoice.
STOP CONDITIONS
Maximum revisions: 3. On the 3rd failed verdict, stop and escalate
to a human with the full revision history attached, do not attempt
a 4th cycle automatically.
Quality threshold: all items on the Judge's checklist must show PASS,
not "mostly passing" or "close enough."
Budget ceiling: if this task has consumed more than [X] tokens or
[Y] minutes, stop immediately regardless of current state and report
what was completed versus what remains.
Write these into the Manager's actual logic, not into a soft instruction inside a longer prompt that the model can talk itself out of under pressure.
## A Worked Example: Self-Correcting Content Production
To make this concrete, here is exactly how the three roles and the stop condition come together for a real, common task, turning a source document into a finished piece of content without a human manually proofreading every draft.
The Builder receives the source material and the brief, and produces a draft. Its output includes the draft itself, plus an explicit confidence statement and a list of anything it was uncertain about while writing, a specific number it was not fully sure was in the source, a claim it inferred rather than found stated directly.
The Judge receives the draft and the original source side by side, never the draft in isolation. It checks three specific things, each with its own pass or fail. Does every factual claim in the draft trace back to something actually present in the source. Does the draft satisfy every specific requirement in the brief, length, tone, required sections. Is the core argument or hook actually present and undiluted by filler. The Judge returns a structured verdict with a pass or fail on each of the three checks separately, because collapsing this into one overall score hides exactly which dimension failed.
The Manager reads that structured verdict. A clean pass on all three sends the draft to a final output queue. A failure on the fact-checking dimension sends it back to the Builder with the specific unverified claim flagged directly, not a vague instruction to "double check accuracy." A failure on brief compliance sends it back with the specific missing requirement named. After three failed cycles on the same specific check, the Manager stops looping entirely and escalates to a human with the complete history of what was tried, rather than continuing to retry a problem the system has already demonstrated it cannot resolve on its own.
This is a small system. Three roles, one structured handoff format, one explicit stop condition. It is also a system you could genuinely run unattended and trust the output of, because every failure mode has a defined path instead of an undefined one.
## Testing The Loop Before You Trust It
Before you rely on any self-correcting system for something that actually matters, run it through these specific stress tests deliberately. Most loops that fail in real use would have failed one of these tests immediately, if anyone had bothered to check first.
The unsolvable task test. Deliberately give the Builder a task it cannot complete to the Judge's standard, on purpose. Does the Manager correctly hit the iteration ceiling and escalate to a human, or does it spin indefinitely, burning cost on a task that was never going to succeed.
The confidently wrong test. Feed the Judge an output you already know is subtly wrong, something that reads well but contains a specific factual or logical error. Does the Judge, with its ground truth reference, correctly catch it. If the Judge passes something you know is broken, your ground truth reference is not actually being checked, or the check is too shallow.
The same-model blind spot test. If your Builder and Judge run on the same underlying model, this is worth checking directly. Feed the Judge an output containing exactly the kind of mistake that model characteristically tends to make. If the Judge waves it through, you have built a loop that shares its blind spots between roles, which defeats the entire purpose of separating them. Consider using a genuinely different model, or at minimum a meaningfully different prompt framing, for the Judge role specifically.
The cost runaway test. Calculate the worst case path through your system, maximum revisions, most expensive model calls involved, longest reasonable content length, and work out what that actually costs in real dollars and real time. If that number would alarm you appearing on an actual invoice, your stop conditions are not tight enough yet.
Running these four tests before trusting a self-correcting loop with anything real catches the overwhelming majority of failures that would otherwise show up for the first time in front of a client, a boss, or your own bank statement.
## Common Mistakes That Quietly Break An Otherwise Good Design
Even with the right three-role architecture, a handful of specific implementation mistakes show up repeatedly across completely different domains, and knowing them in advance saves you from rediscovering each one the hard way.
Letting the Judge see only the Builder's output, with no independent reference. This is the single most common mistake, and it silently turns your system from a correctness check into a coherence check. A Judge with nothing to compare against can only tell you the output looks internally consistent, never whether it is actually right.
Giving every role the same model with only a thin instruction difference layered on top. If the Judge is running the exact same underlying model as the Builder, with just a different prompt telling it to "be critical," it often inherits the exact same blind spots the Builder has, because it is fundamentally the same reasoning process wearing a different hat. Where the budget allows, a genuinely different model for the Judge role produces real independence rather than theatrical independence.
Treating the Manager as a simple pass-through instead of giving it real memory of prior attempts. A Manager with no visibility into what was already tried on this specific task will happily send the same failed feedback back to the Builder a second and third time, producing the identical failed result each time, because nothing in the system remembers that this exact approach already failed once.
Skipping the four stress tests because the system worked fine in the one demo run everyone watched closely. A system that behaves correctly while you are watching it closely and a system that behaves correctly while running unattended are different claims. Only the second one is the actual point of building a self-correcting loop in the first place. If you have not tested the failure modes deliberately, you do not actually know which claim is true of your system yet.
Writing the stop condition as a soft instruction instead of hard logic. "Stop when it's good enough" inside a prompt is not a stop condition, it is a suggestion the model can and eventually will talk itself past under the right pressure. A hard iteration counter the Manager checks mechanically before allowing another cycle is a stop condition. The difference between these two matters enormously the first time a task turns out to be genuinely unsolvable.
## A Second Worked Example: Self-Correcting Code
The same skeleton looks different but follows identical logic when the task is code instead of content, and walking through both side by side makes clear how little actually changes between domains.
The Builder here is a coding agent working through a defined task, a bug fix, a feature, a refactor. Its structured output is not just the code diff, but the actual command output from attempting to run it, the test results, the lint output, the build status, bundled into the handoff. A Builder that produces code but never actually executes it is not really filling the Builder role correctly, because syntactically plausible code that fails its own test suite is worse than no code at all, since it looks finished without being finished.
The Judge checks three specific, verifiable things. Did the change pass the existing test suite without the tests themselves being modified, since a Builder quietly editing a test to make it pass is a specific and surprisingly common failure worth checking for directly. Did static analysis and linting come back clean. Does the diff actually address the task that was assigned, not a related but different problem the Builder decided was more interesting to solve along the way. Each of these gets its own explicit pass or fail in the structured verdict.
The Manager routes based on which specific check failed. A failing test suite goes back to the Builder with the exact failing test output attached directly, not a generic instruction to "fix the tests." A scope mismatch, where the diff solved a different problem than the one assigned, escalates immediately to a human rather than looping, because that is a judgment failure about what the task actually was, not a mechanical defect the Builder can simply iterate its way out of on its own.
Notice that the underlying skeleton here, Builder produces and submits with evidence, Judge checks against specific named criteria with a per-check verdict, Manager routes based on exactly which check failed, is identical to the content production example above. This is the actual lesson worth carrying forward from seeing two different domains side by side. Once you have the skeleton correct, applying it to a new kind of task is mostly a matter of writing a new, specific checklist for the Judge, not redesigning the entire architecture from first principles each time.
## Scaling To Multiple Concurrent Loops
Once a single self-correcting loop is genuinely reliable, the next real question is how to run several at once without the system becoming unmanageable, since this is exactly where most people's second attempt at scaling this up goes wrong.
The temptation is to spin up many loops simultaneously the moment the first one works, tackling five different tasks in parallel because the architecture technically supports it. Resist this longer than feels necessary. Each additional concurrent loop is another place where a stop condition can fail silently, another place where cost can run away unnoticed, another place where a Judge's ground truth reference might be subtly wrong in a way that only shows up under real volume rather than in a single test run.
The safer scaling path is sequential expansion with a genuine trust threshold at each step. Get one loop running reliably enough that you have stopped checking its output closely, meaning it consistently passes your own manual spot-checks over a real stretch of time, not just a single successful demo run. Only then add a second loop for a different task. Track each loop's actual failure rate over time, not just whether it appeared to work on the runs you happened to observe.
When you do run multiple loops concurrently, give serious thought to a shared cost dashboard across all of them, not per-loop tracking in isolation. A single loop with a reasonable per-task budget looks completely fine in isolation. Ten loops each individually within budget can still add up to a genuinely alarming total that nobody notices until the aggregate bill arrives, precisely because each individual loop's tracking looked fine on its own.
The single habit that prevents scaling problems before they start: log every stop condition trigger across every loop, not just the successful completions. A loop that hits its maximum iteration ceiling and escalates to a human is doing exactly what it is supposed to do, but if one specific loop is hitting that ceiling constantly while others rarely do, that is a signal the Judge's standard for that particular task is either miscalibrated, too strict to ever actually pass, or checking against the wrong ground truth entirely. That pattern is invisible if you are only tracking successes and treating every escalation as an isolated, unremarkable event rather than a data point about that specific loop's design.
## Where To Start This Week
Do not try to build a fully general self-correcting system on your first attempt. Pick one specific, narrow, well-defined task you already do regularly, something with a clear standard you could write down if asked, and build the three-role loop around that single task first.
Write the Judge's checklist down explicitly before you write a single line of the Builder's prompt. The standard you are checking against should shape what you ask the Builder to produce, not the other way around. If you cannot write the checklist yet, you do not yet know what "correct" means for this task well enough to automate checking it, and that is worth discovering before you build anything.
Run the four stress tests above before you trust the loop with anything that actually matters, not after something has already gone wrong in front of someone. Add the stop condition as real, hard logic from the very first version, not as an afterthought once you have already been burned by a runaway loop once.
Once one loop is genuinely reliable, running unattended, catching real mistakes, stopping cleanly when it should, the second one goes much faster. Not because the prompts transfer directly, they usually need to be rewritten for the new task, but because you already understand the actual shape of the problem. Separate the building from the judging. Give the judging something real to check against. Write the stop condition as logic, not hope.
That shape is the entire discipline. Everything else is just applying it to whatever task is in front of you.
Follow @cyrilXBT for the exact loop templates and Builder-Judge-Manager setups behind everything in this article.
## 相关链接
- [CyrilXBT](https://x.com/cyrilXBT)
- [@cyrilXBT](https://x.com/cyrilXBT)
- [239K](https://x.com/cyrilXBT/status/2077827005777588266/analytics)
- [@cyrilXBT](https://x.com/@cyrilXBT)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [2:45 AM · Jul 17, 2026](https://x.com/cyrilXBT/status/2077827005777588266)
- [239.7K Views](https://x.com/cyrilXBT/status/2077827005777588266/analytics)
- [View quotes](https://x.com/cyrilXBT/status/2077827005777588266/quotes)
---
*导出时间: 2026/7/18 13:41:52*
---
## 中文翻译
# 如何构建一个能在你发现问题之前自我纠错的 AI 循环
**作者**： CyrilXBT
**日期**： 2026-07-16T18:45:36.000Z
**来源**： [https://x.com/cyrilXBT/status/2077827005777588266](https://x.com/cyrilXBT/status/2077827005777588266)
---
有一个特定的时刻，能区分随口使用 AI 的人和真正把 AI 当作系统来运行的人。
那就是他们不再亲自去发现错误的时刻。
现在，对大多数人来说，这个循环是这样的：向 Claude 提出请求。阅读输出。发现有问题。指出来。得到一个修正版。再阅读。又发现别的问题。再指出来。你是那个验证层，每一次、每一个任务，都在手动执行。
自我纠错循环则让你完全脱离这个位置。系统生成结果，依据真实标准检查自己的工作，发现错误，修正它，然后才把结果展示给你。当你看到输出时，那些明显的错误已经被发现并处理了。留给你的，是对那些真正需要人类判断的事情做出判断，而不是给机器的初稿做校对。
这就是完整的构建方案。读完之后，你将掌握确切的架构、确切的提示词，以及在把重要任务托付给它之前需要测试的确切失败模式。
## 为什么这不等于“多问一次”
最直观的第一反应，就是在同一个对话中让模型检查自己的工作。“审阅你刚才写的内容，修正其中的错误。”这有点帮助，但它并不能构建一个真正的自我纠错循环，而理解其中的原因，正是后续所有内容的根本基础。
模型在同一个上下文中审阅自己的输出时，由于产生错误的正是同一套推理过程，它往往会为自己的成果辩护，而不是真正地审视它。这不是某个特定模型的缺陷，而是一个结构性问题。生成那个听起来合理但实际错误的同一遍处理，很难发现它有错，因为从内部看，这个答案依然听起来合理。问“你确定吗？”得到的更多是安抚，而不是真正的重新审视。
解决方法不是问得更好，而是架构。真正的自我纠错循环把“生成答案”和“评判答案”的工作分离开来，使用不同的处理过程、不同的提示词，最好采用完全不同的参照框架，这样评判过程就不会被制造出错误的那套盲点所污染。
## 每个自我纠错循环需要的三个角色
任何一个能正常运转的自我纠错系统，无论任务是什么，都可以归结为三个不同的角色。清晰理解这些角色，比下面任何具体的提示词都更重要，因为一旦看清了它们，你就能通过填入具体细节，为几乎任何任务构建一个循环。
构建者（Builder）。产出实际成果。编写代码、起草内容、做研究、执行任务。这个角色应该被赋予最大的创作自由度和最少的约束，因为它的职责是产出一个初步尝试，而不是完美的成品。
评判者（Judge）。不负责构建任何东西。它唯一的职责是依据一个具体的、成文的标准来评估构建者的输出，而不是凭模糊的质量感觉。代码是否通过了测试。草稿是否符合要求。研究是否真正回答了所提的问题。评判者最好能访问一些构建者无法访问的东西——原始素材、测试套件、实际需求文档——这样它就有了独立的基准真值可供核对，而不只是重读同一份输出然后形成一个新的看法。
管理者（Manager）。阅读评判者的裁决，并决定下一步做什么。带着具体的反馈把任务退回给构建者。升级给人类处理。标记任务完成。这里也是你的停止条件所在——即防止循环在无法自动修复时永远运行下去的规则。
贯穿这三个角色的关键设计原则是：验证必须引用构建者自身推理之外的东西。一个测试套件。一份原始文档。一份书面的检查清单。一次采用真正不同框架的 AI 调用。任何东西都可以，只要不是“同一个模型、在同样的语境下再问一遍”。
## 构建交接机制
自我纠错循环中真正的工程工作，不是为每个角色写巧妙的提示词，而是它们之间传递内容的结构。这正是大多数人第一次构建循环时完全跳过的部分，然后才纳闷为什么系统表现不可预测。
一个交接要可靠运作，需要具备三个属性。一个定义好的格式，这样接收方就不必解析松散的文字并猜测什么是重点。一个定义好的触发条件，这样决定任务何时完成的就不是构建者自己。还有一个定义好的失败路径，这样当某个环节没有顺利通过时，就有明确的下一步，而不是系统悄然中断或无限循环。
在实践中，这意味着构建者应该输出结构化的内容，而不只是对话式文本。一个清晰的交付成果，加上对它不确定之处的明确说明。然后评判者依据成文标准评估这份结构化输出，并返回它自己的结构化裁决——不是一段含糊其辞的文字，而是明确的通过、失败或需修改，并附上具体原因。管理者读取的是这份结构化裁决，而不是原始内容，并根据事先设定的规则来决定下一步行动，而不是临场即兴判断。
下面是一套适用于大多数任务的模板结构，无论底层工作是写作、代码还是研究：
构建者输出格式
交付物：[实际输出]
置信度：[高 / 中 / 低]
已知的不确定点：[明确陈述任何你不确定的内容]
所做的假设：[任何在未被告知的情况下做出的假设]
评审者裁决格式
裁决：[通过 / 不通过 / 需要修改]
对照标准：[使用的具体标准，例如原始需求说明、
测试套件、源文档]
发现的具体问题：[确切的问题，而非笼统的印象]
对本次裁决的置信度：[高 / 中 / 低]
管理者行动
如果通过：标记为完成，交付给用户。
如果不通过或需要修改：连同评审者发现的
具体问题一并退回给构建者。递增修订计数器。
如果修订计数器超过 [N]：停止循环，向人类上报，
并附上完整的尝试历史及失败原因。
```
这看起来比随意的来回对话有更多的结构，事实也确实如此。这笔前期投入换来的是一个在第百次运行时表现与第一次完全一致的系统，而不是随着上下文积累而不可预测地漂移。
## 评审者需要基准真相，而不仅仅是意见
这是整个系统中最重要的原则，值得单独用一节来讲，因为一旦做错，会悄悄地破坏其他所有环节。
一个只能看到构建者输出、没有独立参照物可供核对的评审者，只能评估内部一致性，即输出是否看起来连贯、格式良好。它无法评估正确性，即输出是否真正符合要求、是否真正解决了实际问题。一个自信却错误的答案，只要格式良好、内部一致，每次都能轻松通过一个没有基准真相的评审者。
对于编码任务，基准真相是测试套件、实际运行代码的输出、lint 结果、构建状态。不是“这段代码看起来对不对”，而是“实际执行时是否真的通过了”。
对于内容任务，基准真相是原始素材和原始需求说明，与草稿并排对照。不是“这篇读起来好不好”，而是“草稿中的每一个具体论断是否都能追溯到源材料中确实存在的内容，这篇作品是否真正满足需求说明中的每一项要求”。
对于研究任务，基准真相是研究本应依据的实际搜索结果和源文档。不是“这份摘要听起来是否权威”，而是“每一个论断是否都能追溯到具体来源，并且所搜索的来源是否确实是相关的来源”。
如果你无法明确说出针对你的具体任务，评审者的基准真相是什么，那你就还没有一个自我纠错的循环。你有的只是一个换个说法的循环，构建者的自信错误会被评审者自信地换个说法复述，而不是真正被抓住。
## 停止条件不是可选项
自我纠错循环变成一场昂贵失控的烂摊子，最常见的原因就是缺少一个明确的、硬性的停止条件。没有它，构建者和评审者可以无限循环，每次修订触发又一次评估，每次评估又触发又一次修订，成本不断攀升，直到账单送达才有人注意到。
一个真正的停止条件需要三个组成部分，且三者都应作为明确的逻辑加以执行，而不是留给模型在当时自行判断。
最大迭代次数。修订周期的硬性上限，超过之后，管理者必须向人类上报，无论评审者是否已经满意。
一个真正可衡量的、而非停留在愿望层面的质量阈值。“足够好”作为提示词中的一条指令，并不是一个停止条件，因为它只是一个建议，模型在适当的压力下可以并且终将无视它。一个具体的、可核验的标准——全部十一个测试用例通过，或草稿满足需求说明中明确列出的全部五项要求——才是停止条件，因为它可以被机械地验证，而不是每次都靠主观判断。
成本或时间上限。一项无论任务在进行到什么状态时都不允许超出的绝对预算。这道护栏专门保护你免受最坏情况的伤害——一个真正无法解决的任务不断循环，直到有人注意到那张发票。
停止条件
最大修订次数：3。在第 3 次不通过裁决时，停止并向人类上报，
附上完整的修订历史，不要自动尝试第 4 轮循环。
质量阈值：评审者清单上的所有条目都必须显示“通过”，
而不是“基本通过”或“差不多”。
预算上限：如果本任务已消耗超过 [X] 个 token 或
[Y] 分钟，无论当前状态如何，立即停止，
并报告已完成的内容与尚未完成的内容。
把这些写进管理者的实际逻辑中，而不是写在较长提示词里的一条软性指令中——那种指令模型在压力下会自己说服自己不去遵守。
## 一个实战示例：自我纠错的内容生产
为了让这一切更具体，下面准确展示这三个角色和停止条件如何在一个真实、常见的任务中结合起来——将一份源文档转化为成品内容，而无需人工校对每一版草稿。
构建者接收源材料和需求说明，并产出一份草稿。其输出包括草稿本身，外加一份明确的置信度声明，以及它在写作过程中不确定的所有事项的清单——某个它不完全确定是否出现在源材料中的具体数字，或某个它是推断出来而非直接找到明确陈述的论断。
裁判会同时收到草稿和原始素材，永远不会只收到孤立的草稿。它检查三个具体事项，每项都有各自的通过或不通过判定。草稿中的每个事实性陈述是否都能追溯到素材中实际存在的内容。草稿是否满足简报中的每项具体要求——篇幅、语气、必需的章节。核心论点或卖点是否确实存在且未被废话稀释。裁判返回一份结构化的判定结果，分别对三项检查给出通过或不通过，因为把这三项合并为一个总分，会掩盖究竟是哪个维度失败了。
管理者读取这份结构化判定。三项全部顺利通过，草稿就会被送入最终输出队列。事实核查维度失败，草稿会被退回给构建者，并直接标出具体的未经验证的陈述，而不是笼统地要求"再检查一下准确性"。简报合规性失败，退回时会点名具体缺失的要求。在同一项具体检查上连续失败三次后，管理者会完全停止循环，并附上完整的尝试历史上报给人类，而不是继续重试一个系统已证明自己无法解决的问题。
这是一个小系统。三个角色、一种结构化的交接格式、一个明确的停止条件。它同时也是一个你真正可以无人值守运行并信任其输出的系统，因为每种失败模式都有明确的处理路径，而不是无定义的。
## 在信任循环之前先测试它
在依赖任何自我纠错系统处理真正重要的事情之前，刻意让它通过这些特定的压力测试。大多数在真实使用中失败的循环，只要当初有人费心检查，本来都会立刻栽在其中一项测试上。
不可解决任务测试。故意给构建者一个它无法达到裁判标准的任务。管理者是否能正确达到迭代上限并上报给人类，还是无限空转，在一个注定不会成功的任务上烧钱。
自信但错误测试。给裁判输入一个你已知存在细微错误的输出——读起来不错但含有具体的事实或逻辑错误。拥有基准真值参照的裁判能否正确发现它。如果裁判放行了一个你明知有问题的东西，那说明你的基准真值参照实际上没有被检查，或者检查太浅。
同模型盲点测试。如果你的构建者和裁判运行在同一个底层模型上，这一点值得直接检验。给裁判输入一个恰好包含该模型特征性易犯错误的输出。如果裁判放行了，你就构建了一个在角色之间共享盲点的循环，这完全违背了分离角色的初衷。考虑为裁判角色使用一个真正不同的模型，或至少采用一个明显不同的提示词框架。
成本失控测试。计算出穿过系统的最坏情况路径——最多修订次数、涉及的最昂贵模型调用、最长合理内容长度——然后算出这在真实的金钱和时间上究竟要花多少。如果这个数字出现在实际账单上会让你心惊，那说明你的停止条件还不够严格。
在把任何真实任务交给自我纠错循环之前运行这四项测试，可以捕获绝大多数失败，否则这些失败会第一次就出现在客户、老板或你自己的银行对账单面前。
## 那些悄然毁掉原本良好设计的常见错误
即使拥有正确的三角色架构，一些具体的实现错误也会在完全不同的领域中反复出现，提前了解它们能让你免于用惨痛的方式逐一重新发现它们。
让裁判只看到构建者的输出，没有任何独立参照。这是最常见的错误，它会悄悄把你的系统从正确性检查变成连贯性检查。一个没有任何比较对象的裁判只能告诉你输出在内部看起来一致，永远无法告诉你它是否真的正确。
给每个角色使用相同的模型，只在上面叠一层微薄的指令差异。如果裁判运行的是与构建者完全相同的底层模型，只是用不同的提示词告诉它"要挑剔"，它往往会继承构建者拥有的完全相同的盲点，因为它本质上是同一个推理过程戴了顶不同的帽子。在预算允许的地方，为裁判角色使用一个真正不同的模型，才能产生真正的独立性，而非表演式的独立性。
把管理者当作简单的传声筒，而不给它对先前尝试的真实记忆。一个看不到这个具体任务上已经尝试过什么的管理者，会 happily 把同样的失败反馈第二次、第三次发回给构建者，每次都产生完全相同的失败结果，因为系统中没有任何东西记得这种方法已经失败过一次了。
仅仅因为系统在大家都盯着看的那一次演示中表现良好，就跳过四项压力测试。"在你密切注视时表现正确"和"在无人值守运行时表现正确"是两个不同的命题。只有第二个才是构建自我纠错循环的真正目的。如果你没有刻意测试过失败模式，你实际上还不知道你的系统符合哪个命题。
把停止条件写成软性指令而非硬性逻辑。提示词里写"足够好了就停下来"并不是停止条件，那只是一个建议——在适当的压力下，模型能够、并且最终会说服自己越过它。一个由 Manager 在允许进入下一轮循环前机械检查的硬性迭代计数器，才是真正的停止条件。这两种做法的区别，在第一次遇到真正无法解决的任务时会变得极其重要。
## 第二个工作实例：自纠错的代码
当任务从内容变成代码时，同样的骨架看起来不同，但遵循的逻辑完全一致。将两者并排走一遍，可以清楚地看到在不同领域之间实际变化的东西是多么少。
这里的 Builder 是一个处理明确任务的编码代理——修复一个 bug、实现一个功能、进行一次重构。它的结构化输出不仅是代码差异（diff），还包括尝试运行时的实际命令输出、测试结果、lint 输出、构建状态，全部打包在交接内容中。一个只产出代码却从不实际执行代码的 Builder，并没有真正履行好 Builder 的角色，因为语法上看似合理却无法通过自身测试套件的代码，比没有代码还要糟——它看起来完成了，实际上并没有完成。
Judge 检查三个具体的、可验证的事项。改动是否在测试套件本身未被修改的前提下通过了现有测试——因为 Builder 悄悄修改测试使其通过，是一种具体且出人意料地常见的失败模式，值得直接检查。静态分析和 lint 是否干净通过。diff 是否真的解决了被分配的任务，而不是 Builder 在过程中自行决定更有意思的某个相关但不同的问题。每一项检查都会在结构化裁决中得到明确的通过或不通过。
Manager 根据具体是哪项检查失败来路由。测试套件失败则返回给 Builder，并直接附上确切的失败测试输出，而不是一条笼统的"修复测试"的指令。范围不匹配——即 diff 解决的问题与被分配的问题不同——则立即升级给人类处理而不是循环，因为这是对任务实质的判断失误，而不是 Builder 可以靠自己迭代解决的机械性缺陷。
注意，这里的底层骨架——Builder 带着证据产出并提交、Judge 针对具体明确的检查项进行裁决并给出逐项结论、Manager 根据具体是哪项检查失败来路由——与上面的内容生产实例完全相同。这就是将两个不同领域并排观察后真正值得带走的经验。一旦骨架正确，将其应用到新类型的任务上，主要是为 Judge 编写一份新的、具体的检查清单，而不是每次都从第一性原理重新设计整个架构。
## 扩展到多个并发循环
一旦单个自纠错循环真正可靠，下一个真实的问题就是如何同时运行多个循环而不让系统变得难以管理——这恰恰是大多数人在第二次尝试扩展时出错的地方。
诱惑在于，一旦第一个循环跑通了，就立刻同时启动许多循环，并行处理五个不同的任务，因为架构在技术上支持这样做。请抵制这种冲动，比你觉得必要的再坚持久一点。每增加一个并发循环，就多了一个停止条件可能静默失效的地方，多了一个成本可能悄然失控的地方，多了一个 Judge 的真值参考可能存在细微错误的地方——这种错误只有在真实规模下才会暴露，而不是在单次测试运行中。
更安全的扩展路径是顺序扩展，并在每一步设置真正的信任门槛。先让一个循环运行得足够可靠，以至于你已经不再仔细检查它的输出——这意味着它在你真实的一段时间内持续通过你自己的手动抽查，而不仅仅是一次成功的演示运行。只有这样，才为另一个任务添加第二个循环。持续追踪每个循环随时间变化的实际失败率，而不仅仅是看它在恰好被观察到的那些运行中是否正常。
当你确实要并发运行多个循环时，认真考虑为所有循环建立一个共享的成本仪表板，而不是各循环孤立地追踪。单个循环在合理的单任务预算内看起来完全没问题。十个循环各自都在预算之内，累加起来仍然可能是一个真正惊人的总额，而没人会注意到，直到总账单到来——恰恰因为每个循环的单独追踪看起来都没问题。
有一个习惯能在扩展问题出现之前就将其预防：记录所有循环中每一次停止条件的触发，而不仅仅是成功的完成。一个达到最大迭代上限并升级给人类处理的循环，正是在做它应该做的事；但如果某个特定的循环不断触顶而其他循环很少如此，这就是一个信号，说明 Judge 针对该特定任务的标准要么校准失当、过于严格以至于永远无法真正通过，要么检验所依据的根本就是错误的真值。如果你只追踪成功，并把每次升级都当作孤立、不值得注意的事件而非关于该特定循环设计的数据点，那么这种模式将是不可见的。
## 本周从哪里开始
不要在第一次尝试时就去构建一个完全通用的自纠错系统。挑选一个你已经定期执行的、具体、狭窄、定义清晰的任务——一个如果被问到你能写下明确标准的事情——先围绕这一个任务构建三角色循环。
在写下构建者提示词的第一行之前，先把裁判者的检查清单明确写下来。你用来检查的标准应该决定你要求构建者产出什么，而不是反过来。如果你还写不出检查清单，那说明你对这个任务中“正确”的含义还不够了解，不足以将检查自动化，这一点值得在构建任何东西之前先弄清楚。
在你把循环托付给任何真正重要的事情之前，先运行上述四个压力测试，而不是等到当着别人的面出了问题之后再做。从第一个版本开始就把停止条件写成真实、严格的逻辑，而不是在被失控循环坑过一次之后才想起来补上。
一旦一个循环真正可靠——能够无人值守运行、捕捉真实的错误、在应该停止时干净利落地停下来——第二个循环就会快得多。不是因为提示词可以直接照搬（它们通常需要为新任务重写），而是因为你已经理解了这个问题的真实形态。把构建和评判分开。给评判一个真实的检查依据。把停止条件写成逻辑，而不是希望。
这个形态就是整门纪律的全部。其余的一切只是把它应用到你面前的任何任务上。
关注 @cyrilXBT，获取本文所有内容背后的确切循环模板和“构建者-裁判者-管理者”设置。
## 相关链接
- [CyrilXBT](https://x.com/cyrilXBT)
- [@cyrilXBT](https://x.com/cyrilXBT)
- [239K](https://x.com/cyrilXBT/status/2077827005777588266/analytics)
- [@cyrilXBT](https://x.com/@cyrilXBT)
- [升级至高级版](https://x.com/i/premium_sign_up)
- [2026年7月17日 凌晨2:45](https://x.com/cyrilXBT/status/2077827005777588266)
- [239.7K 次浏览](https://x.com/cyrilXBT/status/2077827005777588266/analytics)
- [查看引用](https://x.com/cyrilXBT/status/2077827005777588266/quotes)
---
*导出时间： 2026/7/18 13:41:52*
