/goal 理論和實踐全解 - 讓 Codex 和 Claude Code 連續跑數小時直到完成目標的自主任務模式怎麼用好？

作者：AI 啓蒙小夥伴
日期：2026年5月13日 上午8:06
來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點 高亮

AI自主循環模式/gool全解：Codex同Claude Code點樣連續數小時唔使理人

整理版摘要

呢篇文章係由作者整理OpenAI Codex同Anthropic Claude Code推出嘅/gool功能，比較兩種實現嘅差異，並結合理論同實戰經驗，教人點樣用好呢個自主循環模式。作者本身係AI工具重度用家，透過親身試驗同跟進官方文檔，歸納出一套「目標契約」方法論，解決AI長跑任務中「點知佢做完」「點樣唔使逐輪睇」嘅痛點。整體結論係：/gool唔係偷懶快捷鍵，而係逼人喺起跑前諗清楚「咩叫完成」嘅協作契約，滿足三個原則——目標可度量、驗證可執行、狀態可外化——先至發揮到最大威力。

文章先介紹OpenAI Codex點樣定義/gool，強調契約思維同六步法設定循環；再講Claude Code嘅獨立評估器設計，點樣用小型模型去判斷完成條件，避免自我評分偏差。然後詳列兩者喺評估機制、控制命令、適合場景等維度嘅差異，指出共同點遠大於分歧。

最後，作者用OpenAI工程師Chris Hayduk嘅實戰案例，說明點樣將模糊目標拆成可勾選checklist、壓縮單輪反饋時間、同埋用三份Markdown文件外化狀態，先至令到循環穩定跑數小時唔走樣。文章結尾仲提供一條自查清單，幫讀者確認自己準備好先好落指令。

  • /goal令AI自主循環數小時完成任務，但必須事先定義清楚完成條件，否則會過早放棄或永不收斂
  • Codex採用「契約思維」，要求明確回答「達成咩」、「唔改得咩」、「點驗證」、「幾時停」四個問題
  • Claude Code用獨立小型模型做評估，避免AI自己評自己，條件必須係AI輸出可證明嘅嘢，例如測試結果或檔案數量
  • 實戰關鍵：將大目標拆成逐項checklist（如200項格式規則）、壓縮每輪反饋時間（如用小型數據集）、將思考狀態外化到文件系統
  • 落地三原則：目標可度量、驗證可執行、狀態可外化；滿足呢三條先好打/gool，否則寧願唔用
整理重點

背景：點解兩個頂級AI團隊同時揀咗/gool

OpenAI Codex同Anthropic Claude Code最近都推出咗/gool功能，允許AI自主循環直至達成目標，中間唔需要人介入。呢個方向代表住完全自主Agent嘅趨勢，兩種實現雖然細節唔同，但核心理念一致：執行→驗證→判斷，直到停。

OpenAI同Anthropic兩個最頂級AI團隊又一次同時選擇咗/gool

作者認為，呢個功能唔係畀你偷懶唔打字，而係將你從「逐輪審閲」解放出嚟，但要你喺起跑前諗清楚「乜嘢叫做完成」。

整理重點

Codex /goal：契約式長跑任務

Codex嘅/gool係實驗性功能，要手動開啓。佢嘅定位好清晰：比單個prompt大，但比開放式backlog細。適合做代碼遷移、大型重構、原型創建呢類有明確範圍嘅任務。

  1. 1 命名一個目標同停止條件
  2. 2 指明Codex必須先讀邊啲文件（文檔、issue、日誌）
  3. 3 定義證明的命令或產物（例如跑測試）
  4. 4 要求按checkpoint工作，並寫簡短進度日誌
  5. 5 用/gool檢查運行狀態
  6. 6 完成、阻塞或方向變更時用pause/resume/clear控制

作者舉咗三類典型案例：代碼遷移（遊戲、app）、原型創建（新應用、新遊戲）、prompt優化（基於eval套件迭代）。重點係要將「整體合規」拆成「逐項勾選」，令到驗證變得客觀。

整理重點

Claude Code /goal：可驗證嘅完成條件

Claude Code嘅/gool用一個獨立嘅小型模型（默認Haiku）做評估，每輪結束後判斷條件係咪滿足。呢個設計避免咗「自己評自己」嘅偏差，同時確保條件可以用AI輸出證明。

