Gauntlet Loop
此乃 Claude of Duty 背後方法的通用化版本，適用於代理能檢查的任何工作。一次提示產出了約 55,000 行可玩的 AAA 級射擊遊戲程式碼，全程無需人類介入。關鍵區別不在模型，而在循環本身。
核心循環：
拆分 → 建構 → 依據外部標準評判 → 重複。
方法由 Matt Shumer 提出。參見 references/origin.md。
執行合約
你執行此協議。使用者不執行。
當此技能觸發時，不要回傳一個提示、一個待批准計畫、或 Gauntlet Loop 的描述。設定標準、拆解目標、產生建構者與評論者、執行回合，並交付最終工件。
使用者已給出一次目標。此後一切由你負責。
- 不問任何澄清問題。 每個未知都是你的決策，並記錄在最終摘要中。
- 自行選擇標準。 用一句話說明，然後繼續。絕不詢問要使用哪個參考。
- 自行路由模型。 根據工具集提供的選項，為每個產生的代理選擇模型與推理努力程度。絕不詢問使用者要用哪個模型，也絕不將所有任務都留給此次對話的預設設定。
- 執行期間不回報進度。 進度寫入即時進度檔案，而非寫入對話中。
- 僅在以下情況中斷：憑證受阻、缺少付費資源、或執行指示可能造成損害。
如果使用者明確要求在檢查點進行諮詢，請尊重此要求。若無此訊號，則執行至完成。
適用時機
三個條件：
- 請求是建立或改進某物，而非回答問題。
- 輸出可以客觀檢查：可渲染、執行、開啟、測量、測試、閱讀。
- 負擔得起超過一輪的運算。
對於查詢、單行修復與說明，請跳過此技能。它會消耗實際運算資源，僅在品質比速度更重要時才值得投入。
執行手冊
1. 偵測工具集
在執行任何其他動作之前，閱讀 references/harness-setup.md 並選擇對應的接線方式。它決定評論者是來自並行子代理、獨立對話、還是硬性分離的執行階段。不要宣告此步驟，直接適應。
同時，列出此工具集暴露的模型與推理努力設定。你無法路由你未列出的東西。
2. 設定預算與路由表
循環會倍增呼叫次數。若不進行路由，每一次呼叫都會繼承此對話的模型與努力設定，導致大量機械性編輯以最高推理努力的旗艦模型執行，毫無效益可言。
在開始建構前，閱讀 references/model-routing.md 並做出一次性決策：
- 分層。 將可用模型對應到 T0（命令，無需模型）、T1（小型且快速）、T2（中階）、T3（高努力的旗艦模型）。
- 路由表。 哪個角色使用哪個層級：領導者與所有判斷性呼叫使用 T3，標準建構使用 T2，機械性編輯與文書工作使用 T1，任何可由命令驗證的工作使用 T0。
- 預算。 若使用者有給定則尊重其預算，否則自行設定，並保留約四分之一的預算給評論者。
有兩條規則可覆蓋任何節省努力。判斷性任務絕不路由到最便宜的層級，因為一個弱的評論者會過早批准，從而取消此方法。而關於品味或新穎性的片段應從高層級開始，因為一個便宜的建構者輸掉四輪的總成本，會高於一個昂貴的建構者贏在一輪。
將路由表記錄在進度檔案中。不要宣告它，也不要請使用者批准。
3. 設定標準
標準決定此執行是否能夠成功。不當的標準如：「讓它驚人」、「達到生產級品質」、「遵循最佳實踐」。一個真正的標準是與產出相比較、且可以實際落敗的外部工件或測量值。
使用 references/quality-bars.md 選擇一個，該文件涵蓋視覺工作、前端、產品 UI、後端、行動裝置、寫作、設計系統、研究、資料與行銷。
規則：
- 可在執行期間檢查。 是儲存在工作區的螢幕截圖、你可開啟的 URL、可執行的測試套件、可讀取的檔案。不是從訓練資料中記住的標準。
- 不需要可以達成。 Claude of Duty 從未打敗 Call of Duty。標準的存在是為了防止執行在「對 AI 來說夠好了」的狀態下停止。
- 第一輪就通過意味著標準太低。 提高標準並繼續。
現在，在任何建構開始之前，取得或產生標準工件，並儲存在工作區中，以便每個評論者都能存取。
4. 接受目標，而非實作
不要預先規定你自己的架構，也不要接受在檢視工件之前就發想出來的拆解方式。重申最終目的，讓形狀從工作中浮現。
如果使用者指定了技術棧或架構，那是真實的限制。尊重它，並保持所有其他部分開放。
5. 拆分工作
將目標分解為最小的、可以獨立改進與評判的片段，並決定哪些可以並行執行。
粒度是槓桿。「讓整個網站更好」是無法處理的。「讓這個定價區塊勝過參考定價區塊」則是一個你可以持續攻擊直到獲勝的問題。同理，「讓 p95 在指定負載下低於 120 毫秒」以及「讓這個段落至少與參考段落一樣清晰」。
6. 建構與評判，絕不在同一個上下文中
對於每個片段，一個建構者和一個獨立的評論者。始終使用不同的上下文，絕不交由同一個代理。
建構者看到了所有決策並記得為何做出這些決策，這使得它非常擅長解釋為何結果是合理的。但合理並非目標。
使用 assets/delegation-templates.md 對他們進行簡報。評論者會收到目標、標準、限制條件以及實際工件。它絕不會收到建構者的執行紀錄、建構者的解釋、或哪一方是我們的作品。
在產出每個子代理時，使用步驟 2 的路由表對其進行路由。在每個建構者之前詢問三個問題：成功是否可以由命令檢查（無需模型，直接執行）；目標狀態是否已完全指定（最小模型，最低努力）；或者縮小差距是否需要決定什麼是「好」（使用旗艦模型）。評判品味的評論者始終使用旗艦模型；檢查數字的評論者先執行命令，只需小型模型來報告結果。
完整程序在 references/critic-protocol.md 中。要點：盲測 A/B 比對、檢查真實工件、二元判決、指出唯一最大的差距、將其送回。
7. 持續循環
永遠不要設定回合數。任何約定的最終回合都將成為天花板。
當以下情況之一成立時停止，並記錄是哪一個：
- 使用者從進度檔案中確認完成。
- 每回合的改進對目標來說已不再重要。
- 運算預算用完，以步驟 2 設定的預算為基準。
只有在有證據時才將某個片段提升層級：在同一個差距上連續輸掉兩次，則提高其努力程度；第三次則提高其模型層級。一個開始獲勝的片段，在剩餘的執行中會降回較低層級。在預算花費達 80% 時，停止為已經獲勝的片段增加回合，並將剩餘預算投入離標準最遠的片段。
如果同一個差距存活了連續三個回合，則停止該片段並在領導者層級重新決策。這可能是結構性問題、該片段的標準錯了、或者建構者與評論者在測量不同的東西。此時在此片段上花費更多資源是燒光預算最常見的方式。
8. 維護即時進度檔案
在工作區維護一個簡單的 HTML 頁面或 Markdown 檔案，並隨著工作完成更新：螢幕截圖、草稿、測試結果、逐回合判決、未解決的差距。不要過度指定格式，並在你輸出的第一行告知使用者其位置。
此檔案的存在是為了讓使用者可以在不中斷的情況下觀看進度。中斷會耗費上下文視窗並破壞循環。
9. 波次間的平滑處理
當許多代理編輯一個工件的不同部分時，各個部分會變得個別優秀，但整體卻會變得不相關。
在每個主要波次結束時，產生一個全新的代理來檢查整體結果、解決衝突，並使其感覺像是一個統一的整體。它不會重新設計任何東西。
此步驟有用，但非核心。核心始終是：拆分、建構、評判、重複。
結束執行
交付工件，然後提供一份簡短摘要，包含：
- 所使用的標準及其原因。
- 工作相對於該標準達到的程度。
- 最後一個未解決的差距，這是為下一個接手者提供的交接資訊。
- 為取代未提問而做出的假設。
- 是哪個停止條件結束了此次執行。
- 其成本：執行的回合數、預算的大致流向、以及任何消耗了大量預算卻未取得進展的片段。
不對工件進行讚美。評論者的判決已經說了一切重要的東西。
反模式
| 症狀 | 修正方法 |
|---|---|
| 將一個提示交給使用者讓他們自己執行 | 執行此協議，這才是重點 |
| 建構者說：「這看起來很棒！」 | 產生一個擁有乾淨上下文、無歷史記錄的評論者 |
| 評論者閱讀報告而非工件本身 | 強制檢查實際輸出 |
| 主觀標準（如「世界級」、「Apple 等級」） | 替換為一個你可以開啟的具體工件 |
| 在檢視工件之前就固定了拆解方式 | 讓形狀從工作中浮現 |
| 「做 3 次迭代」 | 開放式循環，搭配明確的停止條件 |
| 詢問要使用哪個參考 | 選擇一個，用一句話說明理由，然後繼續 |
| 在對話中報告狀態更新 | 使用即時進度檔案 |
| 各部分良好，但整體不相關 | 在波次結束時進行平滑處理 |
| 標準在第一輪就被通過 | 標準太低，提高它 |
| 同一個差距存活三個回合 | 升級處理，這是結構性問題 |
| 每個代理都繼承了此對話的模型與努力程度 | 對每個產生的子代理進行路由：判斷性任務使用旗艦模型，機械性工作使用小型模型 |
| 用最高努力的旗艦模型來重新命名一個變數 | 使用 T1 及最低努力，或者直接使用無需模型的命令 |
| 為了省一輪而使用便宜的評論者 | 規則零。一個弱的評論者會過早批准，從而取消此方法 |
| 在關於品味的片段上使用便宜的建構者 | 輸掉四輪的總成本，高於一場昂貴的勝利 |
| 因為任務感覺困難就提升層級 | 根據重複的判決結果來升級，而非根據直覺 |
| 評論者的預算被用於額外的建構回合 | 儲備不是一個共用資金池。判斷性任務有權使用它 |