Claude Code 的 /goal：2026 年的自主模式與 Agent View

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

Claude Code 中的 /goal 是什麼？#

過去，Claude Code 每次回覆後都會停止，等待你輸入下一個提示。這對短期任務很有效，但遇到長期任務就會出問題：API 遷移、修復 12 個失敗的測試、重構 800 行的檔案——這類任務需要 20–30 次反覆調整，而每次都得回到終端機操作。

/goal 用一個簡單的想法解決這個問題：把「負責做事的人」和「負責判斷何時完成的人」分開。主要代理程式撰寫程式碼。另一個獨立的評估器（快速的 Haiku 模型）會在每個回合結束後讀取對話，並回答一個問題：「條件達成了嗎？」如果還沒達成，代理程式就會開始下一個回合；如果達成了，控制權就會交還給你。

Anthropic 官方文件將它定義如下：

Claude Code 在 Anthropic 的創作者，於 2026 年 5 月 4 日描述了工作日常：

晚上用手機啟動數千個代理程式——這不是行銷宣傳，而是 Anthropic 工程師目前的實際做法。讓這一切成為可能的機制，就是 2026 年 5 月 11 日同一次發布中推出的 /goal 與 Agent View 組合。

為什麼需要自主模式：2026 年 5 月 11 日前後有什麼不同？#

「讓 AI 整晚工作」的想法早在 2025 年秋季就已出現，當時 Cursor Composer 和 Cline 自動模式已經能在背景執行。但在 2026 年 5 月 11 日之前，Claude Code 必須透過手動包裝程式才能做到：每隔 N 分鐘呼叫 claude -p 的 cron 工作，或監看 git status 並啟動下一個提示的包裝程式。

這種 DIY 做法經常造成災難。2026 年 5 月 22 日，一位開發者讓這類指令稿整晚執行，醒來時收到 6,000 美元帳單。根本原因是 Anthropic 悄悄將 Claude Code 的快取 TTL 從 1 小時改為 5 分鐘，且沒有公告。cron 每 30 分鐘呼叫一次正式環境——兩次執行之間快取有時間過期。每次執行都會從頭重建 800,000 個 token 的歷史紀錄。將新資料寫入快取的成本，遠高於從作用中的快取讀取。

這位開發者並沒有做什麼特別的事——他完全是照著 Anthropic 宣傳的方式使用工具。

/goal 透過內建架構解決這個問題：

1. 監督者程序會讓工作階段在終端機外持續執行，即使關閉視窗或筆電進入睡眠也能維持。
2. Haiku 評估器會以低成本檢查每個回合；評估器的 token 費用只要幾分錢。
3. 條件中的硬性回合上限——你可以明確寫上 or stop after 20 turns，確保工作階段一定會停止。
4. 背景工作階段的 worktree 隔離——變更會寫入個別分支，不會動到你的工作副本。

和「自行撰寫 bash 指令稿」的做法不同，Anthropic 將這些機制都做成工具的一級功能，而不是第三方技巧。

3 個步驟啟用 /goal#

步驟 1. 將 Claude Code 更新至 2.1.139 或更新版本。

檢查版本：

claude --version

如果版本低於 2.1.139，請更新：

claude update
# or force it through npm
npm install -g @anthropic-ai/claude-code@latest

2026 年 5 月 12 日至 19 日間發布的版本修正了第一版中的重要錯誤。在 2.1.140 中，他們修正了 disableAllHooks 導致評估器卡住且沒有任何提示的問題。2.1.143 加入了 worktree.bgIsolation: "none"，並修正了 stop hook 循環。2.1.144（5 月 19 日）則新增了背景工作階段的 --resume 和供指令稿使用的 agents --json。最低版本為 2.1.143。

步驟 2. 輸入 /goal 並附上條件。

開啟一般的 Claude Code 工作階段，輸入以下命令：

/goal all tests in test/auth pass and the linter is clean, or stop after 15 turns

之後不必另外傳送提示——命令會立即啟動第一個回合。條件可用俄文、英文或混合語言撰寫；模型能理解這兩種語言。長度上限為 4,000 個字元。

步驟 3. 透過即時浮層監控。

/goal 啟動後，終端機底部會出現即時面板：

/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail

面板會顯示：

• Turns——已完成的回合數
• Elapsed——啟動後經過的時間
• Tokens——耗用的 token 總數（監控預算的主要數值）
• Last——評估器上次表示「還沒」的原因

