Codex /goal vs Claude Code /goal：讓長任務自動跑到完成

/goal 正在變成 AI 編程工具裡的一個重要命令。

它解決的不是「讓模型多寫幾行程式碼」，而是另一個更實際的問題：當任務有明確完成條件時，能不能讓 Agent 持續推進，直到條件滿足，而不是每完成一輪就停下來等使用者繼續催。

Codex CLI 已經在官方文件裡加入了實驗性的 /goal。Claude Code 也上線了自己的 /goal 文件，而且把它描述成一種可以跨多輪持續工作的自動化能力。兩者名字一樣，但產品取向並不完全一樣。

`/goal` 到底解決什麼問題

普通 AI 編程對話通常是「一問一答」：

使用者提出任務。
Agent 分析、改程式碼、跑測試。
Agent 回報結果。
使用者再決定下一步。

這個流程適合短任務，但遇到遷移、重構、測試修復、issue backlog 清理時，就會變得很碎。Agent 可能每次只推進一小段，然後停下來等你輸入「繼續」。

/goal 的思路是把任務從「下一步做什麼」改成「最終什麼狀態算完成」。例如：

1

/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错

這類目標天然適合長任務，因為它有清楚的終點：測試通過、建置成功、檔案拆分完成、佇列清空、驗收條件滿足。

Codex 的 `/goal`：實驗功能，綁定目前執行緒

OpenAI 的 Codex CLI 文件把 /goal 標為實驗功能。它不是預設穩定能力，需要先開啟 features.goals。

開啟方式有兩種：

1

/experimental

或者在 config.toml 裡加入：

1
2


[features]
goals = true

啟用後，可以這樣使用：

1

/goal Finish the migration and keep tests green

常用命令包括：

1
2
3
4


/goal
/goal pause
/goal resume
/goal clear

按照 OpenAI 文件的說法，Codex 會把 goal 附著在目前 active thread 上，在更大的任務執行過程中持續追蹤這個目標。

這裡要注意一個細節：官方文件對 Codex /goal 的措辭比較克制。它強調「給長任務設定實驗性目標」「把目標附著到目前執行緒」，但沒有像 Claude Code 文件那樣展開說明每一輪結束後由獨立 evaluator 自動判斷並繼續下一輪。所以現在使用 Codex /goal 時，最好仍把它看作實驗中的長任務目標機制，而不是完全穩定的無人值守執行模式。

Claude Code 的 `/goal`：完成條件驅動的多輪執行

Claude Code 的 /goal 文件寫得更明確：使用者設定 completion condition 後，Claude 會跨 turn 持續工作，直到條件滿足。

示例：

1

/goal all tests in test/auth pass and the lint step is clean

Claude Code 的機制大致是：

目前 turn 完成後，不直接把控制權還給使用者。
一個小型快速模型會檢查目標條件是否已經滿足。
如果沒有滿足，Claude 自動開始下一輪。
如果滿足，goal 自動清除，並在 transcript 裡記錄完成狀態。

這意味著 Claude Code 的 /goal 更像「按完成條件自動續跑」。它不只是把目標掛在會話裡，而是把「是否繼續下一輪」交給一個獨立評估步驟。

Claude Code 還支援直接查看狀態：

1

/goal

狀態裡會顯示目標條件、執行時間、已評估 turn 數、token 消耗，以及 evaluator 最近一次給出的原因。

如果要提前停止，可以使用：

1

/goal clear

stop、off、reset、none、cancel 也可以作為清除別名。開啟目標後，如果會話中斷，之後透過 --resume 或 --continue 恢復時，仍然 active 的 goal 可以被帶回來；但計時、turn 數和 token 基線會重新計算。

兩者最大的差異

Codex 和 Claude Code 都在把 AI 編程從「單輪回答」推向「長任務執行」，但 /goal 的定位有差異。

