原文標題：A guide to /goal
原文作者：@dkundel，OpenAI 開發者關係成員
編譯：Peggy

編者備：這篇文章來自 OpenAI 開發者關係成員 Dominik Kundel，對 Codex「goal mode / /goal」功能的使用經驗進行總結。它討論的並不是一個普通 prompt 技巧，而是 AI 編程工具正在發生的一次角色變化：Codex 不再只是響應單輪指令的程式碼助手，而開始成為一個可以圍繞明確目標持續推進的執行型 Agent。

在 /goal 模式下，真正重要的不是把需求寫得越長越細，而是為 Codex 設定清晰、可驗證的退出標準。比如「部署時間降低 30%」「測試覆蓋達到 100% parity」「LCP 降到 2.5 秒以下」。這些指標讓 Codex 能夠判斷任務是否完成，也避免它在模糊目標中無限嘗試。與此同時，用戶還需要提供足夠的方向、工具和真實環境，讓 Codex 能衡量進展、驗證結果，而不是只在本地或假設條件下完成一個看似可行的方案。

文章尤其提醒，視覺類任務最容易讓 Codex 陷入細節泥淖。與其要求「100% 像素級還原」，不如將視覺目標拆解為功能清單、設計系統規範和可評估指標。對於持續數小時甚至數天的長期任務，也需要通過 commit、draft PR、進度文件、Slack 更新或 side chat 等方式持續跟蹤，避免最終只得到一堆不可追溯的改動。

這篇文章的資訊增量在於，它把 /goal 重新定義為一種「長期任務管理機制」。當 AI 可以連續執行幾十甚至上百小時，開發者的核心能力也隨之變化：不只是讓 AI 生成程式碼，而是為它定義目標、建立度量體系、配置執行環境，並在最後完成審查和複盤。換句話說，AI 編程正在從「寫提示詞」走向「管理一個持續工作的工程執行者」。

以下為原文：

我們推出了目標模式（goal mode，或 /goal），是為了幫助你讓 Codex 朝向一個具體結果持續推進。當你設定一個目標後，Codex 會一直工作，直到目標達成——無論這需要幾個小時，還是幾天。已經有人讓 Codex 為同一個目標連續工作超過 120 小時。

目標模式非常強大。想要最大化發揮它的作用，使用 /goal 時有 7 件事值得注意。

設定清晰、可驗證的標準

當你啟動目標模式時輸入的提示詞，既可以作為初始提示，更重要的是，它會成為這個目標的退出標準。Codex 會在每一輪工作之後檢查：這個目標是否已經完成。

因此，你的目標提示不應該寫得過長，而應該聚焦於一個清晰標準：什麼情況下，才算這個目標已經達成。

多數情況下，一個好的目標最好包含一個明確的數字指標，供模型判斷是否完成。例如：

「將建置和部署時間減少 30%。」

「把這個功能從 TypeScript 遷移至 Rust，並達到 100% 的測試一致性。」

「優化應用腳手架，使生產環境中的最大內容繪制（Largest Contentful Paint，衡量頁面主要內容加載速度的指標）低於 2.5 秒。」

這個提示不一定總要包含數字，但通常來說，數字會讓後續步驟更容易推進。

如果你還不確定該如何定義目標，或者想先和 Codex 一起頭腦風暴這個項目，也不必一開始就用目標模式開啟對話。

Codex 可以自行設定目標。你可以先正常開啟一段對話，等你準備好讓 Codex 開始執行時，再讓 Codex 根據前面的討論內容設定目標。

你也可以隨時編輯目標：在 Codex 應用中點擊編輯按鈕，或在 CLI 中再次使用 /goal。

盡可能提供指引

像「將建置和部署時間減少 30%」這樣的提示，聽起來很酷，也可能讓 Codex 找到一些創造性的解決方案。但如果你已經大致知道問題可能出在哪裡，這種提示也可能讓 Codex 走上彎路。

所以，在可能的情況下，最好告訴 Codex 應該從哪裡開始排查、可以使用哪些工具來完成目標，或者給出其他提示，避免它鑽進錯誤方向。

例如，我的同事 @reach_vb 在一次实验中就这样做了：他告诉 Codex，可以使用 Chrome 浏览器进入 Google Colab，并说明了一些可接受的限制条件，比如在让 Codex 训练模型时，可以让它自己生成数据集。

同样，如果你想縮短建置時間，並且已經知道大部分時間消耗在哪個環節，最好在提示詞中先把 Codex 指向那個區域。

另一種做法是，你可以先讓 Codex 在計劃模式（plan mode）下做一些初步研究，並讓它創建一個計劃檔案，用來記錄潛在方案。隨後，再讓你的目標引用這份計劃。

讓進展可衡量

如果你的目標很有野心，或者 Codex 有很多種方式可以逐步接近目標，那麼很重要的一點是：你要給 Codex 提供衡量進展的工具。

對於某些任務來說，這一點可能天然成立。比如優化建置時間、提高測試覆蓋率，因為 Codex 通常已經能使用相關工具，或者會自然地創建這些工具。

但對於其他目標，你最好先和 Codex 一起頭腦風暴：哪些工具有助於判斷進展？或者給它一些提示，讓它知道該如何確認自己是否正在向目標靠近。例如，為兩個截圖創建視覺差異比對工具，或者為你正在調試的智慧體創建一套評估集。

