Claude Code官方解密！一次看懂4種「迴圈」設計法，讓AI Agent自動搞定複雜任務

最近 X（原 Twitter）上很流行討論「設計迴圈（loop）」這個說法，好像不懂 loop 就跟不上 Claude Code 的進階玩法。但你如果真的花時間去查「迴圈」到底是什麼，會發現十個人有十種講法，愈查愈亂。

Claude Code 團隊親自撰文說明。這篇方法論於 2026 年 6 月 30 日發布在 Claude 官方部落格，由 Claude Code 團隊的 Delba de Oliveira 與 Michael Segner 共同撰寫；Claude Code 官方帳號（@claudedevs）也在 X 上發布貼文介紹這篇文章。

文章對「迴圈」的定義是：：迴圈，就是代理（agent，也就是會自己動手做事的 AI）重複執行工作循環，直到滿足停止條件為止。

多數人以為「設計迴圈」就是讓 AI 重複做同一件事，例如叫它「一直改到你滿意為止」。但官方的分類邏輯不是這樣，而是看四個維度：

• 怎麼觸發
  
• 怎麼停止
  
• 用哪一種內建工具或指令
  
• 適合哪一類任務
  

同樣是「讓 AI 自動修 bug」，如果沒先想清楚這四點，做出來的可能只是一個不斷跳出來問你「要不要繼續」的手動流程，而不是真正省力的自動化。

為什麼要分著設計，不是一種迴圈打天下？

因為每種任務需要的「人盯著看」程度不一樣。有些工作你想要每一步都親自確認，有些工作你只想設好停止條件就放著跑，還有些工作你根本不想開電腦、讓它照排程自己執行。用同一套邏輯硬套所有任務，結果不是浪費你的時間盯場，就是浪費運算資源跑不必要的來回確認。

token 用量愈高，會更快消耗方案額度；若使用 API 或開啟額外用量，也可能增加實際費用。Claude Code 團隊的建議也很實際：不是所有任務都需要複雜迴圈，先從最簡單的做法開始，需要時才挑合適的迴圈類型。

第一種：回合制迴圈

• 觸發方式：你自己輸入的一句提示（prompt）
• 停止條件：Claude 自己判斷任務做完了，或是需要你補充更多資訊
• 最適用場景：時間較短、不是例行公事或排程的任務
• 管理用量的方法：把提示寫得更具體，並用「技能檔」（skill，見下方說明）幫 Claude 加強自我檢查，減少來回輪數

你平常直接對 Claude 下指令，其實就是在跑一個「回合制迴圈」：Claude 收集上下文（先讀懂現有的程式碼或資料）、採取行動、檢查自己做得對不對，如果不夠好就再修一次，最後才回覆你。官方把這個過程稱為「代理式迴圈（agentic loop）」。

舉例來說，你請 Claude 做一個按讚按鈕。它會讀你的程式碼、動手改、跑測試，然後把它認為可行的結果交給你。接下來換你手動檢查，再決定下一句要下什麼指令。

這一步能升級的地方，是把你原本手動檢查的步驟，寫成一份「SKILL.md」檔案。這是 Claude Code 裡的一種技能設定檔，簡單講就是一份寫清楚「怎樣才算真的做完」的檢查清單，讓 Claude 能照著清單自己端到端驗收，而不是憑感覺說「應該可以了」。

清單裡最好包含能讓 Claude「看到、量到、或直接操作」結果的工具，愈是能量化的檢查項目，Claude 自我驗證起來就愈準。

以下是一份可以直接存成 .claude/skills/verify-frontend-change/SKILL.md 的驗收清單範例，用來確保前端改動真的測試過，而不是改完就交差。

---name: verify-frontend-changedescription: 在宣告一個 UI 改動完成之前，一定要端到端驗證過。---# 驗證前端改動不要只憑「編輯成功」就回報這個 UI 改動已經完成。要像真人審查者一樣驗證：1. 啟動開發伺服器，在瀏覽器中打開被修改的頁面。2. 直接操作這個改動。如果是新的控制元件（按鈕、輸入框、切換開關）： 點擊它、確認狀態有按預期改變，並拍下操作前後的截圖。3. 檢查瀏覽器主控台：不能有新增的錯誤或警告。4. 使用 Chrome Devtools MCP，跑一次效能追蹤，並檢查核心網頁指標（Core Web Vitals）。如果任何一步失敗，先修好問題，再從第 1 步重跑一次，不要交出只驗證一半的工作。

