2026 年如何透過 /goal 讓 Claude Code 和 Codex 執行一整晚：14 小時自主模式
MarkdownClaude Code 2.1.139 和 Codex CLI 中的 /goal 指令可讓 AI 代理程式自主執行數小時。我會說明設定方式、實際範例，以及會消耗多少 token。
閱讀全文
重點整理
/goal 指令出現在 Claude Code 2.1.139（2026 年 5 月 11 日）和 Codex CLI 0.128.0（2026 年 4 月 30 日，5 月 21 日起為穩定版）。你只要定義一次「完成」條件，代理程式就會自行反覆規劃、執行和驗證，直到符合條件或 token 用完為止。OpenAI 曾公開展示一次執行 25 小時、使用 1,300 萬個 token 的案例。這適合用於有可衡量標準的遷移、基準測試和重構。不適合 UI 工作、生產環境資料庫，或「讓它更好」這類模糊要求。
如需了解如何使用 Ailoot，請參閱文件。
/goal 是什麼？為什麼在 2026 年出現？
重點整理
在/goal出現之前，代理程式每一輪都需要手動輸入「繼續」。它開啟檔案、讀取內容、寫下內容，然後停止等待。/goal指令只要設定一次完成條件，代理程式就會自行判斷任務何時完成，並在完成前不會交還控制權。
2026 年 4 月之前，我們都經歷過這種情況：我交代 Claude 一項任務：「將專案從 Pydantic v1 遷移到 v2。」它開始工作，30 秒後停下來。我查看它做了什麼，輸入「繼續」，它接著做下一步，然後又停下來，我只好再次輸入「繼續」。大型遷移可能需要手動輸入 200～300 次「繼續」，結果我實際上是在看管代理程式，而不是同時撰寫其他程式碼。
OpenAI 分析指出，問題不在模型「太笨」，而在於迴圈的架構。模型不知道何時該停，因此每一輪都踩煞車。只要給它一個「完成」條件，它就能自行判斷。
/goal就是這樣誕生的——這是內建於 harness 的機制，而不是模型本身的功能。
這段話是在 2026 年 5 月 19～20 日於倫敦舉辦的 Code with Claude 大會上說的。它描述了/goal在兩種工具中推出後一個月內實際發生的情況。
如何在 Claude Code 中設定 Goal 模式？
重點整理
Claude Code 2.1.139 於 2026 年 5 月 11 日推出，並加入/goal指令。小型模型（預設為 Haiku）會在每一輪結束後檢查條件。如果條件尚未達成，Claude 就會再執行一輪。條件最多可有 4,000 個字元，而且每個工作階段只能設定一個目標。
Anthropic 官方文件中的最精簡範例：
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"
這個指令會在背景啟動代理程式，並設定一個目標。Claude 會找出 PR、對照 CHANGELOG.md 檢查，補上遺漏的項目，並在條件達成時停止。
在互動模式中，只要輸入/goal，後面接著條件即可：
/goal all pytest tests pass and mypy strict reports zero errors
Claude 接下來會這麼做：
- 每一輪結束後，系統會將目前條件和對話紀錄交給另一個快速模型（預設為 Haiku）
- 這個模型會回答「是」或「否」，並簡短說明理由
- 如果答案是「否」，Claude 會自動再執行一輪，不會交還控制權
- 如果答案是「是」，目標就會清除，控制權也會交還給你
每一輪結束後，小型快速模型會檢查條件是否達成。如果尚未達成，Claude 就會在不交還控制權的情況下開始下一輪。
有些嚴格限制，直到你碰上時才會知道：
/goal只能在已接受信任對話框的工作目錄中使用。如果你在新電腦上使用，而 Claude 尚未記住該目錄，指令就會失敗- 在設定了
disableAllHooks或allowManagedHooksOnly的企業環境中，無法使用此指令 - 條件最多可有 4,000 個字元
- 每個工作階段只能有一個啟用中的目標。新的
/goal會重設舊目標 - 使用
--resume時，條件會保留，但回合、時間和 token 計數器會重設
控制指令：
- 不加參數的
/goal——顯示目前狀態 /goal clear（或stop、off、reset、none、cancel）——清除目標
Anthropic 表示，評估器的成本「通常相較於主要回合的成本可忽略不計」。Haiku 會評估條件和對話文字，不會呼叫工具，因此檢查成本很低；昂貴的是主要模型執行的回合。
如何在 Codex CLI 中設定/goal？
重點整理
Codex CLI 0.128.0 於 2026 年 4 月 30 日以實驗性功能加入/goal。5 月 21 日，該模式在版本 26.519／npm 0.133.0 中轉為穩定版。它透過兩個提示範本運作：continuation.md（「繼續」）和budget_limit.md（「停止」）。目標會綁定至對話串，並在重新啟動後保留。
指令與 Claude 的用法相同：
codex
> /goal all vitest tests pass and there are no eslint errors
Codex 提供更多目標控制指令：
| 指令 | 功能 |
|---|---|
/goal condition | 設定目標 |
/goal | 檢視狀態 |
/goal pause | 暫停 |
/goal resume | 恢復 |
/goal edit | 修改條件（GA 版） |
/goal clear | 清除目標 |
與 Claude 的主要差異在於，Codex 會自行檢查是否「完成」，而不是交由另一個模型判斷。每一輪結束後，Codex 會自動將openai/codex儲存庫中的continuation.md範本插入上下文。直譯如下：
「繼續朝著目前對話串的目標工作。不要重複已完成的工作。選擇一項能推進目標的下一個具體行動。只有在稽核確認目標確實達成，而且沒有必要工作尚未完成時，才標記目標已達成。」
當 token 接近上限時，系統會插入第二個範本budget_limit.md：
「目標已達 token 上限。不要開始大量的新工作。請盡快結束本輪：整理有用的進度、指出剩餘工作和阻礙，並清楚告知使用者下一步。」
邏輯相同：「不要謊稱自己做過什麼。」只有目標確實尚未達成時才繼續。budget_limit要求停止，但要如實說明尚未完成的部分。
和 Claude 不同，Codex 會將目標綁定到對話串，而不是工作階段。舉例來說，你可以在晚上關閉終端機，早上重新開啟，輸入 /goal resume，接續相同目標，並保留記憶中的相同事實。若想按照自己的時間安排分段執行，這項功能很有用。
Claude Code 的/goal和 Codex 的/goal有何不同？
重點整理
Claude 將撰寫者和判斷者分開：主要模型撰寫程式碼，另一個小型模型負責判斷。Codex 則由同一個代理程式檢查自己的工作，提醒自己「不要謊稱自己做過什麼」。兩者架構不同，但陷入迴圈的風險相同。
這是比較時最常被忽略的差異，我們來仔細看看。
| 面向 | Claude Code /goal | Codex /goal |
|---|---|---|
| 發布版本 | v2.1.139，2026 年 5 月 11 日 | v0.128.0，2026 年 4 月 30 日（實驗版）→ v0.133.0／26.519，2026 年 5 月 21 日（穩定版） |
| 目標範圍 | 工作階段 | 對話串（重新啟動後仍保留） |
| 控制功能 | set、clear（及其別名） | set、view、pause、resume、edit、clear |
| 由誰檢查是否「完成」 | 另一個模型（預設為 Haiku） | 同一個代理程式透過插入的提示自行檢查 |
| 評估器存取檔案的權限 | 否，只根據對話文字判斷 | 是，可以檢查檔案、測試和日誌 |
| 預算 | 在條件文字中寫明「或執行 20 輪後停止」 | 內建 token 上限，達到上限時自動插入budget_limit.md |
| 硬性支出上限 | 無；只有訂閱方案限制 | 無；只有訂閱方案限制 |
| 條件長度 | 最多 4,000 個字元 | 未指定 |
| 可用環境 | 互動模式、-p、桌面應用程式、Remote Control | 應用程式、IDE 擴充功能、CLI、ACP 用戶端 |
兩者在概念上的差異是：Claude 將迴圈視為品質合約（由外部評估器判斷），而 Codex 將它視為執行機制（由代理程式自我管理）。
實際上，如果你希望由公正的角度判斷「完成」條件，就選 Claude。如果你希望代理程式在評估時能檢查檔案和日誌，就選 Codex。
如需進一步了解這些工具，請閱讀Codex 與 Claude Code 比較指南。
實例：花 31 小時將 Pydantic v1 遷移至 v2
重點整理
Codex /goal在 4 個工作階段、共 31 小時的實際時間內，完成了將某項內部服務的 14,000 行程式碼從 Pydantic v1 遷移至 v2。使用 gpt-5.3-codex 的費用約為 44 美元。
任務設定如下：「從 Pydantic v1 遷移至 v2，所有 pytest 測試都必須通過，而且 mypy strict 回報的錯誤數必須為零。」
實際經過如下：
- 工作階段 1（8 小時）— Codex 分析匯入項目、改寫
BaseModel宣告，並設定 mypy - 工作階段 2（10 小時）— 改寫驗證器，導致約 200 個測試失敗
- 工作階段 3（7 小時）— 修正測試並找出循環相依性
- 工作階段 4（6 小時）— 解決剩下的 mypy 錯誤和回歸問題
Token 費用：
「總實際時間：約 31 小時，分成四個工作階段。依 gpt-5.3-codex 的費率計算，Codex token 總費用約為 $44。」
費用主要來自 gpt-5.3-codex 的輸出 token，每百萬個收費 $14。也就是說，讓它自主工作 31 小時，費用約等於數週的 ChatGPT Plus 訂閱費。
代理程式沒有自行完成的工作：
- 它沒有替團隊撰寫遷移文件（Codex 不知道這也屬於「遷移」的一部分）
- 它沒有更新用於以新版 Pydantic 發布內容的設定檔
- 它漏掉一項生產環境回歸問題，直到隔天才被發現
換句話說，/goal完成了 95% 的工作，剩下的 5% 仍得手動完成。這是目前世代的正常情況，並不構成不用它的理由。
一般原則是：
一夜之間讓 macOS 驅動程式運作 14 小時
重點整理
驅動程式這類任務不適合互動式工作，卻非常適合長時間執行的迴圈。
這種方法最能發揮效果的任務類型：
- 低階工作，其中一次迭代和檢查要花數分鐘（編譯、執行測試）
- 有明確正式標準的遷移（型別、測試、lint）
- 有可衡量結果的基準測試和最佳化
- 結構清晰的文件和變更日誌
Claude /goal同樣能勝任，但驅動程式工作較常選用 Codex，因為它能自行檢查檔案和日誌，不必依賴外部判斷者。
費用是多少？如何避免一夜之間耗盡 token？
重點整理
/goal沒有硬性支出上限，只有方案本身的限制。使用 gpt-5.3-codex 執行 Codex 一小時，實際費用約為 $1.50～$3。Claude 的執行成本較高，評估成本較低。唯一的防護方式是在條件中直接寫上「或執行 N 輪後停止」。
公開案例的數據：
| 執行案例 | 時長 | Token | 費用 |
|---|---|---|---|
| OpenAI 設計工具示範 | 25 小時 | 1,300 萬 | （內部執行） |
| Pydantic v1→v2 | 31 小時，4 個工作階段 | 約 310 萬個輸出 token | 約 $44 |
| 語音訪談系統 | 總計 6 小時 44 分鐘（運算時間 41 分鐘） | 輸入 680 萬，94% 已快取 | - |
| 字型煙霧測試 | 5 分鐘 | 188,832 | 不到每週配額的 5% |
首先要了解的是，Claude Code 和 Codex 都沒有「支出達到 $N 就停止」的硬性上限。共有三種防護方式：
- 訂閱方案限制——Pro、Max 或 Enterprise。使用 Anthropic 的 Max 方案（每月 $100），執行 14 小時的夜間任務仍能符合每週配額，且有餘裕
- 在條件文字中設限——在
/goal中直接寫上「或執行 20 輪後停止」。Claude 的判斷者會讀取這項條件並結束目標 - Codex 的 token 上限——內建機制，token 用完時會插入
budget_limit.md
一夜之間讓帳單增加的因素：
- 「讓它更方便」這類模糊條件——評估器不知道「更好」代表什麼，因此代理程式永遠不會停止
- 未使用 stub 的外部 API 存取——每次重試都會消耗 token
- 冗長的上下文——超過 670 萬個 token 後，就會開始壓縮上下文，並遺失部分記憶
如需進一步了解如何節省成本，請參閱指南Claude Code 的 token 都花在哪裡和如何避免耗盡使用上限。
5 種不應執行/goal的情況
重點整理
條件模糊，例如「讓它看起來漂亮」、只需一行的編輯、含有使用者資料的生產環境資料庫、攸關安全性的變更，以及外部相依項目不明確的任務。在這 5 種情況下，代理程式不是陷入迴圈，就是白白耗掉 token。
OpenAI 的文件明確指出不該怎麼做：
- 一行的編輯——為了重新命名變數而執行
/goal，成本比手動修改還高 - 模糊的目標——「改善效能」、「讓程式碼更整潔」、「讓它更方便」等。評估器沒有判斷標準，代理程式就會不停打轉
- 含有使用者資料的生產環境資料庫——代理程式可能會弄壞遷移，而從備份復原的成本高於節省的費用
- 安全性變更——驗證、加密、付款處理。這類變更的每個提交都需要人工檢查
- 未使用 stub 的外部 API——每次網路故障都會消耗 token，而且超出你的控制範圍
安全性流程需要人工核准，而不明確的外部相依項目可能會讓執行中途失敗。
代理程式卡住時該怎麼辦？
重點整理
代理程式連續 3～4 輪都編輯同一處，之後又還原，就是陷入迴圈的跡象。按 Ctrl+C 中斷，檢查日誌，接著收緊條件，或將任務縮小為單一部分。在 Claude 中，/goal clear會派上用場；在 Codex 中，使用/goal pause並編輯條件。
快速辨識迴圈的方法：
- 代理程式連續 3 輪以上修改相同檔案，最後又把檔案還原成原本狀態
- 日誌中重複出現它已經處理過的錯誤
- 你認為條件已經達成，但代理程式仍表示「尚未達成」
- 每一輪使用的 token 越來越多，程式碼卻沒有進展
接下來該做什麼：
- Claude Code：執行
/goal clear，然後讓條件更明確 - Codex：執行
/goal pause，檢查目前對話串，以/goal edit修改條件，再執行/goal resume - 兩者皆適用：確認條件確實可驗證（例如指令回傳 exit 0，或產生特定輸出）
迴圈的成因通常是任務本身，而非代理程式。設定「所有測試都通過」這項條件，代表假設測試本來就能通過。如果程式碼存在深層的架構問題，代理程式就會一直繞著症狀打轉。
「完成」條件：用/goal嚴謹管理任務
重點整理
好的條件應該是一個回傳 exit 0 的指令，或是能產生特定輸出的指令。「所有測試都通過」可行，「程式碼更整潔」則不行。最好將正式檢查與可衡量指標結合，例如測試加上最低覆蓋率。
OpenAI 在官方 Codex Cookbook 中明確說明這項規則：
不能只因為模型認為目標已完成，就認定目標完成。只有在對照檔案、測試、日誌、基準測試或其他具體產出檢查結果後，才能算完成目標。
實際可行的條件範本：
| 條件類型 | 表述方式 |
|---|---|
| 測試 | 「pytest tests/ 回傳 exit 0，且覆蓋率至少為 80%」 |
| 型別 | 「mypy strict 對 src/ 回報 0 個錯誤」 |
| Lint | 「eslint . 在所有變更檔案上回傳 exit 0」 |
| 建置 | 「npm run build 成功完成，且沒有 TypeScript 錯誤」 |
| 基準測試 | 「k6 run perf test 顯示 p95 低於 200 ms」 |
| 差異 | 「git diff 顯示只有檔案 X、Y、Z 有變更」 |
| 組合 | 「pytest 通過，且 mypy strict 回報 0 個錯誤，且 ruff check 通過」 |
Combo 列結合了測試、mypy 和 lint。只要其中一項檢查仍未通過，目標就不會結束。評估器沒有蒙混過關的機會。
反面範例：
- 「程式碼變得更好」
- 「易用性提升」
- 「效能提升」
- 「文件完整了」
「可運作」和「不可運作」的差異在於是否可驗證。如果無法用指令檢查某項條件，就根本無從檢查。這也呼應 OpenAI 所說的「長期一致性」：代理程式可以長時間思考，卻無法自行判斷怎樣才算「夠好」。
你可以在真實專案中測試「一個提示、一個結果」這個想法：設定/goal、制定條件、執行，然後分析出了什麼問題。
來源
認識一下 Ailoot。
更多詳情
常見問題：2026 年如何透過 /goal 讓 Claude Code 和 Codex 執行一整晚：14 小時自主模式
什麼樣的 /goal 完成條件有用？
使用可檢查成果，明確列出測試、型別檢查、建置或基準及預期結果，組合全部必要檢查並限制可動檔案。「做得更好」沒有可量測停止點。
代理重複同樣的失敗修改時，該做什麼？
中斷並檢查日誌。若一直碰同些檔案又還原，請縮小任務或具體化條件；繼續前確認必要檢查確實有可能通過。