---
title: "Claude Code Loop Engineering 指南：4種 Loop 與安全自動化設計"
locale: zh-hant
category: tutorial
category_name: "教學課程"
translation_status: machine
license: cc_by
author: "Injoys Admin"
source_url: https://injoys.com/en/articles/claude-code-loop-engineering-guide
published_at: 2026-07-17T09:40:17+09:00
---

# Claude Code Loop Engineering 指南：4種 Loop 與安全自動化設計

> Claude Code 的 Loop 是一種控制結構，使 Agent 反覆執行觀察、行動與驗證，直到達到結束條件。本文說明四種 Loop 類型的差異，以及包含驗證證據、Hard stop、冪等性、成本、最小權限在內的實務設計方法。

## Key Points

- Claude Code 的 Loop 不是程式碼迴圈，而是讓 Agent 反覆執行觀察、行動、驗證直到達到結束條件的 Agent 執行結構。
- Turn-based 將驗證程序、Goal-based 將結束判斷、Time-based 將重新執行時點、Proactive 將工作開始與編排交給系統。
- 良好的 Loop 必須具備可測量的完成條件、外部驗證證據、強制結束、冪等性與最小權限。
- `/goal` 評估模型只判斷對話中呈現的證據，因此必須明確回報測試輸出、結束代碼與變更範圍。
- 決定性轉換應以 Script 處理，而 Dynamic Workflow 與多個 Agent 只應用於確實需要並行性的大規模工作。

Claude Code 的 Loop 不只是讓模型長時間執行的功能。核心在於在以機率方式行動的 AI Agent 周圍配置 **Trigger, Verifier, Success condition, Hard stop, Permission boundary**，把重複工作變成可控的系統。本文一次整理 Turn-based, Goal-based, Time-based, Proactive Loop 的差異與實務設計原則。

## 1. Claude Code 中的 Loop 是什麼

這裡的 Loop 不是程式語言中的 `for` 或 `while` 敘述。Claude Code 團隊所說明的 Loop，是 Agent 觀察目前狀態、採取行動、驗證結果，然後在結束條件被滿足前反覆工作的執行結構。

```text
工作開始
  ↓
掌握狀態與程式碼
  ↓
制定計畫
  ↓
修改程式碼或執行工具
  ↓
測試·驗證
  ↓
滿足完成條件？
  ├─ 否：下一次迭代
  └─ 是：結束並回報結果
```

區分 Loop 時，以下四個問題很有用。

1. 是什麼啟動工作？
2. 是什麼結束工作？
3. 哪個 Claude Code 功能控制重複？
4. 適合哪一類工作？

不需要把所有工作都做成複雜的 Loop。像修正單一檔案的錯字或單純改名這類結果可立即確認的工作，一般 Prompt 更有效率。只有在實際需要多次觀察·修改·驗證時，才應選擇 Loop。

## 2. 四種 Loop 類型比較

| 類型 | 開始條件 | 結束條件 | 主要使用功能 | 適合的工作 | 人交出的責任 |
|---|---|---|---|---|---|
| Turn-based | 使用者的 Prompt | Claude 判斷已完成或需要追加資訊時 | 一般對話、Skills、測試·瀏覽器工具 | 短且一次性的實作·修改 | 重複驗證程序 |
| Goal-based | 使用者指定完成條件 | 評估模型確認條件滿足或使用者中斷 | `/goal`，必要時 Auto mode | 像測試·建置·遷移這類完成狀態可測量的工作 | 結束判斷 |
| Time-based | 指定的時間·間隔·排程 | 使用者取消或外部工作結束 | `/loop`, `/schedule` | PR·CI·部署監控、定期摘要、狀態 Polling | 下次執行時間點 |
| Proactive | 排程、API、GitHub 事件等 | 個別工作的目標滿足、Routine 停用 | Routines, `/goal`, Skills, Dynamic Workflows, Auto mode | 議題分類、錯誤處理、大規模遷移等持續性業務 | 工作發現、Prompt 執行、編排 |

這個分類的核心不是「AI 有多聰明」，而是**人把哪些控制責任交給系統**。在 Turn-based 中，人製作下一個 Prompt；在 Goal-based 中，交出完成判斷；在 Time-based 中，交出重新執行時間點。到了 Proactive 階段，連偵測工作發生並執行適當 Prompt 的責任，也會移到系統。