一個實用技巧：如果評估器連續三個回合都回覆相同理由，就表示你可能陷入循環。這時請按 Ctrl+C 或輸入 /goal clear（同義詞：stop、off、reset、cancel），改寫條件後重新啟動。社群的 /goal 指南也將這條規則列為循環的主要徵兆：「同一個理由卡住三次——這就是循環，退出吧。」

如何撰寫良好的條件：5 條規則與 5 個範例#

Anthropic 的文件指出，良好條件有三個必要要素：

一個現成範本涵蓋這三個要素：

另一個同類條件範例如下：

/goal [執行工作]，直到 [可衡量的最終狀態]，且不得違反 [必須遵守的限制]

最容易讓人出錯的 5 條規則：

規則 1. 最終狀態必須能用命令驗證，而非憑感覺判斷。

不要寫「讓它看起來更好」，而要寫 npm test exits 0。不要寫「改善 UX」，而要寫 Lighthouse Performance score above 90。評估器只會讀取對話紀錄——它不會執行命令，也不會查看螢幕截圖。如果結果無法以文字記錄，評估器就永遠不會說「是」。

規則 2. 限制必須明確且範圍狹窄。

沒有設定限制時，Claude 可能會透過刪除測試本身或註解掉失敗的斷言來修正測試。請指定 without modifying any file outside /auth、without removing existing assertions、without bumping major versions of dependencies。

規則 3. 必須設定硬性回合上限。

每個條件都要加上 or stop after N turns。這是避免無止盡循環的救命索。沒有上限時，循環執行一小時所耗用的 token，會比手動完成同一項任務還多。請為此編列預算。

沒有上限時，循環執行一小時所耗用的 token，會比手動完成同一項任務還多。請為此編列預算。

規則 4. 描述「要什麼」，而不只是「怎麼做」。

如果條件沒有提到視覺效果，Claude 就不會製作。如果條件只要求「測試通過」，Claude 可能會註解掉複雜的測試。請描述你「想要什麼」，而不只是「如何驗證」。

規則 5. 要求 Claude 在聊天中展示證據。

評估器不會執行命令——它只會讀取 Claude 已經展示的內容。如果條件要求「npm test 成功」，但 Claude 沒有在對話紀錄中展示 npm test 的輸出，評估器就會永遠回答「還沒」。請在條件中加上「在對話中顯示 <command> 的輸出」這句話。

常見任務的 5 個實用範例：

1. API 遷移：
/goal every call to getUser() has been replaced with fetchUser(), npm test passes, npm run build is green, no other API names have been touched, or stop after 30 turns

2. 修復測試：
/goal all failing tests in test/auth are now green (npm test shows 0 fails in the chat), without changing assertions or deleting tests, or stop after 20 turns

3. 程式碼品質（檔案大小）：
/goal src/legacy/UserService.ts has been split into files under 200 lines each, all imports are updated, npm run build is green, or stop after 25 turns

4. 清空待辦項目：
/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a worktree branch, open a PR. Continue until the queue is empty or 6 issues have been processed

5. 安全性稽核：
/goal every npm audit vulnerability with severity >= high is fixed, all existing tests pass, no breaking API changes, or stop after 15 turns

想做的不只是執行 /goal，而是打造一套能讓自主模式在專案中真正發揮作用的環境嗎？/goal 只是最後一環。在此之前，需要先準備好三大支柱：AI 分身（你的方法論寫在 Skills 和 Subagents 中）、第二大腦（CLAUDE.md 和 plans/ 資料夾），以及情境工程（Plan Mode 和 /compact）。這三個組成部分需要一起規劃，才能支援具備情境脈絡的工作。

/goal 真正有效的 5 個範例#

Anthropic 的文件列出四種適合使用 /goal 的任務：

以下是五個可直接使用的條件範例——請套用並依照你的專案調整。

範例 1. 將模組遷移至新的 API。

情境：你要從 REST 遷移至 GraphQL，或將舊的 getUser() 函式替換為新的 fetchUser()。這項工作雖然偏向機械式，但會影響 30–50 個檔案。

條件：

/goal every getUser() in src/ has been replaced with fetchUser(), all calls updated to the new interface (id instead of userId), npm test passes, no files outside src/ touched, or stop after 30 turns

這個條件有效的原因：最終狀態可用 grep -r getUser src/ | wc -l 檢查（結果應為 0），也可用 npm test exits 0 驗證。這項限制可保護測試檔案。

範例 2. 修復失敗的測試。

