` | 平行執行機械式重構 | v2.1.63+ | 每個單位都有自己的 git worktree |
`/goal` 是最接近 Ralph Loop 的命令。底層的評估模型（預設為 Haiku）會在每一輪檢查目標是否達成。若尚未達成，下一輪會附上需要修正之處的提示；若已達成，就會停止。我在[透過 /goal 讓 Claude Code 夜間自主執行](https://ailoot.ai/blog/zh-hant-tw/goal-mode-claude-code-codex/)的指南中詳細介紹了 `/goal`，其中包含可直接使用、適合執行 14 小時的情境。
`/batch` 並不常用，但功能強大。當你需要在 100 個以上的檔案中套用相同變更（API 遷移、元件替換、重新命名）時，`/batch` 會將每個檔案交給各自在 git worktree 中運作的子代理程式。每個代理程式都在隔離的副本中工作，因此變更不會互相衝突。關於子代理程式的更多資訊，請參閱[巢狀子代理程式](https://ailoot.ai/blog/zh-hant-tw/claude-code-nested-subagents/)指南。
作者在描述這種做法時，簡單地稱它為：
`/loop` 和 `/goal` 的硬性限制：
- Claude Code 開啟時，任務才會執行。關閉終端機，迴圈就會停止。若要進行正式的夜間工作週期，請使用遠端伺服器或自己的 shell 包裝程式。
- 定期任務的最長存續時間為 **7 天**（之後會自動刪除，避免忘記關閉的迴圈持續存在）。
- 單一工作階段最多可同時執行 **50 個任務**。
想建立一套讓 Claude 可靠運作的配置嗎？Ralph Loop 只是其中一環。你可以考慮三個組成部分：**AI 分身 + Second Brain + Context Engineering**——這種組合能讓 Claude 從「會產生幻覺的助理」變成一個可以接下任務、而你能去忙其他事的工具。
## 5 分鐘內啟動第一個自主迴圈
重點整理
最快的入門方式是使用內建的 `/goal`。開啟 Claude Code，輸入一個包含目標與可驗證停止條件的命令，接著去忙你的事。Claude 會產生程式碼、執行測試、讀取錯誤、修正問題，然後再次執行測試，直到測試通過。
5 個步驟：
1. ### 在 Claude Code 中開啟專案
在終端機中前往專案根目錄並執行 `claude`。等待 Claude 讀取 `CLAUDE.md` 並建立儲存庫索引。
2. ### 定義目標與停止條件
目標是要完成的事情。停止條件則是 Claude 判斷工作完成的方式。理想情況下，這是一個會回傳 0 或 1 的命令。範例：「目標：`tests/api/*.test.ts` 中的 23 個測試全部通過。當 `pnpm test` 回傳結束碼 0 時停止。」
3. ### 執行 /goal
命令：
```
/goal All tests in tests/api/*.test.ts must pass. Run pnpm test, read the errors, fix them, and run it again. Stop when the exit code = 0. Maximum 20 iterations.
```
Claude 會開始迴圈：執行測試、發現失敗、開啟檔案、修正，再次執行測試。
4. ### 設定預算上限
在背景分頁中使用 `/usage` 監控用量。設定每日 token 或金額上限，避免一次迴圈耗盡整個餘額。更多資訊請參閱[如何避免耗盡 Claude Code 使用上限](https://ailoot.ai/blog/zh-hant-tw/claude-code-token-limits-saving/)指南。
5. ### 去忙你的事
30 分鐘後回來看看。如果任務簡單，畫面應該已經顯示「DONE，所有測試都通過了」。如果任務比較複雜，就閱讀報告：「在第 20 次迭代停止，原因 X。」手動修正迴圈無法完成的部分，再重新啟動。
## 驗證器模式：Claude 如何在迴圈中檢查自己的工作
重點整理
Claude 應該永遠有方法檢查自己的工作。沒有檢查機制時，迴圈中的代理程式就會開始產生幻覺——明明一切都壞了，卻認為任務已經完成。驗證器是能明確回傳「完成／未完成」的命令（測試、lint、評估模型、自訂檢查）。
驗證器有三種類型：
**1. 技術驗證（結束碼）**——最可靠。`pnpm test`、`npm run lint`、`tsc --noEmit`、`playwright test`。它們會回傳 0 或 1，不需要解讀。`/goal` 也採用這種方式——底層使用 Haiku 評估模型，在每一輪檢查條件是否已達成（最多 4000 個字元）。
**2. 評估模型**——第二個模型會檢視第一個模型的結果，並根據評分標準評分。適合沒有正式檢查方式的任務（「文章風格好嗎？」「設計符合品牌形象嗎？」）。Anthropic 將這種方式稱為 `Claude Code Review`——由獨立的審查代理程式檢查主要代理程式的工作，找出邏輯錯誤、邊界案例和安全問題。根據 Anthropic 的內部資料，它能在大型 PR 中找出 **84% 的問題**（基準方法為 16%）。
**3. 自訂檢查**——自己撰寫的 shell 指令碼。「如果日誌中沒有 ERROR 一詞，就算完成。」「如果 `output.json` 檔案存在且可解析，就算完成。」「如果 `/pricing` 頁面回傳 200，就算完成。」
```
找出這個專案可能出問題的10個原因。
假設事情已經出了差錯，從這個角度來看。
在公開發布之前，我可以多次檢視這個過程。
```
新手最常犯的錯誤是**啟動沒有驗證器的迴圈**。代理程式會原地打轉：寫程式碼、不檢查、以為完成了、進入下一輪，然後重寫先前已經做好的內容。三小時後，程式碼一團亂，帳單則是 $200。
我學到最好的規則是：**先寫好驗證器，再啟動迴圈**。如果你無法用一句話說明停止條件，這項任務就還沒準備好交給自主流程處理。
## 如何避免一夜之間花掉數千美元：預算上限與停止條件
重點整理
沒有預算上限、成本停止條件或驗證器的迴圈，可能在有人發現前就累積高額帳單。三種防護措施可以避免這種狀況：迭代次數上限、token 或金額上限，以及停滯偵測器。
每個夜間迴圈都需要的三道煞車：
**1. 迭代次數上限。** `--max-iterations 20`。迴圈最多只能執行 N 次——即使驗證器沒有觸發也一樣。若執行 20 次後仍未達成停止條件，代表任務卡住了，需要人工介入。
**2. Token 或金額上限。** `/usage limit 50`——每天不超過 $50。接近上限時，迴圈會自行停止並發出警示。這能避免迴圈失控、累積高額費用。
**3. 明確約定的進度檢查。** 下方 `HEAD` 比較只能偵測新提交，不能偵測所有程式碼修改。只有在隔離 worktree 中，且每次修改程式碼的迭代都先建立本機檢查點提交時，才適用這項比較。有效但未提交的變更不會改變 `HEAD`，可能被誤判為停滯。也要保存驗證結果；新提交只能證明變更已記錄，不能證明任務改善或通過。
以下只示範含這三項檢查的包裝結構。成本回報與代理叫用行是執行器相關範例，並非已驗證的 CLI 安裝配方；改用於已安裝版本前，先確認這些介面。以提交檢查進度時，每次修改程式碼的迭代都必須建立本機檢查點提交；若執行器留下未提交修改，應停止審查，不可標記為「沒有進展」。
```bash
#!/bin/bash
PROMPT="$1"
MAX_ITER=20
MAX_COST_USD=50
COMPLETION="DONE"
PREV_HASH=""
STAGNATION=0
for i in $(seq 1 $MAX_ITER); do
# 金額上限
CURRENT_COST=$(claude usage --json | jq '.cost_usd')
if (( $(echo "$CURRENT_COST > $MAX_COST_USD" | bc -l) )); then
echo "STOP: 已達預算上限 $MAX_COST_USD"
break
fi
# 執行
OUTPUT=$(claude code -p "$PROMPT" --auto-accept)
# 完成檢查
if echo "$OUTPUT" | grep -q "$COMPLETION"; then
echo "STOP: 完成訊號"
break
fi
# 僅檢查提交進度：每次修改程式碼的迭代都須先提交本機檢查點。
# HEAD 無法偵測尚未提交的有效修改。
CURRENT_HASH=$(git rev-parse HEAD 2>/dev/null)
if [ "$CURRENT_HASH" = "$PREV_HASH" ]; then
STAGNATION=$((STAGNATION + 1))
if [ "$STAGNATION" -ge 3 ]; then
echo "STOP: 迭代 3 次後仍停滯"
break
fi
else
STAGNATION=0
fi
PREV_HASH="$CURRENT_HASH"
done
```
擴充範本之前先驗證進度檢查：未提交的修改應視為未記錄工作；檢查點提交會改變 `HEAD`；只有獨立驗證器能判定成功。依上述約定，連續三次雜湊不變代表沒有新提交，不代表所有工作檔都未變動。接下來你可以加上停止時的 Slack 警示、早上的自動 Telegram 報告，以及預算達到 80% 時的推播通知。原則不變：迴圈需要的是**煞車，而不只是油門**。
## 5 個可直接使用的夜間迴圈情境
重點整理
並非每項任務都適合交給自主迴圈處理。適合的任務應能反覆執行，並有明確的驗證器：測試、重構、監控、文章流程、資料匯入。不適合的任務則沒有正式檢查方式，或包含多項主觀標準。
**情境 1：讓失敗的測試全部通過**
```
/goal There are 47 failing tests in the tests/ directory. Goal: make them all pass.
Run pnpm test, read stderr, open the file with the error, fix it, and run pnpm test again.
Stop when exit 0. Max 30 iterations.
```
**情境 2：跨 200 個檔案的大型重構**
```
/batch Replace the old apiV1 API client with the new apiV2 in all files under src/**/*.ts.
Each file gets its own worktree. After the replacement, run tsc --noEmit; fix any errors.
Merge the worktrees at the end.
```
**情境 3：整晚監控正式環境**
```
/loop 30m Every 30 minutes, check https://your-app.example.com/api/health.
If it doesn't return 200, read the logs, find the cause, fix it, and redeploy.
Log each iteration to /tmp/night-monitor.log.
```
**情境 4：匯入大型資料集並去除重複資料**
```
/goal Import the CSV file /tmp/import.csv (12,000 rows) into the clients table.
For each row, check for a duplicate by email; if none, insert it; if one exists, update it.
Log conflicts to /tmp/conflicts.log. Stop when the last row has been processed.
```
**情境 5：文章流程（常見設定）**
對於定期需要 SEO 文章的線上服務或代理商，情境如下：
```
/loop 8h Every 8 hours: open the backlog file for topics with status 'queued'.
If a topic is available, run the skill for writing a guide.
Publish to dev. Change the status to 'review'. Notify the person responsible in Telegram.
```
## 每次迭代要提供什麼：以 CLAUDE.md 和 Second Brain 保存狀態
重點整理
沒有記憶時，Claude 每次迭代都會從頭開始——重新開啟專案、讀取檔案，並忘記上一輪的決策。沒有 `CLAUDE.md`，它就不知道架構；沒有 `business/`（Second Brain），它就不知道產品背景；沒有技能，它就記不住你的規則與風格。透過這三層檔案保存各次迭代之間的狀態。缺少它們，迴圈執行到第 5 次迭代時就會開始退化。
專案「記憶」的三個層次，能將一次性的提示轉變為受控迴圈：
**1. CLAUDE.md**——專案的章程，說明產品內容、技術堆疊、規則，以及絕對不能做的事。Claude 在每個工作階段和每次迴圈迭代開始時都會讀取這個檔案。沒有它，Claude 每次都得「重新開啟」專案，消耗更多上下文，也增加產生幻覺的風險。你可以在 [CLAUDE.md](https://ailoot.ai/blog/zh-hant-tw/claude-md-template/)指南中找到可直接使用的範本和 6 項規則。
**2. Second Brain**——一個存放商業知識的資料夾，包含產品、受眾、目標、經濟狀況和行銷資訊。它存放的不是程式碼，而是意義。迴圈撰寫文章或尋找客服答案時，會讀取 Second Brain，根據專案背景回應，而不是憑空作答。
**3. Context Engineering**——決定每次迭代要提供給 Claude 的內容。不是整個 Second Brain 資料夾，也不是整個儲存庫，而是只提供相關內容。Plan Mode 很有幫助：Claude 會判斷任務需要哪些檔案，並只讀取那些檔案。詳情請參閱 [Plan Mode](https://ailoot.ai/blog/zh-hant-tw/claude-code-plan-mode/)指南。
我在錯誤中反覆摸索，才確立了這項主要的操作原則：
這三層構成這套方法的**三大支柱**：AI 分身（透過技能和 CLAUDE.md 教會 Claude 你的風格與規則）、Second Brain（儲存在檔案中的商業脈絡），以及 Context Engineering（你在每次請求中提供的內容）。少了其中任何一項，迴圈都會變成一場帳單不斷增加的無限循環。
## 5 個終端機、10–15 個工作階段、數千個代理程式
重點整理
筆電上有 5 個編號的終端機分頁，每個分頁都有自己的 git checkout。此外，也可透過手機上的 Remote Control，在 Claude 應用程式中開啟 5–10 個工作階段，總共平行執行 10–15 個工作階段。每個工作階段都有自己的任務、驗證器和迴圈。
每個工作階段做什麼？執行不同任務：一個迴圈修復錯誤，另一個撰寫新功能，第三個審查團隊的 PR，第四個最佳化效能，第五個準備文件。不是一個包辦所有工作的通用型代理程式，而是數十個各有專長的代理程式，每個都有自己的技能、目標和驗證器。
關鍵在於換個角度思考：
對沒有程式設計師的創業者來說，這代表一件具體可行的事。你只需要每月 $200 的 Claude 帳戶和一台一般筆電，就能平行啟動 **5 個迴圈**——客服、文章、指標、新產品測試和競爭對手監控。每個迴圈都在自己的 Claude Code 分頁中執行。早上查看摘要即可。這已是 2026 年夏季的工作常態。
## 自主迴圈常見的四種失敗
重點整理
大多數自主迴圈的失敗都符合四種模式：沒有驗證器，代理程式自行判定任務已完成；沒有預算上限，迴圈可能在一夜之間累積高額費用；迭代之間沒有狀態，導致決策互相矛盾；停止條件含糊，迴圈不知道何時該停止。
**失敗 1：「幻覺迴圈」**
即使驗證器沒有觸發，代理程式仍判定任務已完成。或者根本沒有驗證器。三小時後，Claude 說：「都完成了！」但測試失敗、頁面無法開啟，什麼都不能用。你已經在毫無意義的迭代上花掉 $80。
解決方法：使用嚴格的驗證器（命令的 `exit code`），而不是口頭確認。
**失敗 2：「一夜之間燒光預算」**
沒有預算上限的迴圈，就像沒有插銷的手榴彈。
解決方法：使用 `/usage limit`，或透過 `claude usage --json` 停止迴圈的外部指令碼，在達到門檻時關閉迴圈。
**失敗 3：「迴圈在迭代之間失去上下文」**
在第 1 次迭代中，Claude 做了一項架構決策。到了第 7 次迭代，它忘記這項決策，反而做出相反決定。經過 15 次迭代，程式碼已經變得雜亂不堪。
解決方法：透過 `CLAUDE.md` 和 Second Brain 資料夾建立狀態層。迴圈會將每項架構決策**寫入**檔案，並在下一次迭代時讀取。
**失敗 4：「停止條件不精確——迴圈永遠不停止」**
`/goal "讓頁面變漂亮"`——「漂亮」是什麼意思？沒有明確的指標，迴圈就永遠不會停止。它會一直執行，直到達到迭代次數或預算上限。
解決方法：停止條件必須永遠是**可衡量的**。不要說「漂亮」，而要說「Lighthouse Performance ≥ 90、Accessibility ≥ 95」。不要說「能運作」，而要說「`tests/pricing.test.ts` 中的測試全部通過」。
## 什麼時候不需要迴圈工程
重點整理
迴圈工程是處理重複且可驗證任務的工具。一次性的創作任務、沒有正式驗證器的任務，以及需要主觀評估的任務，都不需要迴圈工程。了解這項技術的限制，比了解它的操作方式更重要。
以下任務不適合交給自主迴圈：
- 一次性的創作任務。為新產品製作一個網站、一個標誌，或一份策略備忘錄。使用迴圈太過複雜；寫一個提示，再手動調整結果會更簡單。
- 沒有驗證器的任務。如果你無法用結束碼或明確訊號表達停止條件，就不要啟動迴圈；否則它會變成無止盡的火堆。
- **需要主觀評估的任務。**「讓語氣更好聽」、「改善 UX，讓它更舒適」——這些需要你親自判斷，而不是交給迴圈。
- 全新且陌生的領域。如果你自己也不清楚「完成」應該是什麼樣子，就不要讓 Claude 在迴圈中執行。先理解，再自動化。
而我從錯誤中學到的主要原則是：
啟動迴圈前最重要的問題是：我能否用一句話說明如何判斷 Claude 已完成？如果可以，迴圈就可能有所幫助。如果不行，就先定義可驗證的條件，再啟動迴圈。
### 來源
- [Ralph Loop Claude Plugin - Anthropic](https://claude.com/plugins/ralph-loop) - 官方外掛
- [Ralph Wiggum plugin on GitHub - Anthropic](https://github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum) - 原始碼
- [Claude Code Review - Anthropic blog](https://claude.com/blog/code-review) - 多代理程式 PR 審查研究預覽，問題發現率為 84%
- [Documentation /goal - Claude Code Docs](https://code.claude.com/docs/en/goal) - 命令官方文件
- [Documentation /loop scheduled tasks - Claude Code Docs](https://code.claude.com/docs/en/scheduled-tasks) - 官方文件
迴圈工程是在你已經了解的 Claude Code 知識之上再加一層。首先需要三大支柱：AI 分身 + Second Brain + Context Engineering。缺少它們，迴圈執行到第 5 次迭代時就會開始退化。歡迎前往 [ailoot.ai](https://ailoot.ai/) 繼續探索 Ailoot。
## 常見問題：Claude Code 夜間執行：2026 年的迴圈工程與 Ralph Loop
### 為什麼 HEAD 沒變，可能誤判迴圈沒有進展？
HEAD 指向提交；工作目錄中的有效修改，在提交之前不會改變它。因此範例偵測器要求每次修改程式碼的迭代都建立本機檢查點提交。若沒有這項約定，應暫停檢查未提交內容，不能直接判定停滯。
### 有了新提交，就能證明迴圈改善了成果嗎？
不能，只證明已記錄變更。請把驗證結果與檢查點一起保存，並依真正的驗收條件停止。使用包裝程式之前，也必須驗證對應執行器的叫用方式及成本介面。
## Ailoot · 公司及其專案組合
Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。
公司及其專案組合：數百萬客戶，每月銷售額達數十億。
Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。