## 3. Turn-based Loop：交出驗證程序

Turn-based Loop 是大多數開發者使用 Claude Code 的基本形式。

```text
Human → Claude → Human → Claude
```

使用者提出請求後，Claude 會尋找相關檔案、修改程式碼、測試並回報結果。內部可能發生多次觀察·行動·驗證，但啟動下一個工作的權限仍留在使用者手上。

### 修改程式碼與完成功能不同

即使 Claude 回報「已完成實作與測試」，實際產品中仍可能留下以下問題。

- 點擊按鈕後狀態沒有改變。
- 瀏覽器 Console 發生錯誤。
- 行動版版面破掉。
- 缺少無障礙屬性。
- 測試通過，但實際瀏覽器流程失敗。
- 連與變更無關的檔案也被修改。

因此完成標準不應是「改了程式碼」，而應是「以外部證據確認動作」。

### 用 `SKILL.md` 重複使用驗證

Skill 是把重複使用的指引與程序保存在 `SKILL.md` 的方式。Claude 可判斷相關性後自動載入，或用 `/skill-name` 直接執行。與其總是把冗長的營運程序放進 `CLAUDE.md`，不如分離成只在需要時載入 Skill，這樣能更有效率地使用 Context。

```markdown
---
name: verify-ui-change
description: 在將 UI 變更視為完成前，於實際執行環境中驗證。
---

# UI 變更驗證

1. 執行開發伺服器。
2. 在瀏覽器中開啟變更後的畫面。
3. 實際操作新的控制項。
4. 確認是否發生預期的狀態變化。
5. 確認瀏覽器 Console 中的新錯誤與警告。
6. 檢查無障礙與主要效能指標。
7. 若失敗，修正後從頭重新驗證。
8. 回報執行過的命令、結果、截圖等證據。
```

好的 Skill 包含的不是抽象的叮囑，而是可執行的 Checklist。比起「更謹慎地檢討」，「確認 `npm test` 是否以結束碼 0 結束」是強得多的規則。

### 驗證證據的強度

| 證據 | 可信度 | 原因 |
|---|---:|---|
| Agent 說明「看起來應該正常」 | 低 | 不是執行結果，只是推論 |
| 程式碼 Diff 與靜態檢討 | 中 | 看得到變更內容，但無法確認 Runtime 動作 |
| 實際測試輸出與結束碼 | 高 | 存在可重現的外部結果 |
| 瀏覽器互動、截圖、Console·效能結果 | 非常高 | 直接驗證使用者路徑與 Runtime 狀態 |
| 獨立 Review Agent 與 CI 得出相同結論 | 非常高 | 降低實作 Agent 的自我確認偏誤 |

Claude Code 官方文件也說明了像確認執行中應用程式的 `/run`、在實際執行環境中驗證變更的 `/verify` 這類 bundled Skill。若專案執行方式複雜，將精確的啟動命令、環境變數、資料準備程序記錄在團隊專屬 Skill 中會更安全。

## 4. Goal-based Loop：交出結束判斷

Goal-based Loop 不需要使用者每次決定「是否再做一次」。使用者定義完成狀態，Claude 會持續多個 Turn，直到該條件被滿足。

```text
使用者指定 Goal
  ↓
Claude 工作 Turn
  ↓
另外的評估模型確認完成條件
  ├─ 未滿足：將原因傳給下一個 Turn
  └─ 滿足：Goal 結束
```

`/goal` 已文件化為可在 Claude Code v2.1.139 以上版本使用。一個 Session 只能啟用一個 Goal。

### 評估模型實際上看的是什麼

每個 Turn 結束後，另外的 small fast model 會查看完成條件與對話內容，判斷 `滿足` 或 `未滿足`。預設設定是 Haiku 系列評估模型。重要限制是，評估模型不會直接讀取檔案或另外執行測試。

因此執行工作的 Claude 必須在對話中明確留下以下證據。

- 執行過的命令
- 測試數量與通過·失敗結果
- 結束碼
- 建置結果
- 變更檔案清單
- 剩餘失敗原因
- 確認遵守範圍限制的結果

