{"content_id":"z9qcc6lzi3","slug":"claude-code-loop-engineering-guide","locale":"zh-hant","schema_type":"TechArticle","category":"tutorial","category_name":"教學課程","title":"Claude Code Loop Engineering 指南：4種 Loop 與安全自動化設計","summary":"Claude Code 的 Loop 是一種控制結構，使 Agent 反覆執行觀察、行動與驗證，直到達到結束條件。本文說明四種 Loop 類型的差異，以及包含驗證證據、Hard stop、冪等性、成本、最小權限在內的實務設計方法。","author":{"name":"Injoys Admin","url":"https://injoys.com/ko/about"},"key_points":["Claude Code 的 Loop 不是程式碼迴圈，而是讓 Agent 反覆執行觀察、行動、驗證直到達到結束條件的 Agent 執行結構。","Turn-based 將驗證程序、Goal-based 將結束判斷、Time-based 將重新執行時點、Proactive 將工作開始與編排交給系統。","良好的 Loop 必須具備可測量的完成條件、外部驗證證據、強制結束、冪等性與最小權限。","`/goal` 評估模型只判斷對話中呈現的證據，因此必須明確回報測試輸出、結束代碼與變更範圍。","決定性轉換應以 Script 處理，而 Dynamic Workflow 與多個 Agent 只應用於確實需要並行性的大規模工作。"],"content_markdown":"Claude Code 的 Loop 不只是讓模型長時間執行的功能。核心在於在以機率方式行動的 AI Agent 周圍配置 **Trigger, Verifier, Success condition, Hard stop, Permission boundary**，把重複工作變成可控的系統。本文一次整理 Turn-based, Goal-based, Time-based, Proactive Loop 的差異與實務設計原則。\n\n## 1. Claude Code 中的 Loop 是什麼\n\n這裡的 Loop 不是程式語言中的 `for` 或 `while` 敘述。Claude Code 團隊所說明的 Loop，是 Agent 觀察目前狀態、採取行動、驗證結果，然後在結束條件被滿足前反覆工作的執行結構。\n\n```text\n工作開始\n  ↓\n掌握狀態與程式碼\n  ↓\n制定計畫\n  ↓\n修改程式碼或執行工具\n  ↓\n測試·驗證\n  ↓\n滿足完成條件？\n  ├─ 否：下一次迭代\n  └─ 是：結束並回報結果\n```\n\n區分 Loop 時，以下四個問題很有用。\n\n1. 是什麼啟動工作？\n2. 是什麼結束工作？\n3. 哪個 Claude Code 功能控制重複？\n4. 適合哪一類工作？\n\n不需要把所有工作都做成複雜的 Loop。像修正單一檔案的錯字或單純改名這類結果可立即確認的工作，一般 Prompt 更有效率。只有在實際需要多次觀察·修改·驗證時，才應選擇 Loop。\n\n## 2. 四種 Loop 類型比較\n\n| 類型 | 開始條件 | 結束條件 | 主要使用功能 | 適合的工作 | 人交出的責任 |\n|---|---|---|---|---|---|\n| Turn-based | 使用者的 Prompt | Claude 判斷已完成或需要追加資訊時 | 一般對話、Skills、測試·瀏覽器工具 | 短且一次性的實作·修改 | 重複驗證程序 |\n| Goal-based | 使用者指定完成條件 | 評估模型確認條件滿足或使用者中斷 | `/goal`，必要時 Auto mode | 像測試·建置·遷移這類完成狀態可測量的工作 | 結束判斷 |\n| Time-based | 指定的時間·間隔·排程 | 使用者取消或外部工作結束 | `/loop`, `/schedule` | PR·CI·部署監控、定期摘要、狀態 Polling | 下次執行時間點 |\n| Proactive | 排程、API、GitHub 事件等 | 個別工作的目標滿足、Routine 停用 | Routines, `/goal`, Skills, Dynamic Workflows, Auto mode | 議題分類、錯誤處理、大規模遷移等持續性業務 | 工作發現、Prompt 執行、編排 |\n\n這個分類的核心不是「AI 有多聰明」，而是**人把哪些控制責任交給系統**。在 Turn-based 中，人製作下一個 Prompt；在 Goal-based 中，交出完成判斷；在 Time-based 中，交出重新執行時間點。到了 Proactive 階段，連偵測工作發生並執行適當 Prompt 的責任，也會移到系統。\n\n## 3. Turn-based Loop：交出驗證程序\n\nTurn-based Loop 是大多數開發者使用 Claude Code 的基本形式。\n\n```text\nHuman → Claude → Human → Claude\n```\n\n使用者提出請求後，Claude 會尋找相關檔案、修改程式碼、測試並回報結果。內部可能發生多次觀察·行動·驗證，但啟動下一個工作的權限仍留在使用者手上。\n\n### 修改程式碼與完成功能不同\n\n即使 Claude 回報「已完成實作與測試」，實際產品中仍可能留下以下問題。\n\n- 點擊按鈕後狀態沒有改變。\n- 瀏覽器 Console 發生錯誤。\n- 行動版版面破掉。\n- 缺少無障礙屬性。\n- 測試通過，但實際瀏覽器流程失敗。\n- 連與變更無關的檔案也被修改。\n\n因此完成標準不應是「改了程式碼」，而應是「以外部證據確認動作」。\n\n### 用 `SKILL.md` 重複使用驗證\n\nSkill 是把重複使用的指引與程序保存在 `SKILL.md` 的方式。Claude 可判斷相關性後自動載入，或用 `/skill-name` 直接執行。與其總是把冗長的營運程序放進 `CLAUDE.md`，不如分離成只在需要時載入 Skill，這樣能更有效率地使用 Context。\n\n```markdown\n---\nname: verify-ui-change\ndescription: 在將 UI 變更視為完成前，於實際執行環境中驗證。\n---\n\n# UI 變更驗證\n\n1. 執行開發伺服器。\n2. 在瀏覽器中開啟變更後的畫面。\n3. 實際操作新的控制項。\n4. 確認是否發生預期的狀態變化。\n5. 確認瀏覽器 Console 中的新錯誤與警告。\n6. 檢查無障礙與主要效能指標。\n7. 若失敗，修正後從頭重新驗證。\n8. 回報執行過的命令、結果、截圖等證據。\n```\n\n好的 Skill 包含的不是抽象的叮囑，而是可執行的 Checklist。比起「更謹慎地檢討」，「確認 `npm test` 是否以結束碼 0 結束」是強得多的規則。\n\n### 驗證證據的強度\n\n| 證據 | 可信度 | 原因 |\n|---|---:|---|\n| Agent 說明「看起來應該正常」 | 低 | 不是執行結果，只是推論 |\n| 程式碼 Diff 與靜態檢討 | 中 | 看得到變更內容，但無法確認 Runtime 動作 |\n| 實際測試輸出與結束碼 | 高 | 存在可重現的外部結果 |\n| 瀏覽器互動、截圖、Console·效能結果 | 非常高 | 直接驗證使用者路徑與 Runtime 狀態 |\n| 獨立 Review Agent 與 CI 得出相同結論 | 非常高 | 降低實作 Agent 的自我確認偏誤 |\n\nClaude Code 官方文件也說明了像確認執行中應用程式的 `/run`、在實際執行環境中驗證變更的 `/verify` 這類 bundled Skill。若專案執行方式複雜，將精確的啟動命令、環境變數、資料準備程序記錄在團隊專屬 Skill 中會更安全。\n\n## 4. Goal-based Loop：交出結束判斷\n\nGoal-based Loop 不需要使用者每次決定「是否再做一次」。使用者定義完成狀態，Claude 會持續多個 Turn，直到該條件被滿足。\n\n```text\n使用者指定 Goal\n  ↓\nClaude 工作 Turn\n  ↓\n另外的評估模型確認完成條件\n  ├─ 未滿足：將原因傳給下一個 Turn\n  └─ 滿足：Goal 結束\n```\n\n`/goal` 已文件化為可在 Claude Code v2.1.139 以上版本使用。一個 Session 只能啟用一個 Goal。\n\n### 評估模型實際上看的是什麼\n\n每個 Turn 結束後，另外的 small fast model 會查看完成條件與對話內容，判斷 `滿足` 或 `未滿足`。預設設定是 Haiku 系列評估模型。重要限制是，評估模型不會直接讀取檔案或另外執行測試。\n\n因此執行工作的 Claude 必須在對話中明確留下以下證據。\n\n- 執行過的命令\n- 測試數量與通過·失敗結果\n- 結束碼\n- 建置結果\n- 變更檔案清單\n- 剩餘失敗原因\n- 確認遵守範圍限制的結果\n\n評估模型判斷的不是「實際發生了什麼」，而是「對話中呈現了哪些證據」。\n\n### 好 Goal 的四個要素\n\n好的 Goal 包含以下四個要素。\n\n1. **可測量的成功條件**：測試通過、建置成功、Queue 清空、達到分數門檻\n2. **驗證方法**：明示用什麼命令或工具證明成功\n3. **變更範圍限制**：可修改的目錄、禁止檔案、允許的 Side effect\n4. **強制結束條件**：最大 Turn、最大時間、連續失敗次數、權限錯誤時中斷\n\n```text\n/goal auth 相關測試與 lint 全部成功，\ngit diff 只能包含 src/auth 與相關測試檔案。\n每個 Turn 回報執行結果與結束碼。\n達到最多 12 Turn 或 45 分鐘時中斷，並整理剩餘失敗。\n```\n\n`/goal` 本身的核心結束條件是評估模型的成功判定，或使用者的 `/goal clear`。若要強制 Turn·時間限制，必須在 Goal 條件中明示。\n\n### 好條件與壞條件\n\n| 好條件 | 壞條件 |\n|---|---|\n| `npm test` 以結束碼 0 結束 | 把程式碼做得完美 |\n| 48 個認證相關測試全部通過 | 盡可能改善使用者體驗 |\n| 所有 API 呼叫點改成新介面且建置成功 | 重構成更好的結構 |\n| 待處理 Issue Queue 清空，且每個 Issue 記錄結果 | 盡可能處理更多 Issue |\n\n模糊的目標可能太快結束，也可能無止境地反覆改善。\n\n### 狀態確認與中斷\n\n- `/goal`：確認啟用條件、執行時間、評估 Turn 數、Token 使用量、最近評估理由\n- `/goal clear`：中斷啟用中的 Goal\n- 設定新 Goal：取代既有 Goal\n- `--resume` 或 `--continue`：可復原未完成的 Goal\n\n恢復時條件會維持，但 Turn 數、時間、Token 基準線可能被初始化，因此建議將 Hard stop 與營運指標一起管理。\n\n### `/goal` 與權限是兩回事\n\n`/goal` 只會自動啟動下一個 Turn，不會擴大工具權限。若檔案寫入、測試命令、Git 操作屬於需核准對象，在 Goal 期間也可能需要核准。\n\n無人執行時可搭配 Auto mode，但 Auto mode 不是「無條件允許所有工具」的功能。分類器會阻擋破壞性、難以復原或以信任邊界外為對象的工作，而明確的 `ask` 與 `deny` 規則會優先於分類器套用。\n\n## 5. Time-based Loop：交出重新執行時間點\n\n如果 Goal-based Loop 處理的是「何時停止」，Time-based Loop 處理的就是「何時再次執行」。它適合外部系統狀態會隨時間改變的工作。\n\n- 確認 PR 是否有新的 Review\n- 確認 CI 或部署是否結束\n- 確認長時間建置狀態\n- 每日 Slack 訊息摘要\n- 確認 Issue Queue 的新項目\n\n### `/loop`：在目前 Session 中反覆執行\n\n```text\n/loop 10m 確認目前 PR 並反映新的 Review，\n若有失敗的 CI，分析原因並修正。\n```\n\n目前文件說明的主要形式如下。\n\n| 輸入 | 動作 |\n|---|---|\n| `/loop 5m \u003cprompt\u003e` | 以指定固定間隔執行 Prompt |\n| `/loop \u003cprompt\u003e` | Claude 在每次重複時選擇間隔 |\n| `/loop` | 執行 built-in 維護 Prompt 或專案的 `loop.md` |\n| `/loop 20m /review-pr 1234` | 以指定間隔重新執行允許的 Skill |\n\n`/loop` 依附於目前的 Claude Code Session。電腦與 Session 必須正在執行，若開始新的對話，Session 範圍的工作會消失。未過期工作可用 `--resume` 或 `--continue` 復原，但重複工作基本上會在建立後 7 天過期。它也不會把錯過的週期全部追溯執行。\n\nSession Scheduler 可能套用 Jitter，因此可能不適合「必須整點執行」的營運需求。\n\n### `/schedule`：Anthropic 管理的 Cloud Routine\n\n`/schedule` 會把 Prompt、Repository、Connector、Trigger 綁在一起，建立在 Anthropic 管理基礎設施上執行的 Routine。即使關上筆電也能執行，官方文件將其介紹為 Research Preview。\n\nRoutine 支援的 Trigger 如下。\n\n- 重複排程\n- 特定未來時間點的一次性排程\n- 已驗證的 API 呼叫\n- GitHub Pull request 或 Release 事件\n\n一個 Routine 可以連接多個 Trigger。例如可讓 PR Review Routine 每晚執行，同時也對 `pull_request.opened` 事件做出反應。\n\n### `/loop` 與 `/schedule` 比較\n\n| 區分 | `/loop` | `/schedule` Routine |\n|---|---|---|\n| 執行位置 | 目前電腦與 Session | Anthropic 管理的 Cloud |\n| 電腦關閉後執行 | 通常不可 | 可以 |\n| 是否需要開啟 Session | 需要 | 不需要 |\n| 本機未 Commit 檔案 | 可存取 | 不可存取，每次執行都重新 Clone Repository |\n| 最小間隔 | 依官方文件為 1 分鐘 | 依官方文件為 1 小時 |\n| 持續性 | 以 Session 為中心，重複工作 7 天過期 | 儲存在帳號中的 Routine |\n| 權限 Prompt | 繼承目前 Session 政策 | 無互動式核准而自主執行 |\n| 適合用途 | 短期 PR·部署監控 | 持續性營運自動化 |\n\n### Event 比 Polling 更好的情況\n\n若每 1 分鐘確認一次變更很少的 PR，大多數執行都會什麼也不做就結束。如果外部系統能送出事件，以下結構更有效率。\n\n```text\nCI 失敗或 PR 更新\n  ↓\nGitHub Trigger 或 Routine API\n  ↓\n只在需要時執行 Claude\n```\n\nEvent-based 設計能降低延遲，並減少不必要的模型呼叫與 Token 消耗。若 Polling 不可避免，最好依實際變更頻率拉長間隔，且在長時間沒有變化時套用 Backoff。\n\n### 時間型工作的必要條件\n\n1. **冪等性**：即使多次收到相同事件，也不應產生重複留言、重複 PR、重複部署。\n2. **處理狀態**：必須記錄最後處理的 Event ID、Commit SHA、Review Comment ID 等。\n3. **結束狀態**：必須能判斷像 PR merge·close、Queue empty、Deploy success·rollback 這樣的結束。\n4. **寫入範圍**：必須限制 Side effect，例如允許留言、禁止 Merge、只 Push `claude/*` Branch。\n5. **失敗處理**：外部服務障礙、驗證過期、Rate limit、權限不足時，需要重試與 Escalation 規則。\n\n## 6. Proactive Loop：交出工作發現與編排\n\nProactive Loop 不是單一命令，而是結合多個功能的常駐自動化架構。\n\n```text\nTrigger\n+ Goal\n+ Skills\n+ Dynamic Workflow\n+ Auto mode\n+ Repository·Connector·Browser·CI 工具\n```\n\n即使人不即時輸入 Prompt，新工作也會被偵測、處理、驗證並回報結果。\n\n### 範例：自動處理錯誤回饋\n\n```text\n收到 GitHub Issue 或 Slack 回饋\n  ↓\n分類重複·優先順序·可重現性\n  ↓\n建立重現測試\n  ↓\n探索候選解法\n  ↓\n實作選定解法\n  ↓\n獨立 Review Agent 探索反例\n  ↓\n測試·建置·安全驗證\n  ↓\nDraft PR 與結果回報\n```\n\n各組成要素的責任如下。\n\n| 組成要素 | 責任 |\n|---|---|\n| Trigger 或 `/schedule` | 決定啟動新工作的時間點 |\n| `/goal` | 定義這次執行中什麼是完成狀態 |\n| Skill | 標準化重現、實作、驗證、回報程序 |\n| Dynamic Workflow | 多個 Subagent 的平行執行與條件分支 |\n| Auto mode | 無需等待核准就執行允許的工具呼叫 |\n| Permission policy | 固定禁止·核准·自動允許範圍 |\n\n### Dynamic Workflow 與 Worktree\n\nDynamic Workflow 是由 Claude 撰寫的 JavaScript 編排 Script，交由 Runtime 執行的結構。在一般 Subagent 呼叫中，Claude 會在每個 Turn 選擇下一個 Agent；但在 Workflow 中，Loop、平行處理、分支、中間結果儲存會移到 Script。\n\n```text\nWorkflow Script\n  ├─ Agent A：需求分析\n  ├─ Agent B：測試設計\n  ├─ Agent C：實作候選探索\n  ├─ Agent D：安全檢討\n  └─ Judge：以證據為基礎比較\n```\n\n由於中間結果不是留在主要對話 Context，而是留在 Script 變數中，因此可更可重現地組織大型工作。現行文件明示 Runtime 限制為同時最多 16 個 Agent、每次執行最多 1,000 個 Agent，但產品 Preview 階段的限制可能改變。\n\n如果必須同時測試多個實作候選，可以用 Git Worktree 分離工作空間。\n\n```text\nrepo/\nworktree-solution-a/\nworktree-solution-b/\nworktree-solution-c/\n```\n\n各 Agent 在獨立 Branch 與目錄中工作，可減少同時覆寫相同檔案的問題。Judge Agent 應以需求滿足、測試結果、回歸風險、變更範圍、複雜度、效能、安全、與既有架構的一致性為基準比較候選。\n\n### 更多 Agent 不一定總是更好\n\n對沒有平行性的工作只增加 Agent 數量，會提高成本與延遲。若多個 Agent 共享同一個錯誤假設，錯誤也可能被放大。\n\nDynamic Workflow 適合以下情況。\n\n- 對數百個檔案套用相同轉換的 Migration\n- 整個 Codebase 的安全·品質 Audit\n- 比較多個獨立觀點的 Plan\n- 必須分割處理大量項目並交叉驗證的 Research\n- 難以把所有中間結果放進單一 Agent Context 的工作\n\n小型錯誤修正、單一檔案重構、單純新增測試，使用一般 Turn-based Loop 或 `/goal` 更好。\n\n## 7. 在 Loop 中維持程式碼品質的系統\n\nLoop 結果的品質不只受模型本身影響，也很大程度取決於模型周圍的驗證系統。\n\n### 7.1 整理 Codebase\n\nClaude 會強烈遵循既有程式碼的模式。如果存在舊 API、重複實作、不明確的測試結構、巨大模組、不一致的例外處理規則，Loop 可能快速複製這些問題。\n\n必要基礎如下。\n\n- Formatter 與 lint\n- 明確的目錄與模組邊界\n- 可信賴的 Unit·Integration·E2E Test\n- 區分使用中的 API 與 Deprecated API\n- 專案別開發規則\n- 可重現的 Build·Dev 環境\n\n### 7.2 依變更類型建立 Definition of Done\n\n| 變更類型 | 最小驗證 |\n|---|---|\n| API | Contract 測試、向下相容性、Schema·文件範例更新 |\n| Frontend | 實際瀏覽器操作、Console 錯誤、無障礙、響應式畫面 |\n| Database | Forward·Rollback Migration、Lock 範圍、執行計畫 |\n| Dependency | Build、主要回歸測試、License·Security 確認 |\n| Infrastructure | Plan Diff、最小權限、Rollback、秘密資訊外洩檢查 |\n\n與其每次在 Prompt 中冗長重複這些標準，不如固定在 Skill、Hook、Script、CI Rule 中。\n\n### 7.3 提供最新文件與準確版本\n\nLoop 可能多次重複錯誤假設。必須讓它能容易找到專案使用的準確 Version、官方文件、內部 Architecture 文件、API 規格、Migration Guide、已核准範例。\n\n### 7.4 分離實作 Agent 與 Review Agent\n\n實作的 Agent 已經受所選設計與推論影響。新 Context 的 Review Agent 可以更獨立地提出以下問題。\n\n- 是否削弱測試來讓它通過？\n- 是否修改了範圍外檔案？\n- 安全邊界是否被破壞？\n- 是否遺漏失敗路徑與邊界值測試？\n- 既有功能是否發生回歸？\n\nReview Prompt 與其寫「摘要優點」，不如寫成「在假設實作錯誤的前提下尋找反例，並為每個指摘附上重現證據」，這樣更有效。\n\n### 7.5 將個別失敗連結到系統改善\n\n若相同錯誤反覆發生，不應只修正該次結果。必須改變以下其中一項，讓該失敗類型更難再次發生。\n\n- 新增 Regression Test\n- 強化 Skill 驗證程序\n- 新增 `CLAUDE.md` 規則\n- 新增 Hook 或 lint Rule\n- 新增權限 Deny Rule\n- 強化 Goal 的完成條件\n- 補強 Review Checklist\n\n好的 Loop Engineering 不是修正一次失敗的工作，而是**建立讓該類失敗更難再次出現的系統**。\n\n## 8. Token 與成本管理\n\nLoop 成本可能比單一 Prompt 大幅增加。\n\n```text\n總成本 ≈\n主要 Agent Turn 成本\n+ Goal 評估成本\n+ Subagent 成本\n+ Workflow 重複成本\n+ 讀取工具結果的 Context 成本\n+ 時間型執行頻率\n```\n\n精確計費會依 Plan、Model、Provider 而異，但決定成本結構的原理相同。\n\n### 降低成本的實務原則\n\n1. **小工作不要使用 Loop。** 錯字、改名、單一檔案的型別錯誤用單一 Turn 處理。\n2. **同時設置成功條件與 Hard stop。** 同時考慮成功、最大 Turn、最大時間、連續失敗、權限錯誤。\n3. **大型 Workflow 先在小範圍測試。** 以 5 個檔案、一個目錄、部分 Issue 驗證成本與品質後再擴大。\n4. **決定論工作用 Script 處理。** AST 取代、JSON 轉換、Formatting、固定格式產生，用已驗證的 Script 更便宜且可重現。\n5. **將 Polling 週期配合實際變更頻率。** 可以的話使用 Event Trigger。\n6. **觀察進行中的使用量。** 在 `/usage`, `/goal`, `/workflows` 確認 Skill·Subagent·MCP·Turn·Token 使用量。\n7. **同一錯誤重複時不要持續重試。** 設定連續失敗上限，並 Escalation 給人。\n\n### Model 與 Effort 是不同槓桿\n\n- **Model** 會改變基本推論能力與可解決問題的範圍。\n- **Effort** 會改變讀取檔案數、使用工具數、驗證廣度，以及多階段工作能否推進到底。\n\n如果 Claude 已確認所有必要檔案與測試，但判斷本身持續錯誤，可能需要更強的 Model。相反地，如果它沒有讀重要檔案、跳過測試，或重構做到一半就停止，提高 Effort 可能更適當。\n\n## 9. 權限與安全邊界\n\nProactive Loop 中最危險的設計，是給 Agent 寬泛權限，卻把成功條件與中斷條件設得寬鬆。\n\nAuto mode 會減少一般權限 Prompt，但對難以復原、破壞性或以信任邊界外為對象的 Tool call，分類器可能會阻擋。此外，明確的 `permissions.ask` 與 `permissions.deny` 會優先於 Auto mode。\n\n### 權限層級範例\n\n| 層級 | 範例 |\n|---|---|\n| 自動允許 | 讀取程式碼、測試·lint·Build、分析、建立 `claude/*` Branch、建立 Draft PR |\n| 人工核准 | 反映到 Default Branch、正式環境部署、套用 DB Migration、傳送外部客戶訊息 |\n| 一律禁止 | Force push、輸出 Secret、刪除正式環境資料、繞過權限、移除稽核日誌 |\n\n比起在對話中說一次「不要 Push」，固定成永久 `ask`·`deny` Rule 更安全。因為 Context 壓縮或 Session 變更可能削弱對話規則。\n\nCloud Routine 每次執行都會重新 Clone Repository，並以連接的 GitHub·Connector 權限運作。必須最小化以下範圍。\n\n- 可存取的 Repository 與 Branch\n- 允許的 Network Domain\n- 使用的 Connector\n- 環境變數與 Secret\n- 外部系統寫入權限\n- PR 建立·Push·Merge 範圍\n\nRoutine 執行清單中的「正常結束」狀態，可能只表示 Session 在沒有 Infrastructure 錯誤的情況下結束，並不保證業務目標成功。必須另外檢討 Transcript、Test evidence、產生的 Diff。\n\n## 10. 開發專案用 Loop 設計 Template\n\n以下 YAML 不是實際 Claude Code 語法，而是設計檢討用 Template。\n\n```yaml\ntrigger:\n  type: manual | interval | schedule | github_event | api_event\n\nscope:\n  repositories:\n    - target-repository\n  allowed_paths:\n    - src/**\n    - tests/**\n  prohibited_paths:\n    - production/**\n    - secrets/**\n\ntask:\n  objective: 要變更或處理的目標\n  input: 新進來的 Issue、Event、File 或狀態\n\nverification:\n  commands:\n    - unit-test\n    - integration-test\n    - lint\n    - build\n  runtime_checks:\n    - browser-interaction\n    - console-errors\n    - accessibility\n  evidence:\n    - command-output\n    - exit-code\n    - test-summary\n    - screenshots\n\nsuccess:\n  condition: 可判定真假的完成狀態\n\nstop:\n  max_turns: 12\n  max_duration_minutes: 45\n  max_consecutive_failures: 3\n  stop_on_permission_error: true\n  escalate_on_external_outage: true\n\nside_effects:\n  idempotency_key: event-id-or-commit-sha\n  allow_branch_push: claude/*\n  require_human_for_merge: true\n  require_human_for_deploy: true\n\nreview:\n  independent_agent: true\n  adversarial_review: true\n\nobservability:\n  report_progress: true\n  report_token_usage: true\n  report_changed_files: true\n  report_remaining_failures: true\n```\n\n最重要的項目不是 Prompt 句子本身，而是以下五項。\n\n```text\nTrigger\nVerifier\nSuccess condition\nHard stop\nPermission boundary\n```\n\n## 11. 應該選擇哪種 Loop\n\n| 情況 | 建議方式 |\n|---|---|\n| 一次修改與驗證即可結束的工作 | Turn-based |\n| 需要多次嘗試但完成狀態明確的工作 | `/goal` |\n| 需要短暫等待外部 CI·PR·部署狀態的工作 | `/loop` |\n| 即使關上筆電也必須重複執行的業務 | `/schedule` Routine |\n| 必須立即回應 GitHub 事件或 Alert 的業務 | Event-triggered Routine |\n| 必須平行處理數百項並交叉驗證的業務 | Dynamic Workflow |\n| 輸入與輸出規則完全決定論的轉換 | Script 或 CI Job |\n\n選擇順序應以「達成目標的最簡單控制結構」為基準，而不是「最強大的功能」。\n\n## 12. 安全導入順序\n\n1. 選一個人反覆確認的瓶頸業務。\n2. 先用 Skill、Script、CI 建立驗證程序。\n3. 在 Turn-based 方式中穩定驗證品質。\n4. 若完成狀態明確，加入 `/goal`。\n5. 只有在必須等待外部狀態時使用 `/loop`。\n6. 若需要長期執行，移到 `/schedule` Routine。\n7. 只有在冪等性、權限、成本都經過驗證後，才擴展到 Dynamic Workflow 與 Proactive Loop。\n\n## 13. 常見誤解\n\n| 誤解 | 正確解讀 |\n|---|---|\n| Loop 是無限執行 | 它是具有成功條件與 Hard stop 的受限重複結構 |\n| Agent 的完成回報就是驗證 | 需要外部命令輸出、結束碼、Runtime 結果 |\n| `/goal` 會自動允許所有權限 | 它只會自動啟動下一個 Turn，權限政策是另一回事 |\n| `/loop` 是長期營運 Scheduler | 它以 Session 為中心，且有 7 天過期與執行環境限制 |\n| Agent 越多結果越好 | 只有在角色·觀點·驗證不同時，平行化才有價值 |\n| 所有重複工作都應由 LLM 執行 | 決定論部分用 Script 更便宜且可重現性更高 |\n\n## 結論\n\nLoop Engineering 不是讓 AI 執行更久的技術，而是**設計控制系統，使 AI 在錯誤時能自行發現、在成本限制內修正，並在危險位置停止**。\n\nLLM 擅長探索、推論、實作、例外分析、替代方案比較。系統應負責執行時間點、變更範圍、驗證方法、結束標準、成本限制、核准邊界。這種角色分工越明確，Claude Code 自動化就越能超越單純的程式碼生成工具，接近可重現且可稽核的開發營運系統。","content_html":"\u003cp\u003eClaude Code 的 Loop 不只是讓模型長時間執行的功能。核心在於在以機率方式行動的 AI Agent 周圍配置 \u003cstrong\u003eTrigger, Verifier, Success condition, Hard stop, Permission boundary\u003c/strong\u003e，把重複工作變成可控的系統。本文一次整理 Turn-based, Goal-based, Time-based, Proactive Loop 的差異與實務設計原則。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#1-claude-code-中的-loop-是什麼\" class=\"anchor\" id=\"1-claude-code-中的-loop-是什麼\"\u003e\u003c/a\u003e1. Claude Code 中的 Loop 是什麼\u003c/h2\u003e\n\u003cp\u003e這裡的 Loop 不是程式語言中的 \u003ccode\u003efor\u003c/code\u003e 或 \u003ccode\u003ewhile\u003c/code\u003e 敘述。Claude Code 團隊所說明的 Loop，是 Agent 觀察目前狀態、採取行動、驗證結果，然後在結束條件被滿足前反覆工作的執行結構。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e工作開始\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e掌握狀態與程式碼\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e制定計畫\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e修改程式碼或執行工具\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e測試·驗證\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e滿足完成條件？\n\u003c/span\u003e\u003cspan\u003e  ├─ 否：下一次迭代\n\u003c/span\u003e\u003cspan\u003e  └─ 是：結束並回報結果\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e區分 Loop 時，以下四個問題很有用。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e是什麼啟動工作？\u003c/li\u003e\n\u003cli\u003e是什麼結束工作？\u003c/li\u003e\n\u003cli\u003e哪個 Claude Code 功能控制重複？\u003c/li\u003e\n\u003cli\u003e適合哪一類工作？\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e不需要把所有工作都做成複雜的 Loop。像修正單一檔案的錯字或單純改名這類結果可立即確認的工作，一般 Prompt 更有效率。只有在實際需要多次觀察·修改·驗證時，才應選擇 Loop。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#2-四種-loop-類型比較\" class=\"anchor\" id=\"2-四種-loop-類型比較\"\u003e\u003c/a\u003e2. 四種 Loop 類型比較\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e類型\u003c/th\u003e\n\u003cth\u003e開始條件\u003c/th\u003e\n\u003cth\u003e結束條件\u003c/th\u003e\n\u003cth\u003e主要使用功能\u003c/th\u003e\n\u003cth\u003e適合的工作\u003c/th\u003e\n\u003cth\u003e人交出的責任\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTurn-based\u003c/td\u003e\n\u003ctd\u003e使用者的 Prompt\u003c/td\u003e\n\u003ctd\u003eClaude 判斷已完成或需要追加資訊時\u003c/td\u003e\n\u003ctd\u003e一般對話、Skills、測試·瀏覽器工具\u003c/td\u003e\n\u003ctd\u003e短且一次性的實作·修改\u003c/td\u003e\n\u003ctd\u003e重複驗證程序\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eGoal-based\u003c/td\u003e\n\u003ctd\u003e使用者指定完成條件\u003c/td\u003e\n\u003ctd\u003e評估模型確認條件滿足或使用者中斷\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e，必要時 Auto mode\u003c/td\u003e\n\u003ctd\u003e像測試·建置·遷移這類完成狀態可測量的工作\u003c/td\u003e\n\u003ctd\u003e結束判斷\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTime-based\u003c/td\u003e\n\u003ctd\u003e指定的時間·間隔·排程\u003c/td\u003e\n\u003ctd\u003e使用者取消或外部工作結束\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e, \u003ccode\u003e/schedule\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003ePR·CI·部署監控、定期摘要、狀態 Polling\u003c/td\u003e\n\u003ctd\u003e下次執行時間點\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eProactive\u003c/td\u003e\n\u003ctd\u003e排程、API、GitHub 事件等\u003c/td\u003e\n\u003ctd\u003e個別工作的目標滿足、Routine 停用\u003c/td\u003e\n\u003ctd\u003eRoutines, \u003ccode\u003e/goal\u003c/code\u003e, Skills, Dynamic Workflows, Auto mode\u003c/td\u003e\n\u003ctd\u003e議題分類、錯誤處理、大規模遷移等持續性業務\u003c/td\u003e\n\u003ctd\u003e工作發現、Prompt 執行、編排\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e這個分類的核心不是「AI 有多聰明」，而是\u003cstrong\u003e人把哪些控制責任交給系統\u003c/strong\u003e。在 Turn-based 中，人製作下一個 Prompt；在 Goal-based 中，交出完成判斷；在 Time-based 中，交出重新執行時間點。到了 Proactive 階段，連偵測工作發生並執行適當 Prompt 的責任，也會移到系統。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#3-turn-based-loop交出驗證程序\" class=\"anchor\" id=\"3-turn-based-loop交出驗證程序\"\u003e\u003c/a\u003e3. Turn-based Loop：交出驗證程序\u003c/h2\u003e\n\u003cp\u003eTurn-based Loop 是大多數開發者使用 Claude Code 的基本形式。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eHuman → Claude → Human → Claude\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e使用者提出請求後，Claude 會尋找相關檔案、修改程式碼、測試並回報結果。內部可能發生多次觀察·行動·驗證，但啟動下一個工作的權限仍留在使用者手上。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#修改程式碼與完成功能不同\" class=\"anchor\" id=\"修改程式碼與完成功能不同\"\u003e\u003c/a\u003e修改程式碼與完成功能不同\u003c/h3\u003e\n\u003cp\u003e即使 Claude 回報「已完成實作與測試」，實際產品中仍可能留下以下問題。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e點擊按鈕後狀態沒有改變。\u003c/li\u003e\n\u003cli\u003e瀏覽器 Console 發生錯誤。\u003c/li\u003e\n\u003cli\u003e行動版版面破掉。\u003c/li\u003e\n\u003cli\u003e缺少無障礙屬性。\u003c/li\u003e\n\u003cli\u003e測試通過，但實際瀏覽器流程失敗。\u003c/li\u003e\n\u003cli\u003e連與變更無關的檔案也被修改。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e因此完成標準不應是「改了程式碼」，而應是「以外部證據確認動作」。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#用-skillmd-重複使用驗證\" class=\"anchor\" id=\"用-skillmd-重複使用驗證\"\u003e\u003c/a\u003e用 \u003ccode\u003eSKILL.md\u003c/code\u003e 重複使用驗證\u003c/h3\u003e\n\u003cp\u003eSkill 是把重複使用的指引與程序保存在 \u003ccode\u003eSKILL.md\u003c/code\u003e 的方式。Claude 可判斷相關性後自動載入，或用 \u003ccode\u003e/skill-name\u003c/code\u003e 直接執行。與其總是把冗長的營運程序放進 \u003ccode\u003eCLAUDE.md\u003c/code\u003e，不如分離成只在需要時載入 Skill，這樣能更有效率地使用 Context。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003ename: verify-ui-change\n\u003c/span\u003e\u003cspan\u003edescription: 在將 UI 變更視為完成前，於實際執行環境中驗證。\n\u003c/span\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# UI 變更驗證\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. 執行開發伺服器。\n\u003c/span\u003e\u003cspan\u003e2. 在瀏覽器中開啟變更後的畫面。\n\u003c/span\u003e\u003cspan\u003e3. 實際操作新的控制項。\n\u003c/span\u003e\u003cspan\u003e4. 確認是否發生預期的狀態變化。\n\u003c/span\u003e\u003cspan\u003e5. 確認瀏覽器 Console 中的新錯誤與警告。\n\u003c/span\u003e\u003cspan\u003e6. 檢查無障礙與主要效能指標。\n\u003c/span\u003e\u003cspan\u003e7. 若失敗，修正後從頭重新驗證。\n\u003c/span\u003e\u003cspan\u003e8. 回報執行過的命令、結果、截圖等證據。\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e好的 Skill 包含的不是抽象的叮囑，而是可執行的 Checklist。比起「更謹慎地檢討」，「確認 \u003ccode\u003enpm test\u003c/code\u003e 是否以結束碼 0 結束」是強得多的規則。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#驗證證據的強度\" class=\"anchor\" id=\"驗證證據的強度\"\u003e\u003c/a\u003e驗證證據的強度\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e證據\u003c/th\u003e\n\u003cth\u003e可信度\u003c/th\u003e\n\u003cth\u003e原因\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eAgent 說明「看起來應該正常」\u003c/td\u003e\n\u003ctd\u003e低\u003c/td\u003e\n\u003ctd\u003e不是執行結果，只是推論\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e程式碼 Diff 與靜態檢討\u003c/td\u003e\n\u003ctd\u003e中\u003c/td\u003e\n\u003ctd\u003e看得到變更內容，但無法確認 Runtime 動作\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e實際測試輸出與結束碼\u003c/td\u003e\n\u003ctd\u003e高\u003c/td\u003e\n\u003ctd\u003e存在可重現的外部結果\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e瀏覽器互動、截圖、Console·效能結果\u003c/td\u003e\n\u003ctd\u003e非常高\u003c/td\u003e\n\u003ctd\u003e直接驗證使用者路徑與 Runtime 狀態\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e獨立 Review Agent 與 CI 得出相同結論\u003c/td\u003e\n\u003ctd\u003e非常高\u003c/td\u003e\n\u003ctd\u003e降低實作 Agent 的自我確認偏誤\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eClaude Code 官方文件也說明了像確認執行中應用程式的 \u003ccode\u003e/run\u003c/code\u003e、在實際執行環境中驗證變更的 \u003ccode\u003e/verify\u003c/code\u003e 這類 bundled Skill。若專案執行方式複雜，將精確的啟動命令、環境變數、資料準備程序記錄在團隊專屬 Skill 中會更安全。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#4-goal-based-loop交出結束判斷\" class=\"anchor\" id=\"4-goal-based-loop交出結束判斷\"\u003e\u003c/a\u003e4. Goal-based Loop：交出結束判斷\u003c/h2\u003e\n\u003cp\u003eGoal-based Loop 不需要使用者每次決定「是否再做一次」。使用者定義完成狀態，Claude 會持續多個 Turn，直到該條件被滿足。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e使用者指定 Goal\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eClaude 工作 Turn\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e另外的評估模型確認完成條件\n\u003c/span\u003e\u003cspan\u003e  ├─ 未滿足：將原因傳給下一個 Turn\n\u003c/span\u003e\u003cspan\u003e  └─ 滿足：Goal 結束\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e 已文件化為可在 Claude Code v2.1.139 以上版本使用。一個 Session 只能啟用一個 Goal。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#評估模型實際上看的是什麼\" class=\"anchor\" id=\"評估模型實際上看的是什麼\"\u003e\u003c/a\u003e評估模型實際上看的是什麼\u003c/h3\u003e\n\u003cp\u003e每個 Turn 結束後，另外的 small fast model 會查看完成條件與對話內容，判斷 \u003ccode\u003e滿足\u003c/code\u003e 或 \u003ccode\u003e未滿足\u003c/code\u003e。預設設定是 Haiku 系列評估模型。重要限制是，評估模型不會直接讀取檔案或另外執行測試。\u003c/p\u003e\n\u003cp\u003e因此執行工作的 Claude 必須在對話中明確留下以下證據。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e執行過的命令\u003c/li\u003e\n\u003cli\u003e測試數量與通過·失敗結果\u003c/li\u003e\n\u003cli\u003e結束碼\u003c/li\u003e\n\u003cli\u003e建置結果\u003c/li\u003e\n\u003cli\u003e變更檔案清單\u003c/li\u003e\n\u003cli\u003e剩餘失敗原因\u003c/li\u003e\n\u003cli\u003e確認遵守範圍限制的結果\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e評估模型判斷的不是「實際發生了什麼」，而是「對話中呈現了哪些證據」。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#好-goal-的四個要素\" class=\"anchor\" id=\"好-goal-的四個要素\"\u003e\u003c/a\u003e好 Goal 的四個要素\u003c/h3\u003e\n\u003cp\u003e好的 Goal 包含以下四個要素。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e可測量的成功條件\u003c/strong\u003e：測試通過、建置成功、Queue 清空、達到分數門檻\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e驗證方法\u003c/strong\u003e：明示用什麼命令或工具證明成功\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e變更範圍限制\u003c/strong\u003e：可修改的目錄、禁止檔案、允許的 Side effect\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e強制結束條件\u003c/strong\u003e：最大 Turn、最大時間、連續失敗次數、權限錯誤時中斷\u003c/li\u003e\n\u003c/ol\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/goal auth 相關測試與 lint 全部成功，\n\u003c/span\u003e\u003cspan\u003egit diff 只能包含 src/auth 與相關測試檔案。\n\u003c/span\u003e\u003cspan\u003e每個 Turn 回報執行結果與結束碼。\n\u003c/span\u003e\u003cspan\u003e達到最多 12 Turn 或 45 分鐘時中斷，並整理剩餘失敗。\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e 本身的核心結束條件是評估模型的成功判定，或使用者的 \u003ccode\u003e/goal clear\u003c/code\u003e。若要強制 Turn·時間限制，必須在 Goal 條件中明示。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#好條件與壞條件\" class=\"anchor\" id=\"好條件與壞條件\"\u003e\u003c/a\u003e好條件與壞條件\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e好條件\u003c/th\u003e\n\u003cth\u003e壞條件\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003enpm test\u003c/code\u003e 以結束碼 0 結束\u003c/td\u003e\n\u003ctd\u003e把程式碼做得完美\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e48 個認證相關測試全部通過\u003c/td\u003e\n\u003ctd\u003e盡可能改善使用者體驗\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e所有 API 呼叫點改成新介面且建置成功\u003c/td\u003e\n\u003ctd\u003e重構成更好的結構\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e待處理 Issue Queue 清空，且每個 Issue 記錄結果\u003c/td\u003e\n\u003ctd\u003e盡可能處理更多 Issue\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e模糊的目標可能太快結束，也可能無止境地反覆改善。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#狀態確認與中斷\" class=\"anchor\" id=\"狀態確認與中斷\"\u003e\u003c/a\u003e狀態確認與中斷\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003e/goal\u003c/code\u003e：確認啟用條件、執行時間、評估 Turn 數、Token 使用量、最近評估理由\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e/goal clear\u003c/code\u003e：中斷啟用中的 Goal\u003c/li\u003e\n\u003cli\u003e設定新 Goal：取代既有 Goal\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e--resume\u003c/code\u003e 或 \u003ccode\u003e--continue\u003c/code\u003e：可復原未完成的 Goal\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e恢復時條件會維持，但 Turn 數、時間、Token 基準線可能被初始化，因此建議將 Hard stop 與營運指標一起管理。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#goal-與權限是兩回事\" class=\"anchor\" id=\"goal-與權限是兩回事\"\u003e\u003c/a\u003e\u003ccode\u003e/goal\u003c/code\u003e 與權限是兩回事\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e 只會自動啟動下一個 Turn，不會擴大工具權限。若檔案寫入、測試命令、Git 操作屬於需核准對象，在 Goal 期間也可能需要核准。\u003c/p\u003e\n\u003cp\u003e無人執行時可搭配 Auto mode，但 Auto mode 不是「無條件允許所有工具」的功能。分類器會阻擋破壞性、難以復原或以信任邊界外為對象的工作，而明確的 \u003ccode\u003eask\u003c/code\u003e 與 \u003ccode\u003edeny\u003c/code\u003e 規則會優先於分類器套用。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#5-time-based-loop交出重新執行時間點\" class=\"anchor\" id=\"5-time-based-loop交出重新執行時間點\"\u003e\u003c/a\u003e5. Time-based Loop：交出重新執行時間點\u003c/h2\u003e\n\u003cp\u003e如果 Goal-based Loop 處理的是「何時停止」，Time-based Loop 處理的就是「何時再次執行」。它適合外部系統狀態會隨時間改變的工作。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e確認 PR 是否有新的 Review\u003c/li\u003e\n\u003cli\u003e確認 CI 或部署是否結束\u003c/li\u003e\n\u003cli\u003e確認長時間建置狀態\u003c/li\u003e\n\u003cli\u003e每日 Slack 訊息摘要\u003c/li\u003e\n\u003cli\u003e確認 Issue Queue 的新項目\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#loop在目前-session-中反覆執行\" class=\"anchor\" id=\"loop在目前-session-中反覆執行\"\u003e\u003c/a\u003e\u003ccode\u003e/loop\u003c/code\u003e：在目前 Session 中反覆執行\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/loop 10m 確認目前 PR 並反映新的 Review，\n\u003c/span\u003e\u003cspan\u003e若有失敗的 CI，分析原因並修正。\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e目前文件說明的主要形式如下。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e輸入\u003c/th\u003e\n\u003cth\u003e動作\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop 5m \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e以指定固定間隔執行 Prompt\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eClaude 在每次重複時選擇間隔\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e執行 built-in 維護 Prompt 或專案的 \u003ccode\u003eloop.md\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop 20m /review-pr 1234\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e以指定間隔重新執行允許的 Skill\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003e/loop\u003c/code\u003e 依附於目前的 Claude Code Session。電腦與 Session 必須正在執行，若開始新的對話，Session 範圍的工作會消失。未過期工作可用 \u003ccode\u003e--resume\u003c/code\u003e 或 \u003ccode\u003e--continue\u003c/code\u003e 復原，但重複工作基本上會在建立後 7 天過期。它也不會把錯過的週期全部追溯執行。\u003c/p\u003e\n\u003cp\u003eSession Scheduler 可能套用 Jitter，因此可能不適合「必須整點執行」的營運需求。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#scheduleanthropic-管理的-cloud-routine\" class=\"anchor\" id=\"scheduleanthropic-管理的-cloud-routine\"\u003e\u003c/a\u003e\u003ccode\u003e/schedule\u003c/code\u003e：Anthropic 管理的 Cloud Routine\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/schedule\u003c/code\u003e 會把 Prompt、Repository、Connector、Trigger 綁在一起，建立在 Anthropic 管理基礎設施上執行的 Routine。即使關上筆電也能執行，官方文件將其介紹為 Research Preview。\u003c/p\u003e\n\u003cp\u003eRoutine 支援的 Trigger 如下。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e重複排程\u003c/li\u003e\n\u003cli\u003e特定未來時間點的一次性排程\u003c/li\u003e\n\u003cli\u003e已驗證的 API 呼叫\u003c/li\u003e\n\u003cli\u003eGitHub Pull request 或 Release 事件\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e一個 Routine 可以連接多個 Trigger。例如可讓 PR Review Routine 每晚執行，同時也對 \u003ccode\u003epull_request.opened\u003c/code\u003e 事件做出反應。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#loop-與-schedule-比較\" class=\"anchor\" id=\"loop-與-schedule-比較\"\u003e\u003c/a\u003e\u003ccode\u003e/loop\u003c/code\u003e 與 \u003ccode\u003e/schedule\u003c/code\u003e 比較\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e區分\u003c/th\u003e\n\u003cth\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/th\u003e\n\u003cth\u003e\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e執行位置\u003c/td\u003e\n\u003ctd\u003e目前電腦與 Session\u003c/td\u003e\n\u003ctd\u003eAnthropic 管理的 Cloud\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e電腦關閉後執行\u003c/td\u003e\n\u003ctd\u003e通常不可\u003c/td\u003e\n\u003ctd\u003e可以\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e是否需要開啟 Session\u003c/td\u003e\n\u003ctd\u003e需要\u003c/td\u003e\n\u003ctd\u003e不需要\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e本機未 Commit 檔案\u003c/td\u003e\n\u003ctd\u003e可存取\u003c/td\u003e\n\u003ctd\u003e不可存取，每次執行都重新 Clone Repository\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e最小間隔\u003c/td\u003e\n\u003ctd\u003e依官方文件為 1 分鐘\u003c/td\u003e\n\u003ctd\u003e依官方文件為 1 小時\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e持續性\u003c/td\u003e\n\u003ctd\u003e以 Session 為中心，重複工作 7 天過期\u003c/td\u003e\n\u003ctd\u003e儲存在帳號中的 Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e權限 Prompt\u003c/td\u003e\n\u003ctd\u003e繼承目前 Session 政策\u003c/td\u003e\n\u003ctd\u003e無互動式核准而自主執行\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e適合用途\u003c/td\u003e\n\u003ctd\u003e短期 PR·部署監控\u003c/td\u003e\n\u003ctd\u003e持續性營運自動化\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\u003ca href=\"#event-比-polling-更好的情況\" class=\"anchor\" id=\"event-比-polling-更好的情況\"\u003e\u003c/a\u003eEvent 比 Polling 更好的情況\u003c/h3\u003e\n\u003cp\u003e若每 1 分鐘確認一次變更很少的 PR，大多數執行都會什麼也不做就結束。如果外部系統能送出事件，以下結構更有效率。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eCI 失敗或 PR 更新\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eGitHub Trigger 或 Routine API\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e只在需要時執行 Claude\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eEvent-based 設計能降低延遲，並減少不必要的模型呼叫與 Token 消耗。若 Polling 不可避免，最好依實際變更頻率拉長間隔，且在長時間沒有變化時套用 Backoff。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#時間型工作的必要條件\" class=\"anchor\" id=\"時間型工作的必要條件\"\u003e\u003c/a\u003e時間型工作的必要條件\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e冪等性\u003c/strong\u003e：即使多次收到相同事件，也不應產生重複留言、重複 PR、重複部署。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e處理狀態\u003c/strong\u003e：必須記錄最後處理的 Event ID、Commit SHA、Review Comment ID 等。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e結束狀態\u003c/strong\u003e：必須能判斷像 PR merge·close、Queue empty、Deploy success·rollback 這樣的結束。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e寫入範圍\u003c/strong\u003e：必須限制 Side effect，例如允許留言、禁止 Merge、只 Push \u003ccode\u003eclaude/*\u003c/code\u003e Branch。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e失敗處理\u003c/strong\u003e：外部服務障礙、驗證過期、Rate limit、權限不足時，需要重試與 Escalation 規則。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\u003ca href=\"#6-proactive-loop交出工作發現與編排\" class=\"anchor\" id=\"6-proactive-loop交出工作發現與編排\"\u003e\u003c/a\u003e6. Proactive Loop：交出工作發現與編排\u003c/h2\u003e\n\u003cp\u003eProactive Loop 不是單一命令，而是結合多個功能的常駐自動化架構。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003e+ Goal\n\u003c/span\u003e\u003cspan\u003e+ Skills\n\u003c/span\u003e\u003cspan\u003e+ Dynamic Workflow\n\u003c/span\u003e\u003cspan\u003e+ Auto mode\n\u003c/span\u003e\u003cspan\u003e+ Repository·Connector·Browser·CI 工具\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e即使人不即時輸入 Prompt，新工作也會被偵測、處理、驗證並回報結果。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#範例自動處理錯誤回饋\" class=\"anchor\" id=\"範例自動處理錯誤回饋\"\u003e\u003c/a\u003e範例：自動處理錯誤回饋\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e收到 GitHub Issue 或 Slack 回饋\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e分類重複·優先順序·可重現性\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e建立重現測試\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e探索候選解法\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e實作選定解法\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e獨立 Review Agent 探索反例\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003e測試·建置·安全驗證\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eDraft PR 與結果回報\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e各組成要素的責任如下。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e組成要素\u003c/th\u003e\n\u003cth\u003e責任\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eTrigger 或 \u003ccode\u003e/schedule\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e決定啟動新工作的時間點\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e定義這次執行中什麼是完成狀態\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSkill\u003c/td\u003e\n\u003ctd\u003e標準化重現、實作、驗證、回報程序\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDynamic Workflow\u003c/td\u003e\n\u003ctd\u003e多個 Subagent 的平行執行與條件分支\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAuto mode\u003c/td\u003e\n\u003ctd\u003e無需等待核准就執行允許的工具呼叫\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003ePermission policy\u003c/td\u003e\n\u003ctd\u003e固定禁止·核准·自動允許範圍\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\u003ca href=\"#dynamic-workflow-與-worktree\" class=\"anchor\" id=\"dynamic-workflow-與-worktree\"\u003e\u003c/a\u003eDynamic Workflow 與 Worktree\u003c/h3\u003e\n\u003cp\u003eDynamic Workflow 是由 Claude 撰寫的 JavaScript 編排 Script，交由 Runtime 執行的結構。在一般 Subagent 呼叫中，Claude 會在每個 Turn 選擇下一個 Agent；但在 Workflow 中，Loop、平行處理、分支、中間結果儲存會移到 Script。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eWorkflow Script\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent A：需求分析\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent B：測試設計\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent C：實作候選探索\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent D：安全檢討\n\u003c/span\u003e\u003cspan\u003e  └─ Judge：以證據為基礎比較\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e由於中間結果不是留在主要對話 Context，而是留在 Script 變數中，因此可更可重現地組織大型工作。現行文件明示 Runtime 限制為同時最多 16 個 Agent、每次執行最多 1,000 個 Agent，但產品 Preview 階段的限制可能改變。\u003c/p\u003e\n\u003cp\u003e如果必須同時測試多個實作候選，可以用 Git Worktree 分離工作空間。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003erepo/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-a/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-b/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-c/\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e各 Agent 在獨立 Branch 與目錄中工作，可減少同時覆寫相同檔案的問題。Judge Agent 應以需求滿足、測試結果、回歸風險、變更範圍、複雜度、效能、安全、與既有架構的一致性為基準比較候選。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#更多-agent-不一定總是更好\" class=\"anchor\" id=\"更多-agent-不一定總是更好\"\u003e\u003c/a\u003e更多 Agent 不一定總是更好\u003c/h3\u003e\n\u003cp\u003e對沒有平行性的工作只增加 Agent 數量，會提高成本與延遲。若多個 Agent 共享同一個錯誤假設，錯誤也可能被放大。\u003c/p\u003e\n\u003cp\u003eDynamic Workflow 適合以下情況。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e對數百個檔案套用相同轉換的 Migration\u003c/li\u003e\n\u003cli\u003e整個 Codebase 的安全·品質 Audit\u003c/li\u003e\n\u003cli\u003e比較多個獨立觀點的 Plan\u003c/li\u003e\n\u003cli\u003e必須分割處理大量項目並交叉驗證的 Research\u003c/li\u003e\n\u003cli\u003e難以把所有中間結果放進單一 Agent Context 的工作\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e小型錯誤修正、單一檔案重構、單純新增測試，使用一般 Turn-based Loop 或 \u003ccode\u003e/goal\u003c/code\u003e 更好。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#7-在-loop-中維持程式碼品質的系統\" class=\"anchor\" id=\"7-在-loop-中維持程式碼品質的系統\"\u003e\u003c/a\u003e7. 在 Loop 中維持程式碼品質的系統\u003c/h2\u003e\n\u003cp\u003eLoop 結果的品質不只受模型本身影響，也很大程度取決於模型周圍的驗證系統。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#71-整理-codebase\" class=\"anchor\" id=\"71-整理-codebase\"\u003e\u003c/a\u003e7.1 整理 Codebase\u003c/h3\u003e\n\u003cp\u003eClaude 會強烈遵循既有程式碼的模式。如果存在舊 API、重複實作、不明確的測試結構、巨大模組、不一致的例外處理規則，Loop 可能快速複製這些問題。\u003c/p\u003e\n\u003cp\u003e必要基礎如下。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eFormatter 與 lint\u003c/li\u003e\n\u003cli\u003e明確的目錄與模組邊界\u003c/li\u003e\n\u003cli\u003e可信賴的 Unit·Integration·E2E Test\u003c/li\u003e\n\u003cli\u003e區分使用中的 API 與 Deprecated API\u003c/li\u003e\n\u003cli\u003e專案別開發規則\u003c/li\u003e\n\u003cli\u003e可重現的 Build·Dev 環境\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\u003ca href=\"#72-依變更類型建立-definition-of-done\" class=\"anchor\" id=\"72-依變更類型建立-definition-of-done\"\u003e\u003c/a\u003e7.2 依變更類型建立 Definition of Done\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e變更類型\u003c/th\u003e\n\u003cth\u003e最小驗證\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eAPI\u003c/td\u003e\n\u003ctd\u003eContract 測試、向下相容性、Schema·文件範例更新\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eFrontend\u003c/td\u003e\n\u003ctd\u003e實際瀏覽器操作、Console 錯誤、無障礙、響應式畫面\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDatabase\u003c/td\u003e\n\u003ctd\u003eForward·Rollback Migration、Lock 範圍、執行計畫\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eDependency\u003c/td\u003e\n\u003ctd\u003eBuild、主要回歸測試、License·Security 確認\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eInfrastructure\u003c/td\u003e\n\u003ctd\u003ePlan Diff、最小權限、Rollback、秘密資訊外洩檢查\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e與其每次在 Prompt 中冗長重複這些標準，不如固定在 Skill、Hook、Script、CI Rule 中。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#73-提供最新文件與準確版本\" class=\"anchor\" id=\"73-提供最新文件與準確版本\"\u003e\u003c/a\u003e7.3 提供最新文件與準確版本\u003c/h3\u003e\n\u003cp\u003eLoop 可能多次重複錯誤假設。必須讓它能容易找到專案使用的準確 Version、官方文件、內部 Architecture 文件、API 規格、Migration Guide、已核准範例。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#74-分離實作-agent-與-review-agent\" class=\"anchor\" id=\"74-分離實作-agent-與-review-agent\"\u003e\u003c/a\u003e7.4 分離實作 Agent 與 Review Agent\u003c/h3\u003e\n\u003cp\u003e實作的 Agent 已經受所選設計與推論影響。新 Context 的 Review Agent 可以更獨立地提出以下問題。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e是否削弱測試來讓它通過？\u003c/li\u003e\n\u003cli\u003e是否修改了範圍外檔案？\u003c/li\u003e\n\u003cli\u003e安全邊界是否被破壞？\u003c/li\u003e\n\u003cli\u003e是否遺漏失敗路徑與邊界值測試？\u003c/li\u003e\n\u003cli\u003e既有功能是否發生回歸？\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eReview Prompt 與其寫「摘要優點」，不如寫成「在假設實作錯誤的前提下尋找反例，並為每個指摘附上重現證據」，這樣更有效。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#75-將個別失敗連結到系統改善\" class=\"anchor\" id=\"75-將個別失敗連結到系統改善\"\u003e\u003c/a\u003e7.5 將個別失敗連結到系統改善\u003c/h3\u003e\n\u003cp\u003e若相同錯誤反覆發生，不應只修正該次結果。必須改變以下其中一項，讓該失敗類型更難再次發生。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e新增 Regression Test\u003c/li\u003e\n\u003cli\u003e強化 Skill 驗證程序\u003c/li\u003e\n\u003cli\u003e新增 \u003ccode\u003eCLAUDE.md\u003c/code\u003e 規則\u003c/li\u003e\n\u003cli\u003e新增 Hook 或 lint Rule\u003c/li\u003e\n\u003cli\u003e新增權限 Deny Rule\u003c/li\u003e\n\u003cli\u003e強化 Goal 的完成條件\u003c/li\u003e\n\u003cli\u003e補強 Review Checklist\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e好的 Loop Engineering 不是修正一次失敗的工作，而是\u003cstrong\u003e建立讓該類失敗更難再次出現的系統\u003c/strong\u003e。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#8-token-與成本管理\" class=\"anchor\" id=\"8-token-與成本管理\"\u003e\u003c/a\u003e8. Token 與成本管理\u003c/h2\u003e\n\u003cp\u003eLoop 成本可能比單一 Prompt 大幅增加。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e總成本 ≈\n\u003c/span\u003e\u003cspan\u003e主要 Agent Turn 成本\n\u003c/span\u003e\u003cspan\u003e+ Goal 評估成本\n\u003c/span\u003e\u003cspan\u003e+ Subagent 成本\n\u003c/span\u003e\u003cspan\u003e+ Workflow 重複成本\n\u003c/span\u003e\u003cspan\u003e+ 讀取工具結果的 Context 成本\n\u003c/span\u003e\u003cspan\u003e+ 時間型執行頻率\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e精確計費會依 Plan、Model、Provider 而異，但決定成本結構的原理相同。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#降低成本的實務原則\" class=\"anchor\" id=\"降低成本的實務原則\"\u003e\u003c/a\u003e降低成本的實務原則\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e小工作不要使用 Loop。\u003c/strong\u003e 錯字、改名、單一檔案的型別錯誤用單一 Turn 處理。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e同時設置成功條件與 Hard stop。\u003c/strong\u003e 同時考慮成功、最大 Turn、最大時間、連續失敗、權限錯誤。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e大型 Workflow 先在小範圍測試。\u003c/strong\u003e 以 5 個檔案、一個目錄、部分 Issue 驗證成本與品質後再擴大。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e決定論工作用 Script 處理。\u003c/strong\u003e AST 取代、JSON 轉換、Formatting、固定格式產生，用已驗證的 Script 更便宜且可重現。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e將 Polling 週期配合實際變更頻率。\u003c/strong\u003e 可以的話使用 Event Trigger。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e觀察進行中的使用量。\u003c/strong\u003e 在 \u003ccode\u003e/usage\u003c/code\u003e, \u003ccode\u003e/goal\u003c/code\u003e, \u003ccode\u003e/workflows\u003c/code\u003e 確認 Skill·Subagent·MCP·Turn·Token 使用量。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e同一錯誤重複時不要持續重試。\u003c/strong\u003e 設定連續失敗上限，並 Escalation 給人。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\u003ca href=\"#model-與-effort-是不同槓桿\" class=\"anchor\" id=\"model-與-effort-是不同槓桿\"\u003e\u003c/a\u003eModel 與 Effort 是不同槓桿\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eModel\u003c/strong\u003e 會改變基本推論能力與可解決問題的範圍。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEffort\u003c/strong\u003e 會改變讀取檔案數、使用工具數、驗證廣度，以及多階段工作能否推進到底。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e如果 Claude 已確認所有必要檔案與測試，但判斷本身持續錯誤，可能需要更強的 Model。相反地，如果它沒有讀重要檔案、跳過測試，或重構做到一半就停止，提高 Effort 可能更適當。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#9-權限與安全邊界\" class=\"anchor\" id=\"9-權限與安全邊界\"\u003e\u003c/a\u003e9. 權限與安全邊界\u003c/h2\u003e\n\u003cp\u003eProactive Loop 中最危險的設計，是給 Agent 寬泛權限，卻把成功條件與中斷條件設得寬鬆。\u003c/p\u003e\n\u003cp\u003eAuto mode 會減少一般權限 Prompt，但對難以復原、破壞性或以信任邊界外為對象的 Tool call，分類器可能會阻擋。此外，明確的 \u003ccode\u003epermissions.ask\u003c/code\u003e 與 \u003ccode\u003epermissions.deny\u003c/code\u003e 會優先於 Auto mode。\u003c/p\u003e\n\u003ch3\u003e\u003ca href=\"#權限層級範例\" class=\"anchor\" id=\"權限層級範例\"\u003e\u003c/a\u003e權限層級範例\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e層級\u003c/th\u003e\n\u003cth\u003e範例\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e自動允許\u003c/td\u003e\n\u003ctd\u003e讀取程式碼、測試·lint·Build、分析、建立 \u003ccode\u003eclaude/*\u003c/code\u003e Branch、建立 Draft PR\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e人工核准\u003c/td\u003e\n\u003ctd\u003e反映到 Default Branch、正式環境部署、套用 DB Migration、傳送外部客戶訊息\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e一律禁止\u003c/td\u003e\n\u003ctd\u003eForce push、輸出 Secret、刪除正式環境資料、繞過權限、移除稽核日誌\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e比起在對話中說一次「不要 Push」，固定成永久 \u003ccode\u003eask\u003c/code\u003e·\u003ccode\u003edeny\u003c/code\u003e Rule 更安全。因為 Context 壓縮或 Session 變更可能削弱對話規則。\u003c/p\u003e\n\u003cp\u003eCloud Routine 每次執行都會重新 Clone Repository，並以連接的 GitHub·Connector 權限運作。必須最小化以下範圍。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e可存取的 Repository 與 Branch\u003c/li\u003e\n\u003cli\u003e允許的 Network Domain\u003c/li\u003e\n\u003cli\u003e使用的 Connector\u003c/li\u003e\n\u003cli\u003e環境變數與 Secret\u003c/li\u003e\n\u003cli\u003e外部系統寫入權限\u003c/li\u003e\n\u003cli\u003ePR 建立·Push·Merge 範圍\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eRoutine 執行清單中的「正常結束」狀態，可能只表示 Session 在沒有 Infrastructure 錯誤的情況下結束，並不保證業務目標成功。必須另外檢討 Transcript、Test evidence、產生的 Diff。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#10-開發專案用-loop-設計-template\" class=\"anchor\" id=\"10-開發專案用-loop-設計-template\"\u003e\u003c/a\u003e10. 開發專案用 Loop 設計 Template\u003c/h2\u003e\n\u003cp\u003e以下 YAML 不是實際 Claude Code 語法，而是設計檢討用 Template。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003etrigger\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003etype\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003emanual | interval | schedule | github_event | api_event\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003escope\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erepositories\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etarget-repository\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallowed_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esrc/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etests/**\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eprohibited_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eproduction/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esecrets/**\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003etask\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eobjective\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e要變更或處理的目標\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003einput\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e新進來的 Issue、Event、File 或狀態\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003everification\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ecommands\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eunit-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eintegration-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003elint\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebuild\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eruntime_checks\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebrowser-interaction\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003econsole-errors\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eaccessibility\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eevidence\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ecommand-output\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eexit-code\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etest-summary\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003escreenshots\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003esuccess\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003econdition\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e可判定真假的完成狀態\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003estop\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_turns\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e12\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_duration_minutes\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e45\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_consecutive_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e3\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003estop_on_permission_error\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eescalate_on_external_outage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eside_effects\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eidempotency_key\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eevent-id-or-commit-sha\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallow_branch_push\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eclaude/*\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequire_human_for_merge\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequire_human_for_deploy\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003ereview\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eindependent_agent\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eadversarial_review\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eobservability\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_progress\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_token_usage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_changed_files\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_remaining_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e最重要的項目不是 Prompt 句子本身，而是以下五項。\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003eVerifier\n\u003c/span\u003e\u003cspan\u003eSuccess condition\n\u003c/span\u003e\u003cspan\u003eHard stop\n\u003c/span\u003e\u003cspan\u003ePermission boundary\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003ch2\u003e\u003ca href=\"#11-應該選擇哪種-loop\" class=\"anchor\" id=\"11-應該選擇哪種-loop\"\u003e\u003c/a\u003e11. 應該選擇哪種 Loop\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e情況\u003c/th\u003e\n\u003cth\u003e建議方式\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e一次修改與驗證即可結束的工作\u003c/td\u003e\n\u003ctd\u003eTurn-based\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e需要多次嘗試但完成狀態明確的工作\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e需要短暫等待外部 CI·PR·部署狀態的工作\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e即使關上筆電也必須重複執行的業務\u003c/td\u003e\n\u003ctd\u003e\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e必須立即回應 GitHub 事件或 Alert 的業務\u003c/td\u003e\n\u003ctd\u003eEvent-triggered Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e必須平行處理數百項並交叉驗證的業務\u003c/td\u003e\n\u003ctd\u003eDynamic Workflow\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e輸入與輸出規則完全決定論的轉換\u003c/td\u003e\n\u003ctd\u003eScript 或 CI Job\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e選擇順序應以「達成目標的最簡單控制結構」為基準，而不是「最強大的功能」。\u003c/p\u003e\n\u003ch2\u003e\u003ca href=\"#12-安全導入順序\" class=\"anchor\" id=\"12-安全導入順序\"\u003e\u003c/a\u003e12. 安全導入順序\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e選一個人反覆確認的瓶頸業務。\u003c/li\u003e\n\u003cli\u003e先用 Skill、Script、CI 建立驗證程序。\u003c/li\u003e\n\u003cli\u003e在 Turn-based 方式中穩定驗證品質。\u003c/li\u003e\n\u003cli\u003e若完成狀態明確，加入 \u003ccode\u003e/goal\u003c/code\u003e。\u003c/li\u003e\n\u003cli\u003e只有在必須等待外部狀態時使用 \u003ccode\u003e/loop\u003c/code\u003e。\u003c/li\u003e\n\u003cli\u003e若需要長期執行，移到 \u003ccode\u003e/schedule\u003c/code\u003e Routine。\u003c/li\u003e\n\u003cli\u003e只有在冪等性、權限、成本都經過驗證後，才擴展到 Dynamic Workflow 與 Proactive Loop。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\u003ca href=\"#13-常見誤解\" class=\"anchor\" id=\"13-常見誤解\"\u003e\u003c/a\u003e13. 常見誤解\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e誤解\u003c/th\u003e\n\u003cth\u003e正確解讀\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eLoop 是無限執行\u003c/td\u003e\n\u003ctd\u003e它是具有成功條件與 Hard stop 的受限重複結構\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAgent 的完成回報就是驗證\u003c/td\u003e\n\u003ctd\u003e需要外部命令輸出、結束碼、Runtime 結果\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/goal\u003c/code\u003e 會自動允許所有權限\u003c/td\u003e\n\u003ctd\u003e它只會自動啟動下一個 Turn，權限政策是另一回事\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003e/loop\u003c/code\u003e 是長期營運 Scheduler\u003c/td\u003e\n\u003ctd\u003e它以 Session 為中心，且有 7 天過期與執行環境限制\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eAgent 越多結果越好\u003c/td\u003e\n\u003ctd\u003e只有在角色·觀點·驗證不同時，平行化才有價值\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e所有重複工作都應由 LLM 執行\u003c/td\u003e\n\u003ctd\u003e決定論部分用 Script 更便宜且可重現性更高\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\u003ca href=\"#結論\" class=\"anchor\" id=\"結論\"\u003e\u003c/a\u003e結論\u003c/h2\u003e\n\u003cp\u003eLoop Engineering 不是讓 AI 執行更久的技術，而是\u003cstrong\u003e設計控制系統，使 AI 在錯誤時能自行發現、在成本限制內修正，並在危險位置停止\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003eLLM 擅長探索、推論、實作、例外分析、替代方案比較。系統應負責執行時間點、變更範圍、驗證方法、結束標準、成本限制、核准邊界。這種角色分工越明確，Claude Code 自動化就越能超越單純的程式碼生成工具，接近可重現且可稽核的開發營運系統。\u003c/p\u003e\n","tags":["Claude Code","迴圈工程","AI 代理","開發自動化","代理工作流程"],"faqs":[{"question":"Claude Code的Loop與一般的for·while迴圈有什麼不同？","answer":"一般迴圈會以決定性的方式重複執行程式碼中定義的命令。Claude Code的Loop是一種Agent控制結構：Agent會觀察程式碼和外部狀態、推論下一步行動、執行工具、驗證結果，然後根據結束條件再次作業。"},{"question":"Turn-based Loop在什麼時候最適合？","answer":"適合短期、一次性，且使用者能立即檢視結果的作業。不過，如果像UI·API·資料庫那樣驗證程序會反覆進行，建議將該程序製作成Skill或Script，讓Claude能依相同標準自行驗證。"},{"question":"`/goal`評估模型會直接確認檔案和測試結果嗎？","answer":"不會。評估模型不會呼叫工具或直接讀取檔案，而是判斷Goal條件和對話中顯示的證據。執行作業的Claude必須在結果中明確留下測試命令、結束碼、變更檔案、失敗原因。"},{"question":"好的`/goal`條件應該包含什麼？","answer":"需要可衡量的完成狀態、證明該狀態的命令或工具、可變更範圍與禁止範圍，以及最大Turn·時間·連續失敗等Hard stop。比起「乾淨地重構」，「測試和lint的結束碼為0，且指定路徑之外沒有Diff」是更好的條件。"},{"question":"`/goal`有自動最大Turn或時間限制嗎？","answer":"Goal會持續到評估模型判定成功，或使用者以`/goal clear`中止為止。若要限制執行預算，必須在Goal條件中直接包含Turn·時間條款，例如「最多12輪或45分鐘後中止」。"},{"question":"使用`/goal`時，工具權限也會自動允許嗎？","answer":"不會。`/goal`會自動開始下一個Turn，但檔案寫入、Shell、Git、外部Connector權限政策會維持不變。如果需要無人執行，可以考慮Auto mode，但必須透過`ask`·`deny`規則另行控管危險作業。"},{"question":"`/loop`和`/schedule`最大的差異是什麼？","answer":"`/loop`是在目前Claude Code工作階段和電腦中反覆執行的短期Polling手段。`/schedule`會將Prompt、Repository、Connector、Trigger儲存為Cloud Routine，並在Anthropic管理的基礎設施上執行，因此不需要開啟中的工作階段或開機的筆記型電腦。"},{"question":"如果關閉電腦，`/loop`會繼續執行嗎？","answer":"一般不會繼續執行。`/loop`是工作階段範圍的作業，Claude Code必須正在執行。長期自動化應使用Cloud Routine、Desktop scheduled task、GitHub Actions等可持續的Scheduler。"},{"question":"為什麼Event Trigger比時間Polling更好？","answer":"因為在沒有變化時不會產生不必要的模型呼叫，且能在實際變更後立即執行。CI失敗、PR更新、Alert等能發出事件的系統，透過GitHub Trigger或Routine API連接，在成本和延遲上都更有利。"},{"question":"為什麼要把驗證程序放在`SKILL.md`，而不是`CLAUDE.md`？","answer":"`CLAUDE.md`適合專案整體始終適用的簡短規則，而Skill適合將只在特定作業中需要的程序和支援檔案打包在一起。將冗長的驗證清單分離成Skill後，就能只在相關作業中載入並直接重新執行。"},{"question":"Dynamic Workflow與一般Subagent呼叫有什麼不同？","answer":"在一般Subagent方式中，Claude會在每個Turn選擇下一位工作者，結果則累積在Context中。Dynamic Workflow由JavaScript Script管理平行執行、分支、重複和中間結果，因此能更可重現地組織大規模Migration·Audit·交叉驗證。"},{"question":"使用多個Agent時，品質總是會變好嗎？","answer":"不會。如果角色和觀點重疊，可能會重複相同錯誤而只是增加成本。必須將責任分離為實作、測試設計、安全審查、迴歸分析、Judge等，並要求每個結論都有獨立證據，平行Agent的價值才會產生。"},{"question":"在Time-based或Proactive Loop中，如何防止重複作業？","answer":"必須儲存 Event ID、Commit SHA、Review Comment ID 等 Idempotency key，以及最後處理狀態。已回覆的訊息、已建立的 PR、已處理的 Commit 不得再次處理，這類規則必須包含在驗證階段中。"},{"question":"最初要自動化的 Loop，適合從哪些業務開始？","answer":"適合選擇由人員反覆確認，但危險的 Side effect 較少，且能明確衡量完成狀態的業務。例如，從摘要 PR 中失敗的 CI 原因、偵測文件與程式碼的不一致、既定的測試與 lint 驗證開始，之後再逐步擴大修改與 Push 權限，會比較安全。"}],"sources":[{"url":"https://claude.com/blog/getting-started-with-loops","title":"迴圈工程：開始使用迴圈 | Claude by Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/skills","title":"使用技能擴充 Claude - Claude Code 文件","type":"source"},{"url":"https://code.claude.com/docs/en/goal","title":"讓 Claude 持續朝目標努力 - Claude Code 文件","type":"source"},{"url":"https://code.claude.com/docs/en/scheduled-tasks","title":"依排程執行提示 - Claude Code 文件","type":"source"},{"url":"https://code.claude.com/docs/en/routines","title":"使用例行程序自動化工作 - Claude Code 文件","type":"source"},{"url":"https://code.claude.com/docs/en/workflows","title":"使用動態工作流程大規模協調子代理 - Claude Code 文件","type":"source"},{"url":"https://claude.com/blog/claude-model-and-effort-level-in-claude-code","title":"在 Claude Code 中選擇 Claude 模型和投入程度 | Claude by Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/auto-mode-config","title":"設定自動模式 - Claude Code 文件","type":"source"}],"images":[{"id":195,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg3OSwicHVyIjoiYmxvYl9pZCJ9fQ==--cac49ec584371c2261bd3272e7574ca38ecc1f85/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2006_56_28.webp","is_representative":true,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 06_56_28.png","translations":{"ko":{"alt":"AI 로봇과 코드 화면을 중심으로 반복 화살표, 목표·시간·보안·비용 아이콘이 연결된 자동화 구조","caption":"관찰·실행·검증을 반복하는 AI 에이전트와 목표, 일정, 권한, 강제 종료, 비용 제어 요소를 함께 보여준다.","description":null},"en":{"alt":"AI robot and code dashboard surrounded by loop arrows, goal, schedule, security, and cost control icons","caption":"The illustration shows an AI agent repeating observation, action, and verification within goal, timing, permission, stop, and cost controls.","description":null},"ja":{"alt":"AIロボットとコード画面を中心に、循環矢印、目標、時間、安全、コスト管理のアイコンが連結された構成","caption":"観察・実行・検証を繰り返すAIエージェントを、目標、実行時期、権限、停止、コストの制御要素とともに示している。","description":null},"es":{"alt":"Robot de IA y panel de código rodeados por flechas de ciclo e iconos de objetivo, tiempo, seguridad y coste","caption":"La ilustración muestra un agente de IA que repite observación, acción y verificación bajo controles de objetivo, tiempo, permisos, parada y coste.","description":null},"id":{"alt":"Robot AI dan dasbor kode dikelilingi panah loop serta ikon tujuan, waktu, keamanan, dan biaya","caption":"Ilustrasi menampilkan agen AI yang mengulang observasi, tindakan, dan verifikasi dengan kontrol tujuan, waktu, izin, penghentian, dan biaya.","description":null},"pt":{"alt":"Robô de IA e painel de código cercados por setas de ciclo e ícones de meta, tempo, segurança e custo","caption":"A ilustração mostra um agente de IA repetindo observação, ação e verificação sob controles de objetivo, tempo, permissão, parada e custo.","description":null},"zh-hant":{"alt":"AI 機器人與程式碼面板置於循環箭頭中央，周圍連結目標、時間、安全與成本控制圖示","caption":"圖中呈現 AI 代理在目標、排程、權限、強制停止與成本控制下反覆觀察、執行與驗證。","description":null}}},{"id":196,"url":"https://injoys.com/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6MTg4NiwicHVyIjoiYmxvYl9pZCJ9fQ==--e5ead4b7a604375b9c6a192eb3a981cf4c93b3c9/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2007_02_56.webp","is_representative":false,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 07_02_56.png","translations":{"ko":{"alt":"보호 울타리 안의 AI 에이전트가 검증, 중단 장치, 권한 게이트와 비용 계측을 거쳐 작업하는 자동화 구조","caption":"트리거부터 검증과 강제 중단, 자원 관리, 승인된 결과 출력까지 안전하게 통제되는 에이전트 워크플로를 보여준다.","description":null},"en":{"alt":"AI agent inside a guarded workspace with verification, stop controls, permission gates, and resource monitoring","caption":"The illustration shows an agent workflow controlled from triggers through validation, hard stops, resource checks, and approved output.","description":null},"ja":{"alt":"検証、強制停止、権限ゲート、資源監視に囲まれた保護領域内のAIエージェント","caption":"トリガーから検証、停止制御、コスト管理、承認済み出力まで安全に統制されたエージェント処理を表している。","description":null},"es":{"alt":"Agente de IA en un entorno protegido con verificación, parada forzada, permisos y control de recursos","caption":"La ilustración muestra un flujo de agente controlado desde los disparadores hasta la validación, los límites y la salida aprobada.","description":null},"id":{"alt":"Agen AI dalam area terlindungi dengan verifikasi, penghentian paksa, gerbang izin, dan pemantauan sumber daya","caption":"Ilustrasi ini menunjukkan alur agen yang dikendalikan dari pemicu hingga validasi, batas aman, pemantauan biaya, dan keluaran yang disetujui.","description":null},"pt":{"alt":"Agente de IA em área protegida com verificação, parada forçada, controle de permissões e monitoramento de recursos","caption":"A ilustração mostra um fluxo de agente controlado desde os gatilhos até a validação, os limites de segurança e a saída aprovada.","description":null},"zh-hant":{"alt":"受保護工作區中的AI代理，周圍設有驗證、強制停止、權限閘門與資源監控","caption":"圖中呈現從觸發、驗證、停止控制與成本監測，到核准輸出的安全代理工作流程。","description":null}}}],"published_at":"2026-07-17T09:40:17+09:00","updated_at":"2026-07-17T09:40:17+09:00","license":"cc_by","translation_status":"machine","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/en/articles/claude-code-loop-engineering-guide"}