執行模型同評判模型分離——避免自我評估偏差

  1. 1 一個可度量嘅終止狀態：測試結果、構建退出碼、文件數量、空隊列
  2. 2 明確嘅證明方式：例如npm test退出碼為0、git status clean
  3. 3 過程中不可違反嘅約束：例如「唔修改其他測試文件」
  4. 4 可加兜底子句，例如「或喺20輪後停止」，防止無限循環

同Codex唔同，Claude Code嘅/gool冇pause/resume，只有clear（同義詞多）。佢可以無頭運行，用claude -p命令直接設定條件，適合自動化場景。成本方面，評估器用細模型，開銷幾乎可忽略。

整理重點

Codex vs Claude Code /goal 差異對比

  • 評估機制：Codex無公開細節，強調「合理確信」；Claude Code用獨立小模型+Stop hook，透明可控
  • 控制命令：Codex有pause/resume，Claude Code只有clear加多種別名
  • 文檔側重：Codex強調契約思維、checkpoint、長時間獨立運行；Claude Code強調評估器架構、可恢復、headless
  • 上限/邊界：Codex建議用PLAN.md引導；Claude Code單條件4000字符，可加輪數兜底
  • 典型案例：Codex列舉遷移、原型、prompt優化；Claude Code列舉測試通過、規格落地、隊列清空

共同點遠大於差異：兩者都係同一抽象——帶終止條件嘅自主循環。選擇邊個主要睇你係咪需要pause/resume，同埋評估機制透明度嘅偏好。

整理重點

Chris Hayduk 嘅實戰經驗：點樣唔翻車

OpenAI工程師Chris Hayduk喺Codex內部大量使用/gool，沉澱出一套方法論。佢嘅核心洞察係：將「模糊願望」拆成「可驗證條件」，係連接人同AI嘅關鍵橋樑。

第二個案例係蛋白質結構模型，完整訓練要數天。佢用NanoFold小型數據集將單輪評分耗時壓縮到幾分鐘，令到循環可以快速迭代。反饋迴路越緊，效果越好。

  • 模糊指令「令我的代碼變好」：過早放棄或永不停止
  • 改寫「將特定文件嘅運行時間減少20%，且不引入測試迴歸」：量化指標+約束條件

Chris仲推薦用三份Markdown文件外化狀態：PLAN.md（高層計劃）、EXPERIMENTS.md（結構化嘗試記錄）、EXPERIMENT_NOTES.md（實時草稿）。其中EXPERIMENTS.md最重要，可以防止長循環中重複行同一條死路。

EXPERIMENTS.md係最關鍵嘅：記錄試過乜、結果點樣，令到人同AI都覆盤到

最後總結落地三原則：目標可度量、驗證可執行、狀態可外化。滿足呢三條，/goal就可以穩定跑數小時甚至數天；唔滿足，循環只會失敗。

OpenAI Codex 前幾日推出咗 /goal，令 Codex 自己循環幾個鐘直到達成目標，中間完全唔停唔需要人插手，好多朋友包括我自己都試緊，臨瞓前將複雜任務交畀 /goal，瞓醒發現任務居然真係順利同正確咁完成咗！

https://developers.openai.com/codex/use-cases/follow-goals

而一直被認為係 Coding Agent 標杆嘅 Claude Code 都緊隨其後推出咗 /goal！

https://code.claude.com/docs/en/goal

OpenAI 和 Anthropic 兩個最頂級 AI 團隊同最強競爭對手，又一次同時揀咗 /goal，呢個完全自主 Agent 方向，今日我哋一齊睇嚇佢哋對 /goal 嘅唔同定義同最佳實踐。

  1. Codex 官方對 /goal 嘅定義同用法
  2. Claude Code 官方對 /goal 嘅定義同機制
  3. Codex 同 Claude Code 兩家差異對比
  4. OpenAI 工程師 Chris Hayduk 嘅實戰案例同落地方法論

Codex /goal：契約式嘅長跑任務

1.1 功能定位

/goal 令 Codex 持續向一個目標推進，而唔係喺一輪對話之後停低。啓用之後，Codex 可以獨立運行幾個鐘，唔使用戶插手每一步。

目前係 Codex 嘅實驗性功能，需要明確開啓：

  • 在 /experimental 度啓用，或者
  • 在 config.toml 中添加 goals = true 至 [features]

1.2 控制命令

命令作用
/goal <目標>設定目標並開始執行
/goal睇嚇目前目標狀態
/goal pause暫停
/goal resume恢復
/goal clear清除目標