評估模型判斷的不是「實際發生了什麼」，而是「對話中呈現了哪些證據」。

### 好 Goal 的四個要素

好的 Goal 包含以下四個要素。

1. **可測量的成功條件**：測試通過、建置成功、Queue 清空、達到分數門檻
2. **驗證方法**：明示用什麼命令或工具證明成功
3. **變更範圍限制**：可修改的目錄、禁止檔案、允許的 Side effect
4. **強制結束條件**：最大 Turn、最大時間、連續失敗次數、權限錯誤時中斷

```text
/goal auth 相關測試與 lint 全部成功，
git diff 只能包含 src/auth 與相關測試檔案。
每個 Turn 回報執行結果與結束碼。
達到最多 12 Turn 或 45 分鐘時中斷，並整理剩餘失敗。
```

`/goal` 本身的核心結束條件是評估模型的成功判定，或使用者的 `/goal clear`。若要強制 Turn·時間限制，必須在 Goal 條件中明示。

### 好條件與壞條件

| 好條件 | 壞條件 |
|---|---|
| `npm test` 以結束碼 0 結束 | 把程式碼做得完美 |
| 48 個認證相關測試全部通過 | 盡可能改善使用者體驗 |
| 所有 API 呼叫點改成新介面且建置成功 | 重構成更好的結構 |
| 待處理 Issue Queue 清空，且每個 Issue 記錄結果 | 盡可能處理更多 Issue |

模糊的目標可能太快結束，也可能無止境地反覆改善。

### 狀態確認與中斷

- `/goal`：確認啟用條件、執行時間、評估 Turn 數、Token 使用量、最近評估理由
- `/goal clear`：中斷啟用中的 Goal
- 設定新 Goal：取代既有 Goal
- `--resume` 或 `--continue`：可復原未完成的 Goal

恢復時條件會維持，但 Turn 數、時間、Token 基準線可能被初始化，因此建議將 Hard stop 與營運指標一起管理。

### `/goal` 與權限是兩回事

`/goal` 只會自動啟動下一個 Turn，不會擴大工具權限。若檔案寫入、測試命令、Git 操作屬於需核准對象，在 Goal 期間也可能需要核准。

無人執行時可搭配 Auto mode，但 Auto mode 不是「無條件允許所有工具」的功能。分類器會阻擋破壞性、難以復原或以信任邊界外為對象的工作，而明確的 `ask` 與 `deny` 規則會優先於分類器套用。

## 5. Time-based Loop：交出重新執行時間點

如果 Goal-based Loop 處理的是「何時停止」，Time-based Loop 處理的就是「何時再次執行」。它適合外部系統狀態會隨時間改變的工作。

- 確認 PR 是否有新的 Review
- 確認 CI 或部署是否結束
- 確認長時間建置狀態
- 每日 Slack 訊息摘要
- 確認 Issue Queue 的新項目

### `/loop`：在目前 Session 中反覆執行

```text
/loop 10m 確認目前 PR 並反映新的 Review，
若有失敗的 CI，分析原因並修正。
```

目前文件說明的主要形式如下。

| 輸入 | 動作 |
|---|---|
| `/loop 5m <prompt>` | 以指定固定間隔執行 Prompt |
| `/loop <prompt>` | Claude 在每次重複時選擇間隔 |
| `/loop` | 執行 built-in 維護 Prompt 或專案的 `loop.md` |
| `/loop 20m /review-pr 1234` | 以指定間隔重新執行允許的 Skill |

`/loop` 依附於目前的 Claude Code Session。電腦與 Session 必須正在執行，若開始新的對話，Session 範圍的工作會消失。未過期工作可用 `--resume` 或 `--continue` 復原，但重複工作基本上會在建立後 7 天過期。它也不會把錯過的週期全部追溯執行。

Session Scheduler 可能套用 Jitter，因此可能不適合「必須整點執行」的營運需求。

### `/schedule`：Anthropic 管理的 Cloud Routine

`/schedule` 會把 Prompt、Repository、Connector、Trigger 綁在一起，建立在 Anthropic 管理基礎設施上執行的 Routine。即使關上筆電也能執行，官方文件將其介紹為 Research Preview。

Routine 支援的 Trigger 如下。

