/goal 使用指南

我們推出了目標模式（或 /goal），幫助你引導 Codex 朝著具體成果前進。當你設定一個目標時，Codex 會持續工作直到目標達成，無論這需要數小時或數天。有些人已經使用 Codex 針對單一目標工作了 超過 120 小時。

目標模式非常強大，有幾件事可以幫助你充分利用它。以下是使用 /goal 時要記住的 7 件事。

**1. 明確且可驗證的標準**

你在啟動目標模式時定義的提示，不僅是初始提示，更重要的是它會作為目標的退出標準。Codex 會在每次回合後檢查目標是否已達成。因此，你的目標提示不應過長，而應專注於一個明確的達成標準。

在大多數情況下，一個好的目標包含一個明確的數字*，讓模型在目標被視為完成前達到。好的例子：

「將建置和部署時間減少 30%。」
「將此功能從 TypeScript 遷移到 Rust，並達到 100% 的測試覆蓋率。」
「改善應用程式框架，讓正式環境中的最大內容繪製時間低於 2.5 秒。」

\提示不一定總是需要數字，但通常有助於後續的技巧。*

如果你不確定如何最好地定義目標，或者想先與 Codex 腦力激盪專案，你不必以目標模式啟動對話。

Codex 可以自行設定目標，因此你可以先開始對話，當你準備好讓 Codex 開始工作時，可以要求 Codex 根據你的對話來設定目標。

你也可以隨時編輯目標，只需在 Codex 應用程式中按下編輯按鈕，或在 CLI 中再次使用 /goal 即可。

2. 盡可能提供指引

發送像 「將建置和部署時間減少 30%」 這樣的提示可能很酷，甚至能找到一些創新的解決方案。但如果你對問題所在有想法，它也可能讓 Codex 白費力氣。

盡可能給 Codex 一個起點，告訴它可以使用哪些工具來達成目標，或任何其他可以避免 Codex 走錯路的提示。

例如，我的同事 @reach_vb 在他的一個實驗中就是這樣做的，他告訴 Codex 可以使用 Chrome 瀏覽器進入 Google Colab，以及一些可接受的限制，例如在讓 Codex 訓練模型時自行生成數據集。

同樣地，如果你想要減少建置時間，並且知道大部分時間花在哪裡，試著在提示中先將 Codex 引導到那個區域。

或者，你甚至可以讓 Codex 先在計劃模式下進行一些初步研究，並讓 Codex 建立一個計劃檔案，用來記錄可能的選項。然後讓你的目標參考那個計劃。

3. 讓進度可衡量

如果你的目標很有野心，或者 Codex 有多種方式可以接近目標，那麼給 Codex 衡量進度的工具就很重要。

對於某些任務，這可能是顯而易見的，例如改善建置時間或增加測試覆蓋率，因為 Codex 通常已經擁有或自然會建立這些工具。

對於其他目標，值得與 Codex 腦力激盪哪些工具會有幫助，或暗示它一些了解進度的方法。例如，建立工具來計算兩個螢幕截圖之間的視覺差異，或為你正在調整的 Agent 建立一個評估套件。

當我讓 Codex 從一個影片中重建一些元件時，我讓 Codex 為自己建立一個工具，能夠比較螢幕截圖並檢查差異。它選擇隨著時間演進這個工具，使其擁有不同的差異模式。

Codex 生成的一張用於視覺比較兩個畫面的螢幕截圖

根據你的任務，你也需要考慮是否有其他需要衡量/檢查的標準，這些標準可能讓 Codex 認為任務已完成，但你卻認為尚未完成。例如，透過裁剪設計靈感並內嵌來實現「像素級完美」的 UI，或者透過減少測試覆蓋率來達到 100% 的測試通過率。

4. 建立一個逼真的環境

為了讓 Codex 真正朝著目標前進，它需要在一個逼真的環境中運作。實際上，這意味著如果你正在嘗試改善部署時間或延遲問題，它應該能夠存取模擬正式環境的部署和測試環境。因此，需要相同的技術棧、相同的標誌、類似的資料庫。

舉例來說，我們正在為 developers.openai.com 調試建置和部署時間的改善。我們已經在使用部署預覽，所以 Codex 可以使用它們來部署並查看相關日誌，但我們的預覽部署與完整的正式環境運行相比，停用了某些建置路徑。因此，Codex 不得不手動部署到具有類似正式環境配置的相同環境中來檢查環境。

同樣地，你可以讓 Codex 使用電腦使用來測試實際的應用程式。為了改善 iOS 上的某些效能，@dimillian 甚至使用了實體設備來獲得最準確的環境。

5. 小心視覺目標

給 Codex 一個視覺目標，例如 「根據這張圖片，100% 像素級完美地實現這個 UI」 很誘人，但根據設定方式，也可能會造成一些麻煩。

如果你沒有給予正確的指引和限制，它可能會在一些問題上鑽牛角尖，而忽略了整體目標。例如，如果參考資料包含 Codex 需要生成的圖形（無論是 SVG 圖示還是圖片），它可能會迷失在讓這些圖形精準上，而不是適當地分析問題。

此外，Codex 需要工具來正確進行視覺比較，這意味著更多的圖像輸入和更高的整體 token 使用量，而不一定能讓 Codex 輕易找到機會。

相反地，圖像通常可以作為有幫助的上下文來推動目標，但你應該找到其他方式讓 Codex 確認目標已達成，例如功能檢查清單、要實作的規格、對設計系統的遵循程度等。

6. 追蹤進度

如果 Codex 在背景（甚至是在另一台機器上）連續工作數小時或數天，很容易失去對 Codex 進度或已完成工作的掌握。根據目標的不同，我發現有幾件事有助於跟上進度：

要求 Codex 在有意義的步驟進行提交，並推送到一個草稿 PR。這在你處理一個有預覽部署的網站時特別有用。
讓 Codex 為主管更新一個成品。這可以是一個 HTML 檔案，你可以保持在應用程式內瀏覽器中開啟，甚至可以使用 Sites 部署給你的團隊，也可以是一張追蹤進度的渲染圖表圖像，或是一個純粹的 Markdown 檔案。
指示 Codex 發布更新。你也可以在目標中要求 Codex 將重大進展回報到 Slack 頻道或其他你想要記錄進度的地方。
使用其他對話來詢問狀態更新。如果你只是想快速了解當前狀態，可以執行 /side 來啟動一個新的側邊對話並在那裡提問。因為它會分岔當前的對話，所以擁有到目前為止的所有上下文，但也是短暫的。在 Codex 應用程式中，另一種方法是讓 Codex 在一個新的普通對話中讀取另一個目標對話並回答你的問題。如果你要求 Codex 安排一個自動化任務來定期檢查，這會特別強大。