Codex 現在能自己幹完一個任務了
整理版優先睇
Codex CLI 新增 /goal 功能，讓 AI 自主完成任務，你只需定好目標，等佢交報告就得
呢篇文章係 Simon Willison 喺 2026 年 4 月 30 日嘅博客提到 Codex CLI 0.128.0 新增嘅 /goal 功能，作者由呢條短更新出發，分析呢個功能點樣改變 AI 編程工具嘅工作模式。以前用 Codex 做 vibe coding，每次都要你話「繼續」，佢先做下一步，好似個實習生咁要你不停催；而家設定一個 /goal，Codex 就會自己進入自循環，持續評估任務進度，直到完成或者 token 預算用完。呢個轉變唔只係功能升級，仲代表 AI 開始「持有任務」，用戶由督工變成審核者。
OpenAI 內部已經用類似機制嘅 Symphony 系統，結果工程團隊嘅 PR 交付量提升咗 500%，證明呢種自主循環模式有效釋放工程師嘅生產力，因為佢哋唔再需要花時間管理任務狀態，可以專注喺關鍵決策。文章結論係 /goal 值得認真試用，但用戶要調整工作方式，從「點樣催 AI 一步步做」變成「點樣清楚描述目標同邊界」，呢個思維轉變先係長遠有用嘅技能。
- Codex CLI 新增 /goal 功能，AI 可以自主循環完成任務，唔使逐個步驟催，直到目標達成或 token 用完。
- 以前係「一問一答」模式，用戶持有任務；而家 /goal 令 AI 持有任務，用戶退到審核位置，控制權轉移係重大變化。
- OpenAI 內部用類似系統 Symphony，工程團隊 PR 交付量提升 500%，證明自主循環大幅減輕任務管理負擔。
- 用戶需要適應新工作方式：專註定目標同邊界，唔再 micromanage 執行步驟，但要留意 token 預算限制。
- 點樣清楚描述目標比點樣催 AI 一步步做更重要，呢個能力會隨工具迭代一直有用。
從一問一答到自主完成：AI 開始持有任務
以前用 Codex 嘅體感好似帶個實習生，你畀佢一個任務，佢做一步就停，等你講「繼續」先再做下一步。你要全程盯實，行開一陣佢就喺度待命。呢種模式叫「一問一答」，你問咩佢答咩，下一步點走仲係你決定。
/goal 功能令 Codex 進入自循環，持續評估任務進度，唔需要你喺旁邊不斷催
設定一個 /goal 之後，Codex 會自己判斷「而家做到邊」「仲差咩」「下一步做咩」，循環直到目標達成或者 token 預算耗完。呢個模式叫 Ralph Loop，目標驅動嘅自主循環，而家正式落地。
OpenAI 內部數據：PR 交付量提升 500%
呢個功能唔係得個講字，OpenAI 內部有一套叫 Symphony 嘅系統，原理同 /goal 循環類似，都係 Agent 自主完成任務。
Symphony 系統令工程團隊嘅 PR 交付量提升咗 500%
呢個數字初睇好似誇張，但諗深一層好合理：以前工程師好多時間花喺「記住任務狀態」「決定下一步」「檢查進展」，呢啲嘢唔產出 code 但佔咗大量精力。如果 Agent 可以自己管理個循環，工程師就只需要喺關鍵節點做判斷，實際產量自然上升。
以前嘅 AI 工具要你識得 prompt engineering 先問到好答案，但循環式 Agent 嘅核心係持續評估目標有冇達成，然後調整策略繼續行。呢兩種能力嘅底層邏輯好唔同。
用戶要調整工作方式：從督工變成定方向
如果你而家用緊 Codex 做 vibe coding，/goal 值得認真試嚇。以前你可能習慣咗一步一確認，驚佢跑偏。呢種習慣喺早期 AI 工具係合理，但而家工具變咗。
更好嘅工作方式係：定清楚目標，然後等 Codex 自己跑，你做其他嘢，等佢畀進展報告
不過要留意，「token 預算耗完」係兜底機制，目標拆得太大或者上下文唔夠，佢仲係會跑偏或者卡住。自循環唔係無限循環，預算用完就停。
真正要練嘅技能係「點樣清楚描述目標同邊界」，而唔係「點樣催 AI 一步步行」
前者係定方向，後者係管執行。定方向其實比管執行更難，但呢個能力會一直有用，唔理工具點樣迭代。
好似一個要不斷催住佢行嘅實習生。
你要全程睇實，稍微行開一陣，佢就喺度待命，乜都唔做。
用vibe coding做過有啲複雜嘅項目嘅人應該明呢種感覺。你腦入面有個完整目標，但每次只能俾佢推進一小步，然後確認，再推進一小步。你唔係喺度創作，你係喺度督工。
4月30號，Simon Willison嘅博客提到Codex CLI 0.128.0新增嘅 /goal 功能。一條好短嘅更新，但我覺得呢個變化比表面睇嚟大好多。
具體係咩：你設定一個 /goal，Codex會進入一個自循環，持續評估任務完成未，未完成就繼續推落去，直到目標達到或者token預算用完。
用一句話講，就係佢自己會睇住目標轉圈，唔需要你喺旁邊一直催。
呢個模式有個名，叫Ralph Loop，目標驅動嘅自主循環。Codex將呢個概念正式實現咗。
「一問一答」同「自主完成」到底差喺邊
以前嘅Codex工作模式，用「一問一答」嚟形容好準確。
你問，佢答，交互結束。下一步點行，仍然係你決定。佢係個好好用嘅工具，但你要當佢係工具咁用，主動去用，唔用就擺喺度。
某程度上，同搜索引擎有啲似。你唔問，佢唔講。你問咩，佢答咩，唔多唔少。
/goal 之後，模式變咗。
你設定目標，佢自己判斷「目前進展到邊度」「仲差啲咩」「下一步做咩」。呢個循環佢自己行，唔係你推住佢行。
分別喺邊？在於邊個「持有任務」。
以前係你持有任務，Codex幫你執行某個具體步驟。你係項目經理，佢係執行層。每一步做完，控制權仲喺你手，下一步點行你話事。
而家Codex開始持有任務，你退到審核位置。佢去推進，遇到決策點再嚟問你，或者直接按自己判斷行落去。
呢個唔係小事。
將「持有任務」嘅角色交出去，需要兩件事：一係AI要真係有能力自主判斷下一步，二係你要願意放手。第一件事，/goal 循環提供咗基礎能力。第二件事，需要你適應一種新嘅工作方式。
OpenAI內部已經在用，PR交付量升咗5倍
呢個唔係停留喺功能介紹層面嘅事。有數據喺背後支撐。
OpenAI內部有一套叫Symphony嘅系統，工作原理同 /goal 循環類似，就係Agent自主完成任務嗰種模式。佢哋用咗呢套系統之後，工程團隊嘅PR交付量提升咗500%。
5倍。
呢個數字我第一次見到時有啲唔信。500%提升，太誇張啦。但再諗諗，都合理。
以前人寫code，大量時間花喺「記住任務狀態」「決定下一步做咩」「返去檢查之前嘅進展」呢啲事情上。呢啲工作本身唔產出code，但佔咗相當多精力。軟件工程師嘅一大塊工作，其實唔係喺度寫code，係喺度管理任務狀態。
如果Agent可以自己管呢個循環，工程師就只需要喺關鍵節點做判斷，實際產出量當然會向上。
/goal 功能就係將呢個邏輯帶到Codex CLI呢個層面。
仲有一個角度。以前嘅AI工具，你要搞清楚點樣問問題，先可以令佢俾出有用嘅輸出。「prompt engineering」呢門學問就係咁嚟。但循環式Agent唔同，佢嘅核心唔係一次性俾出好答案，而係持續評估目標達到未，然後調整策略繼續行。
呢兩種能力，底層邏輯其實好唔一樣。
用嘅人需要調整工作方式
如果你而家用緊Codex做vibe coding，/goal 值得認真試一試。
以前你可能習慣咗「睇實佢行」嘅工作方式，一步一確認，怕佢行錯。呢種習慣唔係冇道理，早期嘅AI編程工具確實需要咁用。行錯咗，你唔知，等到發現問題，前面做嘅嘢要全部推倒重來。
但工具喺變。
自循環能力實現之後，更好嘅工作方式可能係：將目標定清楚，然後俾佢去行，你去做第啲嘢，等佢俾你一個進展報告。
當然，「token預算用完」呢個兜底機制提醒我哋，佢未去到完全唔使理嘅程度。目標拆得太大，或者任務本身冇俾足夠嘅上下文，佢仍然會行錯或者卡住。自循環唔係無限循環，預算用完就會停。
所以真正要練嘅技能，由「點樣催住AI一步步行」變成「點樣將目標描述清楚、邊界定好」。
呢兩件事，表面上都係「同AI講嘢」，但思維模式好唔一樣。前者係喺度管執行，後者係喺度定方向。
前者你要識流程，後者你要識目標。
將目標講清楚，其實比催住行更難。但呢個都係值得花時間練嘅地方，因為呢個能力會一直有用，唔理工具點迭代。
數據來源：
Simon Willison博客，2026-04-30，「codex-goals」：https://simonwillison.net/2026/Apr/30/codex-goals/[1] OpenAI Symphony數據來自公開報道，具體數字以原始來源為準
引用連結
[1]https://simonwillison.net/2026/Apr/30/codex-goals/
像一個需要被不停催着走的實習生。
你得全程盯着，稍微走開一會兒，它就在那待命，什麼都不幹。
用 vibe coding 做過稍微複雜點的項目的人應該懂這種感覺。你腦子裏有個完整的目標，但每次只能給它推進一小步，然後確認，再推進一小步。你不是在創作，你是在督工。
4 月 30 日，Simon Willison 的博客提到了 Codex CLI 0.128.0 新增的 /goal 功能。一條很短的更新，但我覺得這個變化比看起來大多了。
具體是什麼：你設定一個 /goal，Codex 會進入一個自循環，持續評估任務有沒有完成，沒完成就繼續往下推，直到目標達成或 token 預算耗完。
用一句話說，就是它自己會盯着目標轉圈，不需要你在旁邊一直催。
這個模式有個名字，叫 Ralph Loop，目標驅動的自主循環。Codex 把這個概念正式落地了。
「一問一答」和「自主完成」到底差在哪
以前的 Codex 工作模式，用「一問一答」來形容很準確。
你問，它答，交互結束。下一步怎麼走，還是你決定。它是個很好用的工具，但你得把它當工具用，主動去用，不用就閒着。
某種程度上，這和搜索引擎有點像。你不問，它不說。你問什麼，它答什麼，不多也不少。
/goal 之後，模式變了。
你設定目標，它自己判斷「當前進展到哪了」「還差什麼」「接下來做什麼」。這個循環它自己走，不是你推着走。
區別在哪？在於誰在「持有任務」。
以前是你在持有任務，Codex 幫你執行某個具體步驟。你是項目經理，它是執行層。每一步做完，控制權還在你手裏，下一步怎麼走你說了算。
現在 Codex 開始持有任務了，你退到了審核位置。它去推進，遇到決策點再來問你，或者直接按自己的判斷走下去。
這不是小事。
把「持有任務」的角色交出去，需要兩件事：一是 AI 要真的有能力自主判斷下一步，二是你得願意放手。第一件事，/goal 循環提供了基礎能力。第二件事，需要你適應一種新的工作方式。
OpenAI 內部已經在用，PR 交付量漲了 5 倍
這不是停留在功能介紹層面的事。有數據在背後支撐。
OpenAI 內部有一套叫 Symphony 的系統，工作原理跟 /goal 循環類似，就是 Agent 自主完成任務的那種模式。他們用這套系統之後，工程團隊的 PR 交付量提升了 500%。
5 倍。
這個數字我第一次看到時有點不信。500% 提升，這太誇張了。但再想想，也合理。
以前人寫代碼，大量時間花在「記住任務狀態」「決定下一步做什麼」「回去檢查之前的進展」這些事情上。這些工作本身不產出代碼，但佔了相當多的精力。軟件工程師的一大塊工作，其實不是在寫代碼，是在管理任務狀態。
如果 Agent 能自己管這個循環，工程師就只需要在關鍵節點做判斷，實際產出量當然會往上走。
/goal 功能就是把這個邏輯帶到了 Codex CLI 這個層面。
還有一個角度。以前的 AI 工具，你得搞清楚怎麼問問題，才能讓它給出有用的輸出。「prompt engineering」這門學問就是這麼來的。但循環式 Agent 不一樣，它的核心不是一次性給出好答案，而是持續評估目標有沒有達成，然後調整策略繼續走。
這兩種能力，底層邏輯其實很不一樣。
用的人需要調整工作方式
如果你現在在用 Codex 做 vibe coding，/goal 值得認真試一試。
以前你可能習慣了「盯着它走」的工作方式，一步一確認，生怕它跑偏。這種習慣不是沒道理，早期的 AI 編程工具確實需要這樣用。跑偏了，你不知道，等發現問題，前面做的東西得全部推倒重來。
但工具在變。
自循環能力落地之後，更好的工作方式可能是：把目標定清楚，然後讓它去跑，你去做別的事，等它給你一個進展報告。
當然，「token 預算耗完」這個兜底機制提醒我們，它還沒到完全不用管的程度。目標拆得太大，或者任務本身沒給足夠的上下文，它還是會跑偏或者卡住。自循環不是無限循環，預算用完就停。
所以真正要練的技能，從「怎麼催着 AI 一步步走」變成了「怎麼把目標描述清楚、邊界定好」。
這兩件事，表面上都是「和 AI 說話」，但思維模式很不一樣。前者是在管執行，後者是在定方向。
前者你得懂流程，後者你得懂目標。
把目標說清楚，其實比催着走更難。但這也是值得花時間練的地方，因為這個能力會一直有用，不管工具怎麼迭代。
數據來源：
Simon Willison 博客，2026-04-30，「codex-goals」：https://simonwillison.net/2026/Apr/30/codex-goals/[1] OpenAI Symphony 數據來自公開報道，具體數字以原始來源為準
引用連結
[1]https://simonwillison.net/2026/Apr/30/codex-goals/