情境：更新函式庫後，有 15 個測試壞掉。你知道修復方式很機械——更新 mock，並依照新格式調整斷言。你不想手動處理。

條件：

/goal all failing tests in test/ are now green, npm test shows the results in the chat with 0 failures, without deleting tests or commenting out assertions, or stop after 25 turns

另一個同類條件範例如下：

另一個同類條件範例：

修復所有失敗的測試，直到 npm test 回傳 0，且不得修改 /auth 目錄以外的任何檔案

範例 3. 拆分巨型類別。

情境：一個 1,200 行的檔案包含所有內容——模型、服務、工具程式和 API 用戶端。你想依照「一個檔案、一項職責」的原則拆分，更新所有匯入，並讓測試持續通過。

條件：

/goal src/legacy/UserService.ts has been split into files under 200 lines, each file handles one responsibility (model, repository, api-client, validator), all imports are updated, npm run build is green, existing tests pass, or stop after 25 turns

範例 4. 一夜之間清空待辦項目。

情境：你有一個開源程式碼儲存庫，其中有 20 個標記為 good-first-issue 的未解決 issue。你想讓 Claude 在夜間逐一處理。

條件：

/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a separate worktree branch worktree-issue-N, open a PR with a description. Continue until the queue is empty or 6 issues have been processed, or stop after 80 turns

數字 6 並非隨意選定——這是 Pro 方案一個晚上可處理的合理上限。若要平行執行多個代理程式，則需要 Max 或 Enterprise。

範例 5. 安全性稽核。

情境：npm audit 顯示 8 個高嚴重性弱點。你想修復它們，同時不更新 major 版本。

條件：

/goal every npm audit vulnerability with severity high+ is fixed, npm audit shows 0 high in the chat, all existing tests pass, no breaking API changes, no major version bumps to packages, or stop after 15 turns

不要用 /goal 執行的任務：

Croucher 在他的實戰指南中強調這項原則：凡是「完成」代表「看起來不錯」、「感覺對了」、「設計得很好」或「有趣」的任務，都不要使用 /goal。評估器只會讀取對話紀錄——它不會執行工具，也無法評估結果的實際運作情況。這條規則排除了 80% 的主觀任務，因為在這些任務中，/goal 會不斷循環，卻沒有產出有用結果。

/goal 何時會白白耗費金錢：3 種反模式#

反模式 1. 條件含糊且沒有硬性回合上限。

最常見的錯誤是使用「改善程式碼」、「讓它變好」或「最佳化」這類條件。沒有回合上限，代理程式就會一直執行，直到耗盡你的額度。

Findskill 描述了一個真實案例：

一位開發者表示，他用含糊的條件執行了 14 小時的工作階段，花費 200 美元。若條件寫得不好，讓評估器一直回答「還沒」，你可能要等執行到第 50、100 甚至 500 個回合後才會察覺。

含糊的條件執行 14 小時花掉 200 美元，相當於 Max 方案整週的使用上限。隔天早上醒來時，你的額度已經用完，卻沒有任何有用成果。

防範方式：每個條件最後都加上 or stop after N turns（簡單任務設為 15，困難任務設為 50，整夜執行最多設為 100）。

反模式 2. 快取失效的遞迴循環。

2026 年 5 月 22 日，一位開發者報導了一則故事：Anthropic 悄悄將快取 TTL 從 1 小時改為 5 分鐘，導致一夜之間花費 6,000 美元。該開發者並未直接使用 /goal，但邏輯相同：自動循環每 30 分鐘由 cron 計時器啟動，每次都從頭重建 800,000 個 token 的歷史紀錄。

根本問題在於外部自動化並不知道提供者內部發生的變更。如果你讓 /goal 在無人監督下執行 8 小時，也可能發生同樣的事：token 使用量會非線性成長，而且提示快取的運作方式可能和你想的不一樣。

防範方式：

1. 不要讓 /goal 在沒有中途檢查的情況下執行 8 小時以上。
2. 在 Settings → Usage 中啟用使用量上限（這是 6,000 美元事件後新增的防護措施）。
3. 夜間開啟 claude agents 兩次——按 Space 查看狀況，確認回合數沒有比預期增加得更快。
4. 使用昂貴的模型鏈（Opus 4.7）時，設定更嚴格的回合上限，最多 30 回合。

反模式 3. 用 /goal 進行創意工作。

