設個目標讓 AI 自己跑一夜，Codex 和 Claude Code 的 /goal 到底怎麼用
整理版優先睇
用 /goal 畀 AI 自己跑一夜：Codex 同 Claude Code 點樣實現，點樣先用得靚
呢篇文章係講 AI 編程工具嘅 /goal 命令，作者係一個技術寫手，想解答嘅問題係：點樣用一條命令就令 AI 自己不斷重複做嘢直到完成目標，而唔使下下等用人手確認。文章比較咗 Codex 同 Claude Code 兩間公司嘅實現方案，指出雖然功能名一樣，但底層邏輯同實際表現有好大分別。整體結論係：/goal 令 AI 編程從「你講一步佢做一步」進化到「你講個目標就離手」，但要寫得靚嘅終止條件、識得揀啱時機用，否則好易燒好多 token 又做唔到嘢。
Codex 嘅做法係畀模型自己判斷任務完唔完成，透過一個 update_goal(complete) 工具，配合空轉檢測同原生 token 預算控制，唔畀模型自己暫停。Claude Code 就請咗個獨立裁判——每輪完結後用 Haiku 評估條件係咪達到，好處係幹活同判別分開，減少自己呃自己，但缺點係模型成日彈問題問你，令你走唔開。Ralph Loop 呢個 bash while-true 循環係靈感來源，而家已經俾 Anthropic 收編做官方 plugin。
實際使用上，寫條件要有可測量嘅終態、驗證方式同約束，例如「npm test exits 0」。用之前最好手動跑一轉確認可行，配合 auto mode 避免卡喺工具調用，同埋拆成多個細 goal 會更穩定。跑長時間任務消耗唔細，要設預算上限。Codex 適合 6 小時以上埋頭苦幹型任務，Claude Code…
- /goal 令 AI 編程從逐輪確認變為目標驅動，省卻中間反覆指示，但要寫好終止條件先得。
- Codex 靠模型自己調用 update_goal(complete) 判斷完成，加上空轉檢測同 token 預算，表現係埋頭苦幹唔問人。
- Claude Code 用獨立小模型 Haiku 做裁判，每輪評估條件，但模型成日彈問題打斷自動流程，並有上下文壓縮後遺忘問題。
- 寫條件要包括可測量終態、驗證方式同約束，例如「npm test exits 0」；避免「make the code better」呢類模糊目標。
- 實際操作建議：先手動跑通，開 auto mode，一個 goal 一個終態，設 token 上限或輪次限制，按任務長短揀工具。
/goal 係咩玩法？由 Ralph Loop 講起
/goal 命令嘅核心係改變咗人同 AI 嘅合作模式：以往你講一句佢做一步，而家你畀個終點線，佢自己一輪一輪跑到完先交返控制權。呢個概念嘅前身係 Ralph Loop，一個簡單到好笑嘅 bash while-true 循環，由澳洲開發者 Geoffrey Huntley 喺 2025 年底整出嚟。
Ralph Loop 個邏輯就係反覆將同一段 prompt 餵畀 AI，等佢睇住上一輪改過嘅文件繼續做，直至任務完成。
Huntley 原話：「Ralph is a Bash loop.」但就係咁簡單嘅嘢，有人喺 Y Combinator hackathon 一夜跑出 6 個倉庫，亦有人用 297 美元 token 費完成咗 5 萬美元嘅合同。而家 Anthropic 已經將 Ralph 收編做 Claude Code 官方 plugin。
Codex 同 Claude Code 實現大不同
兩家雖然都叫 /goal，但底層思路完全唔同。Codex 嘅做法係將判斷權交畀模型本身：模型有一個叫 update_goal(complete) 嘅工具，佢覺得做曬就 call 呢個工具標記完成。系統仲設計咗限制——模型唔可以暫停或恢復 goal，全部由系統控制；另外如果某一輪模型淨係 chat 冇 call 任何工具，系統會抑制下一次自動續跑，避免空轉燒 token。
Codex 呢種設計係有意唔畀模型自己話「太難我歇嚇」
Claude Code 就請咗個獨立裁判：每輪完結後，系統將你設嘅條件同當前對話 pack 畀一個小快模型（預設係 Haiku），由佢判斷係咪達到條件。如果未達到，就將判斷理由作為下一輪引導；達到就清除 goal。好處係幹活同判別分開，唔會出現自己做完順手打勾嘅情況。
Claude Code 用 Haiku 做評估，等於請咗個唔識偷懶嘅監工
其他分別仲包括：Codex 用 SQLite 做持久化，斷咗線可以續返；Claude Code 係 session 級，恢復時輪次同 token 統計會重置。Codex 有原生 token_budget 字段做預算控制，Claude Code 就要喺條件文字入面自己寫「30 輪後停止」。
- Codex：上線 2026-04-30（0.128.0），由模型判斷完成，持久化強，有空轉檢測
- Claude Code：上線 2026-05-12（2.1.139），由獨立小模型評估，持久化弱，易請示
- Codex 預算控制原生，Claude Code 要靠文字約束
點樣寫條件先跑到終點？同埋注意啲咩
/goal 成唔成功，條件寫得好唔好佔一大半。好條件通常有呢三個要素：一個可測量嘅終態（例如測試全過、構建退出碼為 0）、一個明確嘅驗證方式（AI 點樣證明做到，例如「運行 npm test 且退出碼為 0」）、同埋約束（過程中唔準改啲咩文件）。
好例子：/goal npm test exits 0 with no skipped tests
壞例子就好似「make the code better」，呢啲模糊目標評估模型根本睇唔明，結果永遠唔停或者隨便停。實用技巧係喺條件加個剎車，例如「stop after 30 turns」，咁就唔怕燒到天光。
- 1 記得搭 auto mode：/goal 只免除輪與輪之間嘅確認，但每一輪入面嘅工具調用仲要彈框，唔開 auto mode 一樣卡住。
- 2 一個 goal 一個終態：塞太多條件（例如「測試通過 AND 覆蓋率 > 80% AND 文檔更新」）會令模型卡死循環，拆成幾個細 goal 更穩。
- 3 對花費有預期：跑幾個鐘嘅 goal 消耗幾十美元好正常，Codex 可以用 token_budget 設硬上限，Claude Code 建議喺條件寫明輪次上限。
實際跑嘅體驗方面，Codex 埋頭幹唔問人，上下文壓縮後恢復得唔錯；Claude Code 開局雖然有宏觀規劃，但跑一陣就會彈問題問你，有時仲會主動話目標太大然後 fail。呢啲分別同兩家嘅工程方案同模型行為模式有關，揀邊隻用要睇任務性質。
兩間幾乎同一時間加入咗 /goal 指令，但係工程方案完全唔同——一個俾模型自己判斷完成，另一個就專登請咗個裁判。
以前用 AI 寫 code，你講一句，佢做一步，你再講一句，佢再做一步。每輪都要你確認、要你催促。
而家變咗。Codex 4 月底加咗 /goal，Claude Code 5 月中都加咗。你俾佢設定一個終點線，行開，佢自己一輪一輪繼續跑，直到條件滿足先停低還返控制權俾你。
功能一樣，但實際跑起上嚟差距大到令人懷疑兩間公司做嘅係咪同一樣嘢。
/goal 做啲乜嘢
傳統模式之下，AI 每完成一輪就會停低等你下一句指令。/goal 改咗呢個規則：
你設定一個終止條件，AI 每輪結束之後自己判斷條件係咪滿足。唔滿足嘅話，自動開始下一輪；滿足咗，就停。
適合嘅任務有個共通點——最終狀態可以驗證：
唔適合嘅：需要成日人工判斷方向嘅探索性工作，或者 5 分鐘搞得掂嘅小嘢。
前身：Ralph Loop
/goal 嘅精神前身叫 Ralph Loop，個名嚟自《阿森一族》入面嘅角色 Ralph Wiggum。
2025 年底，澳洲開發者 Geoffrey Huntley 整咗呢個嘢。核心邏輯簡單得有啲掃興——就係一個 bash 嘅 while-true loop，重複將同一個 prompt 檔案餵俾 AI agent，等佢睇到自己上一輪改過嘅檔案，繼續做，直到任務完成。Huntley 原話："Ralph is a Bash loop."
社區有人用佢做咗唔少嘢。根據 Ralph 官方 plugin 文件記載：Y Combinator hackathon 上面有人一晚跑出 6 個 repo；有個價值 5 萬美金嘅合約，最終 API 使費得 297 美金。Huntley 自己用咗 3 個月整咗一門實驗性編程語言（佢自己叫佢做"cursed"）。
而家 Anthropic 已經將 Ralph 吸納做官方 Claude Code plugin，放咗喺 plugins/ralph-loop/ 目錄下面。
/goal 喺 Ralph 嘅基礎上主要加咗三樣嘢：
兩間係點實現嘅
同樣叫 /goal，底層思路唔一樣。
Codex：模型自己判斷完成。
Codex 俾模型暴露咗一個工具叫做 update_goal(complete)——模型覺得做完咗，就 call 呢個工具將 goal 標記為完成。但係模型唔可以暫停或者恢復 goal，呢啲由系統控制（例如你撳 Ctrl+C 就暫停，重新入 thread 就自動恢復）。呢個係刻意咁樣設計——唔俾模型自己決定"太難啦我唞一陣"。
防空轉都做咗：如果某一輪自動續跑期間 AI 無 call 任何工具，只係傾偈，系統就會抑制下一次自動續跑，避免原地打圈燒 token。
Claude Code：請咗個獨立裁判。
Claude Code 嘅做法唔一樣。每輪結束之後，系統將你設定嘅條件同當前對話 send 俾一個快啲嘅細模型（預設係 Haiku），由佢判斷條件係咪滿足。回"否"就同 Claude 講繼續做，將判斷理由做下一輪嘅引導；回"是"就清除 goal。
好處係"做嘢嘅"同"判完未"嘅唔係同一個模型——唔會自己做完成就順便俾自己打剔。Codex 嗰邊靠工程約束（模型唔可以暫停自己 + 空轉檢測）嚟制衡，思路唔同但都唔係完全無剎車。
核心差異一覽：
條件要點樣寫先至跑到終點
/goal 能否跑到終點，條件寫得好唔好佔咗一大半。
好條件通常有三個要素：
npm test 而且 exit code 係 0"好例子：
壞例子：
"better"無辦法判斷。評估模型睇唔明乜嘢叫"更好"，結果一係永遠唔停，一係隨便停。
仲有個實用技巧——喺條件入面加個剎車：
咁樣就算任務比預期複雜，都唔會無限燒 token。
跑 /goal 嘅幾個注意事項
用過一段時間之後，有幾個容易中招嘅地方：
1. 記得搭配 auto mode。
/goal 免除嘅係"輪與輪之間"嘅手動確認。但係每一輪入面，AI 要讀檔案、寫檔案、執行指令，呢啲工具 call 預設係要彈確認框嘅。如果你唔開 auto mode（或者 Codex 嘅 full-auto），goal 跑跑嚇彈個"允許寫呢個檔案嗎"——一樣會卡住等你。
所以實際操作上 /goal 基本上都係配合自動批准權限一齊用。
2. 先手動跑通一次先 set goal。
唔好第一次做某個任務就直接 /goal。先手動跑一輪，確認 AI 理解到任務、路徑可行、唔會喺第一步就卡死。跑通咗之後再 set goal 等佢重複或者擴展，成功率高好多。
3. 一個 goal 一個最終狀態，唔好塞太多目標。
"測試通過 AND 覆蓋率 > 80% AND 文檔更新 AND 類型檢查通過"——塞太多條件，模型容易喺中間某步反覆卡死 loop。拆成多次 /goal 更穩陣：先跑通測試，再跑覆蓋率，再跑文檔。
4. 對使費要有個預期。
長時間 /goal 嘅 token 消耗唔低。一個跑幾個鐘嘅 goal，消耗幾十美金好正常。Codex 可以 set token_budget 硬上限；Claude Code 建議喺條件入面寫明輪次上限，避免唔記得之後賬單嚇親。
實際跑出嚟係點樣
下面呢啲體驗主要嚟自社區入面幾個長期跑 /goal 嘅開發者實測，唔係官方數據，之後嘅版本可能會變——但係暫時大家反饋嘅感覺都幾一致：
Codex 跑起上嚟嘅表現：埋頭做，唔問人，唔放棄。
跑 /goal 嘅時候，Codex 幾乎唔會 interrupt 你。唔會彈出嚟問"你想要方案 A 定係方案 B"，自己判斷繼續行。
上下文壓縮之後恢復得唔錯。長任務跑得耐，對話歷史越來越長，差唔多塞爆上下文窗口時，系統會自動壓縮舊內容騰出空間。壓縮完 Codex 基本上可以接返上一輪嘅狀態繼續推進，唔會突然唔記得之前做緊乜。
卡住咗會轉角度。遇到一個方向行唔通，佢唔會直接報告"目標無法實現"，而係轉個思路再試，直到 token 預算燒曬先停。有人測試過成晚跑三個獨立 /goal session，朝早起身大部分仲喺度正常推進。
Claude Code 跑起上嚟嘅表現：開局華麗，但係鍾意請示。
Claude Code 一開始 /goal 就睇得出佢思路更宏觀——先列計劃，將大任務拆成細塊分配俾並行嘅子助手一齊做，做全局協調。開局睇落確實好勁。
但係跑跑嚇問題就嚟啦。
佢會彈出嚟問你揀。"呢個 interface 有兩種實現方式，你傾向邊個？"平時呢個係優點，表示佢喺度對齊你嘅意圖。但係喺 /goal 模式下呢個變咗障礙——你 set goal 嘅目的就係行開唔理，佢一彈問題你就返嚟睇住。
佢有時跑咗冇耐就主動話你知"呢個目標太大，當前 session 完成唔到"，然後真係 fail 咗。
上下文壓縮之後資訊流失比較明顯。之前列嘅計劃、已經排除嘅方案，壓縮完佢可能會唔記得，要重新摸索。不過 Claude Code 嘅默認上下文窗口係 1M，比 Codex 默認嘅 400K 大唔少，壓縮觸發頻率本身就低啲。
補充返個背景：Claude Code 嘅部分"惰性"同 Opus 4.7 嘅一個已知 regression 有關。2026 年 4 月 16 日 Opus 4.7 發佈時，Anthropic 喺系統 prompt 入面加咗"reduce verbosity"指令，無意中拖累咗編碼質量，4 日後回滾咗，但係社區反饋未有完全恢復。所以上面呢啲感受唔一定係永久嘅。
場景選擇：
上手指南
兩間嘅用法幾乎一樣：入 interactive mode 之後打 /goal 加上終止條件就得。Codex 要求 0.133.0 以上版本（呢個版本 /goal 正式轉正），Claude Code 要求 2.1.139 以上。
Claude Code 仲可以睇當前 goal 狀態（/goal 唔帶參數）同提前結束（/goal clear）。
兩間都支援 headless mode，適合背景跑或者接 CI：
寫喺最後
/goal 令 AI 編程由"你講一句佢做一步"變成咗"你講清楚目標就行開"。2025 年底有人用 bash while-true loop 證明咗呢條路行得通，半年之後兩間正式做咗產品級功能。
兩間跑出嚟嘅效果唔一樣，同底層工程方案有關，亦同模型本身嘅行為模式有關。你手頭上嘅任務係邊種性質，就揀邊間跑。
Claude Code 免費白嫖，參閲下面文章
兩家幾乎同時加了 /goal 命令，工程方案卻完全不同——一個讓模型自己判斷完成，另一個專門請了個裁判。
以前用 AI 寫代碼，你說一句，它幹一步，你再說一句，它再幹一步。每一輪都要你確認、要你催。
現在變了。Codex 4 月底加了 /goal，Claude Code 5 月中也加了。你給它設一個終點線，走開，它自己一輪一輪往下跑，直到條件滿足才停下來還你控制權。
功能一樣，實際跑起來差距大到讓人懷疑兩家做的是不是一回事。
/goal 乾的是什麼事
傳統模式下，AI 每完成一輪就停下來等你的下一條指令。/goal 改了這個規則：
你設一個終止條件，AI 每輪結束後自己判斷條件是否滿足。不滿足，自動開下一輪；滿足了，停。
適合的任務有個共同點——終態可驗證：
不適合的：需要頻繁人工判斷方向的探索性工作，或者 5 分鐘能搞定的小活。
前身：Ralph Loop
/goal 的精神前身叫 Ralph Loop，名字來自辛普森動畫裏的角色 Ralph Wiggum。
2025 年底，澳洲開發者 Geoffrey Huntley 搞了這麼個東西。核心邏輯簡單得有點掃興——就是一個 bash 的 while-true 循環，反覆把同一個 prompt 文件餵給 AI agent，讓它看到自己上一輪改過的文件，接着幹，直到任務完成。Huntley 原話："Ralph is a Bash loop."
社區有人拿它幹了不少活。據 Ralph 官方 plugin 文檔記載：Y Combinator hackathon 上有人一夜跑出 6 個倉庫；有個價值 5 萬美元的合同最終 API 花費只有 297 美元。Huntley 自己花 3 個月造了一門實驗性編程語言（他自己稱之為"cursed"）。
現在 Anthropic 已經把 Ralph 吸收為官方 Claude Code plugin，放在 plugins/ralph-loop/ 目錄下。
/goal 在 Ralph 的基礎上主要加了三樣東西：
兩家怎麼實現的
同樣叫 /goal，底層思路不一樣。
Codex：模型自己判斷完成。
Codex 給模型暴露了一個工具叫 update_goal(complete)——模型覺得幹完了，就調這個工具把 goal 標記為完成。但模型不能暫停或恢復 goal，這些由系統控制（比如你按 Ctrl+C 就暫停，重新進線程就自動恢復）。這是故意這麼設計的——不讓模型自己決定"太難了我歇一會兒"。
防空轉也做了：如果某一輪自動續跑中 AI 沒調用任何工具，只是在聊天，系統就抑制下一次自動續跑，避免原地打轉燒 token。
Claude Code：請了個獨立裁判。
Claude Code 的做法不一樣。每輪結束後，系統把你設的條件和當前對話發給一個小快模型（默認是 Haiku），由它來判斷條件是否滿足。返回"否"就告訴 Claude 繼續幹，把判斷理由作為下一輪引導；返回"是"就清除 goal。
好處是"幹活的"和"判完沒"的不是同一個模型——不會自己幹完就順手給自己打勾。Codex 那邊靠工程約束（模型不能暫停自己 + 空轉檢測）來制衡，思路不同但也不是完全沒有剎車。
核心差異一覽：
條件怎麼寫才能跑到終點
/goal 能不能跑到終點，條件寫得好不好佔了一大半。
好條件通常有三個要素：
npm test 且退出碼為 0"好例子：
壞例子：
"better"沒法判斷。評估模型看不懂什麼叫"更好"，結果要麼永遠不停，要麼隨便停。
還有個實用技巧——在條件里加個剎車：
這樣即使任務比預期複雜，也不會無限燒 token。
跑 /goal 的幾個注意事項
用過一段時間之後，有幾個容易踩到的地方：
1. 記得搭配 auto mode。
/goal 免除的是"輪與輪之間"的手動確認。但每一輪裏面，AI 要讀文件、寫文件、跑命令，這些工具調用默認還是要彈確認框的。如果你不開 auto mode（或者 Codex 的 full-auto），goal 跑着跑着彈個"允許寫這個文件嗎"——照樣卡住等你。
所以實操中 /goal 基本都是配合自動批准權限一起用的。
2. 先手動跑通一次再設 goal。
不要第一次幹某個任務就直接 /goal。先手動跑一輪，確認 AI 能理解任務、路徑可行、不會在第一步就卡死。跑通了之後再設 goal 讓它重複或擴展，成功率高很多。
3. 一個 goal 一個終態，別塞太多目標。
"測試通過 AND 覆蓋率 > 80% AND 文檔更新 AND 類型檢查通過"——塞太多條件，模型容易在中間某步反覆卡死循環。拆成多次 /goal 更穩：先跑通測試，再跑覆蓋率，再跑文檔。
4. 對花費有個預期。
長時間 /goal 的 token 消耗不低。一個跑幾小時的 goal，消耗幾十美元很正常。Codex 可以設 token_budget 硬上限；Claude Code 建議在條件裏寫明輪次上限，避免忘了之後賬單嚇一跳。
實際跑出來什麼樣
下面這些體驗主要來自社區裏幾個長期跑 /goal 的開發者的實測，不是官方數據，後續版本可能會變——但目前大家反饋的感覺挺一致：
Codex 跑起來的表現：埋頭幹，不問人，不放棄。
跑 /goal 的時候，Codex 幾乎不中斷你。不會彈出來問"你想要方案 A 還是方案 B"，自己做判斷往下走。
上下文壓縮後恢復得不錯。長任務跑久了，對話歷史越來越長，快把上下文窗口撐滿時，系統會自動壓縮舊內容騰空間。壓縮完 Codex 基本能接着上一輪的狀態繼續推進，不會突然忘了之前在幹什麼。
卡住了會換角度。碰到一個方向走不通，它不會直接報告"目標無法實現"，而是換個思路再試，直到 token 預算燒完才停。有人測試過整夜跑三個獨立 /goal session，早上起來大部分還在正常推進。
Claude Code 跑起來的表現：開局華麗，但愛請示。
Claude Code 一啓動 /goal 就能看出它思路更宏觀——先列計劃，把大任務拆成小塊分配給並行的子助手同時幹，做全局協調。開局看着確實猛。
但跑着跑着問題來了。
它會彈出來問你做選擇。"這個接口有兩種實現方式，你傾向哪個？"平時這是優點，說明它在對齊你的意圖。但在 /goal 模式下這變成了障礙——你設 goal 的目的就是走開不管，它一彈問題你就得回來盯着。
它有時候跑了沒多久就主動告訴你"這個目標太大了，當前 session 完成不了"，然後真的 fail 了。
上下文壓縮後信息丟失比較明顯。之前列的計劃、已經排除的方案，壓縮完它可能就忘了，要重新摸索。不過 Claude Code 的默認上下文窗口是 1M，比 Codex 默認的 400K 大不少，壓縮觸發頻率本身就低一些。
補充一個背景：Claude Code 的部分"惰性"跟 Opus 4.7 的一個已知迴歸有關。2026 年 4 月 16 日 Opus 4.7 發佈時，Anthropic 在系統提示詞里加了"reduce verbosity"指令，無意中拖累了編碼質量，4 天后回滾了，但社區反饋沒完全恢復。所以上面這些感受不一定是永久的。
場景選擇：
上手指南
兩家的用法幾乎一樣：進交互模式後敲 /goal 加上終止條件就行。Codex 要求 0.133.0 以上版本（這個版本 /goal 正式轉正），Claude Code 要求 2.1.139 以上。
Claude Code 還能查看當前 goal 狀態（/goal 不帶參數）和提前結束（/goal clear）。
兩家都支持無頭模式，適合後台跑或接 CI：
寫在最後
/goal 讓 AI 編程從"你說一句它幹一步"變成了"你說清目標就走開"。2025 年底有人用 bash while-true 循環證明了這條路走得通，半年後兩家正式做成了產品級功能。
兩家跑出來的效果不一樣，跟底層工程方案有關，也跟模型本身的行為模式有關。你手上的任務是哪種性質，就選哪家跑。