「我不再在 Claude 輸入提示詞了。現在是循環在運作，循環自己決定下一步要做什麼，方法是呼叫 Claude。我的工作變成了『寫循環』。」
這是 Claude Code 主導者 Boris Cherny 公開說過的話（出現在 The New Stack 與 Addy Osmani 的文章中）。
當我們大多數人還在打磨提示詞以提升準確度時，打造工具的人早已不再扮演「提示者」的角色。
仔細想想，只要「人類回合」還存在——坐在螢幕前等待 AI 回覆、檢查、再下指令——速度的上限就取決於你自己的手速。
循環工程（Loop Engineering） 的概念，就是從結構中移除這個人類回合。Boris 全力投入這個方向；他說他在 2024 年 11 月就把開發工具（IDE）刪掉了，此後再也沒開過。他聲稱最近一個月對 Claude Code 的幾乎所有貢獻（據報導超過 200 個 PR）都是由 Claude Code 自己寫的。
工具的創造者自己不寫程式，而是轉移到「觀察循環是否正常運轉」的位置。今天我要以技術規格層級來拆解這個概念，而不只是講感覺。我自己也正在往循環的一端轉移，而且越偏過去，越覺得雙手變得自由。
相關文章：Vibe Coding 入門：不會寫程式的人也能用 Claude 打造 App 的 6 個步驟。週末自家生產的時代來了
https://note.com/nobel/n/n8192ec07d689
循環工程意味著角色的轉變
換句話說，你的位置變了。過去，人類坐在一來一往的中間：人類下指令、AI 回答、人類檢查修正。在循環設計中，人類負責設計循環機制（循環），而試錯與驗證結果則轉移到 AI 那一側。你只需要等它完成後的通知。
Google 的 Addy Osmani 在標題為 Loop Engineering 的文章中也寫了同樣的內容，形容為「用一個能代替人類輸入提示詞的機制，取代那個每次都要親手輸入提示詞的人」。槓桿點已經從「寫好提示詞的能力」轉移到「如何設計一個讓 AI 替你寫提示詞的系統」。這就是核心。
不過，Addy 自己也警告：「這還在早期階段，我有點懷疑。你真的要小心 Token 成本。」我們會在後半段回頭談這個陷阱。
/loop 的技術規格
Claude Code 內建了一個名為 /loop 的技能（v2.1.72 起）。這是進入循環工程最簡單的切入點。由於網上說明常混雜錯誤，我將根據官方 排程執行文件 專注在關鍵點上。
傳入的參數會改變行為：
- 同時指定間隔與提示詞：
/loop 5m check if the deployment is finished and let me know會以固定間隔執行。 - 只給提示詞：
/loop check if the CI passed and respond to review comments。Claude 會自行決定間隔（1 分鐘到 1 小時之間，自我調整節奏）。 - 不傳任何參數
/loop：會執行內建的維護提示詞（繼續未完成的工作、照顧 PR、輕度清理）或你放置的loop.md檔案。
間隔可以放在開頭如 30m，或結尾如 every 2 hours。單位是 s / m / h / d。也可以傳入其他指令，例如 /loop 20m /review-pr 1234，讓它每次執行都呼叫已儲存的技能。要停止時，在等待過程中按 Esc（經由自然語言請求建立的任務無法用 Esc 停止，必須要求刪除）。在自我調整節奏模式下，如果 Claude 判斷任務真的完成了，它就不會排程下一次執行，直接結束。
自我調整節奏模式有一個微妙的優點：它會自動調整，如果建置快完成了就等短一點，如果什麼都沒發生就等長一點。有時候會使用一種叫「Monitor」的機制來串流背景輸出而非輪詢，這通常比固定間隔呼叫提示詞更省成本。
讓我先澄清一個在源頭文章中常見的誤解。有些文章寫說任務「建立後 3 天自動刪除」，但準確來說是定期任務在建立後 7 天過期（它會執行最後一次後消失）。另外，/loop 是與對話綁定（session-scoped），當你開始新對話時就會消失。如果關閉了，只要它還沒過期，可以用 --resume 重新回來。
排程方式有三種，依使用情境選擇：
- Cloud (Routines)：在 Anthropic 端執行。即使你的機器關機也會繼續跑。最小間隔 1 小時。
- Desktop Scheduled Tasks：在你的機器上執行，可以接觸本地檔案。
- /loop：只限對話開啟期間。最小間隔 1 分鐘，適合在對話中進行輪詢監控。
分工是：用 Routines 或 GitHub Actions 做不需要人介入的永久常駐工作，用 /loop 在對話中進行監控。
循環適合的標準任務
那些你日常工作流程中「檢查並修一點」的重複性任務，通常都適合用循環。常見的有三種模式：
- Bug 巡邏：發現問題或測試失敗，讀取原因、修復、跑測試、定時建立 PR。
- 持續審查：監控程式碼變更，持續指出需要關注的地方。人類只決定是否接受建議。
- 文件同步：偵測原始碼變更，持續更新 README 或規格文件。
這三者的共通點是目標可以明確判斷，例如「測試通過」或「PR 已建立」。反之，判斷標準模糊的任務就不適合循環。如果不能明確知道何時該停，它就會一直跑、一直消耗 Token。一開始選擇那種成功失敗一目瞭然的任務比較安全。
用「狀態檔案」防止失控與遺忘
循環有兩個恐懼：重複相同的失敗，以及無止盡地消耗 Token。
這時候，在專案中設計一個單一狀態檔案就非常有效。無論是 STATE.md 還是 todo.md，AI 在每次循環時都會讀寫當前的目標 / 已完成項目 / 下一步 / 卡住的地方。即使對話中斷，AI 也不會遺失「現在在哪裡、目標是什麼」。
這不是隨便的做法；Anthropic 自己也在 Effective harnesses for long-running agents（2024 年 11 月）中得出了幾乎相同的結論。他們的配置使用兩種角色：初始化 Agent 負責設定環境，編寫 Agent 則每回合推進一個功能。進度透過 git commit 和一個 claude-progress.txt 檔案在工作階段之間傳遞。對於長時間的工作，單純用摘要壓縮是不夠的，策略是寫入結構化檔案一次，然後重建上下文。
在我自己的操作中，我用 tasks/state.md 作為共享狀態的中心，無論是腦力激盪端還是實作端，在行動前都會先讀取它。這跟論文說的完全一樣：「不要信任上下文，要信任檔案。」雖然簡單，但沒有這個，循環在第二圈就會迷路。
Ralph 方法與 Maker/Checker 分離
循環有一個極端版本叫做「Ralph」方法。由 Geoffrey Huntley 推廣，原始來源 只是一個簡單的 bash 迴圈：
透過無止盡地餵入相同的提示詞，並將計畫放在 Markdown 檔案中作為磁碟上的共享狀態，AI 每次讀取後自行決定「接下來要做什麼」。看起來很魯莽，但因為有狀態檔案，所以每繞一圈就會前進。Claude Code 也有官方的 ralph-loop 外掛，它會不斷重新提交相同的提示詞，直到完成條件（完成承諾）被滿足。約束是：只有在真正達成時才能宣告完成。
然而，如果把所有事情都交給同一個 AI，它對自己寫的程式碼會說「沒問題」。這時候，把「創造的 AI（Maker）」和「審查的 AI（Checker）」分開來就很有效。在我自己的操作中，我把實作和驗證交給不同的 Agent，而且不給驗證方實作意圖，只給需求讓它獨立評估。我吃過苦頭才學會：在同一個對話中做自我審查，必然會寬容。
把「具有不同觀點的純審查 Agent」納入循環——設計這個多層次的檢查機制，是人類應該保留的工作之一。
設計自主性的三個階段
一次全部交出去會出意外。比較安全的作法是將參與程度分層：
- L1（手動）：人類輸入提示詞並逐一檢查。傳統方式。
- L2（半自主循環）：依狀態檔案，用
/loop監督特定一批任務直到完成。 - L3（常駐）：透過 Routines 或 GitHub Actions 持續執行，無需人工介入。
從 L2 開始比較實際。先用 /loop 跑一個任務到完成，觀察行為。等到你看到可靠性的範圍之後，再升級到 L3。我在頭幾次時，會開另一個螢幕看 log，觀察「它在哪裡判斷錯了」。
陷阱（先知道這些）
到目前為止我只寫了好的一面，這裡列出三個你可能會卡住的地方：
- Token 成本：循環愈跑愈消耗。這就是 Addy 強調的；如果間隔設太短，一晚可能花掉不少錢。自我調整節奏模式比固定間隔好，因為它會在該等的地方等，減少浪費。
- 不可逆的操作：內建的維護提示詞只會執行「對話中已允許範圍內」的推送或刪除等不可逆動作。當你寫自己的提示詞時，最好為破壞性操作自訂邊界。
- 7 天後消失：定期
/loop任務在建立後 7 天過期。如果你想跑更久，請改用 Routines 或 Desktop 任務。
給進階使用者的備註
/loop和/goal不同。/loop是根據間隔執行。如果你想在條件達成之前持續進行每個回合，請用/goal。如果你想在事件發生的瞬間反應，請透過 Channels 使用推播。- 放置
loop.md（.claude/loop.md或~/.claude/loop.md）可以讓你用自己的提示詞替代裸/loop的預設提示詞。適合用來寫常式任務，例如「如果 release branch CI 紅燈就修復」。 - 每個對話最多 50 個排程任務。可以用
CronList查看清單，用CronDelete依 ID 刪除。
總結
過去，我坐在螢幕前的時間就是進度的上限。現在，當我睡覺時，一個會讀取狀態檔案的循環，一個功能一個功能地推進，而我的早晨從檢查進度開始。
在改善內容（提示詞準確度）之前，先設計它運作的方式（循環拆解、狀態管理、驗證）。槓桿點已經轉移到那裡——這是 Boris、Addy 以及 Anthropic 的 harness 故事的共同點。我認為它不是什麼困難的理論，而是簡單設計的穩健累積，就像在啟動循環之前先決定好何時停止。
在 LINE 的 OpenChat 中正在分享無法在 X 上傳遞的有用資訊。如果您有興趣利用 Claude Code/Codex，或使用 AI 進行 X 營運，歡迎加入我們。
