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