2小時燒掉9億token後，我發現了OpenAI和Anthropic在/goal上的本質區別
整理版優先睇
Codex同Claude Code嘅/goal功能：自審定他審，完成判定先係關鍵
呢篇文章係一位開發者喺試用 Codex 0.128.0 嘅 /goal 功能之後嘅反思。社區有人燒咗 9 億 token 連續跑 21 個鐘，而 Anthropic 亦迅速跟進同名命令。作者最初以為 /goal 只係一個循環，但深入研究 Codex 同 Claude Code 嘅實現之後，發現兩者表面一樣，骨子裏係完全相反嘅工程哲學。
/goal 嘅核心係完成判定——AI 點知道自己真係做完？Codex 嘅做法係強制注入一段好狠嘅審計提示詞，逼工作模型逐項核對證據；Claude Code 就另請一個冇工具嘅小模型嚟判卷。兩種方法各有優劣，但共同點係：完成判定係長任務質量嘅瓶頸，而且關鍵約束必須寫喺代碼層，唔可以只靠 prompt 規勸。
Ralph Loop 嘅做法係等 AI 自己話 DONE 就退出，但完成判定靠字符串匹配完全唔可靠。Codex 改用強制審計提示詞，要求模型假設未完成，逐項找證據，證據強度唔夠就算未完成。Claude Code 就完全分離判卷人，用獨立小模型睇對話紀錄判斷——呢個小模型冇工具，只能基於文字。呢兩種思路背後係 OpenAI 信約束工程化，Anthropic 信分離比約束有效。
- /goal 將 prompt 從「做任務」進化到「達到狀態」，閉環自動化依賴完成判定機制。
- Codex 用強制審計提示詞逼工作模型自審，可調工具驗證真實狀態；Claude Code 用獨立小模型他審，只能基於對話文字。
- 自審上限受模型能力限制，他審可能被工作模型嘅輸出誤導——兩條路都唔完美。
- 關鍵約束必須從提示詞層提升到代碼層：寫喺 CLAUDE.md 嘅規則可以被忽略，但寫喺代碼裏嘅強制注射冇得繞。
- 用 /goal 需要寫結構化 SPEC，將 prompt 變成合約，定義清楚完成條件同驗證標準。
/goal 嘅出現：一個命令兩種哲學
4 月 30 日，Codex 0.128.0 發佈，第一次帶上咗 /goal 命令。社區有人即刻用佢跑咗 21 個鐘，燒咗 9 億 token。OpenAI 總裁 Greg Brockman 喺 X 上將佢對標成 Ralph loop 嘅內置版本。兩星期後，Anthropic 喺 Claude Code 都跟進咗同名命令。
Codex 0.128.0
/goal
Ralph loop
9 億 token
作者話，最初見到 /goal 冇乜感覺——咪又係一個循環？但讀完兩家嘅實現之後，嚇咗一跳。表面一樣，骨子裏係完全相反嘅路。
表面一樣，骨子裏完全相反
Ralph Loop：讓 AI 自己話做完就退出
Ralph Loop 係一個簡單循環：反覆將同一段任務餵畀 AI，直到佢自己輸出特定暗號（例如 DONE）就算完成。Anthropic 官方倉庫有示例插件，用鈎子攔截。作者話，呢個設計就係讓 AI 自己批改自己嘅試卷。
DONE
自己批改自己嘅試卷
Ralph Loop 作者都知唔可靠，文檔提醒要配最大輪次兜底。注入嘅提示詞有一句：'ONLY when statement is TRUE - do not lie to exit'——你唔好撒謊啊。但靠提示詞一句話兜唔住。
自審 vs 他審：兩種判卷法
Codex 同 Claude Code 都重新設計咗完成判定，但路線完全唔同。
- Codex 方法：每次想停，強行注入一段審計提示詞，要求模型假設未完成，逐項核對證據，證據強度唔夠就算未完成。審計唔可以憑記憶或合理結論，要真係揾到證據。呢段提示詞係運行時強制注入，模型冇得跳過。
- Claude Code 方法：工作模型做完一輪，將完成條件同對話紀錄打包，交畀一個獨立小模型判卷。小模型冇工具，只能基於文字判斷，返一個「係/否」加理由。係就退出，否就將理由塞返畀主模型繼續。
自審路線（Codex）審嘅係真狀態
他審路線（Claude Code）獨立但睇唔到現實
生成同判定要分開
完成判定係長任務質量嘅天花板
兩家嘅本質都係承認完成判定係長任務質量嘅瓶頸。如果 AI 跑咗 21 個鐘、燒咗 9 億 token，最後話做完——你信嗎？唔審計，就只能信。但信唔係工程。
完成判定係長任務質量嘅瓶頸
作者話，/goal 改變咗 prompt 嘅形態。以前 prompt 係做呢件事，而家變成達到呢個狀態，按呢個標準驗證。prompt 變成一份合約，對寫需求嘅人要求更高。如果你將一份結構化 SPEC 餵畀 /goal，完成審計先可以精確工作。
關鍵約束必須從提示詞層提升到代碼層
prompt 變咗一份合約
- 將 prompt 從「做呢件事」改寫成「達到呢個狀態，按呢個標準驗證」
- 完成條件要可驗證，最好係測試通過、lint 冇報錯等客觀指標
- 關鍵約束要寫喺代碼層，唔好依賴模型自覺遵守 prompt
4月30日，Codex 0.128.0 發佈，第一次加入咗 /goal。社區即刻有人用佢跑咗21個鐘，燒咗9億 token。OpenAI 總裁 Greg Brockman 喺 X 上面將佢對標成 Ralph loop 嘅內置版本——佢原話係「codex now has a built in Ralph loop++」。
兩個禮拜後，Anthropic 喺 Claude Code 都跟進咗同名嘅命令。
除咗呢兩間，Hermes、OpenCode 都陸續跟咗上嚟。/goal 已經變咗呢類工具嘅共識機制。
講真，第一次見到呢個命令嗰陣我冇乜感覺——咪又係一個循環？以前用腳本同埋鈎子拼埋一齊都做到出嚟。
但係讀完兩間嘅實現之後，我呆咗一下。
表面睇用法一樣，骨子裏行嘅係兩條完全相反嘅路。
/goal 到底係做乜嘢嘅
以前你同 Claude Code 或者 Codex 講「幫我將呢堆測試跑通」，佢跑一輪，停低，你睇一眼話「繼續」，佢再跑一輪。中間總要有人喺度睇住。
/goal 將呢件事改咗。你俾一段任務，再俾一個完成條件——例如所有測試通過、lint 冇報錯——撳嚇 Enter，AI 自己開始跑。每跑完一輪，佢自己判斷條件係咪滿足，冇滿足就再嚟一輪，滿足咗先停。
形式上係咁樣：
/goal 將 src/auth/ 下面所有測試跑通，lint 冇報錯
唔需要中間撳 Enter 講「繼續」。
prompt 嘅形態變咗。以前係叫 AI 做呢件事，而家係叫 AI 將呢件事做到呢個狀態為止。
聽落都幾美好。
但你諗下——AI 點知自己真係做曬？
呢個就係成件事嘅核心問題。
Ralph Loop：AI 自己話做完，就退出
/goal 唔係無端端走出來嘅。喺佢之前，社區流行過一個做法叫 Ralph Loop。
個名嚟自《阿森一族》入面嗰個屢戰屢敗嘅 Ralph Wiggum——一種鍥而不捨嘅工作法。原始版本就係一段簡單嘅循環：反覆將同一段任務餵俾 AI，直到佢自己話「我做曬」。
Anthropic 官方倉庫入面有個示例插件，將呢個套路工程化咗。邏輯得兩件事：
第一，每次 AI 想停低，鈎子攔住佢，將原任務再餵一次。
第二，AI 輸出一句特定嘅暗號（例如 DONE），就算完成，循環退出。
我第一次見到呢個設計嗰陣，第一個反應係——
呢個咪即係叫 AI 自己改自己份卷？
佢願意寫出 DONE 就退出，唔願意就繼續跑。完成判定權完全喺 AI 自己手上。
Ralph Loop 嘅作者自己都好清楚呢件事唔靠譜，所以喺文檔入面反覆提示要配最大輪次兜底。注入俾 AI 嘅提示詞入面甚至有一句好說明問題：
ONLY when statement is TRUE - do not lie to exit
你唔好講大話啊。
但係叫 AI 唔講大話呢件事，靠提示詞一句說話係兜唔住嘅。
AI 話「我做曬」同真係做曬之間，爭咗一座獨立驗證嘅橋。
兩種判卷方法
Ralph Loop 驗證咗一件事——循環呢套思路，工程上係可行嘅。
但完成判定唔可以靠模型自己話事。呢個係佢最大嘅瓶頸。
Codex 同 Claude Code 都重新設計咗呢一部分。但係兩間揀咗完全唔同嘅方向。
Codex 嘅方法：叫 AI 自己審，但審得冇咁舒服
Codex 冇換判卷人。每次 AI 想停低，運行時強行塞一段審計提示詞俾佢——而且呢段提示詞寫得相當狠。
我將呢段提示詞嘅核心意思翻譯一下：
喺你判定任務完成之前，先假設冇完成。然後逐項核對——目標入面每一條要求、每一個產物、每一個測試、每一道關卡，逐個揾證據證明佢已經做曬。證據強度唔夠？當冇完成。
最關鍵嘅一句：審計必須證明做曬，唔可以淨係以冇揾到冇做嘅嘢作為完成依據。
而且佢明確禁止憑印象、憑記憶、憑一個睇落合理嘅結論當證據。
我讀到呢段嗰陣有啲佩服。呢個係將完成呢件事，由模糊感覺變咗做一份逐項核對嘅清單。
更重要嘅係，呢段提示詞唔係寫喺文檔入面建議你最好咁做——佢係被運行時強行注入到 AI 每一輪嘅上下文入面。你想 skip 都 skip 唔到。
工作模型本身有行命令、查文件、睇測試結果嘅能力。所以佢審嘅係真狀態，唔係憑腦補。
Claude Code 嘅方法：另外請一個小模型嚟判
Anthropic 行嘅係另一條路。
工作模型做完一輪嘢，停低。Claude Code 將完成條件同對話記錄打包，交俾一個獨立嘅小模型去睇。呢個小模型嘅工作得一件事：讀完對話，判斷條件係咪真係滿足咗。
佢返回嘅係一個簡單嘅判斷：係 / 唔係，配一段簡短嘅理由。
係？退出循環。
唔係？將理由作為系統消息塞返去，叫主模型繼續做。
呢個小模型有個關鍵約束——佢冇工具。佢行唔到測試、查唔到文件，只能基於對話入面已經寫咗出嚟嘅文字做判斷。
我見到呢個設計第一個反應係：呢個就係 Anthropic 一貫嘅思路——生成嘅人同判定嘅人，一定要係兩個人。
VentureBeat 報道入面有一句講得好到位：
You can't trust a model to judge its own homework. The model doing the work is the worst judge of whether it's done.
意思係：你冇辦法叫一個模型自己改自己嘅功課。做嘢嗰個人，係最唔應該做判卷人嗰個。
自審 vs 他審，分別喺邊
你睇得出嚟啦——一邊係叫 AI 自己審，一邊係另外請判卷人。
各有優劣。
自審路線（Codex）嘅優勢係審嘅係真嘢。佢可以調工具、可以行命令、可以讀真實文件。證據係硬嘅。但佢有個上限——審計能力被工作模型本身嘅能力卡住。模型唔得，再狠嘅提示詞都只係做嚇樣。
他審路線（Claude Code）嘅優勢係獨立。判卷人同做嘢嘅人完全解耦，思路上更乾淨。但佢嘅侷限都好明顯：判卷人睇唔到現實，只能基於對話入面講咗啲乜做判斷。如果工作模型喺對話入面寫一句「測試全部通過咗」，但實際上冇行——判卷人見到嘅證據就成立咗，佢會放行。
Claude Code 嘅文檔入面寫得好坦白：
你要將條件寫成 Claude 自己可以喺輸出入面證明嘅樣。例如 test/auth 下面所有測試通過呢種條件用得，係因為 Claude 會執行測試，結果會落喺對話入面，判卷人睇得到。
潛台詞係：你要信做嘢嗰個人唔會作命令輸出。
兩條路都唔完美。
但你諗下——Codex 揀咗叫 AI 自己審，但審得冇咁舒服；Anthropic 揀咗另外請一個睇唔到現實嘅判卷人。
呢個背後係兩種工程哲學。
OpenAI 信約束可以工程化——只要審計提示詞寫得夠狠，工具調用框得夠死，就可以逼出審計行為。
Anthropic 信分離比約束有效——你冇辦法叫一個人自己審自己，咁就揾另一個人嚟審。
兩間都冇默認將可以調工具嘅他審 AI 整入 /goal，即使呢條路從原理上完全做得到。點解？每輪多行一個模型，成本翻倍，仲要俾佢獨立嘅沙盒同權限，狀態機跟住都複雜埋。
工程上有時唔係最完美嘅方案贏，係成本同效果妥協落嚟仲行得鬱嘅方案贏。
關鍵約束一定要放喺代碼層
讀完兩間嘅設計，有一件事係相通嘅。
Codex 嗰段強約束審計提示詞，本質上只係一段文字。佢之所以生效，係因為每一輪上下文都被運行時強行注入咗呢段文字——AI 冇可能 skip 過。
呢個強行注入嘅動作，寫喺代碼入面，模型冇得改。
Claude Code 嘅判卷人都一樣。判卷人可以喺每一輪無條件被調用，係因為呢個係鈎子協議喺 Claude Code 內核入面嘅強制契約。
兩間用完全唔同嘅代碼結構，表達咗同一件事——
嗰啲模型可能唔會遵守嘅關鍵約束，一定要由提示詞層提升到代碼層。
寫喺 CLAUDE.md 入面嘅規則，模型可以選擇性忽略。寫喺 prompt 入面嘅「請你嚴格審計」，模型可以求其過關。但係寫喺代碼入面嘅「每一輪無條件做呢件事」，模型冇辦法繞過。
我之前喺 Harness Engineering 嗰篇文章入面寫過：建議同約束，完全兩回事。而家更加確信。
不過兩間分離嘅位置唔同。Claude Code 係另外開咗一個獨立權重嘅小模型，工作模型同佢冇共用嘅判斷邏輯——分離發生喺模型權重一層。Codex 冇換模型，叫工作模型自己審，但靠運行時強制注入嘅審計提示詞將審計動作同生成動作隔離開——分離發生喺上下文一層。
同樣係分離，做法可以完全唔同。
完成判定，係長任務質量嘅天花板
Ralph Loop 嘅瓶頸喺邊？
字串匹配判完成。AI 只要肯輸出 DONE，成個循環就失效。
Codex 同 Claude Code 都重新設計咗完成判定。思路截然不同——一個加上強約束嘅審計提示詞逼工作模型自審，一個乾脆將審計責任移俾獨立小模型。
但兩間嘅本質都係承認咗一件事：
完成判定係長任務質量嘅瓶頸。
如果一個 AI 跑咗 21 個鐘、燒咗 9 億 token，最後佢話「我做曬」——你信唔信？
唔審計，就惟有信。
但信唔係工程。
社區入面有人喺 Claude Code 上面拼咗一套 Codex 風格嘅實現，用鈎子攔截，自己持久化目標狀態，用一段強約束嘅提示詞包裹任務，要求模型喺標記完成前做證據核對。
呢個說明啲乜？
呢個說明呢兩條路喺內核層級係可以互相替換嘅。差別只係邊個原生支持邊一種。
最後產出嘅質量好唔好，都係睇工作模型本身嘅能力。
/goal 係 prompt 嘅新形態
我自己用 Claude Code 大半年，/goal 令我再睇一次點樣寫 prompt 呢件事。
以前 prompt 係做呢件事。
而家 prompt 變成達到呢個狀態，按呢個標準驗證，期間唔可以違反呢啲約束。
prompt 變成咗一份合約。
呢種形態對寫需求嘅人提出咗更高嘅要求。/goal 一跑就係成日——目標寫得求其，就只會換來求其嘅產出。
如果你將一份結構化嘅 SPEC 文檔餵俾 /goal，完成審計先可以精確工作。如果你只寫一句「將代碼跑通」，審計就只會退化到測試通過等於完成。
SDD（Spec-Driven Development）呢種開發範式之所以會興起，正正係因為 /goal 呢種自治循環嘅工具開始普及。
工具變咗，寫需求嘅方式都要跟住變。
最後
我諗咗一下 /goal 呢件事。
佢唔係一個新功能。佢係 AI 工具開始接管自我驗證呢一環嘅信號。
以前 AI 做完嘢，要有人睇住。
而家 AI 做完嘢，AI 自己（或者另一個 AI）判斷佢係咪真係做曬。
人由睇住退咗一步——退到定義合約呢一步。
但係合約能唔可以定義清楚，決定咗呢件事最後值唔值。
工具越強，人嘅判斷越重要。
4 月 30 日，Codex 0.128.0 發佈，第一次帶上了 /goal。社區裏立刻有人用它跑了 21 個小時，燒掉 9 億 token。OpenAI 總裁 Greg Brockman 在 X 上把它對標成 Ralph loop 的內置版本——他原話是「codex now has a built in Ralph loop++」。
兩週後，Anthropic 在 Claude Code 也跟進了同名命令。
除了這兩家，Hermes、OpenCode 也都陸續跟上。/goal 已經成了這一類工具的共識機制。
說實話，第一次看到這個命令的時候我沒什麼感覺——不就是一個循環嗎？以前用腳本和鈎子拼一拼也能做出來。
但讀完兩家的實現之後，我愣了一下。
表面看用法一樣，骨子裏走的是兩條完全相反的路。
/goal 到底是幹嘛的
以前你跟 Claude Code 或者 Codex 說「幫我把這堆測試跑通」，它跑一輪，停下來，你看一眼說「繼續」，它再跑一輪。中間總得有個人在那盯着。
/goal 把這件事改了。你給一段任務，再給一個完成條件——比如所有測試通過、lint 沒報錯——回車一敲，AI 自己開始跑。每跑完一輪，它自己判斷條件是否滿足，沒滿足就再來一輪，滿足了才停。
形式上像這樣：
/goal 把 src/auth/ 下所有測試跑通，lint 沒報錯
不需要中間敲回車說「繼續」。
prompt 的形態變了。以前是讓 AI 做這件事，現在是讓 AI 把這件事做到這個狀態為止。
聽起來挺美好的。
但你想想——AI 怎麼知道自己真的做完了？
這就是整件事的核心問題。
Ralph Loop：AI 自己說做完，就退出
/goal 不是憑空冒出來的。在它之前，社區裏流行過一個做法叫 Ralph Loop。
名字來自《辛普森一家》裏那個屢戰屢敗的 Ralph Wiggum——一種鍥而不捨的工作法。原始版本就是一段簡單的循環：反覆把同一段任務餵給 AI，直到它自己說「我做完了」。
Anthropic 官方倉庫裏有個示例插件，把這個套路工程化了。邏輯就兩件事：
第一，每次 AI 想停下來，鈎子攔住它，把原任務再喂一次。
第二，AI 輸出一句特定的暗號（比如 DONE），就算完成，循環退出。
我第一次看到這個設計的時候，第一反應是——
這不就是讓 AI 自己批改自己的試卷嗎？
它願意寫出 DONE 就退出，不願意就接着跑。完成判定權完全在 AI 自己手裏。
Ralph Loop 的作者自己也清楚這事兒不靠譜，所以在文檔裏反覆提示要配最大輪次兜底。注入給 AI 的提示詞裏甚至有一句話很說明問題：
ONLY when statement is TRUE - do not lie to exit
你別撒謊啊。
但讓 AI 不撒謊這件事，靠提示詞上一句話是兜不住的。
AI 說「我做完了」和真的做完了之間，差着一座獨立驗證的橋。
兩種判卷法
Ralph Loop 驗證了一件事——循環這套思路，工程上是可行的。
但完成判定不能靠模型自己說了算。這是它最大的瓶頸。
Codex 和 Claude Code 都重新設計了這一塊。但兩家選了完全不同的方向。
Codex 的方法：讓 AI 自己審，但審得沒那麼舒服
Codex 沒換判卷人。每次 AI 想停下來，運行時強行塞一段審計提示詞給它——而且這段提示詞寫得相當狠。
我把這段提示詞的核心意思翻譯一下：
在你判定任務完成之前，先假設沒完成。然後逐項核對——目標裏每一條要求、每一個產物、每一個測試、每一道關卡，挨個找證據證明它已經做完了。證據強度不夠？算沒完成。
最關鍵的一句：審計必須證明做完了，不能僅以沒找到沒做的事作為完成依據。
而且它顯式禁止憑印象、憑記憶、憑一個看起來合理的結論當證據。
我讀到這段的時候有點佩服。這是把完成這件事，從模糊感受變成了一份逐項核對的清單。
更重要的是，這段提示詞不是寫在文檔裏建議你最好這麼做——它是被運行時強行注入到 AI 每一輪的上下文裏。你想跳過都跳不過去。
工作模型本身有跑命令、查文件、看測試結果的能力。所以它審的是真狀態，不是憑腦補。
Claude Code 的方法：另外請一個小模型來判
Anthropic 走的是另一條路。
工作模型幹完一輪活，停下來。Claude Code 把完成條件和對話記錄打包，交給一個獨立的小模型去看。這個小模型的工作只有一件事：讀完對話，判斷條件是不是真的滿足了。
它返回的是一個簡單的判斷：是 / 否，配一段簡短的理由。
是？退出循環。
否？把理由作為系統消息塞回去，讓主模型接着幹。
這個小模型有個關鍵約束——它沒有工具。它跑不了測試、查不了文件，只能基於對話裏已經寫出來的文字做判斷。
我看到這個設計第一反應是：這就是 Anthropic 一貫的思路——生成的人和判定的人，得是兩個人。
VentureBeat 報道里有一句話挺到位的：
You can't trust a model to judge its own homework. The model doing the work is the worst judge of whether it's done.
意思是：你沒法讓一個模型自己批改自己的作業。幹活的人，是最不該當判卷人的人。
自審 vs 他審，差在哪
你看出來了——一邊是讓 AI 自己審，一邊是另請判卷人。
各有優劣。
自審路線（Codex）的優勢是審的是真東西。它能調工具、能跑命令、能讀真實文件。證據是硬的。但它有個上限——審計能力被工作模型本身的能力卡住。模型不行，再狠的提示詞也只是走過場。
他審路線（Claude Code）的優勢是獨立。判卷人和幹活的人完全解耦，思路上更乾淨。但它的侷限也很明顯：判卷人看不到現實，只能基於對話裏說了什麼做判斷。如果工作模型在對話裏寫一句「測試全部通過了」，但實際沒跑——判卷人看到的證據就成立了，它會放行。
Claude Code 的文檔裏寫得很坦誠：
你要把條件寫成 Claude 自己能在輸出裏證明的樣子。比如 test/auth 下所有測試通過這種條件能用，是因為 Claude 會運行測試，結果會落到對話裏，判卷人看得到。
潛台詞是：你得相信幹活的人不會編造命令輸出。
兩條路都不完美。
但你想一下——Codex 選了讓 AI 自己審，但審得沒那麼舒服；Anthropic 選了另請一個看不見現實的判卷人。
這背後是兩種工程哲學。
OpenAI 信約束可以工程化——只要審計提示詞寫得夠狠，工具調用框得夠死，就能逼出審計行為。
Anthropic 信分離比約束有效——你沒法讓一個人自己審自己，那就找另一個人來審。
兩家都沒默認把能調工具的他審 AI 做進 /goal，即使這條路從原理上完全做得到。為什麼？每輪多跑一個模型，成本翻倍，還得給它獨立的沙盒和權限，狀態機也跟着複雜。
工程上有時候不是最完美的方案勝出，是成本和效果折中下來還能跑得動的方案勝出。
關鍵約束必須放在代碼層
讀完兩家的設計，有一件事是相通的。
Codex 那段強約束審計提示詞，本質上只是一段文字。它之所以能生效，是因為每一輪上下文都被運行時強行注入了這段文字——AI 不可能跳過。
這個強行注入的動作，寫在代碼裏，模型沒法改。
Claude Code 的判卷人也一樣。判卷人能被每一輪無條件調用，是因為這是鈎子協議在 Claude Code 內核裏的強制契約。
兩家用完全不同的代碼結構，表達了同一件事——
那些模型可能不遵守的關鍵約束，必須從提示詞層提升到代碼層。
寫在 CLAUDE.md 裏的規則，模型可以選擇性忽略。寫在 prompt 裏的「請你嚴格審計」，模型可以糊弄過去。但是寫在代碼裏的「每一輪無條件做這件事」，模型沒辦法繞。
我之前在 Harness Engineering 那篇文章裏寫過：建議和約束，完全兩回事。現在更確信了。
不過兩家分離的位置不一樣。Claude Code 是另起了一個獨立權重的小模型，工作模型跟它沒有共用的判斷邏輯——分離發生在模型權重一層。Codex 沒換模型，讓工作模型自己審，但靠運行時強制注入的審計提示詞把審計動作和生成動作隔離開——分離發生在上下文一層。
同樣是分離，做法可以完全不同。
完成判定，是長任務質量的天花板
Ralph Loop 的瓶頸在哪？
字符串匹配判完成。AI 只要願意輸出 DONE，整個循環就失效。
Codex 和 Claude Code 都重新設計了完成判定。思路截然不同——一個加上強約束的審計提示詞逼工作模型自審，一個乾脆把審計責任挪給獨立小模型。
但兩家的本質都是承認了一件事：
完成判定是長任務質量的瓶頸。
如果一個 AI 跑了 21 個小時、燒了 9 億 token，最後它說「我做完了」——你信嗎？
不審計，就只能信。
但信不是工程。
社區裏有人在 Claude Code 上拼了一套 Codex 風格的實現，用鈎子攔截，自己持久化目標狀態，用一段強約束的提示詞包裹任務，要求模型在標記完成前做證據核對。
這說明什麼？
這說明這兩條路在內核層級是可以互相替換的。差別只是誰原生支持哪一種。
最後產出的質量好不好，還是看工作模型本身的能力。
/goal 是 prompt 的新形態
我自己用 Claude Code 大半年了，/goal 讓我重新看了一眼怎麼寫 prompt 這件事。
以前 prompt 是做這件事。
現在 prompt 變成達到這個狀態，按這個標準驗證，期間不能違反這些約束。
prompt 變成了一份合約。
這種形態對寫需求的人提出了更高的要求。/goal 一跑就是一整天——目標寫得糊弄，就只能換回糊弄的產出。
如果你把一份結構化的 SPEC 文檔餵給 /goal，完成審計才能精確工作。如果你只寫一句把代碼跑通，審計就只能退化成測試通過等於完成。
SDD（Spec-Driven Development）這種開發範式之所以會火，正是因為 /goal 這種自治循環的工具開始普及。
工具變了，寫需求的方式也得跟着變。
最後
我想了一下 /goal 這件事。
它不是一個新功能。它是 AI 工具開始接管自我驗證這一環的信號。
以前 AI 幹完活，得有人盯着。
現在 AI 幹完活，AI 自己（或者另一個 AI）判斷它是不是真做完了。
人從盯着退了一步——退到定義合約這一步。
但合約能不能定義清楚，決定了這件事最後值不值。
工具越強，人的判斷越重要。