第二種：目標式迴圈 /goal

• 觸發方式：你即時手動下的一句提示
• 停止條件：目標達成，或是達到你設定的最高回合數
• 最適用場景：有明確、可驗證完成條件的任務
• 管理用量的方法：設定具體的完成標準，並明確訂出「最多跑幾個回合」的上限

有些任務一個回合根本做不完，尤其是比較複雜的工作。這時候與其你自己一輪一輪盯著改，不如用 /goal 這個指令（需 Claude Code v2.1.139 以上），先把「怎樣才算完成」講清楚，讓 Claude 自己反覆嘗試到達標為止。

當你把成功標準定義出來，Claude 就不用自己判斷「這樣算不算夠好」然後提早喊停。每次 Claude 想要收工，都會有一個評估模型去檢查你設的條件，沒過關就打回去繼續做，直到達成目標，或是碰到你設定的回合數上限。也因為這樣，愈明確、愈可以量化的條件（例如通過幾個測試、分數要達到多少門檻）效果愈好。

要注意的是，這個評估模型只根據對話中呈現的證據判斷，不會自己讀檔案或執行測試，所以 Claude 必須把驗證結果（例如測試輸出、分數報告）放進對話，評估才有依據。另外，/goal 不會自動改變權限模式：在預設權限模式下，該向你確認的操作仍然會停下來問，想讓它完全無人值守，要另外搭配 auto mode（見第四種迴圈）。

以下範例，把「網站首頁載入效能要衝到多少分」這種模糊需求，變成一句可以直接貼給 Claude Code 的目標式指令。

/goal 把首頁的 Lighthouse 效能分數提升到 90 分以上；如果 5 個回合後仍未達成，就停止並說明阻礙

第三種：時間式迴圈 /loop 與 /schedule

• 觸發方式：你設定的固定時間間隔
• 停止條件：固定間隔的迴圈會一直跑到你手動停止，或建立滿 7 天自動到期；未指定間隔、由 Claude 自行調節節奏的迴圈，才可能在判斷工作完成（例如 PR 被合併、待處理清單清空）後自行結束
• 最適用場景：例行重複的工作，或是需要跟外部系統互動的任務
• 管理用量的方法：間隔拉長一點，或是改成「事情發生才反應」而不是每隔固定時間都檢查一次

有些代理工作是重複性的：任務內容不變，只有輸入的資料每次不一樣，例如每天早上整理一次 Slack 訊息摘要。另一種情況是任務要跟外部系統打交道，簡單的做法就是每隔一段時間去檢查一次、看有什麼變化就反應，例如一個可能隨時被留言審查、或是 CI（持續整合測試）跑失敗的 PR（Pull Request，指你要合併進主專案的程式碼改動）。

針對這類需求，可以用 /loop 這個指令，讓同一句提示每隔固定時間重跑一次。

以下範例讓 Claude 每 5 分鐘自動檢查一次你的 PR 狀態，有審查意見或 CI 失敗就自動處理。

/loop 5m 檢查我的 PR，回覆審查意見，並修正失敗的 CI

使用 /loop 前要注意幾個限制：它跑在你自己的電腦與目前這個 Claude Code session（工作階段）中，電腦和 session 都必須保持運作，關掉任何一個，迴圈就會停止。

排程的最低間隔是 1 分鐘；週期性任務建立 7 天後會自動到期，避免被遺忘的迴圈一直跑下去。還沒到期的任務，重新開啟 session 時可以用 --resume 或 --continue 恢復。

如果想讓迴圈徹底離開你的電腦、關機後仍可運作，可以用 /schedule 這個指令建立「常駐排程任務（routine，目前為研究預覽階段）」。它不是單純把同一句提示搬上雲端，而是會引導你設定提示內容、要處理的 repository（程式碼儲存庫）、connectors（外部服務連接器）、雲端執行環境與觸發條件，之後改由 Anthropic 管理的雲端基礎設施執行。

另外，雲端週期排程的最低間隔是 1 小時，沒辦法像本機 /loop 一樣密集到每分鐘檢查。

還要注意登入方式：/schedule 必須以 claude.ai 訂閱帳號登入才能使用；如果你是透過 Console API key、Amazon Bedrock、Google Cloud 或 Microsoft Foundry 驗證，CLI 可能直接顯示「Unknown command」。此時可改到 claude.ai 網頁端建立與管理排程。

第四種：主動式迴圈

• 觸發方式：某個事件發生，或是排程時間到了，全程沒有真人即時盯著
• 停止條件：每一項任務在達成自己的目標後就結束；整套常駐排程本身則是你手動關掉才會停
• 最適用場景：持續不斷、但定義明確的工作串流，例如 bug 回報、issue 分類、系統遷移、依賴套件升級
• 管理用量的方法：把例行工作交給比較小、比較快的模型處理，遇到需要判斷力的關鍵決策才動用最強的模型

前面三種原語，再加上 Claude Code 另外兩個功能，就能組成處理長時間工作的「主動式迴圈」：

• auto mode（自動模式）：讓 Claude 不用每一步都跳出來問「要不要繼續」、直接照著做完，不必你隨時盯著授權。auto mode 會透過一個分類模型在背景檢查每個操作、擋下高風險動作，但官方也明確提醒這不保證安全，不能取代敏感操作的人工審查
• dynamic workflows（動態工作流，目前為研究預覽階段，需 Claude Code v2.1.154 以上）：讓 Claude 能把一項任務拆給多個子代理分工合作、互相審查，而不是單一個 Claude 從頭做到尾

舉例來說，如果要處理使用者陸續回報的問題，可以這樣組合：

• 用 /schedule（研究預覽階段）跑一個常駐排程，定期檢查有沒有新回報進來
• 用 /goal 定義「怎樣算做完」，並搭配技能檔（skill）寫清楚「怎麼驗證」
• 用 dynamic workflows 編排多個子代理，分別負責分類、修正、審查每一則回報
• 開啟 auto mode，讓整套流程能自己跑完，不必每一步都停下來等你點頭

以下是官方示範的功能組合概念，把上面四個功能兜在一起，讓 Claude 自己巡邏回報頻道、修 bug 並互相審查。

要提醒的是，這段指令並不是複製貼上就能直接執行：動手前必須先完成 GitHub 與 Slack connector 連接、雲端執行環境，以及前述各功能的版本與權限設定。

/schedule 每小時檢查一次 project-feedback 頻道有沒有新的 bug 回報。/goal：這一輪找到的每一則回報都要被分類、處理並回覆完才停止。修 bug 的時候，用 workflow 平行開三個 worktree（指同一份程式碼的多個獨立工作副本）分別嘗試不同解法，並安排一個裁判角色互相對照審查。

維持程式碼品質，迴圈才不會愈跑愈爛

迴圈跑出來的結果好不好，取決於你圍繞在它周邊的整套系統，而不是單靠 AI 自己聰不聰明。設計時可以照顧幾個重點：

• 保持既有程式碼本身乾淨：Claude 會跟著專案裡已經存在的寫法與慣例走，原本的程式碼愈亂，它學到的壞習慣也愈多
• 給 Claude 一套能自我檢查的方法：把「怎樣才算做得好」寫成技能檔（skill），讓標準不必每次重新口頭講一遍
• 讓官方文件容易找到：框架與函式庫的官方文件通常會寫最新的最佳實務，放在 Claude 容易讀到的地方
• 找第二個代理來做程式碼審查：一個帶著全新視角的審查者，比較不會被原本負責寫程式那個代理的思路牽著走，可以用內建的 /code-review 技能，或是搭配 GitHub 的 Code Review 功能

如果某一次的結果沒有達標，不要只修那一個問題就結束，最好把這次學到的教訓也寫進系統裡（例如更新技能檔），讓下一次迴圈也能受惠。

管理 token 用量：迴圈要有清楚的邊界