- 重複排程
- 特定未來時間點的一次性排程
- 已驗證的 API 呼叫
- GitHub Pull request 或 Release 事件

一個 Routine 可以連接多個 Trigger。例如可讓 PR Review Routine 每晚執行，同時也對 `pull_request.opened` 事件做出反應。

### `/loop` 與 `/schedule` 比較

| 區分 | `/loop` | `/schedule` Routine |
|---|---|---|
| 執行位置 | 目前電腦與 Session | Anthropic 管理的 Cloud |
| 電腦關閉後執行 | 通常不可 | 可以 |
| 是否需要開啟 Session | 需要 | 不需要 |
| 本機未 Commit 檔案 | 可存取 | 不可存取，每次執行都重新 Clone Repository |
| 最小間隔 | 依官方文件為 1 分鐘 | 依官方文件為 1 小時 |
| 持續性 | 以 Session 為中心，重複工作 7 天過期 | 儲存在帳號中的 Routine |
| 權限 Prompt | 繼承目前 Session 政策 | 無互動式核准而自主執行 |
| 適合用途 | 短期 PR·部署監控 | 持續性營運自動化 |

### Event 比 Polling 更好的情況

若每 1 分鐘確認一次變更很少的 PR，大多數執行都會什麼也不做就結束。如果外部系統能送出事件，以下結構更有效率。

```text
CI 失敗或 PR 更新
  ↓
GitHub Trigger 或 Routine API
  ↓
只在需要時執行 Claude
```

Event-based 設計能降低延遲，並減少不必要的模型呼叫與 Token 消耗。若 Polling 不可避免，最好依實際變更頻率拉長間隔，且在長時間沒有變化時套用 Backoff。

### 時間型工作的必要條件

1. **冪等性**：即使多次收到相同事件，也不應產生重複留言、重複 PR、重複部署。
2. **處理狀態**：必須記錄最後處理的 Event ID、Commit SHA、Review Comment ID 等。
3. **結束狀態**：必須能判斷像 PR merge·close、Queue empty、Deploy success·rollback 這樣的結束。
4. **寫入範圍**：必須限制 Side effect，例如允許留言、禁止 Merge、只 Push `claude/*` Branch。
5. **失敗處理**：外部服務障礙、驗證過期、Rate limit、權限不足時，需要重試與 Escalation 規則。

## 6. Proactive Loop：交出工作發現與編排

Proactive Loop 不是單一命令，而是結合多個功能的常駐自動化架構。

```text
Trigger
+ Goal
+ Skills
+ Dynamic Workflow
+ Auto mode
+ Repository·Connector·Browser·CI 工具
```

即使人不即時輸入 Prompt，新工作也會被偵測、處理、驗證並回報結果。

### 範例：自動處理錯誤回饋

```text
收到 GitHub Issue 或 Slack 回饋
  ↓
分類重複·優先順序·可重現性
  ↓
建立重現測試
  ↓
探索候選解法
  ↓
實作選定解法
  ↓
獨立 Review Agent 探索反例
  ↓
測試·建置·安全驗證
  ↓
Draft PR 與結果回報
```

各組成要素的責任如下。

| 組成要素 | 責任 |
|---|---|
| Trigger 或 `/schedule` | 決定啟動新工作的時間點 |
| `/goal` | 定義這次執行中什麼是完成狀態 |
| Skill | 標準化重現、實作、驗證、回報程序 |
| Dynamic Workflow | 多個 Subagent 的平行執行與條件分支 |
| Auto mode | 無需等待核准就執行允許的工具呼叫 |
| Permission policy | 固定禁止·核准·自動允許範圍 |

### Dynamic Workflow 與 Worktree

Dynamic Workflow 是由 Claude 撰寫的 JavaScript 編排 Script，交由 Runtime 執行的結構。在一般 Subagent 呼叫中，Claude 會在每個 Turn 選擇下一個 Agent；但在 Workflow 中，Loop、平行處理、分支、中間結果儲存會移到 Script。

```text
Workflow Script
  ├─ Agent A：需求分析
  ├─ Agent B：測試設計
  ├─ Agent C：實作候選探索
  ├─ Agent D：安全檢討
  └─ Judge：以證據為基礎比較
```