Croucher 用 /goal 建置了一款遊戲——條件包含決定性、不變條件，以及檢查關卡是否可以通關。遊戲建置完成，測試通過，評估器也判定「已達成」。但遊戲沒有視覺效果，因為條件沒有提到圖像。

這說明了通則：評估器會精確最佳化你衡量的項目。條件沒有提到視覺效果，就不會有視覺效果；條件只提到測試，代理程式可能會註解掉斷言。

防範方式：不要用 /goal 執行任何仰賴品味的工作（設計、文案、UX）。請回到一般工作階段或 Plan Mode——這些模式讓你持續參與決策。

Agent View 是什麼？如何開啟儀表板#

如果 /goal 是「持續工作直到完成」的命令，Agent View 就是可一次查看所有工作階段的控制室。Anthropic 如此描述：

開啟命令：

claude agents

系統會開啟 TUI——終端機中的文字儀表板。左側是工作階段清單，右側是 peek 窗格，顯示所選列的最新訊息。

六種工作階段狀態：

主要快速鍵：

↑ / ↓             在工作階段清單中移動
Space             peek 窗格（檢視但不連線）
Enter / →         連線到工作階段（進入工作階段）
←                 detach（離開但不終止）
Ctrl+T            pin（保護工作階段，避免自動停止）
Ctrl+X            停止工作階段；2 秒內再按一次即可刪除
Ctrl+R            重新命名
Ctrl+S            切換分組方式（狀態 ↔ 目錄）

如何啟動背景工作階段：

從互動式 Claude Code 啟動：

/bg fix the failing test test/auth/login.test.ts

或直接從 shell 啟動：

claude --bg "fix the failing test test/auth/login.test.ts"

也可以替它命名（方便在 Agent View 中以容易辨識的標籤顯示）：

claude --bg --name "flaky-test-fix" "fix test/auth/login.test.ts"

背景工作階段會自動加入 Agent View——使用 --bg 啟動，再開啟 claude agents，就會在清單中看到它。

主要功能：即使筆電進入睡眠或關閉視窗，工作階段仍會持續。

但如果關閉筆電或手動重新啟動，背景工作階段就會以 Failed 結束。整夜執行大量背景代理程式，必須讓筆電保持開機。

Worktree：Claude 如何隔離並行工作階段#

Worktree 解決了並行自主工作中的主要問題：如果兩個工作階段同時嘗試編輯 src/auth.ts，會發生什麼事？在 2.1.139 之前，這些工作階段確實可能互相覆蓋變更。透過 Agent View，Anthropic 導入了自動隔離：

實際運作方式：

# Launched three background sessions:
claude --bg --name "fix-tests" "fix the failing tests in test/"
claude --bg --name "add-oauth" "add Google OAuth according to the plan in plans/oauth.md"
claude --bg --name "split-userservice" "split UserService.ts into modules"

# File structure after launch:
.claude/worktrees/
├── fix-tests/             # separate repo copy on branch worktree-fix-tests
├── add-oauth/             # separate copy on branch worktree-add-oauth
└── split-userservice/     # separate copy on branch worktree-split-userservice

每個工作階段都會在自己的副本中工作。任務完成後，將需要的分支合併至 main。

危險陷阱——刪除工作階段也會刪除它的 worktree。

如果你在 Agent View 中終止工作階段（按兩次 Ctrl+X），它的 worktree 就會消失。所有尚未提交的變更都會遺失。在 Agent View 中刪除工作階段前，務必先提交或推送變更。

選擇停用（適用於少數情況）：

如果你的儲存庫不適合使用 git worktree（例如採用符號連結的架構，或 checkout 緩慢的大型 monorepo），可以停用隔離：

// .claude/settings.json
{
  "worktree": {
    "bgIsolation": "none"
  }
}

如此一來，背景工作階段就會直接編輯你的工作副本。大型 monorepo 團隊提出需求後，這項選擇停用功能於 2.1.143 推出。

並行執行會消耗使用額度：

這代表每月 20 美元的 Pro 方案足以讓 1–2 個工作階段整夜並行，而不是 10 個。若要平行執行大量代理程式，就需要 Max 或 Enterprise 方案。

結合 /goal、Plan Mode 和 subagents 處理長期任務#

常見的失敗方式是直接輸入 /goal build a new feature。這行不通，因為評估器不知道「功能完成」是什麼樣子。你需要一份含有核取方塊的計畫，讓評估器能逐項驗證。

第 1 層：Plan Mode 撰寫分階段計畫。

