AI 說"我做完了"到底能不能信？Codex 這次給出了答案
整理版優先睇
AI 話「做完」唔等於真係做完——Codex /goal 教你要識定驗收標準
呢篇文章主要講 OpenAI 嘅 Codex CLI 最新加入嘅 /goal 命令，係一個用嚟解決 AI 做完嘢但亂交差嘅新機制。作者指出 AI 成日自己覺得「搞掂咗」就停手，但其實未達標，而 /goal 嘅目標就係要逼 AI 按預設驗收條件自我審計，直到所有條件滿足先當完成。
文章背景係源自 OpenAI 官方同 Felipe Coury 嘅帖文，作者以編輯角度整理咗 /goal 嘅用法、設定方法、控制指令，同埋點樣寫一個好嘅目標。佢特別強調，寫目標唔可以鬆散，例如「提升性能」呢類模糊字眼只會令 AI 偷懶改一行就收工；一定要具體到「修復邊個檔案、加測試、通過邊個 spec、總結改咗啲乜」。
整體結論係：/goal 唔係魔法，而係一種協作模式轉換——由「你睇實 AI 一步步做」變成「你先定義完成條件，再放 AI 自己追」。呢個概念呼應 Karpathy 講過嘅「傳統自動化處理你能描述清楚嘅事，AI 自動化處理你能驗證清楚嘅事」。用 /goal 之前，最緊要係搞清「做到咩先算完成」。
- /goal 係一個自動循環機制：你畀目標，Codex 自己寫 Code、跑測試、睇結果，未過線就繼續做。
- 設定好目標嘅關鍵係具體驗收條件，例如「修復 race condition、加測試、通過 pnpm test、總結驗證方式」，唔好寫「提升性能」呢類模糊願望。
- /side 命令可以開臨時分支問問題，唔會污染主線任務，好適合主任務進行中想查嘢嘅情況。
- 系統有三道閘防 AI 亂循環：卡住就停、預算限額同完成審計（強制模型逐項對照證據先可標記完成）。
- 用 /goal 之前要轉換心態：唔好再諗 prompt 點寫，而係諗清楚「做到咩先算完成」，先係真正用得掂呢個工具嘅關鍵。
Codex CLI 倉庫
OpenAI Codex CLI GitHub 倉庫，包含 /goal 功能原始碼及文檔
Felipe Coury 原帖
Felipe Coury 喺 X 上面分享 /goal 用法嘅原始帖文
內容片段
/goal 修復 auth/session.ts 裏 session refresh 的 race condition完成標準:
1. 找到並修復根因2. 加併發刷新測試3. 跑 pnpm test auth/session-refresh.spec.ts 通過4. 總結改了哪些文件、用什麼命令驗證、還有哪些風險四條全滿足才能標記完成。/goal 係點樣運作嘅？
/goal 係 Codex CLI 最新嘅實驗功能，用嚟解決 AI 話做完但未達標嘅問題。開啓方法好簡單：先確認 version ≥ 0.128.0，然後喺 ~/.codex/config.toml 加 [features] goals = true，或者直接打 codex features enable goals，重啟 CLI 就用得。
基本用法係喺 Codex CLI 輸入 /goal 後加一句目標，例如「修復登錄跳轉 bug，加一個迴歸測試」，Codex 就會自動開工，一輪唔夠自動下一輪。
控制命令有 /goal pause（暫停）、/goal resume（繼續）、/goal clear（清掉），按 Ctrl+C 都係暫停，下次返嚟可以繼續。如果目標好長，可以將詳細指令寫入 .md 檔案，再用 /goal follow task.md，好處係上下文壓縮時細節唔易走失。
點樣寫一個唔會出事嘅目標？
所以要將目標拆做多條驗收項，每一項都要可以核對。唔好將願望直接當目標，例如「提升性能」應該改成「將 API 回應時間由 200ms 降到 50ms，並通過壓力測試」。咁樣模型先知道咩叫「做完」。
- 1 目標要具體，例如指定檔案、功能、指標。
- 2 驗收標準要可核對，最好一條條寫清楚。
- 3 避免模糊詞，例如「優化」「改進」「提升」。
- 4 開工前先諗清楚「做到咩算完成」。
除咗 /goal 仲有咩配套？
今次仲加咗 /side 命令，用途係開臨時分支問問題，唔會污染主線任務。
例如 /goal 正在跑，你想問某個 API 參數點寫，直接打字會搞亂主線。用 /side 開個臨時對話，問完按 Esc 返主線，分支直接扔掉。呢個設計同 Claude Code 嘅 /btw 一樣，好順手。
不過要注意 /goal 同 Plan mode 互斥，唔可以同時用。另外 API quota 報錯有機會引致死循環，遇到就要 Ctrl+C 停手。
系統點樣防止 AI 呃人話做完？
Codex 設計咗三道閘嚟確保唔會亂循環：第一係卡住就停——如果某一輪冇調任何工具（冇寫 Code、冇跑命令、冇讀文件），系統就停，等用戶新輸入先再跑。第二係預算兜底——每個目標可以設 token 預算同時間上限，燒超咗會塞提示叫模型總結進度畀下一步建議。
仲有一個細節：模型只可以標記完成，唔可以自己暫停或恢復，只有用戶得。呢個設計防止模型覺得「差不多了」就提早收工。目標掛上去後得兩種結束方式：真係做完，或者你手動停。
用 /goal 之前要諗清楚嘅心態轉變
呢件事值得講，唔係因為 /goal 有幾複雜，而係佢改變咗你同 AI 嘅協作方式。以前係你睇實 AI 一步步做，家陣係你先講清楚終點同驗收條件，然後放 AI 自己跑。
Karpathy 講過一句話：傳統自動化處理你能描述清楚嘅事，AI 自動化處理你能驗證清楚嘅事。/goal 正正係行緊呢條路。
所以用之前，唔好急住諗 prompt 點寫，先諗清楚「做到咩算完成」。目標定得靚，AI 先唔會偷懶。
AI話自己做曬，到底信唔信得過？
OpenAI俾Codex CLI加咗個新指令叫 /goal，專治呢個問題。
你可以當佢係一個會自動追結果嘅循環：你俾個目標，佢就去寫code、run測試、睇結果，唔夠就不停補，直到過關。
而家仲係實驗階段，要手動開。
怎麼開
兩步。
先確認版本 ≥ 0.128.0：
codex --version
然後在 ~/.codex/config.toml 里加:
[features]
goals = true
或者一行指令：
codex features enable goals
重啟CLI，開咗就得。
基本用法
入Codex CLI直接打：
/goal 修復登錄跳轉 bug,加一個迴歸測試
Codex就會開始做。一輪唔夠就自動開下一輪。
控制指令都好簡單：
/goal pause:暫停/goal resume:繼續/goal clear:清掉
按Ctrl+C都係暫停。下次返返呢個對話，佢會喺上次嘅位繼續做。
如果目標好長，寫喺命令行太亂。將詳細指示掉入一個 .md 文件入面，然後：
/goal follow task.md
呢招仲有個好處：壓縮上下文嘅時候，細節冇咁易走甩。
呢度有個大陷阱
/goal 唔係魔法。完成與否，最終都係由模型自己判斷。
目標越模糊，模型越容易偷懶——改一行code就覺得「嗯，做曬」。
舉個反面例子：
/goal 提升項目性能
送命題。「提升性能」係咩意思？降一毫秒算唔算？模型唔知「完成」係點樣，求其改改就交貨。
正面例子係咁：
/goal 修復 auth/session.ts 裏 session refresh 的 race condition
完成標準:
1. 找到並修復根因
2. 加併發刷新測試
3. 跑 pnpm test auth/session-refresh.spec.ts 通過
4. 總結改了哪些文件、用什麼命令驗證、還有哪些風險
四條全滿足才能標記完成。
講到底，目標要具體，驗收要寫清楚，最好逐條可以對照。唔好將願望直接當目標。
順便一提：/side
呢版仲加咗 /side。
用途係咁：/goal 喺跑緊嘅時候，用戶突然想問個無關嘅問題，例如某個API參數點寫。直接打字會污染主線。
/side 就係開個臨時分支傾偈，問完按Esc返主線，分支對話直接掉咗佢。
同Claude Code嘅 /btw 係同一樣嘢。
主要任務喺度跑，臨時疑問用 /side 掉入去，幾順手。
佢會唔會不停循環？
Codex做咗幾重防線。
第一重：卡住就停。
如果某一輪冇用任何工具——冇寫code、冇run指令、冇讀文件——系統會當佢卡住咗，循環就會停。要等用戶俾新輸入先會再run。
第二重：預算兜底。
每個目標可以set token預算同時間上限。用超咗，系統會塞一條提示入去，叫模型唔好開新任務，將進度總結一下，俾用戶下一步建議。
第三重：完成審計。呢個最關鍵。
/goal 唔係模型話「做曬」就完。
每輪繼續之前，系統會偷偷塞一條developer指令，要求模型做一次完成審計：
將目標拆做驗收項 每一項對應返實際證據 對照實際嘅code文件、測試輸出、指令結果 全部滿足先可以呼叫 update_goal({"status":"complete"})
呢一步主要防佢自我感覺良好：產出咗嘢，但唔等於目標真係完成咗。
測試run過 ≠ 功能做完。code寫咗 ≠ 需求滿足。
咁樣佢就冇得靠一句「差唔多」呃過去。
仲有一個細節：模型只可以標記「完成」，唔可以自己暫停或恢復。
得用戶先可以暫停同恢復。
咁樣設計，係因為模型好容易自己判定「差唔多」，然後提早收工。
目標掛上去之後，只有兩種結束方式：佢真係做完，或者你手動停咗佢。
而家仲有啲粗糙
實驗階段，幾個陷阱：
得CLI，桌面app仲未有 API quota報錯可能會入死循環——不停請求不停撞額度，遇到呢啲情況就用Ctrl+C kill咗佢 Plan mode同 /goal互斥，唔可以同時用早完成問題：模型有時開一個file就覺得搞掂，明明只係改咗表面。所以驗收標準寫得越仔細，越唔容易出事
呢件事值得講，唔係因為 /goal 有幾複雜。正正相反，佢嘅思路唔花巧。
真正重要嘅係，佢將你同AI嘅合作方式調轉咗。以前似係你睇住佢一步步做；而家似係你先講清楚終點同驗收條件，跟住俾佢自己搞。
Karpathy講過一句話，大意係：傳統自動化處理嘅係你能夠描述清楚嘅事，AI自動化處理嘅係你能夠驗證清楚嘅事。/goal 就係向呢條路行。
所以用之前，唔好急住諗提示詞點寫，先將「做到咩算完成」寫清楚。
連結
Codex CLI倉庫：https://github.com/openai/codex Felipe Coury原帖：https://x.com/fcoury/status/2049917871799636201
AI 說自己做完了,到底能不能信?
OpenAI 給 Codex CLI 加了個新命令叫 /goal,專門治這個病。
你可以把它理解成一個會自己追結果的循環：你給目標，它去寫代碼、跑測試、看結果，不夠就繼續補，直到過線。
現在還在實驗階段,得手動打開。
怎麼開
兩步。
先確認版本 ≥ 0.128.0:
codex --version
然後在 ~/.codex/config.toml 里加:
[features]
goals = true
或者一行命令:
codex features enable goals
重啓 CLI,開完了。
基本用法
進 Codex CLI 直接輸:
/goal 修復登錄跳轉 bug,加一個迴歸測試
Codex 就開始幹了。一輪不夠就自動開下一輪。
控制命令也簡單:
/goal pause:暫停/goal resume:繼續/goal clear:清掉
按 Ctrl+C 也是暫停。下次回到這個對話,它接着上次的地方繼續幹。
目標如果很長,寫命令行裏太亂。把詳細指令丟到一個 .md 文件裏,然後:
/goal follow task.md
這招還有個好處:上下文壓縮的時候,細節不容易丟。
這裏有個大坑
/goal 不是魔法。完成與否,最終還是模型自己判斷。
目標越模糊,模型越容易偷懶——改一行代碼就覺得"嗯,做完了"。
舉個反面教材:
/goal 提升項目性能
送命題。"提升性能"是啥意思?降一毫秒算嗎?模型不知道"完成"長啥樣,隨便改改就交差。
正面教材長這樣:
/goal 修復 auth/session.ts 裏 session refresh 的 race condition
完成標準:
1. 找到並修復根因
2. 加併發刷新測試
3. 跑 pnpm test auth/session-refresh.spec.ts 通過
4. 總結改了哪些文件、用什麼命令驗證、還有哪些風險
四條全滿足才能標記完成。
說白了，目標要具體，驗收要寫清，最好一條條都能核對。別把願望直接當目標。
順帶一提:/side
這版還加了 /side。
用途是這樣:/goal 在跑,用戶突然想問個不相關的問題,比如某個 API 參數怎麼寫。直接打字會污染主線。
/side 就是開個臨時分支聊天,問完按 Esc 回主線,分支對話直接扔掉。
跟 Claude Code 的 /btw 是一回事。
主任務在跑,臨時疑問用 /side 扔進去,挺順手。
它會不會一直循環?
Codex 做了幾道閘。
第一道:卡住就停。
如果某一輪沒調任何工具——沒寫代碼、沒跑命令、沒讀文件——系統認為它卡住了,循環就停。要等用戶給新輸入才會再跑。
第二道:預算兜底。
每個目標可以設 token 預算和時間上限。燒超了,系統會塞一條提示進去,告訴模型別開新任務,把進度總結一下,給用戶下一步建議。
第三道:完成審計。這個最關鍵。
/goal 不是模型說"做完了"就結束。
每輪繼續之前,系統會偷偷塞一條 developer 指令,要求模型做一次完成審計:
把目標拆成驗收項 每一項映射到真實證據 對照實際的代碼文件、測試輸出、命令結果 全部滿足才能調 update_goal({"status":"complete"})
這一步主要防的是它自我感覺太好：東西是產出了，但不等於目標真的完成了。
測試跑過 ≠ 功能做完。代碼寫了 ≠ 需求滿足。
這樣它就沒法靠一句“差不多了”糊弄過去。
還有一個細節:模型只能標記"完成",不能自己暫停或恢復。
只有用戶能暫停和恢復。
這麼設計，是因為模型很容易自己判定“差不多了”，然後提前收工。
目標掛上去以後，只有兩種結束方式：它真的做完，或者你手動停掉。
現在還有點糙
實驗階段,幾個坑:
只有 CLI,桌面 app 還沒有 API quota 報錯可能進死循環——一直請求一直撞額度,遇到這種 Ctrl+C 幹掉 Plan mode 和 /goal互斥,不能同時用早完成問題:模型有時候建一個文件就覺得搞定了,明明只動了表層。所以驗收標準寫得越細,越不容易翻車
這事值得說，不是因為 /goal 有多複雜。恰恰相反，它的思路並不花哨。
真正重要的是，它把你和 AI 的配合方式換了一下。以前更像你盯着它一步步做；現在更像你先把終點和驗收條件說清楚，剩下的讓它自己跑。
Karpathy 講過一句話，大意是：傳統自動化處理的是你能描述清楚的事，AI 自動化處理的是你能驗證清楚的事。/goal 就是在往這條路上走。
所以用它之前，先別急着想提示詞怎麼寫，先把“做到什麼算完成”寫明白。
連結
Codex CLI 倉庫:https://github.com/openai/codex Felipe Coury 原帖:https://x.com/fcoury/status/2049917871799636201