由於中間結果不是留在主要對話 Context，而是留在 Script 變數中，因此可更可重現地組織大型工作。現行文件明示 Runtime 限制為同時最多 16 個 Agent、每次執行最多 1,000 個 Agent，但產品 Preview 階段的限制可能改變。

如果必須同時測試多個實作候選，可以用 Git Worktree 分離工作空間。

```text
repo/
worktree-solution-a/
worktree-solution-b/
worktree-solution-c/
```

各 Agent 在獨立 Branch 與目錄中工作，可減少同時覆寫相同檔案的問題。Judge Agent 應以需求滿足、測試結果、回歸風險、變更範圍、複雜度、效能、安全、與既有架構的一致性為基準比較候選。

### 更多 Agent 不一定總是更好

對沒有平行性的工作只增加 Agent 數量，會提高成本與延遲。若多個 Agent 共享同一個錯誤假設，錯誤也可能被放大。

Dynamic Workflow 適合以下情況。

- 對數百個檔案套用相同轉換的 Migration
- 整個 Codebase 的安全·品質 Audit
- 比較多個獨立觀點的 Plan
- 必須分割處理大量項目並交叉驗證的 Research
- 難以把所有中間結果放進單一 Agent Context 的工作

小型錯誤修正、單一檔案重構、單純新增測試，使用一般 Turn-based Loop 或 `/goal` 更好。

## 7. 在 Loop 中維持程式碼品質的系統

Loop 結果的品質不只受模型本身影響，也很大程度取決於模型周圍的驗證系統。

### 7.1 整理 Codebase

Claude 會強烈遵循既有程式碼的模式。如果存在舊 API、重複實作、不明確的測試結構、巨大模組、不一致的例外處理規則，Loop 可能快速複製這些問題。

必要基礎如下。

- Formatter 與 lint
- 明確的目錄與模組邊界
- 可信賴的 Unit·Integration·E2E Test
- 區分使用中的 API 與 Deprecated API
- 專案別開發規則
- 可重現的 Build·Dev 環境

### 7.2 依變更類型建立 Definition of Done

| 變更類型 | 最小驗證 |
|---|---|
| API | Contract 測試、向下相容性、Schema·文件範例更新 |
| Frontend | 實際瀏覽器操作、Console 錯誤、無障礙、響應式畫面 |
| Database | Forward·Rollback Migration、Lock 範圍、執行計畫 |
| Dependency | Build、主要回歸測試、License·Security 確認 |
| Infrastructure | Plan Diff、最小權限、Rollback、秘密資訊外洩檢查 |

與其每次在 Prompt 中冗長重複這些標準，不如固定在 Skill、Hook、Script、CI Rule 中。

### 7.3 提供最新文件與準確版本

Loop 可能多次重複錯誤假設。必須讓它能容易找到專案使用的準確 Version、官方文件、內部 Architecture 文件、API 規格、Migration Guide、已核准範例。

### 7.4 分離實作 Agent 與 Review Agent

實作的 Agent 已經受所選設計與推論影響。新 Context 的 Review Agent 可以更獨立地提出以下問題。

- 是否削弱測試來讓它通過？
- 是否修改了範圍外檔案？
- 安全邊界是否被破壞？
- 是否遺漏失敗路徑與邊界值測試？
- 既有功能是否發生回歸？

Review Prompt 與其寫「摘要優點」，不如寫成「在假設實作錯誤的前提下尋找反例，並為每個指摘附上重現證據」，這樣更有效。

### 7.5 將個別失敗連結到系統改善

若相同錯誤反覆發生，不應只修正該次結果。必須改變以下其中一項，讓該失敗類型更難再次發生。

- 新增 Regression Test
- 強化 Skill 驗證程序
- 新增 `CLAUDE.md` 規則
- 新增 Hook 或 lint Rule
- 新增權限 Deny Rule
- 強化 Goal 的完成條件
- 補強 Review Checklist

好的 Loop Engineering 不是修正一次失敗的工作，而是**建立讓該類失敗更難再次出現的系統**。

## 8. Token 與成本管理

Loop 成本可能比單一 Prompt 大幅增加。

```text
總成本 ≈
主要 Agent Turn 成本
+ Goal 評估成本
+ Subagent 成本
+ Workflow 重複成本
+ 讀取工具結果的 Context 成本
+ 時間型執行頻率
```