1.3 適合嘅工作類型

官方明確畀出標準："比單條 prompt 大，但比開放式 backlog 細"。

適合：

  • 代碼搬遷：目標技術棧、對等性檢查、約束都好明確
  • 大型重構：每個 checkpoint 之後都可以跑測試
  • 原型 / 遊戲 / 實驗：Codex 可以持續打磨一個行得到嘅產物

唔適合：一堆相互無關嘅零散任務清單。

1.4 設定循環嘅六步法

  1. 命名一個目標同一個停止條件
  2. 指明 Codex 必須先讀邊啲文件、文檔、issue、日誌或者計劃
  3. 定義「可以證明進度」嘅命令或者產物
  4. 要求 Codex 按 checkpoint 工作並維護一份簡短嘅進度日誌
  5. 用 /goal 檢查運行狀態
  6. 喺完成、阻塞或者方向變更嘅時候，用 pause / resume / clear 控制

1.5 核心思想：契約思維

Codex 必須喺開始之前就知道「完成」意味住啲咩。

一個目標契約要回答四個問題：

  • 要達成啲咩
  • 唔可以改動啲咩
  • 點樣驗證進度
  • 幾時停止

舉例：

  • 搬遷類目標：「新路徑通過契約測試，舊路徑仍然保留可回滾方案」
  • 原型類目標：「應用可以構建、可以啓動，並匹配輸入參考或預期行為」

1.6 長跑期間嘅協作方式

運行過程中應該向 Codex 拎精簡進度報告：目前 checkpoint、已經驗證咗啲咩、仲剩低啲咩、係咪阻塞。

如果狀態報告開始變得空泛，「應該收緊目標本身，而唔係疊加臨時指令」。

把 /goal 當做後台任務咁對待——Codex 喺合理確信達成停止條件嘅時候先停。

1.7 三類典型案例

  • 遷移：遊戲搬去新棧、手機應用搬去新平台、代碼庫搬去新框架
  • 原型創建：新應用、新遊戲、新功能由零做起拋光嘅初版（建議用 PLAN.md 描述目標）
  • Prompt 優化：基於 eval 套件迭代——檢查失敗用例、改 prompt、再跑 eval，直到分數達標

Claude Code /goal：可以驗證嘅完成條件

2.1 功能定位

/goal <條件> 設定一個完成條件。Claude Code 持續做嘢直到條件滿足；條件達成之後目標會自動清除。

適用場景例子：

  • 將模塊搬去新 API，直到所有調用點編譯通過同測試通過
  • 實現 design doc，直到所有驗收標準達成
  • 拆開大檔案，直到每個模塊低過規模預算
  • 處理 issue 隊列，直到清空

2.2 評估機制（關鍵設計）

每一輪結束之後：

  1. 目前條件 + 已有對話內容會被送去一個小型快速模型（預設 Haiku）
  2. 評估器會返一個 yes/no 判斷同簡短理由
  3. No → 將理由作為下一輪嘅指引，等 Claude Code 繼續
  4. Yes → 清除目標，喺 transcript 度記錄「已達成」

執行模型同評判模型分開——避免「自己評自己」嘅偏差。

評估器唔會主動調用工具，只能根據對話入面已經出現嘅內容做判斷。呢個意味住：條件必須係 Claude 自己嘅輸出可以證明嘅嘢。例如「test/auth 下面所有測試通過」——Claude Code 跑咗測試、結果落咗入 transcript，評估器就可以判斷。

2.3 寫出有效條件嘅三個要素

  1. 一個可以度量嘅終止狀態：測試結果、構建退出碼、檔案數量、空隊列
  2. 明確嘅證明方式：例如 npm test 退出碼係 0、git status clean
  3. 過程中唔可以違反嘅約束：例如「唔好改其他測試檔案」

補充約定：

  • 條件最長 4000 字符
  • 可以加入兜底子句，例如「或者喺 20 輪之後停止」，防止無限循環

2.4 同其他自主工作流程嘅分別

方式下一輪幾時啓動幾時停止
/goal上一輪結束之後即時評估模型確認條件達成
/loop時間間隔到達用戶停止，或者 Claude 判斷完成
Stop hook上一輪結束之後用戶嘅腳本或者 prompt 決定
Auto mode（唔啓動新一輪）Claude 自己判斷完成