在 Plan Mode 中，請 Claude 建立一份分成 5–7 個階段、並附有可驗證核取方塊的詳細變更計畫。儲存為 plans/2026-05-24-google-oauth.md。每個階段包含 3–7 個核取方塊，列出具體行動。

第 2 層：Subagents 依照階段拆分工作。

如果計畫可以平行處理（例如各階段彼此獨立——後端端點、前端表單和 DB 遷移），你可以使用 claude --bg --name "<phase>"，在個別背景工作階段中啟動每個階段。每個工作階段都會有自己的 worktree。

第 3 層：/goal 持續執行循環，直到核取方塊全部完成。

/goal all phases 1–7 in plans/2026-05-24-google-oauth.md are complete and marked [x], all tests in test/auth pass (npm test shows 0 failures), npm run build is green, or stop after 50 turns

每個回合結束後，評估器會讀取計畫並檢查哪些核取方塊已完成；如果還有未完成項目，代理程式就會繼續工作。

這種組合仰賴三個組成部分：

• 情境工程：plans/ 中的正確情境脈絡，評估器會讀取這些內容
• 第二大腦：plans/ 資料夾會在不同工作階段之間保存計畫
• AI 分身：CLAUDE.md 設定代理程式遵循的規則

沒有 CLAUDE.md，/goal 可能會建議破壞架構的解決方案。沒有 plans/ 中的計畫，評估器就不知道成功標準。沒有 subagents，就無法平行處理不同階段；所有工作都會依序進行。

如何比較 /goal、Codex、Cursor 與其他代理模式#

/goal 在每回合後增加獨立完成檢查。其他產品有不同模式，本機 CLI、託管雲端任務及受監督編輯器，不是可直接互換的比較單位；不要把所有 Codex CLI 都叫雲端容器，也不要假設每次都用同一驗證模型及帳務。

用相同儲存庫快照、任務及驗收比較：

固定多用幾倍 token 的主張，需要相同成功成果及上述條件與實測數。基準百分比也需版本、模型、測試工具及設定；未提供這些條件的 Terminal-Bench 數字不能取代證據，本文沒有跨工具獨立基準。

依需要的流程選擇：受監督編輯、有界背景工作，或有明確完成條件的多回合任務。應測已安裝產品支援模式，不要假設整個競品沒有自主操作。權限核准與任務延續分開；自動核准工具不等於使用者目標完成。

啟動 /goal 前的檢查清單：7 個項目#

每次執行 /goal 前，請檢查以下清單：

1. Claude Code 版本為 2.1.139 以上——使用 claude --version 檢查，若版本較舊就更新。建議的最低版本為 2.1.143（2026 年 5 月 15 日），此版本修正了 stop hook 循環。

2. 條件包含可驗證的最終狀態——不要寫「改善它」，而要指定 npm test exits 0。如果想不出可用來驗證結果的 bash 命令，這項任務就不適合使用 /goal。

3. 設定硬性回合上限——每個條件都要指定 or stop after N turns。簡單任務設為 15，困難任務設為 50，整夜執行最多設為 100。

4. 明確列出狹窄範圍的限制——without modifying files outside /auth、without removing existing assertions、without bumping major versions。若沒有限制，Claude 可能會透過刪除測試本身來修復測試。

5. 重要變更都已提交或推送——若你沒有在 worktree 中工作（例如 worktree.bgIsolation: "none"），Claude 會直接編輯你的工作副本。任何錯誤都可能導致未儲存的工作遺失。

6. 在 Settings → Usage 中啟用使用量上限——這是 6,000 美元事件後新增的防護措施。請設定每日、每個工作階段和每月的上限。

7. 在另一個視窗開啟 Agent View claude agents——處理長期任務時，每小時按一次 Space 檢視狀況。如果回合數增加得比預期快，或評估器連續三個回合重複相同理由，請按 Ctrl+C 並改寫條件。

還有一個額外項目——絕不要在他人的程式碼或不熟悉的程式碼上使用 /goal 搭配 --dangerously-skip-permissions。這個組合會停用所有檢查，讓代理程式在專案中為所欲為。本文作者只會在沒有任何損失風險的新 worktree 中使用它。

/goal 是強大的功能，但不是魔法。它的效果完全取決於你如何撰寫條件。如果你能用可由命令驗證的文字描述「完成」，剩下的工作就交給 /goal。如果做不到，請回到一般工作階段或 Plan Mode。

你可以前往 ailoot.ai 繼續探索 Ailoot。