精確計費會依 Plan、Model、Provider 而異，但決定成本結構的原理相同。

### 降低成本的實務原則

1. **小工作不要使用 Loop。** 錯字、改名、單一檔案的型別錯誤用單一 Turn 處理。
2. **同時設置成功條件與 Hard stop。** 同時考慮成功、最大 Turn、最大時間、連續失敗、權限錯誤。
3. **大型 Workflow 先在小範圍測試。** 以 5 個檔案、一個目錄、部分 Issue 驗證成本與品質後再擴大。
4. **決定論工作用 Script 處理。** AST 取代、JSON 轉換、Formatting、固定格式產生，用已驗證的 Script 更便宜且可重現。
5. **將 Polling 週期配合實際變更頻率。** 可以的話使用 Event Trigger。
6. **觀察進行中的使用量。** 在 `/usage`, `/goal`, `/workflows` 確認 Skill·Subagent·MCP·Turn·Token 使用量。
7. **同一錯誤重複時不要持續重試。** 設定連續失敗上限，並 Escalation 給人。

### Model 與 Effort 是不同槓桿

- **Model** 會改變基本推論能力與可解決問題的範圍。
- **Effort** 會改變讀取檔案數、使用工具數、驗證廣度，以及多階段工作能否推進到底。

如果 Claude 已確認所有必要檔案與測試，但判斷本身持續錯誤，可能需要更強的 Model。相反地，如果它沒有讀重要檔案、跳過測試，或重構做到一半就停止，提高 Effort 可能更適當。

## 9. 權限與安全邊界

Proactive Loop 中最危險的設計，是給 Agent 寬泛權限，卻把成功條件與中斷條件設得寬鬆。

Auto mode 會減少一般權限 Prompt，但對難以復原、破壞性或以信任邊界外為對象的 Tool call，分類器可能會阻擋。此外，明確的 `permissions.ask` 與 `permissions.deny` 會優先於 Auto mode。

### 權限層級範例

| 層級 | 範例 |
|---|---|
| 自動允許 | 讀取程式碼、測試·lint·Build、分析、建立 `claude/*` Branch、建立 Draft PR |
| 人工核准 | 反映到 Default Branch、正式環境部署、套用 DB Migration、傳送外部客戶訊息 |
| 一律禁止 | Force push、輸出 Secret、刪除正式環境資料、繞過權限、移除稽核日誌 |

比起在對話中說一次「不要 Push」，固定成永久 `ask`·`deny` Rule 更安全。因為 Context 壓縮或 Session 變更可能削弱對話規則。

Cloud Routine 每次執行都會重新 Clone Repository，並以連接的 GitHub·Connector 權限運作。必須最小化以下範圍。

- 可存取的 Repository 與 Branch
- 允許的 Network Domain
- 使用的 Connector
- 環境變數與 Secret
- 外部系統寫入權限
- PR 建立·Push·Merge 範圍

Routine 執行清單中的「正常結束」狀態，可能只表示 Session 在沒有 Infrastructure 錯誤的情況下結束，並不保證業務目標成功。必須另外檢討 Transcript、Test evidence、產生的 Diff。

## 10. 開發專案用 Loop 設計 Template

以下 YAML 不是實際 Claude Code 語法，而是設計檢討用 Template。

```yaml
trigger:
  type: manual | interval | schedule | github_event | api_event

scope:
  repositories:
    - target-repository
  allowed_paths:
    - src/**
    - tests/**
  prohibited_paths:
    - production/**
    - secrets/**

task:
  objective: 要變更或處理的目標
  input: 新進來的 Issue、Event、File 或狀態

verification:
  commands:
    - unit-test
    - integration-test
    - lint
    - build
  runtime_checks:
    - browser-interaction
    - console-errors
    - accessibility
  evidence:
    - command-output
    - exit-code
    - test-summary
    - screenshots

success:
  condition: 可判定真假的完成狀態

stop:
  max_turns: 12
  max_duration_minutes: 45
  max_consecutive_failures: 3
  stop_on_permission_error: true
  escalate_on_external_outage: true

side_effects:
  idempotency_key: event-id-or-commit-sha
  allow_branch_push: claude/*
  require_human_for_merge: true
  require_human_for_deploy: true

review:
  independent_agent: true
  adversarial_review: true

observability:
  report_progress: true
  report_token_usage: true
  report_changed_files: true
  report_remaining_failures: true
```