/goal 同 Auto mode 互補：Auto mode 唔使逐個工具調用確認，/goal 唔使逐輪人工觸發。

2.5 工程化細節

  • 會話級：一個 session 同一時間只允許一個 active goal

  • 可恢復：--resume / --continue 嘅時候活躍目標會被恢復，但計時同 token 計數會重置

  • 可以無頭運行：

    claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

  • 狀態可見：界面有 ◎ /goal active 指示器；/goal 無參數就睇條件、運行時間、輪數、token 花費、最近一次評估理由

  • 成本可控：評估用小型快速模型，相對主循環開銷基本可以忽略

  • 安全界線：需要 workspace trust；如果策略禁用咗 hooks，命令會明確提示而唔係靜默失效

2.6 常用命令

命令作用
/goal <條件>設定/取代目標，即時開始執行
/goal睇嚇目前狀態
/goal clear提前清除目標（別名：stop / off / reset / none / cancel）

Codex 同 Claude Code 嘅分別

維度Codex /goalClaude Code /goal
評估機制未公開細節，強調「合理確信」明確小模型評估器 + Stop hook
控制命令pause / resume / clearclear（含多種別名）
文檔側重契約思維、checkpoint、長時間獨立運行評估器架構、可以恢復、headless
上限/邊界強調用 PLAN.md 引導單條件 4000 字符；可以加輪數兜底
典型案例搬遷、原型、prompt 優化測試通過、規格落地、隊列清空

共同點遠大過分別：兩者都係同一抽象——「帶終止條件嘅自主循環」：

執行 → 驗證 → 判斷是否達標 → 達標則停，否則繼續

分別主要在評估實現嘅透明度同互動控制粒度上。

實戰案例：Chris Hayduk 嘅 /goal 落地經驗

OpenAI 工程師 Chris Hayduk 喺 Codex 內部同個人項目中大量使用 /goal，沉澱出一套可以直接套用嘅方法論。呢啲經驗將官方文檔裏面嘅「應該點做」翻譯成「具體點做先唔會炒車」。

4.1 案例一：NeurIPS 論文轉 ICML 格式

背景：ICML 有幾百條格式同風格約束，分散喺 LaTeX 模板裏面，好難直接評分。

做法：

  1. 先等 Codex 將所有規則抽做一份 200+ 條目嘅 checklist.md

  2. 設定目標：

    "根據 checklist.md 將 NeurIPS 論文改做 ICML 格式，同唔改變任何技術內容。」

  3. 要求 Codex 喺完成每條嘅時候剔 checklist，將進度持久化到檔案系統

關鍵洞察：將「整體合規」拆做「逐項剔」——單條規則嘅判斷比整體判斷容易得多。呢個係連接「模糊願望」同「可驗證條件」嘅通用橋樑。

4.2 案例二：搜索改進嘅蛋白質結構模型架構

背景：完整訓練一次要幾日，循環根本行唔鬱。

做法：用 NanoFold（小型但充分採樣嘅數據集）做實驗，將單輪評分耗時從「幾日」壓縮到「幾分鐘」。

關鍵洞察：喺唔損害評分質素嘅前提下，用一切方法壓縮單輪反饋耗時。反饋迴路越緊，循環越有效。

4.3 模糊目標嘅兩種死法

模糊指令失敗模式
令我的代碼變得更好過早放棄：行幾分鐘就停
改進我的算法永遠唔停：盲目反覆修改，追逐無法滿足嘅目標

改寫後：

將 specific_file 中代碼嘅運行時間減少 20%，同唔引入任何單元測試同集成測試嘅迴歸。

包含兩個要素：量化指標（runtime −20%）+ 約束條件（測試唔迴歸）。

4.4 三份 Markdown 檔案作為外部記憶

即使有上下文壓縮，模型都好難喺幾個鐘甚至幾日嘅跨度上保持思路連貫。將「思考狀態」外化到檔案系統係最平可靠嘅解法：

文件作用寫作風格
PLAN.md高層計劃，可以預先寫入種子思路結構化大綱
EXPERIMENTS.md最關鍵——結構化嘅嘗試記錄標題 / 做咗咩 / 結果
EXPERIMENT_NOTES.md實時草稿本按時間順序嘅思考流水

EXPERIMENTS.md 係最重要嘅一份：佢令同 Agent 都可以覆盤「試過咩、點解成功或者失敗」，防止長循環中反覆嘗試同一個失敗方案。

