Codex Goals：給它目標、它測完才停——OpenAI 最新功能完整實戰
Codex Goals：給它目標、它測完才停——OpenAI 最新功能完整實戰
過去你叫 Codex 做事，是這樣的：
「幫我寫一個登入頁。」→ Codex 寫完、給你 PR、停。
至於那個登入頁到底能不能用？密碼錯誤會不會顯示錯誤訊息？登入成功會不會跳轉？滾動會不會卡？——Codex 不會幫你測。你自己打開瀏覽器、自己點、自己發現一堆 bug、再回頭叫它修。
最近這條變了。OpenAI 的 Goals 功能從實驗模式正式上線——你不再給「任務」，你給「目標」。差別是：
- 任務：寫完就停
- 目標：達成才停
它會自己寫、自己跑、自己測、自己修——直到你給的目標真的被達成。中間不需要你催。配上 Computer Use 外掛，它甚至會自己開瀏覽器、自己點按鈕、自己驗證使用者旅程。
這篇我會講清楚：Goals 跟普通 Codex 任務差在哪、為什麼這個改變比看起來大、我自己用它跑出來的真實案例、以及一份你可以直接複製的 Goal prompt 範本。讓我們開始吧。
1. Goals 是什麼？從實驗到正式版的轉折
Goals 是 Codex 桌面 App 裡新的執行模式。它不是「更強的 prompt」，是完全不同的執行邏輯。
過去你跟 Codex 互動是「指令式」——你下一條指令、它做一件事、停。
Goals 是「目標式」——你描述「我想達成什麼樣的狀態」，Codex 自己拆任務、自己執行、自己驗證，只在「達成」或「完全做不到」時才停下來。
這條最早是實驗功能、藏在 Codex App 設定的「Experiments」分頁裡。最近從實驗轉正式版、現在所有 Codex 用戶都能直接打開用。
對照來看：
| 普通 Task | Goals | |
|---|---|---|
| 你給的東西 | 指令（do X） | 目標（reach state Y） |
| Codex 做的事 | 執行一次 | 執行 + 驗證 + 修正、循環 |
| 停下來的條件 | 寫完 | 目標達成（或徹底失敗） |
| 你要做的 | 自己驗證 | 基本上不用 |
| 適合場景 | 單一動作 | 多步驟、需驗證的功能 |
2. 為什麼這條改變比看起來大
讀到這你可能會想「這不就是 agent 應該有的能力嗎？」——對，但實際做出來跟講得出來是兩件事。
過去半年所有 agent 工具都在喊「自主任務執行」、但真的試下去你會發現：
- 它不知道什麼算「完成」——寫了一個 function 就回報「done」，但你 spec 裡的 edge case 它根本沒測
- 它不會循環修錯——遇到 bug 它報給你、等你回應；不會自己跑測試發現問題、自己改
- 它沒有清楚的 stopping criterion——你要它跑 5 個 iteration 還是 50 個？它自己也不知道
Goals 的價值在於把這三件事系統化解決：
- 你在 goal 裡明確寫「達成條件」（acceptance criteria）——Codex 知道什麼算完成
- 內建驗證循環——它寫完就跑測試、跑不過就改、改完再測
- 達成條件清楚 = 自然有 stopping criterion——滿足條件就停
實質上：它把一個工程師「拿到任務 → 做完 → QA 通過 → 交付」的完整流程，變成 Codex 自己會跑的閉環。
3. 我的真實使用情境：Goals + Computer Use = 自動開發 + 自動測試
理論講完，講我自己每天怎麼用。
Goals 單獨用已經很強。但配上 Computer Use 外掛——Codex 能操控你的 Mac、開瀏覽器、點按鈕、驗證 UI——這個組合變成「自動開發 + 自動 user journey 測試」的閉環。
我的標準工作流是這樣：
Step 1：先裝好 Computer Use 外掛
在 Codex 桌面 App 的「外掛程式」分頁找到 Computer Use、啟用、授權 Mac 控制權限。（前篇 Codex 完整入門有完整截圖教學。）
Step 2：給 Codex 一個結構化的 Goal
不是「做一個登入頁」這種模糊指令。是這樣的結構：
【目標】做什麼產品 / 解決什麼問題
【需求】功能規格、技術限制
【使用者旅程】從使用者第一次接觸到完成核心動作的完整 flow
【驗證條件】開發完成後，請你用 Computer Use 跑完整個 user journey 做測試，
全部通過才算達成。
關鍵在最後那行——「請你開發完畢後一定要用 Computer Use 針對整個使用者旅程做測試」。
Step 3：放手讓它跑
按下執行、然後去做別的事。Codex 會：
- 讀你的 goal、拆成子任務
- 寫第一版 code
- 自己起本機 dev server
- 用 Computer Use 打開瀏覽器、跑使用者旅程
- 發現 bug → 自己改 → 再跑一次 user journey
- 重複直到整個 journey 跑得通
跑完它回報「達成」、附完整測試 evidence——截圖、log、覆蓋的 user journey 步驟。你打開直接驗收。
Step 4：你只做最後審美與商業判斷
Codex 跑完，你的工作只剩兩件：
- 看起來對嗎？品味、視覺、文案——這些 AI 還做不到的
- 業務邏輯對嗎？「這個 flow 真的解決了我說的問題嗎」——這需要你的領域判斷
剩下的「寫程式 + 跑測試 + 修 bug + 再測」這個傳統開發循環，完全被 Codex 吞下去。
4. 完整 Goal Prompt 範本（可直接複製）
下面這份是我自己每次跑都會用的結構。複製、把 <> 換成你的內容、貼進 Codex：
【目標】
我要做一個 <產品名稱>。它解決的問題是 <你想解決的痛點>。
核心使用者是 <誰>，他們會用這個產品做 <什麼>。
【需求】
- 技術棧：<例如 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. 知道但沒解決的限制（如果有）
寫好的 Goal 跟寫差的 Goal、跑出來的成品差 10 倍。重點不是長度——是「達成條件夠清楚、Codex 知道什麼時候該停」。
5. 3 個容易踩的坑
天下沒有完美工具。
坑 1：目標太模糊、Codex 永遠跑不完
「做一個好用的 dashboard」——「好用」是什麼？什麼算完成？Codex 會無止盡迭代、改 UI、改字、永遠不停。
解法：把「好用」展開成具體的 user journey + 視覺 spec。「U3 提交表單後、3 秒內看到 toast 通知」 比「操作要順」可驗證 100 倍。
坑 2：忘了給 Computer Use 授權
Computer Use 第一次跑要授權 Mac 的「控制你的電腦」權限。Codex 如果沒拿到授權、它跑 user journey 那步會卡住、回報「無法操控瀏覽器」。
解法：第一次跑前先打開 Codex 桌面 App、確認 Computer Use 外掛「已連接」。
坑 3：複雜任務還是要拆
Goals 強的是「達成才停」的閉環。但它沒辦法把超複雜任務變簡單——「做一個 Notion」這種規模、Goals 也會翻車（前面 Codex 入門那篇有講過）。
解法：複雜任務先用 Plan Mode 拆成幾個 sub-goal，每個 sub-goal 分開派出去。Goals 是放大器、不是萬靈丹。
6. 你今天就能做的事
不要把這篇收藏完就關掉。30 分鐘內做這 3 件事：
- 打開 Codex 桌面 App 設定——看「Experiments」或主功能列裡是否有 Goals 模式。已經正式上線、應該直接看得到
- 裝好 Computer Use 外掛——5 分鐘、前篇 Codex 入門有完整教學
- 挑一個你今天想做但懶得寫的小工具——例如「我想要一個記錄每天運動量的小網頁」——用上面的 Goal 範本寫一份、貼進去執行、去喝杯咖啡
回來時你會看到一份寫完 + 測試通過 + 有 evidence的成果。
那個感受很爽。爽到你以後派任務給 Codex 都會用 Goals。
常見問題
Q：Goals 要付費嗎？
A：不要。它包在你已經付的 ChatGPT Plus / Pro / Business 訂閱裡——Codex 本身吃哪個 tier、Goals 就吃哪個 tier。邊際成本是 0。
Q：Goals 用的 token 會比普通 task 多嗎？
A：會。因為它要跑 N 輪迭代直到達成、每輪都吃 token。Plus 用戶實測：複雜 Goal 可能跑 10-20 分鐘、用掉一個下午 ~5% 的 5 小時窗配額。對 Plus 用戶（基本不撞上限）來說可接受。
Q：Goals 跟 Claude Code 的 Ralph Loop 差在哪？
A：底層概念類似——「達成才停」。差別在 Ralph Loop 是 Anthropic 給工程師的設計模式（要自己寫 bash 配 progress.md），Goals 是 OpenAI 把這個概念做成 UI 內建模式——你不用寫 code、直接在桌面 App 描述目標就跑。
Q：失敗了會怎樣？
A：Codex 在嘗試 N 輪後判斷「真的做不到」會回報失敗 + 卡關理由（例如「無法操控某個 element / 第三方 API 持續報錯 / spec 內部矛盾」）。它不會無止盡跑下去燒你 token。
Q：可以叫 Goals 寫超複雜系統嗎？
A：可以但有 ceiling。超過 3000-5000 行 code 規模的系統建議先用 Plan Mode 拆 sub-goal。Goals 是好的「閉環機制」、不能取代你的系統設計。
Q：跟普通 Task 模式差在哪？
A：普通 Task 是「寫 → 停」、Goals 是「寫 → 測 → 改 → 測 → ... → 達成」。對「我要可用的成品、不要 PR 等我自己測」的場景、Goals 完勝。
延伸資源
- Codex 桌面 App 官網
- 前篇延伸閱讀：
- OpenAI Codex 完整入門——沒玩過 Codex 的先看這篇
- Harness Engineering：做 AI 產品工程師必須得知道的新技能——Goals 是 5 維度裡「驗證」+「編排」的 OpenAI 官方解法