最重要的項目不是 Prompt 句子本身，而是以下五項。

```text
Trigger
Verifier
Success condition
Hard stop
Permission boundary
```

## 11. 應該選擇哪種 Loop

| 情況 | 建議方式 |
|---|---|
| 一次修改與驗證即可結束的工作 | Turn-based |
| 需要多次嘗試但完成狀態明確的工作 | `/goal` |
| 需要短暫等待外部 CI·PR·部署狀態的工作 | `/loop` |
| 即使關上筆電也必須重複執行的業務 | `/schedule` Routine |
| 必須立即回應 GitHub 事件或 Alert 的業務 | Event-triggered Routine |
| 必須平行處理數百項並交叉驗證的業務 | Dynamic Workflow |
| 輸入與輸出規則完全決定論的轉換 | Script 或 CI Job |

選擇順序應以「達成目標的最簡單控制結構」為基準，而不是「最強大的功能」。

## 12. 安全導入順序

1. 選一個人反覆確認的瓶頸業務。
2. 先用 Skill、Script、CI 建立驗證程序。
3. 在 Turn-based 方式中穩定驗證品質。
4. 若完成狀態明確，加入 `/goal`。
5. 只有在必須等待外部狀態時使用 `/loop`。
6. 若需要長期執行，移到 `/schedule` Routine。
7. 只有在冪等性、權限、成本都經過驗證後，才擴展到 Dynamic Workflow 與 Proactive Loop。

## 13. 常見誤解

| 誤解 | 正確解讀 |
|---|---|
| Loop 是無限執行 | 它是具有成功條件與 Hard stop 的受限重複結構 |
| Agent 的完成回報就是驗證 | 需要外部命令輸出、結束碼、Runtime 結果 |
| `/goal` 會自動允許所有權限 | 它只會自動啟動下一個 Turn，權限政策是另一回事 |
| `/loop` 是長期營運 Scheduler | 它以 Session 為中心，且有 7 天過期與執行環境限制 |
| Agent 越多結果越好 | 只有在角色·觀點·驗證不同時，平行化才有價值 |
| 所有重複工作都應由 LLM 執行 | 決定論部分用 Script 更便宜且可重現性更高 |

## 結論

Loop Engineering 不是讓 AI 執行更久的技術，而是**設計控制系統，使 AI 在錯誤時能自行發現、在成本限制內修正，並在危險位置停止**。

LLM 擅長探索、推論、實作、例外分析、替代方案比較。系統應負責執行時間點、變更範圍、驗證方法、結束標準、成本限制、核准邊界。這種角色分工越明確，Claude Code 自動化就越能超越單純的程式碼生成工具，接近可重現且可稽核的開發營運系統。

## FAQ

### Claude Code的Loop與一般的for·while迴圈有什麼不同？
一般迴圈會以決定性的方式重複執行程式碼中定義的命令。Claude Code的Loop是一種Agent控制結構：Agent會觀察程式碼和外部狀態、推論下一步行動、執行工具、驗證結果，然後根據結束條件再次作業。

### Turn-based Loop在什麼時候最適合？
適合短期、一次性，且使用者能立即檢視結果的作業。不過，如果像UI·API·資料庫那樣驗證程序會反覆進行，建議將該程序製作成Skill或Script，讓Claude能依相同標準自行驗證。

### `/goal`評估模型會直接確認檔案和測試結果嗎？
不會。評估模型不會呼叫工具或直接讀取檔案，而是判斷Goal條件和對話中顯示的證據。執行作業的Claude必須在結果中明確留下測試命令、結束碼、變更檔案、失敗原因。

### 好的`/goal`條件應該包含什麼？
需要可衡量的完成狀態、證明該狀態的命令或工具、可變更範圍與禁止範圍，以及最大Turn·時間·連續失敗等Hard stop。比起「乾淨地重構」，「測試和lint的結束碼為0，且指定路徑之外沒有Diff」是更好的條件。

### `/goal`有自動最大Turn或時間限制嗎？
Goal會持續到評估模型判定成功，或使用者以`/goal clear`中止為止。若要限制執行預算，必須在Goal條件中直接包含Turn·時間條款，例如「最多12輪或45分鐘後中止」。