4.5 落地三原則

將官方文檔同上頭經驗合併，可以提煉成三條硬性要求：

  1. 目標可以度量 —— 等循環知道幾時應該停
  2. 驗證可以執行 —— 等循環行得快同可信
  3. 狀態可以外化 —— 等循環行得耐都唔會丟失上下文

滿足呢三條，Codex 同 Claude Code 就可以喺硬問題上穩定咁「自己磨」幾個鐘甚至幾日；唔滿足，循環一係提早放棄，一係永遠唔收斂。

總結

/goal 唔係等人打字打少啲嘅快捷鍵，而係將人類從「逐輪審閲」中解放出來、要求喺起跑前將「咩係完成」定義清楚嘅協作契約。

佢對提示詞工程提出咗根本性轉變：

  • 日常 Chat 似傾偈 —— 依賴模型善意理解
  • /goal 模式似寫驗收標準書 —— 依賴人自己嘅需求工程能力

下次準備啓動一個長跑任務之前，先停低問自己三個問題：

  1. 點樣算完成？（可以用一個命令、一個數字、一份 checklist 來表達嗎？）
  2. 每輪點樣驗證？（呢個驗證夠快、夠可信嗎？）
  3. 進度記喺邊？（斷咗上下文之後，模型仲可以繼續做嗎？）

三個問題都答得出，先再撳 /goal。

相關資源推薦

Agent Harness Engineering 三重前沿實踐：Codex、Claude Code、Cursor 點樣令人類從編碼者升做架構師

OpenAI Codex 係最好嘅 Agent 嗎？點解佢比 Claude Code 更強？Google 點解又唔得啦？OpenClaw 係個人 Agent 嘅未來嗎？

OpenAI Codex 前幾天推出了 /goal，讓 Codex 自主循環數小時直至達成目標，中間完全不間斷不需要人介入，很多朋友包括我自己也在嘗試，睡前把複雜任務交給 /goal，睡醒發現任務居然真的順利且正確的完成了！

https://developers.openai.com/codex/use-cases/follow-goals

而一直被認為是 Coding Agent 標杆的 Claude Code 也緊隨其後推出了 /goal！

https://code.claude.com/docs/en/goal

OpenAI 和 Anthropic 兩個最頂級 AI 團隊和最強競爭對手，又一次同時選擇了 /goal，這個完全自主 Agent 方向，今天咱們一起看看他們對 /goal 的不同定義和最佳實踐。

  1. Codex 官方對 /goal 的定義與用法
  2. Claude Code 官方對 /goal 的定義與機制
  3. Codex 和 Claude Code 兩家差異對比
  4. OpenAI 工程師 Chris Hayduk 的實戰案例與落地方法論

Codex /goal：契約式的長跑任務

1.1 功能定位

/goal 讓 Codex 持續朝一個目標推進，而不是在一輪對話後停下。啓用後，Codex 可以獨立運行數小時，無需用戶介入每一步。

當前為 Codex 的實驗性功能，需要顯式開啓：

  • 在 /experimental 中啓用，或
  • 在 config.toml 中添加 goals = true 至 [features]

1.2 控制命令

命令作用
/goal <目標>設定目標並開始執行
/goal查看當前目標狀態
/goal pause暫停
/goal resume恢復
/goal clear清除目標

1.3 適合的工作類型

官方明確給出標準：比單條 prompt 更大，但比開放式 backlog 更小。

適合：

  • 代碼遷移：目標技術棧、對等性檢查、約束都明確
  • 大型重構：每個 checkpoint 後都能跑測試
  • 原型 / 遊戲 / 實驗：Codex 可以持續打磨一個能跑的產物

不適合：一堆相互無關的零散任務清單。

1.4 設置循環的六步法

  1. 命名一個目標和一個停止條件
  2. 指明 Codex 必須先讀哪些文件、文檔、issue、日誌或計劃
  3. 定義"能證明進度"的命令或產物
  4. 要求 Codex 按 checkpoint 工作並維護一份簡短的進度日誌
  5. 用 /goal 檢查運行狀態
  6. 在完成、阻塞或方向變更時，用 pause / resume / clear 控制

1.5 核心思想：契約思維

Codex 必須在開始前就知道"完成"意味着什麼。

一個目標契約要回答四個問題：

  • 要達成什麼
  • 不能改動什麼
  • 如何驗證進度
  • 何時停止

