不是所有任務都需要複雜的循環。先從最簡單、能動的方案開始，再選擇性地加上這些模式。

前陣子我寫過一篇 Loop Engineering：你不再提示 AI，而是設計一個「提示 AI 的系統」，談 Addy Osmani 為 AI 協作開發的下一階段定名的概念。這幾天，Claude Code 官方開發者帳號（@ClaudeDevs，作者 @delba_oliveira）發了一篇貼文，把「設計循環」（designing loops）從一個抽象概念，拆解成可以直接動手的實務地圖。

我把它整理、翻譯，並加上自己對台灣技術團隊的落地觀點，寫成這篇。原文請見文末連結；以下是我的解讀。

為什麼大家開始談「循環」，而不是「提示」

最近在 X 上如果你認真去查「循環到底是什麼」，會看到各式各樣的答案。官方這次給了一個乾淨的定義：

循環，就是代理人重複執行一段工作循環，直到滿足停止條件為止。

聽起來簡單，但這句話其實把過去隱藏在「agentic loop」裡的迭代過程，顯性化了。你送出的每一個 prompt，其實都啟動了一個循環：Claude 蒐集 context、採取行動、檢查自己的工作、必要時重複，然後才回應你。過去我們只看到「輸入 prompt、拿到結果」，中間那段迴圈是黑箱；現在官方把它攤開來，並且告訴你——你可以親手設計這個迴圈。

這正是從 Prompt Engineering 走向 Loop Engineering 的關鍵一步：重點不再是「怎麼把一句提示寫到最完美」，而是「怎麼設計一個能自我迭代、自我驗證、直到達成明確目標的系統」。

官方怎麼分類循環

Claude Code 團隊用四個維度來區分循環：

  • 怎麼被觸發（trigger）
  • 怎麼停止（stop condition）
  • 用到哪些 Claude Code 基本功能（primitive）
  • 最適合哪種任務

依照這四個維度，可以整理出四種主要的循環類型：

循環類型 觸發方式 停止條件 最適合的任務 對應功能
回合制（Turn-based） 使用者手動 prompt Claude 判斷完成，或需要更多 context 較短、非定期的任務 具體 prompt ＋ Skills
目標導向（Goal-based） 手動 prompt（即時） 達成目標，或到達回合上限 有可驗證退出條件的任務 /goal
時間導向（Time-based） 指定的時間間隔 你取消它，或工作完成 重複性工作、與外部系統介接 /loop、/schedule
主動式（Proactive） 事件或排程，無需即時人類介入 每個任務達標即退出；routine 持續運行 持續且定義明確的工作流 組合上述 ＋ auto mode、dynamic workflows

底下逐一拆解。

一、回合制循環：你手動引導每一回合

這是最基本的模式。你請 Claude 建立一個 like button，它會讀你的程式碼、做修改、跑測試，然後把它「認為可用」的東西交回來；接著你手動檢查，再寫下一個 prompt。每一個 prompt 都啟動一個由你親手引導的循環。

官方的關鍵建議是：把「手動檢查」這一步編碼進 SKILL.md，讓 Claude 能更完整地自我驗證端到端流程。重點在於——檢查越量化，Claude 就越容易自我驗證。給它工具或連接器，讓它能查看、測量、實際與結果互動，而不是靠感覺說「應該可以了」。

二、目標導向循環（/goal）：讓它自己知道什麼叫「做完」

單一回合對複雜任務往往不夠。這時你可以用 /goal 定義「完成」長什麼樣子，延長 Claude 持續迭代的時間。

它的巧妙之處在於：當你定義好成功條件後，Claude 就不需要自己判斷「夠好了吧」而提早收工。每次它想停下來，都會有一個評估模型去檢查你設定的條件，沒達標就把任務送回去繼續做，直到達成目標或到達你設定的回合上限。

這也是為什麼 確定性的條件 特別有效——例如「通過幾個測試」「達到某個分數門檻」。相對的，含糊的目標只會換來含糊的結果。實務上我會加一句像「最多試 5 次就停」，避免它在一個死胡同裡把 token 燒光。

三、時間導向循環（/loop、/schedule）：重複性與外部介接

有些代理人工作本質是重複的：任務不變，只有輸入會變，例如每天早上摘要一次 Slack。另一些工作則依賴外部系統，最省事的介接方式就是「定期檢查、對變化做反應」，例如 PR 收到了 code review、或 CI 失敗了。

針對這兩種情境，/loop 讓 Claude 依你設定的間隔重新執行同一個 prompt。要注意的是——/loop 跑在你自己的電腦上，關機就停。如果你要它長期在雲端運行，可以把它建成一個 routine，改用 /schedule 搬上雲。

四、主動式循環：真正的「無人值守」

