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