我曾讓 Codex 根據一段視訊複刻一些元件，當時 Codex 為自己創建了一個工具，用來比較截圖並檢查差異。後來，它還持續迭代這個工具，加入了不同的差異比對模式。

圖片：Codex 生成的一張截圖，用於對兩個畫面幀進行視覺對比。

根據任務不同，你還需要考慮是否有一些額外標準需要被測量或檢查。否則，Codex 可能會以為任務已經完成，但在你看來其實還不完整。

比如，Codex 可能為了「像素級還原」某個 UI，直接裁剪設計參考圖並內嵌到頁面裡；或者為了讓測試通過率達到 100%，反過來削減測試覆蓋範圍。這些都不是你真正想要的完成方式。

建立真實環境

如果你希望 Codex 真正朝目標取得有效進展，它就需要在一個足夠真實的環境中運行。

在實踐中，這意味著：如果你想優化部署時間或延遲問題，Codex 應該能訪問部署和測試環境，而且這些環境要盡可能模擬生產環境。也就是使用相同的技術棧、相同的配置開關，以及類似的數據庫。

舉個例子，我們曾經在調試 developers.openai.com 的構建和部署時間優化。當時我們已經在使用部署預覽，因此 Codex 可以利用這些預覽環境進行部署，並查看相關日誌。但問題在於，我們的預覽部署和完整生產環境相比，禁用了一些構建路徑。

因此，Codex 最後不得不進行手動部署，把代碼部署到與生產配置更接近的環境中，才能真正檢查問題所在。

類似地，你也可以讓 Codex 使用 computer use（讓模型操作真實應用界面的能力）來測試實際應用。為了優化 iOS 上的一些性能問題，@dimillian 甚至使用了實體設備，以獲得最準確的測試環境。

謹慎設定視覺目標

給 Codex 一個視覺目標，比如「根據這張圖片 100% 像素級還原這個 UI」，確實很誘人。但根據具體設定不同，這也可能帶來麻煩。

如果你沒有給出合適的指引和約束，Codex 可能會在某些細節上越陷越深，反而忽略整體目標。比如，如果參考圖中包含一些圖形元素，而你期待 Codex 生成這些元素——無論是 SVG 圖標還是圖片——它可能會把大量精力耗在「如何精確複刻這些素材」上，而不是正確拆解整個問題。

此外，Codex 需要工具才能正確進行視覺比較。這意味著更多圖片輸入、更高的整體 token 消耗，但並不一定能給 Codex 提供一種簡單方式，讓它識別真正有價值的改進機會。

所以，圖片通常更適合作為目標上下文，而不是唯一的完成標準。你應該尋找其他方式，讓 Codex 判斷目標是否已經達成，例如功能清單、實現規範、是否符合設計系統等。

追蹤進展

如果 Codex 最終在背景工作數小時甚至數天，甚至是在另一台機器上運行，你很容易忘記它到底推進到哪裡、已經做了哪些工作。

根據不同目標，我發現下面幾種方式很有幫助：

·讓 Codex 在關鍵節點提交代碼，並推送到一個草稿 PR。尤其是當你在做網站，並且有預覽部署時，這會非常有用。

·讓 Codex 更新一份面向管理層的交付物。它可以是一個 HTML 檔案，你可以在應用內瀏覽器裡一直打開；也可以是·一個通過 Sites 部署給團隊查看的頁面；可以是一張渲染後的進度圖，也可以只是一份普通的 Markdown 檔案。

指示 Codex 主動發布進展更新。你也可以把這寫進目標裡：讓 Codex 在取得重要進展時，把更新發送到 Slack 頻道，或者你希望記錄進展的其他地方。

使用其他聊天窗口詢問狀態。如果你只是想快速了解當前狀態，可以運行 /side 啟動一個新的側邊聊天，並在那裡提問。因為它會從當前線程分叉出來，所以擁有截至目前的全部上下文，但生命週期很短。

在 Codex 應用中的另一個替代方法是：開啟一個普通新聊天，讓 Codex 閱讀另一個目標線程，並回答你的問題。如果你讓 Codex 設置一個自動化任務，定期檢查進展，這種方式會尤其強大。

清理並最終確認結果

太好了，目標終於完成了！現在是不是就可以直接把成果甩給團隊，然後收工？

通常來說，尤其是在優化類任務中，我發現讓 Codex 複習並審查自己完成的工作會很有幫助。你可以先用 /review 運行一次本地代碼審查，但也值得讓 Codex 更深入地反思：它為達成目標嘗試過哪些路徑？哪些嘗試有效？哪些嘗試無效？然後據此清理代碼。

因為 Codex 會一直工作，直到達到目標，所以它可能嘗試過一些效果不夠好、甚至完全無效的方法，而這些殘留改動可能還留在最終代碼中。

給你的下一個任務也設一個 goal

Codex 的目標功能是一個極其強大的工具，可以幫助你解決一些最有意義的工程挑戰。但只有當你提供了正確的環境和指令，它才能更高效地抵達目標。

你用 /goal 做過什麼？

[原文連結]

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia