Claude Code 迴圈入門指南

目前有許多關於「設計循環（loop）」而非單純對你的程式 Agent 下提示詞的討論。如果你花點時間在 X 上試圖釐清循環究竟是怎麼一回事，你會看到多種不同的答案。

在 Claude Code 團隊中，我們將循環定義為 Agent 重複執行工作週期，直到滿足停止條件為止。我們根據以下幾點來區分幾種不同類型的循環：

• 觸發方式
• 停止方式
• 使用的 Claude Code 原始指令
• 最適合處理哪種任務

本文將涵蓋主要的循環類型、各自的使用時機，以及如何在管理 token 用量的同時維持程式碼品質。並非所有任務都需要複雜的循環；建議從最簡單的方案開始，並有選擇地使用這些模式。

回合制循環

• 觸發方式：使用者提示詞。
• 停止條件：Claude 判斷任務已完成或需要更多資訊。
• 最佳適用於：不屬於定期流程或排程的較短任務。
• 用量管理方式：撰寫具體的提示詞，並利用技能（skills）改善驗證機制，以減少所需回合數。

你發送的每個提示詞都會啟動一個手動循環，由你引導每個回合。Claude 收集上下文、採取行動、檢查自己的工作、必要時重複執行，然後回應。我們稱之為 agentic 循環。

舉例來說，要求 Claude 建立一個讚按鈕。它會讀取你的程式碼、進行編輯、執行測試，然後回傳一個它認為可運作的結果。接著你手動檢查成果，並寫下一個提示詞。

你可以將手動步驟編碼成 SKILL.md 檔案，讓 Claude 能端到端地自行檢查更多工作，從而改善驗證環節。這應包含讓 Claude 能夠看到、衡量或與結果互動的工具或連線功能。檢查項目越量化，Claude 越容易自我驗證。

例如，在你的 SKILL.md 檔案中你可以指定：

1---
2name: verify-frontend-change
3description: 在宣告完成前，端到端驗證任何 UI 變更。
4---
5
6# 驗證前後端變更
7切勿僅根據編輯成功就回報 UI 變更已完成。請像人類審查者一樣進行驗證：
8
91. 啟動開發伺服器，並在瀏覽器中開啟已編輯的頁面。
10
112. 直接與變更互動。對於新的控制項（按鈕、輸入框、切換開關）：點擊它，確認預期的狀態變更，並截取前後對比圖。
12
133. 檢查瀏覽器主控台：不得有任何新的錯誤或警告。
14
154. 使用 Chrome Devtools MCP，執行效能追蹤並審核 Core Web Vitals。
16
17如果任何步驟失敗，請修正問題並從步驟 1 重新執行 —— 不要回傳未完全驗證的成果。

目標導向循環（/goal）

• 觸發方式：即時的手動提示詞。
• 停止條件：達成目標 或 達到最大回合數。
• 最佳適用於：具有可驗證退出條件的任務。
• 用量管理方式：設定明確的完成條件和指定回合上限，例如「嘗試 5 次後停止」。

有時候單一回合是不夠的，特別是對於較複雜的任務。Agent 在能夠迭代時表現更好。你可以透過 /goal 定義「完成」的樣貌，來延長 Claude 持續迭代的時間。

當你定義好成功標準後，Claude 就不需要自行判斷什麼是「夠好了」而提前結束循環。每次 Claude 試圖停止時，一個評估模型會檢查你的條件，並在條件達成或達到你定義的回合數之前，將它送回繼續工作。

這就是為什麼確定性條件（例如通過的測試數量或達到某個分數門檻）如此有效。

例如：

1/goal 讓首頁 Lighthouse 分數達到 90 以上，嘗試 5 次後停止。

時間驅動循環（/loop 和 /schedule）

• 觸發方式：指定的時間間隔。
• 停止條件：你取消它，或工作完成（PR 合併、佇列清空）。
• 最佳適用於：重複性工作，或與外部環境/系統對接。
• 用量管理方式：設定較長的間隔，或根據事件（而非時間）做出反應。

某些 Agent 工作是重複性的：任務保持不變，只有輸入會變化。例如每天早上彙整 Slack 訊息。其他工作則依賴外部系統，與之對接的一個簡單方法就是定期檢查並對變化做出反應。例如，一個可能收到程式碼審查或 CI 失敗的 PR。

針對這些情況，你可以使用 /loop 觸發 Claude 定期重複執行提示詞。例如：

1/loop 5m 檢查我的 PR，處理審查意見，修正失敗的 CI

/loop 在你的電腦上執行，所以如果你關機，它就會停止。你可以透過建立例行任務（/schedule）將循環移至雲端。

主動式循環

• 觸發方式：事件或排程，無需人類即時參與。
• 停止條件：每個任務在達成目標時退出。例行任務本身會持續執行直到你關閉它。
• 最佳適用於：重複出現且定義明確的工作串流：錯誤報告、問題分類、遷移、依賴套件升級等。
• 用量管理方式：將例行任務路由到較小、較快速的模型，並使用最強大的模型進行判斷。

上述的原始指令，以及其他 Claude Code 功能如 自動模式（auto mode）和動態工作流程（dynamic workflows）（研究預覽版）可以組合成適用於長時間工作的循環。

例如，為了處理收到的回饋，你可以使用：

1. `/schedule`（研究預覽版）來執行一個例行任務，檢查是否有新的報告
2. `/goal` 來定義完成的樣貌，以及技能（skills）來記錄如何驗證
3. 動態工作流程來編排 Agent，對每份報告進行分類、修正並審查修正
4. 自動模式讓例行任務在執行時無需停下來請求許可

綜合起來，一個提示詞可能長這樣：

1/schedule 每小時：檢查 project-feedback 頻道中的錯誤報告。 /goal：在本次執行的每份報告都被分類、處理並回應之前不要停止。修正錯誤時，使用工作流程在三個並行工作樹中探索解決方案，並讓一個裁判對其進行對抗性審查。

維持程式碼品質

循環輸出的品質取決於其周圍的系統。在設計系統時：

• 保持程式碼庫本身整潔：Claude 會遵循你程式碼庫中既有的模式和慣例。
• 給 Claude 一個驗證自己工作的方法：透過技能（skills）將你與團隊認為「好」的標準編碼起來。
• 讓文件易於取得：框架與函式庫的文件應包含最新的最佳實務。
• 使用第二個 Agent 進行程式碼審查：擁有全新上下文的審查者較不帶偏見，也不會受到主要 Agent 推理過程的影響。你可以使用內建的 /code-review 技能或適用於 Github 的 Code Review。

當個別結果未達標準時，不要只修正單一問題，試著將其編碼起來，以改善整個系統在未來所有迭代中的表現。

管理 Token 用量

為了管理 token 用量，循環應有明確的邊界：

• 為工作選擇正確的原始指令和模型：較小的任務不需要多個 Agent 或循環。某些任務可以使用較便宜且較快速的模型。
• 定義明確的成功與停止條件：具體說明「完成」的樣貌，讓 Claude 能更快（但也不要太快）得出解決方案。
• 在大規模執行前先進行試點：動態工作流程可能產生數百個 Agent。先在較小的工作區塊上評估用量。
• 對確定性工作使用腳本：執行腳本比逐步推理更便宜。例如，一個 PDF 技能可以提供一個填寫表單的腳本，讓 Claude 每次執行，而不需重新推導程式碼。
• 不要比你需要更頻繁地執行例行任務：將間隔時間設定為與你關注的項目變化頻率相匹配。
• 檢視用量：/usage 指令可細分近期按技能、子 Agent 和 MCP 的用量；不帶參數的 /goal 會顯示迄今的回合數和 token 用量；/workflows 會顯示每個 Agent 的 token 用量，你可以隨時停止任何 Agent。

開始使用

總結如下：

循環

你交出控制權的對象

使用時機

選用

回合制

檢查動作

你在探索或做決定

自訂驗證技能

目標導向

停止條件

你知道完成的樣貌

/goal

時間驅動

觸發條件

工作在專案外部按排程進行

/loop

、

/schedule

主動式

提示詞

工作是重複且定義明確的

以上全部，以及動態工作流程

要開始使用循環，請檢視你已經在做的工作。選擇一個你目前是瓶頸的任務，並思考你可以交出哪個部分：你能寫出驗證檢查嗎？目標夠明確嗎？工作是按排程到達的嗎？

一旦你有想法，就執行循環，觀察結果（例如它在哪裡停滯或過度延伸），並勇於對其進行迭代。

更多資訊，請參閱 Claude Code 文件中有關並行執行 Agent 以及循環、排程、目標和動態工作流程的頁面。

本文由 @delba_oliveira 撰寫*