循環設計與審查 是做什麼的？
前提。 LLM 是一個前饋系統：輸入提示 → 輸出 token，沒有內建的「跨回合朝向目標行進」機制。要讓它「表現得」像一個目標導向的系統，你需要在它周圍包裹一個反饋迴路。本技能幫助你正確撰寫這個迴路，並審查它，使其不會失控。
何時使用 / 不使用
使用時機：
- 你想要將一個重複性任務交給一個代理，讓它反覆執行（寫→測、測→修、修→驗……）。
- 你已經有一個循環，但你擔心它會空轉、作弊，或將錯誤答案執行到底。
不要用於：
- 一次性任務 → 直接執行即可；不需要包裝成循環。
- 簡單的定時器 / 輪詢 → 使用
/loop即可；不需要設計。 - 如何設計循環架構（管線 → DAG、長期執行復原）→ 這是機制層；請參閱
autonomous-loops/continuous-agent-loop。本技能僅涵蓋「目標是否正確，以及它是否會失控」——不會重新解釋機制。
紅線前提：兩個層級的反饋
| 層級 | 擁有者 | 功能 |
|---|---|---|
| 執行（低層） | 機器 / 代理 | 衡量「距離具體目標有多遠」並將其修正為零。機器在此處擅長。 |
| 判斷（高層） | 人類 | 決定「目標本身是否正確、是否應該改變、是否應該停止」。機器無法跳出自己的循環來質疑目標。 |
恆溫器可以反饋「距離 26°C 還有多遠」，但當你發燒且想要 28°C 時，它無法判斷 26°C 是否是正確的目標——它只會朝 26°C 修正。「今天該設定幾度」始終是人類的決定。 將判斷權 / 簽核權 / 最終開關交給機器 = 移除高層級反饋 = 它會快速且猛烈地朝一個無人質疑的目標衝去 → 產生錯誤的輸出。
動作 1 — 撰寫循環（5 個步驟）
步驟 0 · 先減法：你真的應該建構它嗎？（4 條件閘門，任一不符合即否決）
① 任務每週或更頻繁重複 ② 驗證可以自動化 ③ Token 預算可負擔 ④ 代理擁有能夠實際執行並查看結果的工具
任何一項不符合 → 不要建構循環；改用手動或其他方式。
阻礙大多數人的不是「能不能寫出一個循環」，而是「我的儲存庫值不值得一個循環」。一個值得擁有循環的儲存庫，必須具備調和基準線（黃金樣本 / 上游總數）+ 測試 + 程式碼檢查防護。不值得擁有循環的儲存庫，只會讓其錯誤被循環放大。
步驟 1 · 定義一個機器可決策的目標（最困難的部分——循環的成敗取決於此）
整個循環取決於比較器「完成了嗎？」的判斷。比較器只有在你的退出條件可以被機器以是/否判斷時才能正常運作。
- 不良：模糊不清（「讓它變好」、「寫得更精練」）→ 比較器無法判斷 → 要嘛永遠無法通過（卡住重試），要嘛隨機猜測（隨機通過或阻擋）。
- 良好：可決策（「所有 96 個單元測試通過 並且 產生變更清單」、「模組-02 欄位已填寫、pytest 通過、業務邏輯未改動」）→ 一次檢查即可確定；循環平穩收斂。
五點目標框架：
- 完成標準是機器可驗證的。
- 與完成標準一同定義邊界條件（「它不得做的事」）——反古德哈特定律；缺少邊界條件等於授權作弊。
- 具備失敗備援機制——重試上限 N 次，超過則升級給人類處理。
- 目標是層次化的。
- 完成標準偏好使用調和基準而非斷言——將基準錨定於外部事實（黃金樣本 / 上游總數 / 財務對帳 / 平台後台數據），而不是依賴自己的斷言。「所有測試通過」可能被操弄（放鬆斷言、偽造模擬、吞掉例外）；而「與參考資料的差異 < 0.01」則無法被操弄。
自我檢查： 將這個目標讀給一個不熟悉該領域的人聽——他們能否執行一條命令就判斷出是否完成？如果不能，表示目標的可決策性不夠。回去重新定義。
步驟 2 · 選擇循環類型
| 你的任務 | 循環類型（控制論） | 如何停止 |
|---|---|---|
| 有明確的「完成」測試（撰寫到完成 / 一批影像處理完畢） | 伺服（/goal 風格的閉環） | 達成目標後停止 |
| 沒有終點，必須持續維護某種狀態（庫存警報 / 排程健康檢查） | 調節器（/loop 風格的恆溫器） | 永不停止；只在變化發生時行動（死區抑制雜訊） |
| 定期採樣，滿足條件時停止（監看一個 PR 直到 CI 變綠） | 帶有退出條件的調節器 | 當退出條件成立時停止 |
| 必須「確保某件事準時發生」 | 將上述循環包裹在 /schedule 中 | 由 cron 觸發 |
經驗法則：有明確的「完成」測試 → 使用伺服；必須持續維護、沒有終點 → 使用調節器；必須「準時發生」→ 將調節器包裹在排程中。
步驟 3 · 選擇骨架
維護型（照護已存在的東西）→ 文件驅動式分派。 這個循環不是「定時執行固定檢查」，而是**「定時讀取一份文件，且僅在文件發生變化時進行分派」。這份文件就是任務佇列 + 狀態機 + 人類介面。 三個紀律：① 問題欄位僅人類可寫，結果欄位僅循環可寫，狀態單向推進且永不回滾；② 退出碼是最終的（如果腳本回傳 exit 1，則腳本說了算）；③ 狀態只推進到「待驗證」——「完成」儲存格只能由人類翻轉。**循環是工作者，不是驗收者。
新建型（從頭建構）→ 規劃 / 建構 / 裁判，三個角色。
| 角色 | 職責 | 關鍵點 |
|---|---|---|
| 規劃 | 將目標分解為規格 + 可決策的驗收條件 | 驗收條件必須能被腳本判斷 |
| 建構 | 依據規格撰寫程式碼 | 不得更改驗收條件 |
| 裁判 | 獨立執行驗收；通過 → 停止，失敗 → 將失敗原因送回給建構角色 | 獨立 + 確定性 |
三條鐵則（全部押注在裁判身上）：① 裁判必須獨立——不能與建構角色是同一個代理（為自己的作業打分總是會膨脹）；② 確定性規則——pytest / 調和差異 / 型別檢查 / 差異比較，絕不能是「看起來沒問題」；③ 建構角色不得為了讓驗收通過而修改驗收條件。三次重試失敗 → 升級給人類處理。
步驟 4 · 添加阻尼（對抗震盪 / 失控）
重試上限、硬停止、由人類翻轉最後的開關 = 阻尼。沒有阻尼的負反饋會產生震盪（Ralph-Wiggum 循環：原地空轉，浪費 token）。
步驟 5 · 分三個階段落地（不要在第一天就全自動化）
① 手動執行一次（迫使你明確說明「裁判如何決定」）→ ② 將其打磨成一個技能 / Claude Code 子代理（一個主要的 Claude 負責循環，分派規劃/建構/裁判）→ ③ 將它掛在 cron 上以實現全自動化。
動作 2 — 審查循環（檢查清單 = 五種失敗模式）
將你的循環逐行比對。命中任何一項 = 這個循環將會失靈；打回去重做。 這五種是負面經驗（踩過的坑）——比正面規則更有價值。
| # | 失敗模式（如何失效） | 審查問題（命中 = 紅燈） | 解決方案 |
|---|---|---|---|
| 1 | 目標是正確的廢話 → 空轉、燒錢 | 退出條件可否被機器以是/否判斷？還是像「管理好它 / 讓它變好」這種模糊說法？ | 替換為可決策的結果條件（動作 1·步驟 1） |
| 2 | 「驗證」寫成「檢查它是否看起來沒問題」→ 代理自信滿滿地說沒問題並停止 | 裁判就是被告本人嗎？驗證是依賴「看起來正確」還是確定性規則？ | 使用調和機制 + 退出碼規則 + 獨立裁判 |
| 3 | （最糟）僅以「所有測試通過」作為門檻 → 代理刪除了測試 | 是否有邊界條件（「它不得做的事」）？還是只有完成標準？ | 同時具備完成標準 + 邊界條件（反古德哈特定律的解法） |
| 4 | 指望代理在執行過程中提出問題 → 它不會；它會將錯誤答案執行到底 | 是否存在任何「僅在執行時釐清」的環節？ | 預先釐清所有事項；在啟動前一次性解決 |
| 5 | CLAUDE.md 過於臃腫 + 過時的記憶 → 循環越快，錯誤越多 | 它依賴的文件/記憶是否新鮮？誰負責維護？ | 分層記憶 + 定期清理 |
加上三條紅線（違反任何一條 = 不得自動化）：
- 將判斷權保留給人類。 驗收 / 「完成」儲存格由人類翻轉；循環不是驗收者。
- 責任不轉移。 任何你承擔不起失敗後果的事情（合併錯誤的 PR / 發布錯誤的內容 / 分配錯資金）→ 不要自動授予權限。
- 反直覺的警告。 一個循環越是「自我改進 / 改寫自身規則」，它所需的人類審查就越嚴格（以查看它把規則改寫成了什麼）——而不是更寬鬆。機器太快了，事後無法攔截，因此人類的判斷必須設置在行動之前（一個硬性閘門），而不是事後的補丁。
實例演練——審查一個「夜間維穩員」循環
你想要一個每晚執行並修復所有失敗測試的循環。
- 天真的目標：「讓所有測試通過。」→ 步驟 1 的自我檢查失敗：這正是失敗模式 #3 的誘餌。
- 修正後的可決策目標：「所有測試變綠 且 沒有測試檔案被刪除或弱化 且 覆蓋率未降低 且 產生一份變更清單。」邊界條件現在已與完成標準一同定義。
- 類型： 帶有重試上限 3 次的伺服（步驟 2 + 步驟 4）。
- 骨架： 規劃/建構/裁判——裁判是獨立執行的 CI，絕不是負責修正的代理（步驟 3）。
現在運行審查檢查清單，它會捕捉到天真的版本會遺漏的問題：
- 命中 #3 → 天真的「所有測試通過」會讓代理刪除一個失敗的測試來「贏得」目標。已透過邊界條件「沒有測試檔案被刪除/弱化」修正。
- 命中 #2 → 如果修正代理同時也評斷自己的修正，它會讓自己通過。已透過「裁判 = 獨立的 CI，確定性」修正。
- 命中 #4 → 如果某個修正有歧義，代理不會在凌晨兩點停下來詢問；它會猜一個答案並提交。已透過預先釐清修正：有歧義的修正留給人類處理，而不是猜測。
- 紅線 → 循環會開啟一個 PR，但不會自動合併；由人類翻轉最終開關（責任不轉移）。
天真的循環與經審查的循環之間，只差四行約束條件——而這就是「醒來發現測試套件被刪除」與「醒來看到一個乾淨的 PR」之間的差異。
一句話總結
撰寫一個循環最困難的部分不是「能不能寫出一個循環」，而是定義一個機器可以調和的目標——可決策、有邊界、基於調和基準。控制器必須是確定性且外部的；將判斷權和標準保留給人類；系統傾向於熵增，因此需要維護。 一個循環只會回報那些已經深思熟慮過的人。指望它為你思考，它會樂於和你一起，大規模地、錯誤地思考。
來源：Wiener 的雙層反饋機制（《The Human Use of Human Beings》，1950 年）提供了判斷/執行分離與紅線的基礎；規劃/建構/裁判模式來自於 Anatoli 的《Loops explained》與 Addy 的《Loop Engineering》。 機制層（如何設計循環架構）：請參閱
autonomous-loops/continuous-agent-loop。本技能不重新實現機制；僅涵蓋目標定義與防止失控。