有一個特定的時刻，能區分出誰只是隨意使用 AI，誰是真的把它當作一個系統在運行。
這個時刻，就是他們不再需要自己來抓錯誤的時候。
現在，對多數人來說，流程是這樣的：向 Claude 要求某個東西。讀取輸出。發現有問題。指出來。得到修正版。再讀一遍。又發現別的問題。再次指出。你永遠是那個驗證層，手動、每次、每個任務都是如此。
一個自我修正的迴圈，則能完全將你從這個位置抽離。系統會自動生成、根據真實標準檢查自己的成果、抓出錯誤、修正它，然後才把結果呈現給你。當你看到輸出時，那些明顯的錯誤已經被處理掉了。你只需要判斷那些真正需要人類介入的事項，而不是去校對機器的第一版草稿。
這就是完整的建構方式。讀完這篇文章，你將擁有確切的架構、確切的提示詞，以及在你信任這個系統處理任何重要事情之前，需要測試的具體失敗模式。
為什麼這不只是「多問一次」那麼簡單
最直覺的反應，就是在同一個對話中叫模型自己檢查一次。「看看你剛寫的，修正任何錯誤。」這多少有點幫助，但並不能建立一個真正的自我修正迴圈。理解為什麼，是接下來所有內容的基礎。
一個模型在同一個脈絡、使用導致錯誤的同一套推理來檢查自己的輸出，往往會傾向於捍衛自己的成果，而不是真正去審視它。這不是某個特定模型的缺陷，而是結構性的問題。產生出一個聽起來合理但實則錯誤答案的那個過程，本身就很難察覺到這個答案是錯的，因為從內部來看，這個答案聽起來仍然合理。問它「你確定嗎？」得到的往往是「確定」，而不是真正的重新審視。
解法不是問得更好，而是架構。一個真正的自我修正迴圈，會把「產生答案」和「判斷答案」的工作分開，使用不同的階段、不同的提示詞，理想情況下甚至用完全不同的參考框架，這樣判斷就不會被產生錯誤時相同的盲點所污染。
每個自我修正迴圈都需要這三個角色
每個有效的自我修正系統，無論具體任務是什麼，都可以歸結為三個不同的角色。清楚理解這三個角色，比任何特定的提示詞都更重要，因為一旦你掌握了它們，你就能為幾乎任何任務建立迴圈，只需要填入具體細節。
建構者 (Builder)：負責產出實際的輸出。寫程式碼、起草內容、做研究、執行任務。這個角色應該被賦予最大的創造空間和最少限制，因為它的工作是產出一個初步嘗試，而不是完美的成品。
裁判 (Judge)：不負責建構任何東西。它唯一的工作就是根據一個具體的、書面化的標準（而不是模糊的品質感）來評估建構者的輸出。程式碼是否通過測試？草稿是否符合簡報？研究是否真的回答了被問的問題？裁判最好能取得建構者沒有的東西——原始來源材料、測試套件、實際的需求文件——這樣它才有獨立的「事實基準」可以檢查，而不是僅僅重讀同一份輸出然後形成新的看法。
管理者 (Manager)：讀取裁判的裁決，並決定下一步。送回建構者並附上具體回饋。上報給人類。標記任務完成。這也是你的停止條件所在——那個防止迴圈在無法自動修復的事情上永遠跑下去的規則。
貫穿這三個角色的關鍵設計原則是：驗證需要參考建構者自身推理之外的東西。一個測試套件。一份原始來源文件。一份書面檢查清單。一個具有真正不同框架的第二個 AI 呼叫。任何不是「同一個模型，在同一個呼吸中再問一次」的東西。
建立交接機制
自我修正迴圈中真正的工程工作，不是為每個角色設計巧妙的提示詞，而是它們之間傳遞的結構。而這正是大多數人建立第一個迴圈時完全跳過的部分，然後他們就會奇怪為什麼系統的行為如此不可預測。
一個交接要可靠運作，需要三個屬性。一個定義好的格式，這樣接收角色就不需要解析鬆散的散文並猜測什麼是重要的。一個定義好的觸發條件，這樣建構者就不會自己決定何時完成。以及一個定義好的失敗路徑，這樣當事情不順利時，有一個指定的下一步，而不是系統默默地壞掉或永遠迴圈。
實際上，這意味著建構者的輸出應該是結構化的，而不僅僅是對話文字。一個清晰的交付物，加上明確說明它不確定的部分。然後裁判根據一個書面標準來評估這個結構化輸出，並返回自己的結構化裁決——不是一段含糊其辭的散文，而是一個明確的「通過」、「失敗」或「需要修改」，並附上具體原因。管理者讀取這個結構化裁決（而不是原始內容），並根據事先建立的規則決定下一步行動，而不是臨場即興判斷。
以下是一個適用於大多數任務的模板結構，無論底層工作是寫作、程式碼還是研究：
1建構者輸出格式2交付物：[實際輸出]3信心指數：[高 / 中 / 低]4已知不確定性：[任何你不確定的部分，明確說明]5做出的假設：[任何你在未被告知的情況下假設的事情]67裁判裁決格式8裁決：[通過 / 失敗 / 需要修改]9檢查基準：[使用的具體標準，例如原始簡報、測試套件、來源文件]10發現的具體問題：[確切的問題，不是籠統的印象]11對此裁決的信心指數：[高 / 中 / 低]1213管理者行動14如果「通過」：標記完成，交付給使用者。15如果「失敗」或「需要修改」：送回建構者，附上裁判的具體問題。增加修訂計數器。16如果修訂計數器超過 [N]：停止迴圈，上報給人類，附上完整的嘗試歷史和失敗原因。
這看起來比隨意的來回對話需要更多結構，確實如此。但這個前期投入換來的是：一個系統在第一百次運行時，行為和第一次一模一樣，而不是隨著上下文累積而不可預測地漂移。
裁判需要事實基準，而不只是意見
這是整個系統中最重要的單一原則，值得用一個獨立章節來討論，因為一旦搞錯，它會默默破壞所有其他部分。
一個只看到建構者輸出、沒有獨立參考點可以檢查的裁判，只能評估內部一致性——輸出是否看起來連貫、格式是否良好。它無法評估正確性——輸出是否真的符合要求、是否真的解決了實際問題。一個自信但錯誤的答案，如果格式良好、內部一致，就會在沒有事實基準的裁判面前輕鬆過關。
對於程式碼任務，事實基準是測試套件、實際運行程式碼的輸出、lint 結果、建置狀態。不是「這段程式碼看起來對不對」，而是「它實際執行時是否通過」。
對於內容任務，事實基準是原始來源材料和原始簡報，與草稿並列。不是「這篇文章讀起來順不順」，而是「草稿中的每個具體說法，是否都能追溯到來源中的實際內容，以及這篇文章是否滿足簡報中的每一項要求」。
對於研究任務，事實基準是研究應該基於的實際搜尋結果和來源文件。不是「這個摘要聽起來有沒有權威感」，而是「每個說法能否追溯到特定來源，以及搜尋的來源是否真的是相關的」。
如果你無法為你的特定任務說明裁判的事實基準是什麼，那麼你還沒有真正擁有自我修正迴圈。你只有一個改寫迴圈，建構者自信的錯誤會被裁判自信地改寫，而不是被真正抓出來。
停止條件不是可有可無的
自我修正迴圈變成昂貴且失控混亂的最常見原因，就是缺乏明確、硬性的停止條件。沒有的話，建構者和裁判可以無限循環，每次修改都觸發一次評估，每次評估再觸發一次修改，成本不斷攀升，直到帳單送來才有人注意到。
一個真正的停止條件需要三個組成部分，而且這三個部分都應該作為明確的邏輯來執行，而不是留給模型在當下判斷。
一個最大迭代次數。修訂循環的硬性上限，超過後管理者必須強制上報給人類，無論裁判是否滿意。
一個確實可衡量的品質門檻，而不是理想化的。提示詞中的「夠好了」不是停止條件，因為它只是一個建議，模型在適當壓力下最終會忽略它。一個具體的、可檢查的門檻——所有 11 個測試案例都通過，或者草稿符合所有 5 個陳述的簡報要求——才是停止條件，因為它可以機械地驗證，而不是每次主觀判斷。
一個成本或時間上限。一個絕對的預算，任務無論處於什麼狀態都不能超過。這是你針對最壞情況的保護欄：一個真正無法解決的任務，直到有人注意到帳單才停止迴圈。
停止條件
最大修訂次數：3。在第 3 次失敗裁決時，停止並上報給人類，附上完整的修訂歷史，不要自動嘗試第 4 次循環。
品質門檻：裁判檢查清單上的所有項目都必須顯示「通過」，而不是「大致通過」或「差不多」。
預算上限：如果此任務已消耗超過 [X] 個 token 或 [Y] 分鐘，立即停止，無論當前狀態如何，並報告已完成和未完成的內容。
將這些寫入管理者的實際邏輯中，而不是寫在一個更長的提示詞中的軟性指令中，以免模型在壓力下說服自己繞過去。
實例：自我修正的內容產出
為了更具體，這裡展示三個角色和停止條件如何針對一個真實、常見的任務結合在一起：將一份來源文件轉換為完成的內容，而無需人類手動校對每份草稿。
建構者接收來源材料和簡報，產出草稿。它的輸出包括草稿本身，加上明確的信心陳述，以及它在寫作過程中不確定的所有事項——一個它不完全確定是否在來源中的具體數字，一個它推斷而非直接找到的陳述。
裁判同時接收草稿和原始來源，絕不單獨看草稿。它檢查三項具體事項，每一項都有各自的通過或失敗。草稿中的每個事實陳述是否都能追溯到來源中實際存在的內容。草稿是否滿足簡報中的每項具體要求——長度、語氣、所需章節。核心論點或鉤子是否確實存在且未被廢話稀釋。裁判返回一個結構化裁決，對三項檢查分別給出通過或失敗，因為將所有項目合併為一個總分會隱藏具體是哪個維度失敗了。
管理者讀取這個結構化裁決。三項都通過，則將草稿送入最終輸出佇列。事實查核維度失敗，則送回建構者，並直接標記出未經驗證的具體陳述，而不是模糊的指令「再檢查一下準確性」。簡報合規性失敗，則送回建構者，並具體指出缺少哪個要求。如果同一項檢查連續失敗三次，管理者將完全停止迴圈，並將完整的嘗試歷史上報給人類，而不是繼續重試這個系統已經證明無法自行解決的問題。
這是一個小系統。三個角色，一個結構化的交接格式，一個明確的停止條件。但也是一個你可以真正無人值守運行並信任其輸出的系統，因為每個失敗模式都有定義好的路徑，而不是未定義的。
在信任之前測試迴圈
在你依賴任何自我修正系統處理真正重要的事情之前，刻意對它進行以下這些特定的壓力測試。大多數在實際使用中失敗的迴圈，如果有人在之前檢查過，就會立即在這些測試中的某一個上失敗。
無法解決的任務測試。刻意給建構者一個它無法達到裁判標準的任務。管理者是否正確地達到迭代上限並上報給人類？還是它會無限旋轉，在一個永遠不會成功的任務上浪費成本？
自信但錯誤的測試。給裁判一個你已知有微妙錯誤的輸出——讀起來很順但包含特定事實或邏輯錯誤。裁判是否在擁有事實基準的情況下正確地抓住它？如果裁判放過了你已知有問題的內容，那麼你的事實基準要麼沒有被真正檢查，要麼檢查太淺。
同模型盲點測試。如果你的建構者和裁判運行在同一個底層模型上，這值得直接檢查。給裁判一個包含該模型典型錯誤的輸出。如果裁判放過了它，那麼你就建立了一個在角色之間共享盲點的迴圈，這完全違背了分離角色的目的。考慮為裁判角色使用一個真正不同的模型，或者至少使用一個意義上不同的提示框架。
成本失控測試。計算你的系統中最壞情況的路徑：最大修訂次數、最昂貴的模型呼叫、最長的合理內容長度，然後算出這在實際美元和時間上到底花費多少。如果這個數字出現在實際帳單上會讓你警覺，那麼你的停止條件還不夠嚴格。
在信任一個自我修正迴圈處理任何真實事物之前，運行這四個測試，可以捕捉到絕大多數的失敗——否則這些失敗會第一次出現在客戶、老闆或你的銀行對帳單面前。
常見錯誤：會悄悄破壞一個原本良好設計的陷阱
即使有了正確的三角色架構，一些具體的實現錯誤會在不同領域中反覆出現。提前了解它們，可以避免你用艱難的方式重新發現每一個。
讓裁判只看建構者的輸出，沒有獨立參考。這是最常見的單一錯誤，它會悄悄將你的系統從正確性檢查變成連貫性檢查。一個沒有東西可以比較的裁判，只能告訴你輸出看起來內部一致，永遠無法判斷它是否正確。
給每個角色同一個模型，只在上面疊加一個薄薄的指令差異。如果裁判運行的是與建構者完全相同的底層模型，只是用一個不同的提示詞告訴它「要批判」，它通常會繼承建構者完全相同的盲點，因為它本質上是同一個推理過程戴著不同的帽子。在預算允許的情況下，為裁判角色使用一個真正不同的模型，可以產生真正的獨立性，而不是表演性的獨立性。
把管理者當作簡單的傳遞者，而不是給它對先前嘗試的真實記憶。一個管理者對這個特定任務已經嘗試過什麼沒有能見度，就會樂意將相同的失敗回饋第二次、第三次發送給建構者，每次產生相同的失敗結果，因為系統中沒有任何東西記得這個確切的方法已經失敗過一次。
跳過四個壓力測試，因為系統在大家密切關注的一次演示中運作良好。一個在你密切關注時行為正確的系統，和一個在無人值守時行為正確的系統，是兩種不同的主張。只有後者才是建立自我修正迴圈的根本目的。如果你沒有刻意測試失敗模式，你就不知道你的系統實際上屬於哪一種。
將停止條件寫成軟性指令而不是硬性邏輯。提示詞中的「當它夠好時就停止」不是停止條件，而是一個建議，模型在適當壓力下最終會說服自己繞過去。管理者在允許另一個循環之前機械檢查的硬性迭代計數器，才是停止條件。這兩者之間的差異，在第一次遇到一個真正無法解決的任務時，會產生巨大的影響。
第二個實例：自我修正的程式碼
同樣的骨架在任務是程式碼而不是內容時看起來不同，但遵循相同的邏輯。並排來看這兩個例子，可以清楚看出領域之間實際上改變了多少。
這裡的建構者是一個編碼代理，負責處理一個定義好的任務——一個 bug 修復、一個功能、一個重構。它的結構化輸出不僅是程式碼 diff，還包括實際嘗試運行它的命令輸出、測試結果、lint 輸出、建置狀態，全部打包進交接中。一個產生程式碼但從未實際執行它的建構者，並沒有真正正確地履行建構者角色，因為語法上看似合理的程式碼如果無法通過自己的測試套件，比沒有程式碼更糟——它看起來完成但實際上未完成。
裁判檢查三項具體、可驗證的事項。此更改是否通過了現有測試套件，且測試本身未被修改（因為建構者悄悄修改測試以使其通過，是一個具體且令人驚訝地常見的失敗，值得直接檢查）。靜態分析和 linting 是否乾淨。diff 是否確實解決了分配的任務，而不是建構者決定在過程中解決的相關但不同的問題。每一項都會在結構化裁決中獲得自己的明確通過或失敗。
管理者根據哪個具體檢查失敗來路由。測試套件失敗，則送回建構者，並直接附上失敗的測試輸出，而不是泛泛的指令「修復測試」。範圍不匹配——diff 解決了與分配任務不同的問題——則立即上報給人類，而不是迴圈，因為這是關於任務實際是什麼的判斷失敗，而不是建構者可以單純通過迭代自行解決的機械缺陷。
請注意，這裡的底層骨架——建構者產出並提交證據，裁判根據特定命名標準檢查並給出逐項裁決，管理者根據確切失敗的項目路由——與上面的內容產出範例完全相同。這才是從並排看到兩個不同領域中值得帶走的實際教訓。一旦你有了正確的骨架，將其應用於新型任務，主要就是為裁判寫一個新的、具體的檢查清單，而不是每次都從頭開始重新設計整個架構。
擴展到多個並發迴圈
一旦一個單一的自我修正迴圈真正可靠，下一個實際問題就是如何同時運行多個迴圈，而不讓系統變得難以管理，因為這正是大多數人在第二次嘗試擴展時出錯的地方。
當第一個迴圈成功時，誘惑是立即啟動多個迴圈，同時處理五個不同的任務，因為架構在技術上支援這樣做。但請堅持比感覺需要的時間更長。每個額外的並發迴圈，都是一個停止條件可能默默失敗的地方，另一個成本可能不知不覺失控的地方，另一個裁判的事實基準可能微妙地錯誤的地方——這種錯誤只會在真實量級下顯現，而不是在單次測試運行中。
更安全的擴展路徑是循序漸進，每一步都有一個真正的信任門檻。讓一個迴圈運作得足夠可靠，以至於你已經不再密切檢查它的輸出——也就是說，它在真實的一段時間內持續通過你自己的手動抽查，而不僅僅是一次成功的示範運行。然後才為一個不同的任務添加第二個迴圈。追蹤每個迴圈隨時間的實際失敗率，而不僅僅是它在你恰好觀察到的運行中看起來是否有效。
當你確實同時運行多個迴圈時，認真考慮一個跨所有迴圈的共享成本儀表板，而不是單獨追蹤每個迴圈。一個單獨的迴圈，每個任務預算合理，單獨看完全沒問題。十個各自在預算內的迴圈，加起來仍然可能達到一個真正令人震驚的總數，而沒有人注意到，直到總帳單送來——正是因為每個單獨迴圈的追蹤看起來都沒問題。
一個可以在問題開始之前防止擴展問題的習慣：記錄每個迴圈中每個停止條件的觸發，而不僅僅是成功完成。一個達到最大迭代次數並上報給人類的迴圈，正在做它應該做的事情。但如果一個特定迴圈不斷達到這個上限，而其他迴圈很少這樣，這就表示該特定任務的裁判標準要麼校準錯誤，要麼太嚴格以至於永遠無法通過，要麼是在檢查完全錯誤的事實基準。如果你只追蹤成功，並將每次上報視為一個孤立、不起眼的事件，而不是關於該特定迴圈設計的數據點，那麼這個模式就是隱形的。
本週從哪裡開始
不要試圖在第一次嘗試時就建立一個完全通用的自我修正系統。選擇一個你已經經常做的、具體、狹窄、定義明確的任務——一個有明確標準、如果被問到你可以寫下來的任務——然後首先圍繞這個單一任務建立三個角色的迴圈。
在為建構者寫下任何一行提示詞之前，先明確寫下裁判的檢查清單。你用來檢查的標準，應該反過來塑造你要求建構者產出的東西，而不是反過來。如果你還無法寫出檢查清單，那麼你還不夠清楚這個任務的「正確」是什麼意思，以至於無法自動化檢查它——這值得你在建立任何東西之前先發現。
在你信任這個迴圈處理任何真正重要的事情之前，先運行上面的四個壓力測試，而不是等到事情已經在某人面前出錯之後才做。從第一版開始就將停止條件作為真正的、硬性的邏輯加入，而不是等到你已經被失控迴圈燒過一次後才當作事後諸葛亮。
一旦一個迴圈真正可靠——可以無人值守運行，能抓住真正的錯誤，能在應該停止時乾淨地停止——第二個迴圈就會快得多。不是因為提示詞可以直接轉移（它們通常需要為新任務重寫），而是因為你已經理解了問題的實際形狀。把建構和判斷分開。給判斷一些真實的東西來檢查。把停止條件寫成邏輯，而不是希望。
這個形狀就是整個學科。其他一切只是將它應用於你面前的任何任務。
關注 @cyrilXBT 以獲取本文中所有內容背後的確切迴圈模板和建構者-裁判-管理者設定。