舉例：

  • 遷移類目標："新路徑通過契約測試，舊路徑仍保留可回滾方案"
  • 原型類目標："應用能構建、能啓動，並匹配輸入參考或預期行為"

1.6 長跑期間的協作方式

運行過程中應向 Codex 索要精簡進度報告：當前 checkpoint、已驗證什麼、還剩什麼、是否阻塞。

如果狀態報告開始變得空泛，應該收緊目標本身，而不是疊加臨時指令。

把 /goal 當成後台任務對待——Codex 在合理確信達成停止條件時才停。

1.7 三類典型案例

  • 遷移：遊戲遷移到新棧、移動應用遷移到新平台、代碼庫遷移到新框架
  • 原型創建：新應用、新遊戲、新功能從零做出拋光的初版（推薦用 PLAN.md 描述目標）
  • Prompt 優化：基於 eval 套件迭代——檢查失敗用例、改 prompt、重跑 eval，直到分數達標

Claude Code /goal：可驗證的完成條件

2.1 功能定位

/goal <條件> 設定一個完成條件。Claude Code 持續工作直到條件滿足；條件達成後目標自動清除。

適用場景示例：

  • 把模塊遷移到新 API，直到所有調用點編譯通過且測試通過
  • 實現 design doc，直到所有驗收標準成立
  • 拆分大文件，直到每個模塊低於規模預算
  • 處理 issue 隊列，直到清空

2.2 評估機制（關鍵設計）

每一輪結束後：

  1. 當前條件 + 已有對話內容被髮送給一個小型快速模型（默認 Haiku）
  2. 評估器返回一個 yes/no 判斷和簡短理由
  3. No → 把理由作為下一輪的指引，讓 Claude Code 繼續
  4. Yes → 清除目標，在 transcript 中記錄"已達成"

執行模型與評判模型分離——避免"自己評自己"的偏差。

評估器不會主動調用工具，只能依據對話中已經出現的內容做判斷。這意味着：條件必須是 Claude 自己的輸出能證明的東西。比如"test/auth 下所有測試通過"——Claude Code 跑了測試、結果落進了 transcript，評估器就能判斷。

2.3 寫出有效條件的三要素

  1. 一個可度量的終止狀態：測試結果、構建退出碼、文件數量、空隊列
  2. 明確的證明方式：例如 npm test 退出碼為 0、git status clean
  3. 過程中不可違反的約束：例如"不修改其他測試文件"

補充約定：

  • 條件最長 4000 字符
  • 可加入兜底子句，例如"或在 20 輪後停止"，防止無限循環

2.4 與其他自主工作流的區別

方式下一輪何時啓動何時停止
/goal上一輪結束後立即評估模型確認條件達成
/loop時間間隔到達用戶停止，或 Claude 判斷完成
Stop hook上一輪結束後用戶的腳本或 prompt 決定
Auto mode（不啓動新輪）Claude 自己判斷完成

/goal 與 Auto mode 互補：Auto mode 免去逐工具調用確認，/goal 免去逐輪人工觸發。

2.5 工程化細節

  • 會話級：一個 session 同時只允許一個 active goal

  • 可恢復：--resume / --continue 時活躍目標會被恢復，但計時和 token 計數重置

  • 可無頭運行：

    claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

  • 狀態可見：界面有 ◎ /goal active 指示器；/goal 無參數即查看條件、運行時長、輪數、token 花費、最近一次評估理由

  • 成本可控：評估走小型快速模型，相對主循環開銷基本可忽略

  • 安全邊界：需要 workspace trust；如果策略禁用了 hooks，命令會顯式提示而非靜默失效

2.6 常用命令

命令作用
/goal <條件>設置/替換目標，立即開始執行
/goal查看當前狀態
/goal clear提前清除目標（別名：stop / off / reset / none / cancel）

Codex 與 Claude Code 的差異

維度Codex /goalClaude Code /goal
評估機制未公開細節，強調"合理確信"顯式小模型評估器 + Stop hook
控制命令pause / resume / clearclear（含多種別名）
文檔側重契約思維、checkpoint、長時獨立運行評估器架構、可恢復、headless
上限/邊界強調用 PLAN.md 引導單條件 4000 字符；可加輪數兜底
典型案例遷移、原型、prompt 優化測試通過、規格落地、隊列清空

共同點遠大於差異：兩者都是同一抽象——帶終止條件的自主循環：