### 使用`/goal`時，工具權限也會自動允許嗎？
不會。`/goal`會自動開始下一個Turn，但檔案寫入、Shell、Git、外部Connector權限政策會維持不變。如果需要無人執行，可以考慮Auto mode，但必須透過`ask`·`deny`規則另行控管危險作業。

### `/loop`和`/schedule`最大的差異是什麼？
`/loop`是在目前Claude Code工作階段和電腦中反覆執行的短期Polling手段。`/schedule`會將Prompt、Repository、Connector、Trigger儲存為Cloud Routine，並在Anthropic管理的基礎設施上執行，因此不需要開啟中的工作階段或開機的筆記型電腦。

### 如果關閉電腦，`/loop`會繼續執行嗎？
一般不會繼續執行。`/loop`是工作階段範圍的作業，Claude Code必須正在執行。長期自動化應使用Cloud Routine、Desktop scheduled task、GitHub Actions等可持續的Scheduler。

### 為什麼Event Trigger比時間Polling更好？
因為在沒有變化時不會產生不必要的模型呼叫，且能在實際變更後立即執行。CI失敗、PR更新、Alert等能發出事件的系統，透過GitHub Trigger或Routine API連接，在成本和延遲上都更有利。

### 為什麼要把驗證程序放在`SKILL.md`，而不是`CLAUDE.md`？
`CLAUDE.md`適合專案整體始終適用的簡短規則，而Skill適合將只在特定作業中需要的程序和支援檔案打包在一起。將冗長的驗證清單分離成Skill後，就能只在相關作業中載入並直接重新執行。

### Dynamic Workflow與一般Subagent呼叫有什麼不同？
在一般Subagent方式中，Claude會在每個Turn選擇下一位工作者，結果則累積在Context中。Dynamic Workflow由JavaScript Script管理平行執行、分支、重複和中間結果，因此能更可重現地組織大規模Migration·Audit·交叉驗證。

### 使用多個Agent時，品質總是會變好嗎？
不會。如果角色和觀點重疊，可能會重複相同錯誤而只是增加成本。必須將責任分離為實作、測試設計、安全審查、迴歸分析、Judge等，並要求每個結論都有獨立證據，平行Agent的價值才會產生。

### 在Time-based或Proactive Loop中，如何防止重複作業？
必須儲存 Event ID、Commit SHA、Review Comment ID 等 Idempotency key，以及最後處理狀態。已回覆的訊息、已建立的 PR、已處理的 Commit 不得再次處理，這類規則必須包含在驗證階段中。

### 最初要自動化的 Loop，適合從哪些業務開始？
適合選擇由人員反覆確認，但危險的 Side effect 較少，且能明確衡量完成狀態的業務。例如，從摘要 PR 中失敗的 CI 原因、偵測文件與程式碼的不一致、既定的測試與 lint 驗證開始，之後再逐步擴大修改與 Push 權限，會比較安全。

## Sources

- [迴圈工程：開始使用迴圈 | Claude by Anthropic](https://claude.com/blog/getting-started-with-loops)
- [使用技能擴充 Claude - Claude Code 文件](https://code.claude.com/docs/en/skills)
- [讓 Claude 持續朝目標努力 - Claude Code 文件](https://code.claude.com/docs/en/goal)
- [依排程執行提示 - Claude Code 文件](https://code.claude.com/docs/en/scheduled-tasks)
- [使用例行程序自動化工作 - Claude Code 文件](https://code.claude.com/docs/en/routines)
- [使用動態工作流程大規模協調子代理 - Claude Code 文件](https://code.claude.com/docs/en/workflows)
- [在 Claude Code 中選擇 Claude 模型和投入程度 | Claude by Anthropic](https://claude.com/blog/claude-model-and-effort-level-in-claude-code)
- [設定自動模式 - Claude Code 文件](https://code.claude.com/docs/en/auto-mode-config)

## Images

![AI 機器人與程式碼面板置於循環箭頭中央，周圍連結目標、時間、安全與成本控制圖示](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)
![受保護工作區中的AI代理，周圍設有驗證、強制停止、權限閘門與資源監控](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)