Gauntlet Loop
將使用者的初始指示或目標轉換為 Gauntlet Loop——一個自動化的建構者與評論者回饋循環，其基礎來自 Matt Shumer 的 Claude of Duty 技術、robonuggets/gauntlet-loop、duolahypercho/gauntlet-loop 以及 AI 循環工程三元素框架。
多數代理的輸出止於「對 AI 來說夠好」，因為建構者自己批改自己的作業，用的還是模糊的字眼。Gauntlet Loop 以三個核心元素為基礎，用一個持續的循環取代一次性提示：
- 目標：必須實現的具體可交付成果和結果狀態。
- 參考或指標（標竿與嚴苛評論者）：一個具體命名、可取得、可並排比較的基準——在適用的情況下搭配客觀測試或指標——由一個擁有全新上下文的獨立評論者進行盲測。
- 邊界：明確的成功標準、輪次/停滯上限、策略轉向規則以及安全/權限閘門，用於控制循環何時停止或升級。
步驟 1：識別種子指示與背景
- 如果使用者透過
/gauntlet-loop <instructions>內聯傳遞了指示，則使用這些指示作為種子。 - 如果使用者在進行中的對話中呼叫了
/gauntlet-loop但未提供引數，則使用當前正在討論的任務、計畫或提示。 - 如果訊息或對話歷史中沒有明確的任務，請先詢問使用者想要建立或達成什麼。
- 如果任務涉及本地程式碼庫或工作區，請快速檢查目錄結構、技術棧、測試執行器或建置腳本，以便你提出的預設值能參考實際的專案工具和命令。
步驟 2：釐清三個循環元素（提出預設值）
根據下面的三個核心元素審查使用者的請求。每當任何元素缺失、不明確或使用了模糊的品質標準時，請要求使用者確認或調整這三個元素，同時提出具體、有主見的預設值。
快速路徑規則：如果使用者已經提供了明確的目標、一個具體可取得的參考/指標，以及清晰的邊界——或者明確說過 「使用預設值」 / 「直接寫提示就好」——則跳過提問，直接使用你認為最佳的預設值進入步驟 3。
1. 目標（必須實現什麼具體成果？）
- 將模糊的意圖（「讓網站更好」、「寫一個好 CLI」）替換為可觀察的結果狀態和可交付成果（「建立一個使用 Next.js + Tailwind 的響應式 SaaS 定價頁面，讓首次訪問者能比較所有方案並在手機上完成結帳」）。
- 預設提案：草擬一個經過銳化的 1-2 句話目標（包含檢測到或推薦的技術棧/格式），供使用者批准或調整。
2. 參考或指標（品質標竿與外部評判者）
Gauntlet Loop 中的一切都取決於品質標竿。一個有效的參考標竿必須通過三項測試：
- 具體命名：一個真實世界的具體成品，而非形容詞或類別。（「Stripe 的即時定價頁面」 或 「Hades 的戰鬥截圖」 可以；「獲獎的 SaaS 設計」 或 「AAA 品質」 單獨出現則不行。）
- 可取得 / 可檢查：評論者可以在執行過程中實際獲取並檢查該成品——截取即時 URL 的螢幕截圖、閱讀已發布的文章、執行該二進位檔或檢查該儲存庫。如果代理無法取得參考，它將會幻覺式地進行比較，並批准平庸的輸出。
- 可比較：我們的實際輸出和參考可以並排放置，並移除標籤，讓一個全新的評論者進行二元的盲測 A/B 選擇（「哪一個比較好？」）並指出目前最大的單一差距。切勿使用 1-10 的數值評分，因為這在每一輪都會自動向上漂移。
品味 + 數字優於單純的品味：每當目標具有可衡量的維度（單元/整合測試套件、p95 延遲、Lighthouse/無障礙分數、360px 下零水平溢出、基準測試吞吐量、字數或原始來源引用追蹤）時，請將定性的參考標竿與一個硬性的客觀驗證器配對。
| 目標類型 | 可行的參考標竿 + 指標 |
|---|---|
| 網站、應用程式、UI | 特定最佳同類產品的即時 URL（linear.app、stripe.com/pricing、vercel.com），在桌面與行動裝置視口下截圖 + 零主控台/無障礙/溢出錯誤 |
| 程式碼、CLI、函式庫 | 一個特定開放原始碼儲存庫或工具（ripgrep、jq、esbuild）的實作 + 自動化測試套件、屬性模糊測試器以及延遲/吞吐量基準測試腳本 |
| 遊戲、3D、互動式 | 來自特定已發布遊戲（Call of Duty、Hades、Brotato）的實際遊戲截圖或影片，與即時遊戲畫面進行比較 + 目標 FPS / 可玩性檢查 |
| 寫作、文件、解說文 | 由特定作者或出版物（例如 Julia Evans、Stripe Engineering Blog、Gwern）發布的 2-3 篇特定文章，移除署名後進行盲測 + 目標長度/閱讀時間檢查 |
| 研究、策略、分析 | 一份特定的分析師報告、基準測試論文的方法章節或法務放空備忘錄 + 對所有主張與原始資料來源進行自動化核對 |
| 簡報、交付物 | 來自某標竿公司、具有相同頁面/投影片數量的特定公開簡報或備忘錄 + 敘述清晰度檢查 |
- 預設提案：提供 2 到 3 個具體命名、可取得的候選標竿（將最嚴格但確實可達成的那個標記為
（推薦）），並搭配一個具體的客觀指標/驗證器。
3. 邊界（停止條件、預算與安全閘門）
「循環到徹底完美」能激勵評論者，但針對一個無法達到的標竿進行無邊界循環可能會無限旋轉、浪費 Token 或進行不安全的更改。請在三個子軸上定義明確的邊界：
- 成功與收斂停止：當每個組件都通過其客觀驗證器並在盲測中勝過參考時退出（或當人類指定的「煞車」停止執行時）。
- 迭代與停滯上限：限制每個組件的輪數（預設：每個組件最多 5 輪或連續 2 輪無實質改善後停止）。如果完全相同的差距連續兩次失敗，要求建構者改變策略。
- 權限與安全閘門：允許本地讀取、起草、編輯、建置、渲染和測試。禁止未經明確人類批准進行不可逆或外部操作（禁止生產環境部署、破壞性刪除、付費 API 支出、憑證/密碼更改或外部訊息傳送）。
如何向使用者提問
如果需要釐清，請提出一個簡短、易於掃讀的提示（如果可用，也可以使用 harness 的結構化 ask_question 工具），僅涵蓋未解決的元素，並預先填入預設值，以便使用者可以用簡短的內容回覆（例如，「1，使用預設值」）：
- 目標：陳述你提出的已銳化目標 + 技術棧，並詢問是否有任何需要更改的地方。
- 參考與指標：列出 2-3 個具體命名、可取得的候選標竿（
A、B、C，其中A（推薦））以及提出的客觀驗證器/測試。 - 邊界：提出預設的停止條件（例如，贏得盲測 A/B + 通過檢查，每個組件最多 5 輪，連續兩次相同失敗後轉向策略，僅限本地編輯）或 「人類作為煞車（持續循環直到我停止它）」，並詢問他們偏好哪種模式。
步驟 3：輸出轉換後的 Gauntlet Loop
一旦目標、參考/指標和邊界被選定（或使用預設值），請分三部分呈現結果：
1. Gauntlet Loop 設計卡
輸出一個簡潔的摘要表格，鎖定循環架構：
- 目標：必須實現的確切成果和可交付成果。
- 參考標竿（品味）：具體命名、可取得的成品，以及在建置前將如何取得/檢查它。
- 客觀指標（數字）：在評論者審查之前所需的自動化測試、基準測試、佈局檢查或事實驗證。
- 分解規則：工作如何拆分為小的、可獨立判斷的片段（僅平行處理真正獨立的組件；將緊密耦合的系統保留在連貫的順序擁有權下）。
- 評論者協議：具有全新上下文的獨立子代理；檢查真實渲染/執行的成品（絕非建構者的摘要）；執行移除標籤後的盲測 A/B 比較；做出二元選擇並指出目前最大的單一差距。
- 狀態與進度：用於持久化循環記憶的檔案（
GAUNTLET_PROGRESS.md或即時進度頁面），記錄已完成的組件、證據、失敗的方法和剩餘的差距，以便背景不會腐化。 - 邊界：活躍的停止規則、輪次上限和安全閘門。
2. Gauntlet Loop 提示
在一個柵欄包圍的 markdown 程式碼區塊內，輸出一個獨立、可複製貼上的提示。提供下面的通用 Gauntlet Loop 提示（根據使用者的任務、工具和技術棧進行調整），如果使用者想要 Matt Shumer 風格的超緊湊 3 段式提示或 harness 特定的循環命令，請相應地調整結尾（參見 references/examples.md）。
Build [DELIVERABLE / OBJECTIVE] in [STACK / FORMAT].
## 1. 品質標竿與指標（先取得參考）
品質標竿是 [NAMED, FETCHABLE REFERENCE]。在建置或判斷之前，直接取得並檢查實際的參考（[如何取得：在桌面與行動裝置視口下截取即時 URL 的螢幕截圖 / 擷取已發布的文字 / 複製或執行參考實作]）——切勿與其記憶或描述進行比較。
每個組件也必須通過這些客觀檢查：[OBJECTIVE METRICS / TESTS / BENCHMARKS]。
## 2. 分解與所有權
將工作分解為可以獨立建置、驗證和判斷的最小組件：[INITIAL CANDIDATE PIECES]。
- 僅對真正獨立的組件平行分派建構者子代理。
- 將緊密耦合的系統保留在連貫的順序所有權下，以避免組件衝突。
## 3. 建構者與嚴苛評論者循環
對於每個組件，執行一個建構者和一個具有全新上下文的獨立評論者子代理（無法存取建構者的思考鏈或藉口）：
1. **建置與驗證**：建構者建立或修改組件，並執行客觀檢查（[TESTS / LINT / BENCHMARK / RENDER]）。
2. **檢查真實成品**：評論者開啟並檢查實際的輸出（[SCREENSHOTS / RUNNING BINARY / TEST LOGS / DRAFT TEXT]）——絕非建構者的摘要。
3. **盲測 A/B 選擇**：評論者將我們的成品與 [NAMED REFERENCE] 並排放置，移除標籤，做出二元選擇判斷哪一個更好，如果我們的輸了，則指出**目前最大的單一差距**，並附上具體證據，將其送回給建構者。
4. **禁止軟性評分**：評論者必須極其嚴苛。禁止讚美和 1-10 的數值評分。如果我們的成品在盲測中沒有獲勝且未通過所有客觀檢查，則繼續循環。
## 4. 狀態追蹤與策略轉變
每輪結束後維護一個精簡的 `GAUNTLET_PROGRESS.md`（和/或即時進度視圖），記錄：當前組件、輪次編號、評論者判決、鎖定的差距、失敗的方法以及客觀檢查結果。如果相同的差距連續兩次失敗，則放棄當前方法，嘗試一個結構上不同的策略。
## 5. 最終整合檢查與邊界
- **整合評論者**：當各組件獲勝後，分派一個全新的整合評論者來端到端檢查完整的組裝成品，確保其一致性、接縫、效能以及與原始目標的契合度。
- **邊界**：[STOP CONDITIONS: e.g., 當所有組件 + 整合檢查贏得盲測 A/B 並通過所有客觀檢查時停止，或在每個組件經過 N 輪 / 連續 2 輪無可衡量的進展後停止]。允許的操作：[ALLOWED LOCAL ACTIONS]。未經明確人類批准，請勿執行 [FORBIDDEN ACTIONS: deploy to production, delete data, spend money, or touch credentials]。
[HARNESS LOOP TAIL: 持續循環，直到評論者在每個組件上都選擇我們的輸出，並將建構者和評論者作為子代理執行。 / 或者對於 Claude Code：對每個組件執行 `/loop` 直到獲勝；分派子代理並使用 `ultracode`。 / 或者對於 Codex：對每個組件執行 `/goal` 直到獲勝。]
3. 執行提議
最後提問：
「您希望我現在就作為主協調者執行這個 Gauntlet Loop、調整三個元素中的任何一個（目標、參考/指標、邊界），還是切換提示風格（通用有界提示 vs. 經典的 Claude
/loop或 Codex/goal的 150 字目標提示）」？
如果使用者要求執行，請立即採用生成的提示作為你的活躍操作指示：先取得參考、初始化 GAUNTLET_PROGRESS.md、分解組件，然後開始第 1 輪。
破壞 Gauntlet Loop 的因素（防護欄）
絕不允許下列失敗模式出現在生成的 Gauntlet 提示中：
- 模糊或無法取得的標竿：「讓它達到世界級」 或命名一個付費牆後/無法取得的成品，會迫使評論者幻覺式地進行比較並批准一切。
- 建構者自己評判自己的工作：建構者會記得它所做的每一個妥協並將其合理化。評論者必須是一個全新上下文的子代理（或一個剝離了建構者理由的乾淨驗證過程）。
- 使用 1-10 數值評分取代二元選擇：10 分制的評分會自動從 7/10 漂移到 9/10。要求進行二元的盲測 A/B 選擇（「哪一個比較好？」）以及目前最大的單一差距。
- 評論者閱讀摘要而非檢查成品：一份光鮮的 Markdown 狀態報告不是證據。評論者必須檢查渲染的像素、執行二進位檔/測試或閱讀實際的文字。
- 平行化緊密耦合的程式碼：在相同的狀態循環或共享的渲染管線上分派 10 個子代理會導致合併衝突和視覺接縫。只平行化獨立且強制序列化耦合的組件。