Codex Goals：給它目標，讓 Codex 追逐你的目標直到停下
把時間撥回上個月
當時我習慣性的開發一個小工具想讓自己的生活更好
我打開 Codex 桌面 App，透過語音輸入闡述需求、用文字建構起了 AI 對產品的想像，並按下送出。喝杯咖啡，游個泳，讓 AI 完全 handle 一切。
回來的時候 Codex 已經跑完了。PR 開好、code 看起來很完整、commit message 寫得漂漂亮亮。我心想——這次應該一次到位了吧。
結果出乎意料地糟。
我自己起本機 dev server、點開瀏覽器——按鈕點下去沒反應。打開 console 一看、Supabase 連線字串放錯位置；切到表單頁面、送出後直接報 500；最神奇的是首頁載完之後、整個畫面是白的、需要手動 refresh 一次才會出現。Codex 寫完是真的「寫完」、但「能用」這件事跟它一點關係都沒有。
我那個下午又跑了三輪「叫 Codex 修 → 自己驗 → 又找到新 bug → 再叫它修」的循環、總共燒掉 4 個小時。
那天我關掉筆電之前在心裡記了一句：「這條工作流壞掉了。寫程式不是 AI 卡住的地方、QA 才是。」
而兩個月後的這禮拜——OpenAI 把這條 QA loop 直接做進 Codex 裡。它叫 Goals（目標） 。顧名思義，一但開啟後，Codex 會自主判斷你給他的目標是否達成
- 任務：寫完就停
- 目標：達成才停
這篇我會把 Goals 拆給你看：它跟普通 Codex 任務差在哪、為什麼這個改變比看起來大、我自己用它跑出來的真實案例、一份你可以直接複製的 Goal prompt 範本、還有 3 個容易讓你翻車的雷點。讓我們開始吧。
1. Goals 是什麼？從實驗模式正式上線的轉折
Goals 是 Codex 桌面 App 裡新的執行模式。
它不是「更會寫程式的 Codex」、不是「更強的 prompt 模板」、也不是「多了一顆按鈕」——它是一個完全不同的執行邏輯。差別關鍵在「停下來的條件」。
過去你跟 Codex 互動是「指令式」——你下一條指令、它做一件事、停。「幫我寫一個登入頁」→ Codex 寫完、給你 PR、停。至於那個登入頁能不能用、密碼錯誤會不會顯示錯誤訊息、登入成功會不會跳轉、滾動會不會卡——Codex 不管。你自己打開瀏覽器、自己點、自己發現 bug、再回頭叫它修。整套流程跟兩年前的 GitHub Copilot 本質上沒差多少、只是寫得更多更快。
Goals 是「目標式」——你描述「我想達成什麼樣的狀態」、Codex 自己拆任務、自己執行、自己驗證、只在「達成」或「徹底做不到」時才停。中間整段 QA loop 由 Codex 自己跑、你不用催、不用回。
為什麼這個切換很大？因為它把工程師工作裡最痛、也最沒成就感的那一段——「寫完之後一直跑、一直測、發現問題、回去改」——從你身上接走了。
這條最早是 Experiments 分頁裡的實驗功能、藏得很深、要自己手動 enable。本週起 OpenAI 把它從實驗轉正式版、所有 Codex 用戶打開桌面 App 直接看得到——不用切 flag、不用 join waitlist。
兩種模式並排對照看會更清楚：
| 普通 Task | Goals | |
|---|---|---|
| 你給的東西 | 指令（do X） | 目標（reach state Y） |
| Codex 做的事 | 執行一次 | 執行 + 驗證 + 修正、循環 |
| 停下來的條件 | 寫完 | 目標達成（或徹底失敗） |
| 你要做的 | 自己驗證 | 基本上不用 |
| 適合場景 | 單一動作、補丁 | 多步驟、需驗證的功能 |
讀到這你可能會覺得「這不就是 agent 應該有的能力嗎？」——對。但能講出來跟能做出來、是兩件完全不同的事。下一節我們講這個。
2. 為什麼這條改變、比看起來大很多
過去半年所有 agent 工具都在喊「自主任務執行」「閉環迭代」「self-correcting」——但你只要真的試一輪、就會發現所有產品都卡在同樣 3 個地方：
第一個卡點：它不知道什麼算「完成」。
你叫它「做一個登入頁」、它寫了一個 <form> 跟 submit handler 就回報「done」。但你 spec 裡那條「密碼錯誤要顯示紅字提示」呢？「第三次輸錯要 lock 30 秒」呢？這些它都沒做、但也沒回報沒做、就只是「寫完了」。原因不是它笨——是它沒有 acceptance criteria。沒有清楚的「達成」定義、它就用「code 寫得出來」當完成標準。
第二個卡點：它不會自己跑 QA loop。
agent 寫完 code、遇到 bug 它會做什麼？把 error message 丟回來給你、然後等。它不會自己起 dev server、不會自己跑 test suite、不會自己用瀏覽器去點按鈕看 UI 對不對。整個「驗證」環節它沒做、所以「修正」這條 loop 它根本起不來。
第三個卡點：它沒有 stopping criterion。
你要它跑 5 個 iteration 還是 50 個？它自己也不知道。所以 agent 工具的選項通常是兩個極端：要嘛跑一次就停（典型 Codex Task 模式）、要嘛無止盡 loop 直到燒爆你 token（早期 AutoGPT 那種）。中間那個「達成就停、做不到就停、其他時候不停」的甜蜜點、過去沒人做出來。
Goals 的價值、剛好在於把這三件事系統化解決：
- 明確的 acceptance criteria：你在 goal 裡寫「達成條件」、Codex 知道什麼算完成
- 內建 QA loop：寫完就跑、跑不過就改、改完再跑——這套循環內建在 Goals 的執行邏輯裡
- 自然 stopping criterion：達成條件清楚 = 滿足條件就停、徹底卡關也停、剩下時候不停
這意味著什麼？實質上、它把一個工程師「拿到任務 → 做完 → QA 通過 → 交付」的完整流程、變成 Codex 自己會跑的閉環。過去是 AI 寫程式、人 QA；現在是 AI 寫程式、AI QA、人最後驗收。
但 Goals 單獨用、其實還沒到完整實力。它真正展現威力的時刻、是配上另一個外掛——下一節講這個。
3. 我的真實使用情境：Goals + Computer Use = 自動開發 + 自動測試
理論講完、講我自己每天怎麼用。
Goals 單獨開、已經很強——它能跑 test suite、能 check console error、能 grep 自己寫的 code 找漏洞。但這些都是「code 層級的驗證」。真正讓我每天都在用的、是再配上 Computer Use 外掛。
什麼是 Computer Use？簡單講：OpenAI 給 Codex 一個「能操控你的 Mac」的能力。它能打開瀏覽器、能點按鈕、能填表單、能截圖、能讀畫面上的字。
把 Goals + Computer Use 接起來、會發生什麼？Codex 不只會寫 code、它會打開瀏覽器、用真的滑鼠點過你 spec 裡寫的每一個 user journey 步驟、驗證 UI 真的跑得起來。
這個組合的意義是什麼？它把「前端工程師的整個 development + manual QA 流程」變成 Codex 自己會跑的閉環。寫程式 → 起 server → 開瀏覽器 → 點過 user journey → 發現 bug → 改 → 重跑——全部由 Codex 跑、你只負責最後驗收。
我自己的標準工作流是這樣的——四步、每步都有具體動作：
Step 1：先裝好 Computer Use 外掛
打開 Codex 桌面 App、左下角點「外掛程式」、找到 Computer Use、按啟用。
啟用之後 macOS 會跳一個系統權限視窗、要你授權「控制你的電腦」——這是 macOS 的安全機制、不給授權 Computer Use 就跑不起來。授權完之後回 Codex App 看 Computer Use 那一列、應該顯示「已連接」綠燈。
這步 5 分鐘搞定。前篇 Codex 完整入門 有完整截圖教學、忘了在哪可以回去翻。
Step 2：寫一份結構化的 Goal
這步是整套工作流的關鍵。
不是「做一個登入頁」這種模糊指令、是這樣的結構化 prompt：
【目標】做什麼產品 / 解決什麼問題
【需求】功能規格、技術限制
【使用者旅程】從使用者第一次接觸到完成核心動作的完整 flow
【驗證條件】開發完成後，請你用 Computer Use 跑完整個 user journey 做測試，
全部通過才算達成。
關鍵在最後那段——「請你開發完畢後一定要用 Computer Use 針對整個使用者旅程做測試」。這句話不能省。
為什麼？因為如果你只寫前 3 段、Codex 預設會走「Task 模式」的習慣——寫完就停。你要明確告訴它「驗證也是任務的一部分」、它才會把 Computer Use 拉進閉環。
完整範本下一節給。
Step 3：放手讓它跑
按下執行、關掉 Codex 視窗、去做別的事——重點是真的離開。
不要待在電腦前看著它跑。一來你會忍不住手動干預、二來 Computer Use 跑 user journey 的時候會佔用你滑鼠跟鍵盤、你也沒法用電腦。我自己現在的習慣是丟給 Codex 之後直接出門走 20 分鐘、回來剛好看結果。
那 20 分鐘 Codex 在做什麼？
- 讀你的 goal、拆成 5-15 個子任務
- 寫第一版 code、commit
- 自己起本機 dev server（npm run dev 之類）
- 用 Computer Use 打開 Chrome、跑使用者旅程 U1 → U5
- 發現 bug → 寫進自己的 working notes → 改 code → 再跑一次完整 user journey
- 重複直到整個 journey 跑得通、且沒有 console error
跑完它回報「達成」、附完整測試 evidence——使用者旅程每一步的截圖、執行 log、覆蓋的步驟列表。你打開的不是「半成品 PR」、是「完成 + QA 通過 + 有 evidence」的成果。
Step 4：你只做最後審美與商業判斷
Codex 跑完、你的工作只剩兩件：
- 看起來對嗎？——品味、視覺、文案這些「沒辦法量化驗收」的東西、AI 還做不到
- 業務邏輯對嗎？——「這個 flow 真的解決了我說的問題嗎」、這需要你的領域判斷
剩下的「寫程式 + 起 server + 跑 user journey + 修 bug + 再測」這個傳統開發 + 手動 QA 循環、完全被 Codex 吞下去。
差別在哪？前面講過的那個「每日學習打卡網站」——兩個月前我用普通 Task 模式跑、加上自己手動 QA 跟修 bug、總共 4 個小時。這禮拜我用 Goals + Computer Use 重跑一次同樣的 spec、26 分鐘交付、我只審美 + 改了 2 行文案就上線。差距大約 9 倍。
工作流講完。但你寫不好 Goal、整套工作流的效果會打 5 折——所以下一節我把我自己每天都在用的 prompt 範本完整貼出來。
4. 完整 Goal Prompt 範本（可直接複製、把 <> 換成你的內容）
我自己跑了大概 30 個 Goal 之後、慢慢收斂出下面這份結構。每一個欄位都有它的理由、不要刪：
【目標】
我要做一個 <產品名稱>。它解決的問題是 <你想解決的痛點>。
核心使用者是 <誰>，他們會用這個產品做 <什麼>。
【需求】
- 技術棧：<例如 Next.js + Tailwind + Supabase>
- 必要功能：
1. <功能 1>
2. <功能 2>
3. <功能 3>
- 風格要求：<極簡、Apple 風、商業感、復古...>
- 限制：<不要用 X library、避免 Y 模式...>
【使用者旅程（U1 → U5）】
U1. 使用者打開首頁、看到 <X>
U2. 使用者點 <某按鈕>、進入 <某頁>
U3. 使用者輸入 <某資料>、提交
U4. 系統處理、顯示 <某結果>
U5. 使用者完成核心動作、看到 <成功狀態>
【驗證條件 - 重要】
請你開發完畢後，一定要用 Computer Use 跑完整個使用者旅程做測試：
- 打開本機 dev server
- 依序執行 U1 到 U5 的每一步
- 每步驗證 UI 顯示符合預期
- 任何一步失敗就修、修完重新跑完整 journey
- 整個 journey 完整跑過、無 console error、視覺符合 spec、才算達成
【交付】
達成後請給我：
1. 完整 user journey 跑通的截圖證據
2. 重要架構決策說明
3. 知道但沒解決的限制（如果有）
每個區段都有它的功能、我拆給你看：
【目標】——告訴 Codex「為什麼存在」。這段它不會直接用來寫 code、但會影響它的所有取捨。例如「核心使用者是不擅長打字的長輩」、Codex 會自動把字體放大、按鈕放大、減少 input field。沒有這段、它預設工程師審美。
【需求】——具體可數的清單。「3 個必要功能」比「完整的 dashboard」可驗證 100 倍。
【使用者旅程】——這段是 Goals 跟 Task 最大的差別。Task 不需要 user journey、Goals 沒有 user journey 跑不起 Computer Use 驗證。U1 → U5 用編號是因為 Codex 會在 log 裡明確標「U3 失敗、重試」、你後面 debug 看得到對應。
【驗證條件】——必須明確寫「用 Computer Use 跑」「全部通過才算達成」。這兩句話是觸發 Goals 閉環的開關、不能省。
【交付】——指定它回報什麼。「截圖證據」這條一定要寫、不然它會用文字描述「測試通過」打發你、根本沒跑。
寫好的 Goal 跟寫差的 Goal、跑出來的成品差 10 倍。重點不是長度——是「達成條件夠清楚、Codex 知道什麼時候該停」。我自己丟過最短的 Goal 大約 150 字、最長 800 字、跑出來品質跟長度幾乎沒關係、跟「結構清不清楚」高度相關。
prompt 範本講完。但 Goals 不是無敵——它有 3 個我自己踩過的坑、下一節先讓你看一遍、避免你也跌進去。
5. 3 個容易讓你翻車的雷點
天下沒有完美工具。Goals 也一樣。
我自己跑了兩個月、踩過大大小小至少 15 個坑、其中 3 個是「新手第一次用 Goals 一定會撞、撞完一次以後就學乖」的高頻雷點。提前講給你聽。
雷 1：目標太模糊、Codex 永遠跑不完
「做一個好用的 dashboard」——「好用」是什麼？什麼算完成？
Codex 拿到這種 Goal、會無止盡迭代——改 UI、改 layout、改字、改顏色、再 user journey 跑一次、覺得「還不夠好用」、再改一輪。我看過一個極端案例、跑了 45 分鐘還停不下來、最後是配額撞牆它才被迫停下。
這意味著什麼？——Goals 的閉環依賴清楚的 acceptance criteria。沒有 criteria、Codex 就用「主觀判斷」當標準、而主觀判斷沒有底——它永遠覺得還能更好。
解法：把「好用」展開成具體的 user journey + 視覺 spec。「U3 提交表單後、3 秒內看到 toast 通知顯示 Saved」比「操作要順」可驗證 100 倍。記住一條 mantra：「如果你自己也說不清楚什麼算完成、Codex 更說不清楚」。
雷 2：忘了給 Computer Use 授權
Computer Use 第一次跑、macOS 會跳系統權限視窗要你授權「控制你的電腦」。如果你那當下沒注意、按了取消——Codex 跑到 user journey 那步會直接卡住、回報「無法操控瀏覽器」、然後重試 3 次、再失敗、最後標記 Goal 失敗。
為什麼會這樣？——macOS 的安全機制不會主動再彈一次權限請求、得你自己去「系統設定 → 隱私權與安全性 → 輔助使用」手動勾。如果你不知道這條、你會花 20 分鐘怎麼想都想不通為什麼 Computer Use 跑不起來。
解法：第一次跑 Goal 前先打開 Codex 桌面 App、左下角「外掛程式」分頁、確認 Computer Use 那一列顯示「已連接」綠燈。沒綠燈就點進去重跑授權流程。這 30 秒檢查、能幫你省 20 分鐘 debug 時間。
雷 3：複雜任務還是要拆
Goals 強的是「達成才停」的閉環。但它沒辦法把超複雜任務變簡單。
「做一個 Notion」——這種規模的任務丟給 Goals、它會嘗試、會迭代、會看起來在前進、但實際上跑出來的東西架構會散、code base 會越長越亂、最後 user journey 卡在某個複雜互動上跑不動。
為什麼？——Goals 是 single-shot loop、它沒有「先 design 整體架構、再分模組實作」的能力。超過 3000-5000 行 code 規模、單一 Goal 就 hold 不住。前面 Codex 入門那篇有講過這條 ceiling、Goals 也沒突破它。
解法：複雜任務先用 Plan Mode 把整個系統拆成 5-10 個 sub-goal、每個 sub-goal 是「1500 行 code 內可獨立驗證」的單元、分開派出去跑。Goals 是放大器、不是萬靈丹——它讓你的小任務 9 倍效率、但解不開你架構層面的複雜度。
3 個雷講完、剩下的小坑你自己撞一次就知道。下一節是行動段——你今天可以做的事。
6. 你今天就能做的 3 件事
不要把這篇收藏完就關掉。
30 分鐘內做這 3 件事：
- 打開 Codex 桌面 App 設定——看主功能列裡是否有 Goals 模式。本週起所有用戶都看得到、不用切 flag
- 裝好 Computer Use 外掛——5 分鐘、前篇 Codex 入門有完整截圖教學
- 挑一個你今天想做但懶得寫的小工具——例如「我想要一個記錄每天運動量的小網頁」「幫我做一個 markdown 轉 PDF 的小工具」——用上面的 Goal 範本寫一份、貼進去執行、去喝杯咖啡
20-30 分鐘後回來、你會看到一份寫完 + 測試通過 + 有 evidence的成果。
那個感受很爽——爽到你以後派任務給 Codex 都會自動用 Goals、回不去普通 Task 模式。
常見問題
Q：Goals 要付費嗎？
A：不要。它包在你已經付的 ChatGPT Plus / Pro / Business 訂閱裡——Codex 本身吃哪個 tier、Goals 就吃哪個 tier。邊際成本是 0。
Q：Goals 用的 token 會比普通 task 多嗎？
A：會、而且明顯比較多。因為它要跑 N 輪迭代直到達成、每輪都吃 token。Plus 用戶實測：複雜 Goal 可能跑 20-30 分鐘、用掉一個下午大約 5-8% 的 5 小時窗配額。對 Plus 用戶（基本不撞上限）來說可接受、對只買 Free tier 的會撞牆。
Q：Goals 跟 Claude Code 的 Ralph Loop 差在哪？
A：底層概念類似——「達成才停」。差別在 Ralph Loop 是 Anthropic 給工程師的設計模式（要自己寫 bash 配 progress.md 配 hook）、Goals 是 OpenAI 把這個概念做成 UI 內建模式——你不用寫 code、直接在桌面 App 描述目標就跑。一個是「工程師組件」、一個是「消費級產品」。
Q：失敗了會怎樣？會不會無止盡跑下去燒我 token？
A：Codex 在嘗試大約 N 輪後判斷「真的做不到」會主動回報失敗 + 卡關理由（例如「無法操控某個 element」「第三方 API 持續報錯」「spec 內部矛盾」）。它不會無止盡跑下去燒你 token——OpenAI 內建了 stopping criterion 防呆。
Q：可以叫 Goals 寫超複雜系統嗎？
A：可以但有 ceiling。超過 3000-5000 行 code 規模的系統建議先用 Plan Mode 拆 sub-goal。Goals 是好的「閉環機制」、不能取代你的系統設計。
Q：跟普通 Task 模式差在哪？
A：普通 Task 是「寫 → 停」、Goals 是「寫 → 測 → 改 → 測 → ... → 達成」。對「我要可用的成品、不要 PR 等我自己測」的場景、Goals 完勝。對「幫我補一行 bugfix」「幫我把這個 function 改名」這種小任務、用 Task 模式更輕。
延伸資源
- Codex 桌面 App 官網
- 前篇延伸閱讀：
- OpenAI Codex 完整入門——沒玩過 Codex 的先看這篇
- Harness Engineering：做 AI 產品工程師必須得知道的新技能——Goals 是 5 維度裡「驗證」+「編排」的 OpenAI 官方解法