執行 → 驗證 → 判斷是否達標 → 達標則停，否則繼續

差異主要在評估實現的透明度和交互式控制粒度上。

實戰案例：Chris Hayduk 的 /goal 落地經驗

OpenAI 工程師 Chris Hayduk 在 Codex 內部和個人項目中大量使用 /goal，沉澱出一套可直接套用的方法論。這些經驗把官方文檔裏的"應該怎麼做"翻譯成了"具體怎麼做才不翻車"。

4.1 案例一：NeurIPS 論文轉 ICML 格式

背景：ICML 有數百條格式與風格約束，分散在 LaTeX 模板裏，難以直接評分。

做法：

  1. 先讓 Codex 把所有規則抽取為一份 200+ 條目的 checklist.md

  2. 設定目標：

    "根據 checklist.md 把 NeurIPS 論文改為 ICML 格式，且不改變任何技術內容。"

  3. 要求 Codex 在完成每條時勾選 checklist，把進度持久化到文件系統

關鍵洞察：把"整體合規"拆成"逐項勾選"——單條規則的判斷比整體判斷容易得多。這是連接"模糊願望"和"可驗證條件"的通用橋樑。

4.2 案例二：搜索改進的蛋白質結構模型架構

背景：完整訓練一次要數天，循環根本跑不動。

做法：用 NanoFold（小型但充分採樣的數據集）做實驗，把單輪評分耗時從"數天"壓縮到"數分鐘"。

關鍵洞察：在不損害評分質量的前提下，用一切手段壓縮單輪反饋耗時。反饋迴路越緊，循環越有效。

4.3 模糊目標的兩種死法

模糊指令失敗模式
讓我的代碼變得更好過早放棄：跑幾分鐘就停
改進我的算法永不停止：盲目反覆修改，追逐無法滿足的目標

改寫後：

將 specific_file 中代碼的運行時間減少 20%，且不引入任何單元測試和集成測試的迴歸。

包含兩要素：量化指標（runtime −20%）+ 約束條件（測試不迴歸）。

4.4 三份 Markdown 文件作為外部記憶

即便有上下文壓縮，模型也難以在數小時甚至數天的跨度上保持思路連貫。把"思考狀態"外化到文件系統是最便宜可靠的解法：

文件作用寫作風格
PLAN.md高層計劃，可預先寫入種子思路結構化大綱
EXPERIMENTS.md最關鍵——結構化的嘗試記錄標題 / 做了什麼 / 結果
EXPERIMENT_NOTES.md實時草稿本按時間順序的思考流水

EXPERIMENTS.md 是最重要的一份：它讓人和 Agent 都能覆盤"試過什麼、為什麼成功或失敗"，防止長循環中反覆嘗試同一個失敗方案。

4.5 落地三原則

把官方文檔與上述經驗合併，可以提煉為三條硬性要求：

  1. 目標可度量 —— 讓循環知道何時該停
  2. 驗證可執行 —— 讓循環跑得快且可信
  3. 狀態可外化 —— 讓循環跑得久也不丟失上下文

滿足這三條，Codex 與 Claude Code 就能在硬問題上穩定地"獨自磨"數小時甚至數天；不滿足，循環要麼提前放棄，要麼永不收斂。

總結

/goal 不是讓人少打字的快捷鍵，而是把人類從"逐輪審閲"中解放出來、要求在起跑前把"什麼是完成"定義清楚的協作契約。

它對提示詞工程提出了根本性轉變：

  • 日常 Chat 像聊天 —— 依賴模型善意理解
  • /goal 模式像寫驗收標準書 —— 依賴人自己的需求工程能力

下次準備啓動一個長跑任務前，先停下來問自己三個問題：

  1. 怎樣算完成？（能用一個命令、一個數字、一份 checklist 來表達嗎？）
  2. 每輪怎麼驗證？（這個驗證夠快、夠可信嗎？）
  3. 進度記在哪？（斷了上下文之後，模型還能接着幹嗎？）

三個問題都答得出來，再敲下 /goal。

相關資源推薦

Agent Harness Engineering 三重前沿實踐：Codex、Claude Code、Cursor 如何讓人類從編碼者升為架構師

OpenAI Codex 是最好的 Agent 嗎？為什麼它比 Claude Code 更強？Google 為什麼又不行了？OpenClaw 是個人 Agent 的未來嗎？