當你把上面這些基本功能，加上 auto mode 與動態工作流（dynamic workflows，research preview），就能組合出長時間運行的工作流。官方舉的例子是「處理進來的使用者回饋」：

  • 用 /schedule 建一個 routine，定期檢查新回報
  • 用 /goal 定義「完成」的樣子，並用 Skills 把「怎麼驗證」記錄下來
  • 用動態工作流來 orchestrate 多個代理人，分別負責 triage 每則回報、修復、再 review 修復結果
  • 用 auto mode 讓 routine 執行時不用停下來一直問你要不要授權

這種模式最適合 bug 分流、issue triage、依賴升級、大型 migration 這類「持續且定義明確」的工作。官方的資源分配建議很值得記下來：把 routine 導向較小、較快的模型，把需要判斷力的任務才交給最強的模型。

品質，來自循環周圍的「系統」

這是整篇最容易被忽略、但我認為最重要的一點：循環輸出的品質，取決於它周圍的系統，而不是某一句神級 prompt。 官方給了五條原則：

  • 保持 codebase 乾淨：Claude 會沿用你既有的模式與慣例，髒的地方它也會照著髒。
  • 給它自我驗證的方法：用 Skills 把「什麼叫好」為你和團隊編碼下來。
  • 讓文件容易取得：框架與函式庫的文件能提供最新的最佳實踐。
  • 用第二個代理人做 code review：一個帶著全新 context 的 reviewer 比較不會有偏見，也不會被主要代理人的推理過程帶著走。內建的 /code-review 或 GitHub 的 Code Review 功能都可以。
  • 別只修單一問題：當某次結果不達標，不要只補這一次的洞，試著把它編碼進系統，讓未來每一次迭代都跟著變好。

最後那條，其實就是我在前一篇提過的原則——maker 與 checker 必須分離，而且失敗要沉澱成規範，不能只是打補丁。寫 code 的人（或 agent）很容易替自己的答案找理由，這點人跟 AI 意外地像。

把 token 花在刀口上

循環很好用，但 dynamic workflows 一不小心會 spawn 出幾百個子代理人，成本會很快失控。官方的 token 管理原則相當務實：

  • 為工作選對 primitive 與模型：小任務不需要多代理人或循環，有些甚至用更便宜、更快的模型就夠。
  • 把成功與停止條件講清楚：讓 Claude 更快抵達答案——但別逼它太快而犧牲品質。
  • 先小規模 pilot：動態工作流很燒，先拿一小塊工作試用量。
  • 確定性的工作交給 script：跑一段 script，比讓模型一步步推理便宜得多。例如一個處理 PDF 的 Skill，可以直接跑填表 script，而不是每次都重新推導程式碼。
  • 別比需要更頻繁地跑 routine：把間隔調到跟你監控的變化頻率一致就好。
  • 定期檢視用量：/usage 會依 Skills、subagents、MCP 拆解近期用量；/goal 不帶參數會顯示目前回合數與 token；/workflows 會列出每個代理人的用量，你隨時可以停掉某一個。

對台灣的付費使用者來說，用量上限是很實際的痛點。這套原則的價值，不只是省錢，而是讓你的自動化能長期、可持續地跑下去。

怎麼開始：挑一個「你自己就是瓶頸」的任務

官方最後的建議，我很認同，也想原封不動轉給正在導入 AI coding 的團隊：

從你已經在做的工作開始。 挑一個「你自己就是瓶頸」的任務，然後問三個問題：

  1. 這件事，我能不能寫出一個驗證檢查？
  2. 目標夠不夠清楚，清楚到可以定義「完成」？
  3. 這項工作，是不是會定期出現？

有了想法，就實際把循環跑起來，觀察它在哪裡卡住、在哪裡過度擴張，然後大膽迭代。我自己的順序會是：先從目標導向循環（/goal）下手，因為它的停止條件相對好定義；把驗證步驟寫進 SKILL.md，讓 agent 能自我檢查；等這一環穩了，再往時間導向、主動式循環延伸。

如果你已經在玩多模型的代理協作，這套循環思維也能直接接上——我在 Hermes Agent 與 Mixture of Agents 的深度研究 裡談過的那種「把模型、工具、記憶、工作流組成可靠系統」的思路，本質上就是在設計一個更大的循環。

從 Prompt 到 Context，再到 Loop——AI 協作開發的重點一直在往「系統設計」移動。這篇官方指南的價值，就是把原本隱含的迭代過程，變成你可以親手設計、驗證、治理的產線。

你的團隊，現在走到哪一階了？

本文整理、翻譯自 Claude Code 官方開發者帳號 @ClaudeDevs 於 X 的貼文（作者 @delba_oliveira），並加入我自己的理解與落地建議。技術細節以官方原文與 Claude Code 文件 為準。