對比項	Codex CLI `/goal`	Claude Code `/goal`
狀態	experimental	官方文件單獨成頁說明
啟用方式	需要開啟 `features.goals`	可直接在受信任 workspace 使用
目標作用域	目前 active thread	目前 session
常用操作	set / view / pause / resume / clear	set / view / clear
自動判斷	文件強調目標附著與追蹤	明確說明每輪後由 evaluator 判斷
自動續跑	文件表述較克制	條件未滿足時自動下一輪
適合場景	想在 Codex 長任務裡保持目標上下文	想按完成條件讓 Claude Code 持續推進

簡單說，Codex 的 /goal 更像「給目前執行緒掛一個實驗性的長期目標」；Claude Code 的 /goal 更像「給目前會話設定一個可驗證的停止條件，讓它自動做到滿足為止」。

寫好 `/goal` 的關鍵

不管使用哪一個工具，/goal 都不適合寫成模糊願望。

不太好的寫法：

1

/goal 把项目优化一下

更好的寫法：

1

/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件

一個好目標通常包含三點：

明確的完成狀態。
可執行的驗證方式。
必須遵守的邊界。

如果目標太大，還應該加上停止條件：

1

/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题

這很重要。/goal 越強，越需要邊界。否則 Agent 可能會為了追求「完成」而改動過多檔案、跑太久、消耗太多 token，甚至把原本該停下來詢問的問題繼續往前推。

什麼時候適合用 `/goal`

適合：

測試修復：直到指定測試通過。
程式碼遷移：直到所有呼叫點改完並編譯成功。
批量清理：直到某類 lint 或型別錯誤清零。
文件補齊：直到所有指定模組都有說明。
issue 佇列處理：直到某個標籤下的問題都被處理或明確分類。

不適合：

需求本身還沒想清楚。
需要頻繁產品判斷。
涉及高風險刪除、資料遷移或權限變更。
驗收條件只能靠主觀判斷。
任務會跨越大量無關模組。

一個實用原則是：如果你能寫出「跑哪個命令、看到什麼結果、哪些檔案不能碰」，就適合用 /goal。如果只能寫「幫我做得更好」，那還是先用普通對話、計畫模式或人工評審更穩。

對 AI 編程工具的影響

/goal 代表一個很明顯的方向：AI 編程工具正在從「互動式助手」變成「可持續執行的工作單元」。

過去我們讓 Agent 做任務，經常要在旁邊守著。它卡住了要提示，測完了要繼續，報錯了要再下命令。/goal 把這部分互動壓縮成一個完成條件，讓 Agent 自己決定下一輪該做什麼。

但這也帶來新的要求。以後寫 prompt 不只是描述任務，還要寫驗收條件、驗證命令、修改邊界和停止規則。換句話說，使用者的工作從「催它繼續」變成「定義什麼叫完成」。

Codex 和 Claude Code 走到 /goal 這一步，說明長任務 Agent 已經不再只是背景任務或雲端佇列的專利。終端裡的本地編程工具，也開始需要更強的自主推進能力。

總結

Codex CLI 和 Claude Code 都有了 /goal，但現階段不要把它們簡單看成同一個功能。

Codex 的 /goal 仍是實驗能力，需要開啟 features.goals，更適合在 Codex 目前執行緒裡維持長期目標。Claude Code 的 /goal 則更明確地把「完成條件」和「自動續跑」連在一起，透過獨立 evaluator 判斷是否繼續。

對日常開發來說，這類命令最適合處理有明確驗收標準的工程任務。它不會替代需求判斷，也不會消除程式碼審查，但能減少長任務裡大量重複的「繼續」「再跑一次」「修到測試通過」。

真正要學會的不是某個命令本身，而是如何把任務寫成清楚、可驗證、可停止的目標。

參考資料

OpenAI Codex CLI Slash Commands：https://developers.openai.com/codex/cli/slash-commands
Claude Code Goal 文件：https://code.claude.com/docs/en/goal

/goal 到底解決什麼問題

Codex 的 /goal：實驗功能，綁定目前執行緒

Claude Code 的 /goal：完成條件驅動的多輪執行