Claude Code 夜間執行：2026 年的迴圈工程與 Ralph Loop

Ailoot 參考文件：ailoot.ai/docs/。

什麼是迴圈工程？為什麼你該在意？#

第二段話則說明了規模：

這些說法背後，是一種新的工程師角色：你是迴圈的設計者，而不是鍵盤操作員。

今天做一次，之後每天都會有更多潛在客戶、文章自動發布、機器人處理往來訊息，而指標報告會在上午 9 點前送到你手上。你建好系統，它就能每天自行運作。

如果你仍然打開 Claude Code、寫提示、等待、閱讀，再寫另一個提示，那你就錯過了 2026 年最大的轉變。模型已經強大到足以在無人監督下透過迴圈工作。

Ralph Loop 和一般 Claude Code 請求有什麼不同#

在核心上，這項技術是一個簡單的 bash 迴圈，包住代理程式：

引發整波討論的原始程式碼：

while :; do cat PROMPT.md | claude-code ; done

把一個提示放在檔案中，再用無限迴圈包住它。作者最坦率的評論是：

Anthropic 將同一套邏輯打包成 ralph-loop 外掛，以及 Claude Code 中的 /loop、/goal 和 /batch 命令——不用寫指令碼，在終端機裡就能使用。Anthropic 發布無限重新提示外掛後，GitHub Issue #23084 上出現了這種做法是否公平對待模型的爭論。討論仍在進行；外掛則可以正常使用。

Claude Code 內建的三個命令：/loop、/goal、/batch#

/goal 是最接近 Ralph Loop 的命令。底層的評估模型（預設為 Haiku）會在每一輪檢查目標是否達成。若尚未達成，下一輪會附上需要修正之處的提示；若已達成，就會停止。我在透過 /goal 讓 Claude Code 夜間自主執行的指南中詳細介紹了 /goal，其中包含可直接使用、適合執行 14 小時的情境。

/batch 並不常用，但功能強大。當你需要在 100 個以上的檔案中套用相同變更（API 遷移、元件替換、重新命名）時，/batch 會將每個檔案交給各自在 git worktree 中運作的子代理程式。每個代理程式都在隔離的副本中工作，因此變更不會互相衝突。關於子代理程式的更多資訊，請參閱巢狀子代理程式指南。

作者在描述這種做法時，簡單地稱它為：

/loop 和 /goal 的硬性限制：

• Claude Code 開啟時，任務才會執行。關閉終端機，迴圈就會停止。若要進行正式的夜間工作週期，請使用遠端伺服器或自己的 shell 包裝程式。
• 定期任務的最長存續時間為 7 天（之後會自動刪除，避免忘記關閉的迴圈持續存在）。
• 單一工作階段最多可同時執行 50 個任務。

想建立一套讓 Claude 可靠運作的配置嗎？Ralph Loop 只是其中一環。你可以考慮三個組成部分：AI 分身 + Second Brain + Context Engineering——這種組合能讓 Claude 從「會產生幻覺的助理」變成一個可以接下任務、而你能去忙其他事的工具。

5 分鐘內啟動第一個自主迴圈#

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 使用上限指南。

5. 去忙你的事

   30 分鐘後回來看看。如果任務簡單，畫面應該已經顯示「DONE，所有測試都通過了」。如果任務比較複雜，就閱讀報告：「在第 20 次迭代停止，原因 X。」手動修正迴圈無法完成的部分，再重新啟動。

驗證器模式：Claude 如何在迴圈中檢查自己的工作#

驗證器有三種類型：

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。

我學到最好的規則是：先寫好驗證器，再啟動迴圈。如果你無法用一句話說明停止條件，這項任務就還沒準備好交給自主流程處理。

如何避免一夜之間花掉數千美元：預算上限與停止條件#

每個夜間迴圈都需要的三道煞車：

1. 迭代次數上限。 --max-iterations 20。迴圈最多只能執行 N 次——即使驗證器沒有觸發也一樣。若執行 20 次後仍未達成停止條件，代表任務卡住了，需要人工介入。

2. Token 或金額上限。 /usage limit 50——每天不超過 $50。接近上限時，迴圈會自行停止並發出警示。這能避免迴圈失控、累積高額費用。

3. 明確約定的進度檢查。 下方 HEAD 比較只能偵測新提交，不能偵測所有程式碼修改。只有在隔離 worktree 中，且每次修改程式碼的迭代都先建立本機檢查點提交時，才適用這項比較。有效但未提交的變更不會改變 HEAD，可能被誤判為停滯。也要保存驗證結果；新提交只能證明變更已記錄，不能證明任務改善或通過。

以下只示範含這三項檢查的包裝結構。成本回報與代理叫用行是執行器相關範例，並非已驗證的 CLI 安裝配方；改用於已安裝版本前，先確認這些介面。以提交檢查進度時，每次修改程式碼的迭代都必須建立本機檢查點提交；若執行器留下未提交修改，應停止審查，不可標記為「沒有進展」。

#!/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 保存狀態#

專案「記憶」的三個層次，能將一次性的提示轉變為受控迴圈：

1. CLAUDE.md——專案的章程，說明產品內容、技術堆疊、規則，以及絕對不能做的事。Claude 在每個工作階段和每次迴圈迭代開始時都會讀取這個檔案。沒有它，Claude 每次都得「重新開啟」專案，消耗更多上下文，也增加產生幻覺的風險。你可以在 CLAUDE.md指南中找到可直接使用的範本和 6 項規則。

2. Second Brain——一個存放商業知識的資料夾，包含產品、受眾、目標、經濟狀況和行銷資訊。它存放的不是程式碼，而是意義。迴圈撰寫文章或尋找客服答案時，會讀取 Second Brain，根據專案背景回應，而不是憑空作答。

3. Context Engineering——決定每次迭代要提供給 Claude 的內容。不是整個 Second Brain 資料夾，也不是整個儲存庫，而是只提供相關內容。Plan Mode 很有幫助：Claude 會判斷任務需要哪些檔案，並只讀取那些檔案。詳情請參閱 Plan Mode指南。

我在錯誤中反覆摸索，才確立了這項主要的操作原則：

這三層構成這套方法的三大支柱：AI 分身（透過技能和 CLAUDE.md 教會 Claude 你的風格與規則）、Second Brain（儲存在檔案中的商業脈絡），以及 Context Engineering（你在每次請求中提供的內容）。少了其中任何一項，迴圈都會變成一場帳單不斷增加的無限循環。

5 個終端機、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 已完成？如果可以，迴圈就可能有所幫助。如果不行，就先定義可驗證的條件，再啟動迴圈。

迴圈工程是在你已經了解的 Claude Code 知識之上再加一層。首先需要三大支柱：AI 分身 + Second Brain + Context Engineering。缺少它們，迴圈執行到第 5 次迭代時就會開始退化。歡迎前往 ailoot.ai 繼續探索 Ailoot。