# 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 的人与真正将其作为系统运行的人区分开来。
那就是他们不再充当发现错误者的时刻。
目前，对大多数人来说，循环是这样的：向 Claude 提出要求。阅读输出。发现有问题。指出来。获得修正后的版本。阅读那个版本。发现其他问题。再次指出来。你是验证层，手动地，每一次，针对每一项任务。
自我修正循环将你完全从那个位置移除。系统生成内容，对照真实标准检查自己的工作，捕捉错误，修复错误，然后才向你展示结果。当你看到输出时，明显的错误已经被捕获并处理了。留给你的任务是对真正需要人类判断的事情进行裁决，而不是校对机器的初稿。
这是完整的构建过程。到最后，你将拥有确切的架构、确切的提示词，以及在将其用于任何重要事情之前需要测试的确切失败模式。
## 为什么这与仅仅要求两次不同
显而易见的第一直觉是直接让模型在同一个对话中检查它自己的工作。“审查你刚才写的内容并修正任何错误。”这有一点帮助。但它并不能构建一个真正的自我修正循环，而理解为什么是随后一切的基础。
在相同的上下文中，用产生错误的相同推理来审查自己输出的模型，往往会维护自己的工作，而不是真正地审查它。这不是任何特定模型独有的缺陷。这是一个结构性问题。生成一个听起来合理但错误的答案的那一次传递，并没有处于能很好地发现它是错误的位置，因为从内部来看，答案听起来仍然是合理的。询问“你确定吗？”通常产生的是安抚，而不是真正的重新审视。
解决方法不是问得更好。而是架构。一个真正的自我修正循环将生成答案的工作与判断答案的工作分离开来，使用不同的传递、不同的提示词，理想情况下使用完全不同的参考框架，这样判断就不会被产生错误的相同盲点所污染。
## 每个自我修正循环都需要的三种角色
每一个可运行的自我修正系统，无论具体任务是什么，都归结为三个不同的角色。清楚地理解这些角色比下面任何具体的提示词都重要，因为一旦你看到了它们，你就可以通过填充细节为几乎任何任务构建一个循环。
构建者。生成实际的输出。编写代码、起草内容、进行研究、执行任务。这个角色应该被给予最大的创作自由和最少的约束，因为它的工作是产生第一次尝试，而不是完美的尝试。
评判者。不构建任何东西。它唯一的工作是根据具体的、书面标准来评估构建者的输出，而不是一种模糊的质量感。代码是否通过了测试。草稿是否符合简报。研究是否真正回答了所问的问题。评判者理想情况下应该能够访问构建者无法访问的东西——原始源材料、测试套件、实际需求文档——这样它就有独立的“基本事实”可供检查，而不是仅仅重读相同的输出并形成一个新的观点。
管理者。阅读评判者的裁决并决定接下来发生什么。将其连同具体反馈一起发回给构建者。升级给人类。将任务标记为完成。这也是你的停止条件所在，即当某些事情实际上无法自动修复时，防止循环永远运行的规则。
贯穿所有三个角色的关键设计原则：验证需要引用构建者自身推理之外的东西。一个测试套件。一个原始源文档。一个书面的检查清单。第二次具有真正不同框架的 AI 调用。任何不是仅仅“同一个模型，在同一个呼吸中再次被询问”的东西。
## 构建交接机制
自我修正循环中实际的工程工作不是为每个角色编写巧妙的提示词。而是它们之间传递内容的结构，这也是大多数构建第一个循环的人完全跳过的部分，然后他们就会奇怪为什么系统的行为不可预测。
一个交接机制需要三个属性才能可靠地工作。一个定义的格式，这样接收角色就不必解析松散的散文并猜测什么是重要的。一个定义的触发器，这样构建者就不是决定何时完成的人。一个定义的失败路径，这样当事情没有顺利进行时，有一个指定的下一步，而不是系统悄无声息地崩溃或永远循环。
在实践中，这意味着构建者应该输出结构化的内容，而不仅仅是对话文本。一个明确的交付物加上一个明确的关于它不确定什么的陈述。然后评判者根据书面标准评估该结构化输出，并返回它自己的结构化裁决，而不是一段含糊其辞的散文，而是一个明确的通过、失败或需要修订，并附上具体原因。管理者读取该结构化裁决，而不是原始内容，并根据预先建立的规则决定下一步行动，而不是在那一刻即兴做出判断。
这是一个适用于大多数任务的模板结构，无论底层工作是写作、代码还是研究：
```
构建者输出格式
交付物：[实际输出]
置信度：[高 / 中 / 低]
已知的不确定性：[任何你不确定的事情，明确陈述]
做出的假设：[任何你在没有被告知的情况下假设的事情]
评判者裁决格式
裁决：[通过 / 失败 / 需要修订]
检查依据：[使用的具体标准，例如原始简报、测试套件、源文档]
发现的具体问题：[确切的问题，而不是总体印象]
对该裁决的置信度：[高 / 中 / 低]
管理者行动
如果通过：标记完成，交付给用户。
如果失败或需要修订：连同评判者的具体问题一起发回给构建者。增加修订计数器。
如果修订计数器超过 [N]：停止循环，连同完整的尝试历史以及失败原因一起升级给人类。
```
这看起来比随意的来回对话有更多的结构，确实如此。这种前期成本换来的是一个在第一百次运行时与第一次运行时表现相同的系统，而不是随着上下文的积累而不可预测地漂移。
## 评判者需要基本事实，而不仅仅是一个观点
这是整个系统中最重要的原则，它值得拥有自己的章节，因为弄错它会悄悄地破坏其他一切。
一个只看到构建者输出而没有独立参考可供检查的评判者，只能评估内部一致性，即输出是否连贯且格式良好。它无法评估正确性，即输出是否真正符合要求或真正解决了实际问题。一个自信的错误答案，格式良好且内部一致，每次都能骗过一个没有基本事实的评判者。
对于编码任务，基本事实是测试套件、运行代码的实际输出、Lint 结果、构建状态。不是“这段代码看起来对吗”，而是“它执行时真的通过了吗”。
对于内容任务，基本事实是原始源材料和原始简报，与草稿并排对照。不是“这读起来好吗”，而是“草稿中的每一个具体主张都能追溯到源材料中实际存在的东西吗，并且该作品是否真正满足了简报中的每一项要求”。
对于研究任务，基本事实是研究本应基于的实际搜索结果和源文档。不是“这个摘要听起来权威吗”，而是“每一个主张都能追溯到特定的来源吗，并且搜索到的来源实际上是相关的吗”。
如果你不能清楚地说明评判者针对你的特定任务的基本事实是什么，你就还没有一个自我修正循环。你有一个改写循环，其中构建者的自信错误被评判者自信地改写了，而不是真正被捕获。
## 停止条件不是可选项
自我修正循环变得昂贵且失控的最常见方式是缺少一个明确的、硬性停止条件。如果没有它，构建者和评判者可以无限循环，每次修订触发另一次评估，每次评估触发另一次修订，而成本不断攀升，直到账单到来之前没人注意到。
一个真正的停止条件需要三个组成部分，并且所有这三个都应该作为明确的逻辑强制执行，而不是留给模型在那一刻进行判断。
最大迭代次数。修订循环的硬性上限，之后管理者无论评判者是否满意都必须升级给人类。
一个实际上可测量的质量门槛，而不是抱负性的。提示词中作为指令的“足够好”不是一个停止条件，因为它是模型在适当的压力下可以并且最终会忽略的建议。一个具体的、可检查的标准，所有十一个测试用例都通过，或者草稿符合简报中陈述的所有五项要求，是一个停止条件，因为它可以机械地验证，而不是每次都主观判断。
成本或时间上限。任务无论如何不能超过的绝对预算，无论当达到该上限时任务处于什么状态。这是一个护栏，专门保护你免受最坏情况的影响，即一个真正无法解决的任务一直循环，直到有人注意到发票。
停止条件
最大修订次数：3。在第 3 次失败的裁决时，停止并连同完整的修订历史一起升级给人类，不要自动尝试第 4 次循环。
质量门槛：评判者检查清单上的所有项目必须显示通过，而不是“大部分通过”或“足够接近”。
预算上限：如果此任务消耗了超过 [X] 个 Token 或 [Y] 分钟，无论当前状态如何立即停止，并报告已完成的内容与剩余的内容。
将这些写入管理者的实际逻辑中，而不是写入长提示词中的一个软指令中，因为模型在压力下可能会说服自己忽略那个指令。
## 一个实际案例：自我修正的内容生产
为了具体说明，这里确切说明了三种角色和停止条件如何结合在一起处理一个真实、常见的任务，即将源文档转变为成品内容，而无需人类手动校对每一份草稿。
构建者接收源材料和简报，并生成一份草稿。它的输出包括草稿本身，加上一个明确的置信度陈述和它在写作时不确定的任何事情的列表，一个它不完全确定在源材料中的具体数字，一个它是推断出来的而不是直接发现的主张。
评判者接收草稿和原始源材料并排对照，绝不是孤立地接收草稿。它检查三件具体的事情，每一件都有自己的通过或失败。草稿中的每一个事实主张是否都能追溯到源材料中实际存在的东西。草稿是否满足简报中的每一项具体要求、长度、语气、所需章节。核心论点或钩子是否真正存在且未被填充物稀释。评判者返回一个结构化裁决，对三个检查中的每一个分别通过或失败，因为将其折叠为一个总分掩盖了究竟是哪个维度失败了。
管理者读取该结构化裁决。在所有三个检查上全部通过会将草稿发送到最终输出队列。事实检查维度的失败会将其连同具体未验证的主张一起发回给构建者，而不是一个模糊的“再次检查准确性”的指令。简报合规性的失败会连同具体缺失的要求的名称一起发回。在同一个具体检查上失败三次循环后，管理者完全停止循环，并将完整的尝试历史连同尝试的内容一起升级给人类，而不是继续重试系统已经证明它自己无法解决的问题。
这是一个小系统。三个角色，一种结构化交接格式，一个明确的停止条件。这也是一个你可以真正无人值守运行并信任其输出的系统，因为每一个失败模式都有一个定义的路径，而不是未定义的路径。
## 在你信任它之前测试循环
在你将任何自我修正系统用于真正重要的事情之前，故意让它通过这些特定的压力测试。大多数在实际使用中失败的循环，如果有人费心先检查一下，就会立即在这些测试中失败一个。
无法解决的任务测试。故意给构建者一个它无法达到评判者标准的任务。管理者是正确地达到迭代上限并升级给人类，还是无限期地空转，在一个永远不会成功的任务上烧钱。
自信的错误测试。给评判者输入一个你已经知道存在微妙错误的输出，一些读起来很好但包含具体事实或逻辑错误的东西。评判者，凭借其基本事实参考，是否正确地捕获了它。如果评判者通过了一个你知道是坏掉的东西，那么你的基本事实参考实际上没有被检查，或者检查太浅了。
同模型盲点测试。如果你的构建者和评判者在同一个底层模型上运行，这值得直接检查。给评判者输入一个包含该模型特征性地容易犯的那种错误的输出。如果评判者让它通过，你就构建了一个在角色之间共享盲点的循环，这违背了将它们分离的整个目的。考虑为评判者角色使用一个真正不同的模型，或者至少是一个有意义的不同的提示词框架。
成本失控测试。计算通过你的系统的最坏情况路径，最大修订次数，涉及的最昂贵的模型调用，最长的合理内容长度，并计算出这在实际美元和实际时间中实际花费多少。如果这个数字出现在真正的发票上会让你惊慌，那么你的停止条件还不够紧。
在信任自我修正循环处理任何真实的事情之前运行这四个测试，可以捕获绝大多数原本会在客户、老板或你自己的银行报表面前首次出现的失败。
## 悄悄破坏原本良好设计的常见错误
即使有了正确的三种角色架构，一小部分特定的实现错误在完全不同的领域反复出现，提前了解它们可以让你避免自己重新通过艰难的方式发现每一个。
让评判者只看到构建者的输出，而没有独立的参考。这是最常见的一个错误，它悄无声息地将你的系统从正确性检查变成了连贯性检查。一个没有什么可以比较的评判者只能告诉你输出看起来内部一致，永远无法告诉你它是否真的是对的。
给每个角色相同的模型，只在上面叠加一层微薄的指令差异。如果评判者运行与构建者完全相同的底层模型，只是有一个不同的提示词告诉它“要挑剔”，它往往会继承构建者拥有的完全相同的盲点，因为它从根本上说是戴着不同帽子的相同推理过程。在预算允许的情况下，为评判者角色使用一个真正不同的模型会产生真正的独立性，而不是戏剧性的独立性。
将管理者视为一个