要控制 token 用量（用量愈高，會更快消耗方案額度；若使用 API 或開啟額外用量，也可能增加實際費用），迴圈本身要有清楚的邊界：

• 挑對模型：小任務不需要動用多代理或複雜迴圈，有些工作用便宜又快的模型就夠了
• 把條件講清楚：明確定義「怎樣算做完」，Claude 才能盡早收斂到解法（但也不能停得太早、隨便交差）
• 大量執行前先小規模試跑：dynamic workflows 可依工作流設計擴展到數十至數百個子代理，先在一小部分工作上測試用量，抓到感覺再放大規模
• 重複性、確定性的工作交給腳本，不要每次都靠 AI 重新推理：跑一支寫好的腳本，成本比讓 AI 每次重新想一遍怎麼做要便宜。例如處理 PDF 表單的技能，可以內建一支現成的填表腳本，Claude 每次直接執行就好，不必重新生成程式碼
• 不要跑得比實際需要更頻繁：排程間隔要對應你在意的事物「多久才會變化一次」，變化慢的東西沒必要每 5 分鐘就檢查
• 定期檢視用量：/usage 指令能列出最近的用量是花在哪些技能、子代理、MCP（外部工具連接器）上；單獨輸入 /goal（不加任何參數）會顯示目前累積的回合數與 token 用量；/workflows 能看到每個子代理各自花了多少 token，而且你隨時可以中止任何一個還在跑的代理

怎麼決定該用哪一種迴圈？

Claude Code 團隊把四種迴圈整理成一張對照表，這也是這篇方法論最實用的收尾：

迴圈類型 你交出去的是什麼 什麼時候用 對應指令 回合制迴圈 檢查這一步的動作 你還在探索或還沒決定好方向 自訂驗證用的技能檔（skill） 目標式迴圈 停止條件 你已經很清楚「做完」長什麼樣子 /goal 時間式迴圈 觸發的時機 工作是在你的專案之外、按排程發生的 /loop、/schedule 主動式迴圈 整句提示本身 工作是持續發生、而且定義明確的 以上全部功能，再加上 dynamic workflows

想開始設計自己的迴圈，可以先回頭看你目前手上的工作：挑一項你自己是瓶頸的任務，問自己「哪一部分可以交出去」？你寫得出驗證用的檢查標準嗎？目標夠明確嗎？工作是不是本來就照排程進來的？想清楚之後就先跑一次迴圈，觀察它卡在哪裡、有沒有過度擴權，發現不對就大方調整，不用一次到位。

能定義迴圈，才能掌握迴圈

這套分類法有一個前提：你要先能清楚描述「怎樣算做完」，迴圈才有意義。如果連你自己都講不出驗收標準，硬套 /goal 或主動式迴圈，只會變成 Claude 自己瞎繞，一樣要花時間收拾。

所以如果你的任務量本來就不大，或是需要每一步都親自把關（例如涉及敏感資料、對外發布的內容），回合制迴圈配合 SKILL.md 反而比堆疊複雜迴圈更划算。

先想清楚驗收標準，再決定要不要交給迴圈；先從最簡單的回合制開始試，再逐步升級到目標式、時間式、甚至主動式迴圈。

延伸閱讀：ChatGPT Skills怎麼用？@一下呼叫技能、3種建立方式教學、6組好用範例一次看

資料來源：Claude 官方部落格：Loop engineering: Getting started with loops、Claude Code 官方 X 貼文（@claudedevs）、Claude Code 官方文件：迴圈與目標設定（/goal）、Claude Code 官方文件：排程任務與 /loop、Claude Code 官方文件：常駐排程 Routines（/schedule）、Claude Code 官方文件：權限模式、Claude Code 官方文件：Dynamic Workflows、Claude Code 官方文件：指令總覽、Claude Code 官方文件：多代理協作

本文初稿為AI編撰，整理．編輯/ 李先泰

延伸閱讀

打造過濾界「晶片」！桃園新創膜淨材料攜手明基透析，布局台灣高階醫療自主供應鏈
OpenAI首款裝置曝光！設計大師艾夫操刀無螢幕AI音響，主打「具生命感」的AI伴侶
「加入《數位時代》LINE好友，科技新聞不漏接」