一文搞懂如何在Codex中使用goals
整理版優先睇
Codex Goals 係一種持久目標機制，讓AI圍繞可測量嘅結果同驗證標準進行多輪自主工作，適用於除錯、最佳化、研究等複雜任務。
呢篇文章出自 OpenAI 官方，主要介紹 Codex 嘅 Goals 功能。作者想解決嘅問題係：普通 prompt 一次過，做完就等下一條指令，但好多任務（例如效能調校、測試排查、研究復現）需要多輪迭代，下一步取決於上一步嘅發現。Goals 就係為咗呢類任務而設，佢畀 Codex 一個持續有效嘅完成條件同驗證方法，唔使每輪重複目的。
整體結論係：Goals 改變咗 Codex 嘅運作模式，將一次性對話變成圍繞明確結果嘅有狀態工作循環。佢唔係放任 AI 無邊界自主運行，而係一個有範圍、用戶可控嘅完成合約。用戶定義結果，Codex 跟住證據工作，直到任務完成或者誠實咁話俾你知受阻。
文章仲詳細講解咗點樣寫一個好 Goal：要定義結果、驗證方法、約束、邊界、迭代策略同阻塞停止條件。同時亦提到唔適合用 Goals 嘅情況，例如簡單修改、模糊目標或者你只係想要一個答案嘅問題。總括來講，Goals 最有力嘅時候係同時具備三個特性：有持久目標、有基於證據嘅完成線、同埋路徑可能需要多輪調查。
- Goals 係 Codex 嘅持久目標，唔似一次性 prompt，佢畀 Codex 一個持續有效嘅完成條件同驗證方法。
- 寫一個好 Goal 要定義結果、驗證方法、約束、邊界、迭代策略同阻塞停止條件。
- Goals 激活後，Codex 會持續按目標工作，透過檢查證據判斷係咪完成，唔需要每輪重複指令。
- Goals 最啱用喺多步除錯、效能最佳化、測試排查、研究復現呢類任務；唔啱用喺簡單修改或模糊目標。
- 內部設計上，Goal 係線程範圍嘅持久狀態，有生命週期同預算限制，Codex 只會喺安全邊界繼續工作。
寫 Goal 模板
/goal <期望最終狀態>，通過<具體證據>驗證，同時保持<約束>。使用<允許的輸入、工具或邊界>。每次迭代之間，<Codex應如何選擇下一步最佳行動>。如果遇到阻塞或沒有有效路徑，<Codex應報告什麼、什麼能解除阻塞>。
內容片段
/goal 將 p95 checkout 延遲降至 120 毫秒以下，以 checkout 基準測試驗證，同時保持正確性測試套件全部通過。僅使用 checkout 服務、基準測試夾具及相關測試。在每次迭代之間，記錄變動內容、基準測試結果，以及下一步要嘗試的最佳實驗。如果基準測試無法運行或無有效路徑剩餘，則停止，並附上已嘗試路徑、收集到的證據、阻塞點，以及所需的下一步輸入Goals 係咩？點解要用？
Goals 係 Codex 嘅一個 持久目標機制。普通 prompt 係一次性對話：你話做咩，Codex 做完，等你下一條指令。Goals 唔同，佢畀 Codex 一個 持續有效嘅完成條件，包括任務幾時算做完、點樣驗證、過程中有咩唔可以鬱。
目標仲可以俾預算限制住，唔會無止境咁走落去。
Codex 原本已經處理到邊界清晰嘅任務，例如睇 code、修 bug、寫測試。但係有啲任務下一步點做要睇上一步發現咗咩，例如 效能調校、唔穩定測試排查、依賴遷移、需要復現嘅 bug、多步重構、或者要產出最終文檔嘅研究任務。呢類任務需要嘅唔係更長嘅 prompt，而係一個 持久目標。
點樣寫一個好嘅 Goal？
一個好嘅 Goal 唔係更長嘅 prompt，而係一個關於 Codex 點樣工作、咩叫成功、成功暫時達唔到時點做嘅精簡合約。通常要定義 六件事：
- 1 結果：工作完成時應該係咩狀態。
- 2 驗證方法：用咩來證明，例如測試、benchmark、報告、產出物、命令輸出、源材料。
- 3 約束：Codex 工作期間有咩唔可以退化。
- 4 邊界：Codex 可以用嘅文件、工具、數據、倉庫或資源。
- 5 迭代策略：每次嘗試後，Codex 點樣決定下一步試咩。
- 6 阻塞停止條件：幾時應該停落嚟，話俾你知當前限制下冇可行路徑。
一個實用嘅寫法模板：/goal <期望最終狀態>，通過<具體證據>驗證，同時保持<約束>。使用<允許嘅輸入、工具或邊界>。每次迭代之間，<Codex 應如何選擇下一步最佳行動>。如果遇到阻塞或冇有效路徑，<Codex 應報告咩、咩能解除阻塞>。
Goals 嘅實際應用：復現論文
文章用咗一個具體嘅研究例子：復現 Buehler 等人嘅 Deep Hedging 論文。呢篇論文探討神經交易策略能否喺唔同風險偏好、交易成本同更高維度市場配置下復現基於模型嘅對沖。正確嘅 Goal 唔係籠統咁話「復現呢篇論文」，而係要 分離核心結論與支撐性結論，嘗試論文嘅核心數值結論，並明確說明因為材料不足而無法精確復現嘅部分。
實際操作中，Codex 用 Goal 嚟 分離核心結論與支撐性結論，重建可以在本地測試嘅部分，標註因缺乏材料而無法精確復現嘅結論。最後產出嘅報告會將復現成功嘅機制、近似訓練結果、被阻斷嘅精確復現路徑同剩餘不確定性區分開。
幾時唔應該用 Goals？同埋總結
Goals 唔適合所有任務。唔好對 一行 code 嘅修改、簡單解釋、短小嘅 code review、或者你只係想要一個答案然後停下來嘅問題用 Goal。普通 Codex prompt 更適合呢啲情況。另外，終點線模糊 嘅時候都唔好用，例如「將呢個做得更好」冇畀到可靠嘅完成條件。
總括來講，Goals 改變咗 Codex 嘅運作模式，將線程從一連串孤立 prompt 變成圍繞明確結果嘅有狀態工作循環。架構上佢係 線程範圍，帶有生命週期狀態同預算，可以暫停、恢復、清除、完成或被預算停止。Codex 可以繼續工作，但只可以喺用戶定義嘅合約範圍內。
呢個機制令 Goals 對除錯、最佳化、遷移、測試同研究呢類任務最有價值。
對於複雜研究，Goals 係生成一個答案同產出一份審計報告之間嘅區別。好嘅 Goal 唔單止令 Codex 做曬嘢，佢令 Codex 知道「做完」代表咩意思。
OpenAI出咗篇關於喺 Codex 用Goals嘅好文章。
簡單講，呢篇文章講嘅係幾時用Goals、Goals啟動時會有咩變化，同埋點樣寫Goals，令到Codex有清晰嘅結果、約束同驗證標準。如果你有興趣，仲可以瞭解嚇喺架構層面點樣設計Goals。
文中用goals嚟重現論文嘅例子我覺得好有用，好多人應該對呢個有好大需求，對科研嚟講簡直太有用。
原文：
https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex
Goals係咩
Goals係Codex裏面嘅持久目標機制。
普通嘅prompt係一次性：你話做咩，Codex做完，等下一句指令。Goals唔同，佢畀Codex一個持續有效嘅完成條件：任務幾時算做完，點樣驗證，過程入面邊啲唔鬱得。
圖 1 Goal 將一次性對話變成持續循環——每一步都有證據核對
只要目標仲喺度、仲喺預算內，Codex可以自己檢查進度、決定下一步，唔需要你每輪重複一次目的。
Codex本來就可以處理邊界清晰嘅任務：睇code、修bug、寫test、解釋報錯。Goals針對嘅係另一類任務：下一步應該點做，取決於上一步發現咗啲咩。例如性能調優、唔穩定測試排查、依賴遷移、需要重現嘅bug、多步重構、基於benchmark嘅調參，或者要產出最終文檔嘅研究任務。
呢類任務唔需要更長嘅prompt，需要嘅係一個持久嘅目標。
Goals唔係放縱AI冇邊界自主運行。佢係一個有範圍、用戶可控嘅完成合約。你定義結果，Codex對住thread入面嘅證據工作，目標可以暫停、恢復、清除、完成，亦可以被預算限制住。
怎麼用
Goals由Codex 0.128.0開始支援。目前只支援codex cli，更新到最新版，/experimental
用npm安裝或更新：
npm install -g @openai/codex@latest
codex --version用Homebrew：
brew update
brew upgrade --cask codex
codex --version設置目標，用/goal加上你想達到嘅結果：
/goal 將 p95 延遲降至 120 毫秒以下，且不引起正確性測試回退生命週期管理命令：
/goal 查看當前目標
/goal pause 暫停激活中的目標
/goal resume 恢復已暫停的目標
/goal clear 移除當前目標目標啟動後，Codex可以自己睇code、行相關命令、做修改、測結果，一直去到達到停止條件為止。停止條件包括：成功完成、暫停、清除、被打斷、達到預算上限、或者遇到需要用戶介入嘅阻塞點。
Goals同普通prompt嘅分別
普通prompt：你話做呢件事，Codex做，彙報結果，等。
Goals：Codex工作，檢查係咪達標，繼續或完成。
分別就喺度。普通請求入面，Codex做完當前指令，等下一句。Goals令Codex有一個持續黐喺thread上面嘅目標。每輪結束後，佢可以檢查當前證據，判斷目標係咪達成。如果冇，而且目標仍然啟動、仲喺預算內，Codex由最新狀態繼續。
舉個例子：
/goal 在 checkout 基準測試中，將 p95 checkout 延遲降至 120 毫秒以下，同時保持正確性測試套件全綠通過呢個唔只係一個「提升性能」嘅請求。佢畀咗Codex一個可量度嘅結果、一個驗證方法、一個約束條件。Codex可以行benchmark，檢查熱路徑，做針對性修改，再行benchmark，行正確性測試套件，如果結果仲未達標就繼續。
點樣寫一個好嘅Goal
好嘅Goal唔係更長嘅prompt，而係一個關於Codex點樣工作、咩叫成功、成功暫時達唔到時點算嘅精簡合約。
強Goal通常定義六件事：
結果：工作完成時應該係咩狀態
驗證方法：用咩嚟證明，例如測試、benchmark、報告、產出物、命令輸出、源材料
約束：Codex工作期間邊啲唔可以退化
邊界：Codex可以用邊啲文件、工具、數據、倉庫或資源
迭代策略：每次嘗試後，Codex點樣決定下一步試咩
阻塞停止條件：幾時應該停低，話畀人知當前限制下冇可行路徑
一個實用嘅寫法模板：
/goal <期望的最終狀態>，
通過<具體證據>驗證，
同時保持<約束>。
使用<允許的輸入、工具或邊界>。
每次迭代之間，<Codex應如何選擇下一步最佳行動>。
如果遇到阻塞或沒有有效路徑，<Codex應報告什麼、什麼能解除阻塞>。比較一個弱Goal同一個強Goal：
弱版本：
/goal 將 p95 checkout 延遲降至 120 毫秒以下，同時不引起正確性測試回退強版本：
/goal 將 p95 checkout 延遲降至 120 毫秒以下，
以 checkout 基準測試驗證，同時保持正確性測試套件全部通過。
僅使用 checkout 服務、基準測試夾具及相關測試。
在每次迭代之間，記錄變動內容、基準測試結果，以及下一步要嘗試的最佳實驗。
如果基準測試無法運行或無有效路徑剩餘，則停止，並附上已嘗試路徑、收集到的證據、阻塞點，以及所需的下一步輸入強版本入面，如果p95由180ms降到135ms，Goal仲未完成。如果延遲降到120ms以下但正確性測試死咗，Goal都未完成。如果benchmark行唔起，Codex必須將呢個阻塞報告上嚟，而唔係宣佈成功。
同樣嘅原則適用於生成產出物。
弱：
/goal 給這個功能寫份文檔強：
/goal 為 Goals 生成一個文檔頁面，解釋其生命週期、命令界面，並提供兩個示例。驗證該頁面在本地能夠成功構建，且所有引用的命令與當前 CLI 行為一致.第二個Goal畀咗Codex可以檢查嘅嘢：一個頁面、一個構建命令、命令行為。
圖 . 強目標命名最終狀態、驗證面向同約束
如果任務清楚但仲未知道點樣寫Goal，都可以叫Codex幫手寫。先用普通語言描述工作，叫Codex將佢轉成Goal草稿；再審查草稿，收緊成功條件、驗證方法、約束同阻塞停止條件，然後再啟動。
Goal啟動後，三件事會改變
第一，目標持續可見。 如果Codex行咗一個測試、失敗咗，thread入面仲有原始目標。如果benchmark提升咗但未過閾值，Codex可以繼續。如果研究路徑遇到數據缺失，Codex可以調整證據計劃，唔會丟失研究標準。
第二，可以從空閒thread繼續。 Codex唔會喺另一輪仲行緊嗰陣繼續，唔會喺用戶輸入排隊嗰陣繼續，唔會喺有其他thread工作待處理嗰陣繼續。只有喺thread空閒、目標啟動、喺預算內嘅時候先繼續。
第三，完成必須有證據。 Goal唔應該因為模型覺得「大概差唔多啦」就被標記為完成。只有將目標同具體證據對照檢查之後，例如文件改動、命令運行、測試通過、benchmark輸出、生成產物或研究證據，先可以標完成。
Goals嘅內部設計
Goals係持久化嘅thread狀態，唔係全局記憶，亦唔係項目級指令。設計上呢個選擇好重要：目標屬於有相關上下文嘅嗰個thread，包括Codex檢查過嘅文件、行過嘅命令、產出嘅diff、見到嘅日誌、累積嘅推理鏈。
圖 2 目標為當前thread添加持久狀態、延續、控制同證據檢查
喺架構層，Goal係一個持久嘅、thread範圍內嘅狀態。佢記錄咗Codex評估thread所需嘅目標、生命週期、預算同進度。關鍵邊界係範圍：Goal屬於當前thread，唔屬於全局記憶或項目指令。
Codex將呢個狀態作為用戶、模型、thread三者之間嘅合約。Goal可以處於啟動、暫停、完成或達到預算上限等狀態。呢啲狀態決定咗Codex可唔可以繼續、應唔應該等用戶、定係應該彙總進度而唔係開始新工作。
繼續係事件驅動嘅，唔係簡單嘅循環。Codex只喺安全邊界處檢查係咪繼續：一輪結束後、冇其他待處理工作時、冇用戶輸入排隊時、thread空閒時。
圖 . Codex 只有喺目標處於活動狀態、thread處於空閒狀態兼且冇用戶輸入排隊時先會繼續運行
調度器嘅行為係有意保守嘅。純規劃工作唔會觸發繼續。被打斷會暫停目標。恢復thread時，可以喺適當情況下恢復目標。如果某次繼續冇產生任何工具調用，下一次自動繼續會被抑制，防止Codex空轉。
預算處理係明確嘅。達到預算上限時，Codex應該停止實質性工作，彙總進度同阻塞點，並指出下一步有用嘅行動。達到預算上限唔等於完成目標。
工具合約令生命週期權限保持喺邊界內。模型可以發起Goal，亦可以喺證據支持下將現有Goal標記為完成。暫停、恢復、清除同預算限制嘅狀態轉變，由用戶或系統控制。
用Goals做複雜研究：重現一篇量化論文
睇一個具體嘅研究Goal示例。
研究對象係Buehler、Gonon、Teichmann同Wood嘅Deep Hedging論文。呢篇論文探討神經交易策略能否喺唔同風險偏好、交易成本同更高維度市場配置下重現基於模型嘅對沖。正確嘅Goal唔係籠統咁「重現呢篇論文」，而係嘗試論文嘅核心數值結論，將精確嘅機制同近似訓練替代品分開，並清楚講明邊啲內容因為材料唔夠而冇得精確重現。
弱版本：
/goal 復現 Buehler 等人的《Deep Hedging》呢個太模糊。冇講邊部分重要，咩叫重現，點樣處理訓練狀態唔可用嘅情況，點樣區分數值接近同精確重現。
更好嘅版本：
/goal 利用現有論文材料和本地資源，對 Buehler 等人的《Deep Hedging》進行最強證據支持的復現。
嘗試每一個主要結果，驗證輸出，最終形成一份報告，將復現成功的工作機制、近似訓練結果、被阻斷的精確復現路徑及剩餘不確定性區分開來說明強版本有效，因為佢指定咗證據標準同最終產出物。Codex唔只係嘗試做一個令人印象深刻嘅重現，佢係用現有證據盡量減少不確定性，同時唔誇大證據所能支持嘅結論。
圖 一個研究目標在聲明狀態之前，先將論文分解為多個證據通道
喺實際操作中，呢個Goal畀調查提供咗一個具體嘅操作合約。
Codex用佢嚟：
• 分離核心結論同支撐性結論 • 將呢啲結論映射到可用證據上 • 重建可以喺本地測試嘅部分 • 標註邊啲結論因為缺乏可用材料而冇得精確重現
有幾個部分係可行嘅。Codex重建咗定價同對沖機制，重現咗Heston參考價格，訓練咗CVaR對沖實驗嘅策略，重建咗主要嘅直方圖同對沖面產出物，重現咗Black-Scholes交易成本斜率，並為Heston交易成本同高維示例行咗訓練檢查。
有啲結論因為缺少源材料而冇法完成。論文冇提供精確嘅隨機種子、生成嘅訓練路徑、TensorFlow計算圖、優化器狀態、檢查點或完整嘅原始模擬狀態。呢個意味住最終最誠實嘅結果係部分同近似嘅重現，而唔係精確嘅神經網絡重現。
呢個就係Goal嘅價值所在。佢令工作喺遇到阻塞後繼續推進，同時亦令最終語言保持誠實。訓練替代品可以支持一個結論，數值接近可以提升信心，重建嘅圖表可以驗證部分結果，但呢啲都唔應該被描述為精確還原咗原始實驗。
最終報告應該保留呢啲唔同層次嘅支撐，而唔係將佢哋壓平成一個單一嘅「成功」聲明。
圖 最終輸出嘅內容，應清楚區分各項結論背後有唔同強度嘅證據支撐
舉個賬目條目嘅例子：
結論：在沒有交易成本的情況下，深度對沖近似了完全市場Heston對沖。
路徑：重建了模型機制，進行了參考對沖比較，訓練了神經策略。
證據來源：價格檢驗、直方圖和對沖面。
狀態：接近近似復現。
剩餘不確定性：原始訓練路徑、種子和檢查點不可用。呢個就係Goals喺研究入面嘅示範價值。佢令Codex喺模糊中持續工作，同時防止一個似乎合理嘅產出物變成一個過度聲明嘅結論。Goal唔只係令Codex將事情做完，佢定義咗「做完」意味住啲咩：對每個結論逐一審計，有證據支撐，清楚近似之處，並對重現同重現之間嘅邊界保持誠實。
幾時唔應該用Goals
Goals唔適合所有任務。
唔好對一行code嘅修改用Goal，唔好對簡單解釋用Goal，唔好對短小嘅code評審用Goal，唔好對你淨係想要一個答案然後停低嘅問題用Goal。普通嘅Codex prompt更適合呢啲情況。
唔好喺終點線模糊嘅時候用Goal。「將呢個做得更好」冇畀Codex可靠嘅完成條件。「重構呢段code」都好弱，除非你定義咗預期嘅最終狀態、測試同約束。
唔好用Goal嚟掩蓋不確定性。如果數據可能唔可用，喺Goal入面講清楚。如果benchmark可能唔穩定，說明點樣處理。如果允許用代理證據，定義佢應該點樣標註。
Goals喺三個特性同時具備時最有力：有持久目標，有基於證據嘅完成線，以及路徑可能需要多輪調查。
總結一下
Goals改變咗Codex嘅運作模式。佢將一個thread由一連串孤立嘅prompt變咗做圍繞住明確結果嘅有狀態工作循環。
架構上係有意限制嘅。Goal屬於thread範圍，帶有生命週期狀態同預算，可以暫停、恢復、清除、完成或被預算停止。Codex可以繼續工作，但只能喺用戶定義嘅合約範圍內。
呢個令Goals對Codex最有價值嘅工作最有用：調試、優化、遷移、測試同研究。用戶提供目標，Codex跟住證據走，Goal令兩者保持連接，直到工作要麼完成，要麼誠實地宣告受阻。
對於複雜研究，呢個係生成一個答案同產出一份審計報告之間嘅分別。好嘅Goal唔只係令Codex將事做完，佢話畀Codex知「做完」係咩意思。
--end--
最後記得⭐️我，每日都在更新：如果覺得文章仲唔錯嘅話可以點讚轉發推薦評論
/...@作者：你講得完全正確（YAR師）
OpenAI發了一篇關於在 Codex 中使用Goals的很好的文章。
簡單來說這篇文章講的是何時使用Goals、Goals激活時會發生哪些變化，以及如何編寫Goals，以便為 Codex 提供清晰的結果、約束和驗證標準。如果你感興趣的話，還可以瞭解一下在架構層面上是如何設計Goals的
文章中的用goals來複現論文的例子我覺得非常有用，很多人應該對這個有強烈需求，這對科研來說簡直太有用了。
原文：
https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex
Goals是什麼
Goals是Codex裏的持久目標機制。
普通的prompt是一次性的：你說做什麼，Codex做完，等你下一條指令。Goals不一樣，它給Codex一個持續有效的完成條件：任務什麼時候算做完，怎麼驗證，過程中什麼不能動。
圖 1 Goal 把一次性對話變成了一個持續循環——每一步都有證據校驗
只要目標還在、還在預算內，Codex可以自己檢查進度、決定下一步，不需要你每輪重複一遍目的。
Codex原本就能處理邊界清晰的任務：看代碼、修bug、寫測試、解釋報錯。Goals針對的是另一類任務：下一步該怎麼做，取決於上一步發現了什麼。比如性能調優、不穩定測試排查、依賴遷移、需要復現的bug、多步重構、基於benchmark的調參，或者要產出最終文檔的研究任務。
這類任務不需要更長的prompt，需要的是一個持久的目標。
Goals不是放任AI無邊界自主運行。它是一個有範圍、用戶可控的完成合約。你定義結果，Codex對着線程裏的證據工作，目標可以暫停、恢復、清除、完成，也可以被預算限制住。
怎麼用
Goals從Codex 0.128.0開始支持。目前只支持codex cli，更新到最新版，/experimental
用npm安裝或更新：
npm install -g @openai/codex@latest
codex --version用Homebrew：
brew update
brew upgrade --cask codex
codex --version設置目標，用/goal加上你想達到的結果：
/goal 將 p95 延遲降至 120 毫秒以下，且不引起正確性測試回退生命週期管理命令：
/goal 查看當前目標
/goal pause 暫停激活中的目標
/goal resume 恢復已暫停的目標
/goal clear 移除當前目標目標激活後，Codex可以自己看代碼、跑相關命令、做修改、測結果，一直到達到停止條件為止。停止條件包括：成功完成、暫停、清除、被打斷、達到預算上限、或者遇到需要用戶介入的阻塞點。
Goals和普通prompt的區別
普通prompt：你說做這件事，Codex做，彙報結果，等待。
Goals：Codex工作，檢查是否達標，繼續或完成。
區別就在這裏。普通請求裏，Codex做完當前指令，等下一條。Goals讓Codex有一個持續附在線程上的目標。每輪結束後，它能檢查當前證據，判斷目標是否達成。如果沒有，且目標仍然激活、仍在預算內，Codex從最新狀態繼續。
舉個例子：
/goal 在 checkout 基準測試中，將 p95 checkout 延遲降至 120 毫秒以下，同時保持正確性測試套件全綠通過這不只是一個"提升性能"的請求。它給了Codex一個可測量的結果、一個驗證方法、一個約束條件。Codex可以跑benchmark，檢查熱路徑，做針對性修改，重跑benchmark，跑正確性測試套件，如果結果還不達標就繼續。
怎麼寫一個好的Goal
好的Goal不是更長的prompt，是一個關於Codex怎麼工作、什麼算成功、成功暫時無法達到時怎麼辦的精簡合約。
強Goal通常定義六件事：
結果：工作完成時應該是什麼狀態
驗證方法：用什麼來證明，比如測試、benchmark、報告、產出物、命令輸出、源材料
約束：Codex工作期間什麼不能退化
邊界：Codex可以用哪些文件、工具、數據、倉庫或資源
迭代策略：每次嘗試後，Codex怎麼決定下一步試什麼
阻塞停止條件：什麼時候應該停下來，告知當前限制下沒有可行路徑
一個實用的寫法模板：
/goal <期望的最終狀態>，
通過<具體證據>驗證，
同時保持<約束>。
使用<允許的輸入、工具或邊界>。
每次迭代之間，<Codex應如何選擇下一步最佳行動>。
如果遇到阻塞或沒有有效路徑，<Codex應報告什麼、什麼能解除阻塞>。比較一個弱Goal和一個強Goal：
弱版本：
/goal 將 p95 checkout 延遲降至 120 毫秒以下，同時不引起正確性測試回退強版本：
/goal 將 p95 checkout 延遲降至 120 毫秒以下，
以 checkout 基準測試驗證，同時保持正確性測試套件全部通過。
僅使用 checkout 服務、基準測試夾具及相關測試。
在每次迭代之間，記錄變動內容、基準測試結果，以及下一步要嘗試的最佳實驗。
如果基準測試無法運行或無有效路徑剩餘，則停止，並附上已嘗試路徑、收集到的證據、阻塞點，以及所需的下一步輸入強版本里，如果p95從180ms降到135ms，Goal還沒完成。如果延遲降到120ms以下但正確性測試掛了，Goal也沒完成。如果benchmark跑不起來，Codex必須把這個阻塞報上來，而不是宣佈成功。
同樣的原則適用於生成產出物。
弱：
/goal 給這個功能寫份文檔強：
/goal 為 Goals 生成一個文檔頁面，解釋其生命週期、命令界面，並提供兩個示例。驗證該頁面在本地能夠成功構建，且所有引用的命令與當前 CLI 行為一致.第二個Goal給了Codex可以檢查的東西：一個頁面、一個構建命令、命令行為。
圖 . 強目標命名最終狀態、驗證面和約束
如果任務清楚但還不知道怎麼寫Goal，也可以讓Codex來幫寫。先用普通語言描述工作，讓Codex把它轉成Goal草稿；再審查草稿，收緊成功條件、驗證方法、約束和阻塞停止條件，然後再激活。
Goal激活後，三件事會改變
第一，目標持續可見。 如果Codex跑了一個測試、失敗了，線程裏還有原始目標。如果benchmark提升了但沒過閾值，Codex可以繼續。如果研究路徑碰到了數據缺失，Codex可以調整證據計劃，不會丟失研究標準。
第二，可以從空閒線程繼續。 Codex不會在另一輪還在跑的時候繼續，不會在用戶輸入排隊的時候繼續，不會在有其他線程工作待處理的時候繼續。只有在線程空閒、目標激活、在預算內時才繼續。
第三，完成必須有證據。 Goal不應該因為模型覺得"大概差不多了"就被標記為完成。只有把目標和具體證據對照檢查之後，比如文件改動、命令運行、測試通過、benchmark輸出、生成產物或研究證據，才能標完成。
Goals的內部設計
Goals是持久化的線程狀態，不是全局記憶，也不是項目級指令。設計上的這個選擇很重要：目標屬於有相關上下文的那個線程，包括Codex檢查過的文件、跑過的命令、產出的diff、看到的日誌、積累的推理鏈。
圖 2 目標為當前線程添加持久狀態、延續、控制和證據檢查
在架構層，Goal是一個持久的、線程範圍內的狀態。它記錄了Codex評估線程所需的目標、生命週期、預算和進度。關鍵邊界是範圍：Goal屬於當前線程，不屬於全局記憶或項目指令。
Codex把這個狀態作為用戶、模型、線程三者之間的合約。Goal可以處於激活、暫停、完成或達預算上限等狀態。這些狀態決定了Codex是否可以繼續、是否應該等用戶、還是應該彙總進度而不是開始新工作。
繼續是事件驅動的，不是簡單的循環。Codex只在安全邊界處檢查是否繼續：一輪結束後、沒有其他待處理工作時、沒有用戶輸入排隊時、線程空閒時。
圖 . Codex 僅在目標處於活動狀態、線程處於空閒狀態且沒有用戶輸入排隊時才會繼續運行
調度器的行為是有意保守的。純規劃工作不觸發繼續。被打斷會暫停目標。恢復線程時，可以在適當情況下恢復目標。如果某次繼續沒有產生任何工具調用，下一次自動繼續會被抑制，防止Codex空轉。
預算處理是明確的。達到預算上限時，Codex應該停止實質性工作，彙總進度和阻塞點，並指出下一步有用的行動。達到預算上限不等於完成目標。
工具合約讓生命週期權限保持在邊界內。模型可以發起Goal，也可以在證據支持的情況下將現有Goal標記為完成。暫停、恢復、清除和預算限制的狀態轉變，由用戶或系統控制。
用Goals做複雜研究：復現一篇量化論文
來看一個具體的研究Goal示例。
研究對象是Buehler、Gonon、Teichmann和Wood的Deep Hedging論文。這篇論文探討神經交易策略能否在不同風險偏好、交易成本和更高維度市場配置下復現基於模型的對沖。正確的Goal不是籠統地"復現這篇論文"，而是嘗試論文的核心數值結論，把精確的機制與近似訓練替代品分開，並明確說明哪些內容因為材料不足而無法精確復現。
弱版本：
/goal 復現 Buehler 等人的《Deep Hedging》這太模糊了。沒有說哪個部分重要，什麼算復現，怎麼處理訓練狀態不可用的情況，怎麼區分數值接近和精確重現。
更好的版本：
/goal 利用現有論文材料和本地資源，對 Buehler 等人的《Deep Hedging》進行最強證據支持的復現。
嘗試每一個主要結果，驗證輸出，最終形成一份報告，將復現成功的工作機制、近似訓練結果、被阻斷的精確復現路徑及剩餘不確定性區分開來說明強版本有效，因為它指定了證據標準和最終產出物。Codex不只是在嘗試做一個令人印象深刻的復現，它是在用現有證據儘量減少不確定性，同時不誇大證據所能支持的結論。
圖 一個研究目標在聲明狀態之前，先將論文分解為多個證據通道
在實際操作中，這個Goal給調查提供了一個具體的操作合約。
Codex用它來：
• 分離核心結論與支撐性結論 • 把這些結論映射到可用證據上 • 重建可以在本地測試的部分 • 標註哪些結論因缺乏可用材料而無法精確復現
有幾個部分是可行的。Codex重建了定價和對沖機制，復現了Heston參考價格，訓練了CVaR對沖實驗的策略，重建了主要的直方圖和對沖面產出物，復現了Black-Scholes交易成本斜率，併為Heston交易成本和高維示例運行了訓練檢查。
有些結論因缺少源材料而無法完成。論文沒有提供精確的隨機種子、生成的訓練路徑、TensorFlow計算圖、優化器狀態、檢查點或完整的原始模擬狀態。這意味着最終最誠實的結果是部分和近似的復現，而不是精確的神經網絡重現。
這就是Goal的價值所在。它讓工作在遇到阻塞後繼續推進，同時也讓最終語言保持誠實。訓練替代品可以支持一個結論，數值接近可以提升置信度，重建的圖表可以驗證部分結果，但這些都不應該被描述為精確還原了原始實驗。
最終報告應該保留這些不同層次的支撐，而不是把它們壓平成一個單一的"成功"聲明。
圖 最終輸出的內容，應明確區分各項結論背後有不同強度的證據支撐
舉個賬目條目的例子：
結論：在沒有交易成本的情況下，深度對沖近似了完全市場Heston對沖。
路徑：重建了模型機制，進行了參考對沖比較，訓練了神經策略。
證據來源：價格檢驗、直方圖和對沖面。
狀態：接近近似復現。
剩餘不確定性：原始訓練路徑、種子和檢查點不可用。這就是Goals在研究中的示範價值。它讓Codex在模糊中持續工作，同時防止一個似乎合理的產出物變成一個過度聲明的結論。Goal不只是讓Codex把事情做完，它定義了"做完"意味着什麼：對每個結論逐一審計，有證據支撐，明確近似之處，並對復現和重現之間的邊界保持誠實。
什麼時候不該用Goals
Goals不適合所有任務。
不要對一行代碼的修改用Goal，不要對簡單解釋用Goal，不要對短小的代碼評審用Goal，不要對你只想要一個答案然後停下來的問題用Goal。普通的Codex prompt更適合這些情況。
不要在終點線模糊的時候用Goal。"把這個做得更好"沒有給Codex可靠的完成條件。"重構這段代碼"也很弱，除非你定義了預期的最終狀態、測試和約束。
不要用Goal來掩蓋不確定性。如果數據可能不可用，在Goal裏說清楚。如果benchmark可能不穩定，說明怎麼處理。如果允許用代理證據，定義它應該怎麼標註。
Goals在三個特性同時具備時最有力：有持久目標，有基於證據的完成線，以及路徑可能需要多輪調查。
總結一下
Goals改變了Codex的運作模式。它把一個線程從一連串孤立的prompt變成了圍繞着明確結果的有狀態工作循環。
架構上是有意限制的。Goal屬於線程範圍，帶有生命週期狀態和預算，可以暫停、恢復、清除、完成或被預算停止。Codex可以繼續工作，但只能在用戶定義的合約範圍內。
這讓Goals對Codex最有價值的工作最有用：調試、優化、遷移、測試和研究。用戶提供目標，Codex跟着證據走，Goal讓兩者保持連接，直到工作要麼完成，要麼誠實地宣告受阻。
對於複雜研究，這是生成一個答案和產出一份審計報告之間的區別。好的Goal不只是讓Codex把事做完，它告訴Codex"做完"是什麼意思。
--end--
最後記得⭐️我，每天都在更新：如果覺得文章還不錯的話可以點贊轉發推薦評論
/...@作者：你說的完全正確（YAR師）