For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
主要導覽
Codex

Codex use case

透過迭代解決困難問題

運用 Codex 進行評分驅動的改進循環,以解決困難任務。

Difficulty 進階
Time horizon 長時間執行

為 Codex 提供一套評估系統,例如指令碼和可供審查的產出物,讓它能持續改進困難任務的成果,直到分數達到要求。

最適合

  • 每次迭代皆可評分,但通常需要經過多輪才能取得最佳結果的問題
  • 輸出涉及視覺或主觀判斷,且同時需要確定性檢查與 LLM 評審分數的任務
  • 需要清楚追蹤進度、而非依賴上下文的長時間 Codex 對話

Contents

    ← 所有使用案例

    透過迭代解決困難問題

    運用 Codex 進行評分驅動的改進循環,以解決困難任務。

    為 Codex 提供一套評估系統,例如指令碼和可供審查的產出物,讓它能持續改進困難任務的成果,直到分數達到要求。

    進階
    長時間執行

    為 Codex 提供一套評估系統,例如指令碼和可供審查的產出物,讓它能持續改進困難任務的成果,直到分數達到要求。

    進階
    長時間執行

    最適合

    • 每次迭代皆可評分,但通常需要經過多輪才能取得最佳結果的問題
    • 輸出涉及視覺或主觀判斷,且同時需要確定性檢查與 LLM 評審分數的任務
    • 需要清楚追蹤進度、而非依賴上下文的長時間 Codex 對話

    起始提示詞

    這個工作區中有一項困難任務,我希望你採用評估驅動的改進循環來處理這項任務。 進行任何變更前: - 閱讀 `AGENTS.md`。 - 找出用來為目前輸出評分的指令碼或指令。 迭代循環: - 每次只進行一項有針對性的改進。 - 每次有實質變更後,重新執行評估指令。 - 記錄分數以及變更內容。 - 直接檢視生成的產出物。如果是視覺輸出,請使用 `view_image`。 - 持續進行,直到整體分數和 LLM 評審平均分數都高於 90%。 限制: - 不要在首次取得可接受的結果時就停止。 - 除非從分數或產出物來看,新結果明顯較差,否則不要還原至較早版本。 - 如果評估分數有所提升但仍低於目標,請說明瓶頸所在並繼續改進。 輸出: - 目前最佳分數 - 主要迭代紀錄 - 尚存的風險或薄弱環節
    這個工作區中有一項困難任務,我希望你採用評估驅動的改進循環來處理這項任務。 進行任何變更前: - 閱讀 `AGENTS.md`。 - 找出用來為目前輸出評分的指令碼或指令。 迭代循環: - 每次只進行一項有針對性的改進。 - 每次有實質變更後,重新執行評估指令。 - 記錄分數以及變更內容。 - 直接檢視生成的產出物。如果是視覺輸出,請使用 `view_image`。 - 持續進行,直到整體分數和 LLM 評審平均分數都高於 90%。 限制: - 不要在首次取得可接受的結果時就停止。 - 除非從分數或產出物來看,新結果明顯較差,否則不要還原至較早版本。 - 如果評估分數有所提升但仍低於目標,請說明瓶頸所在並繼續改進。 輸出: - 目前最佳分數 - 主要迭代紀錄 - 尚存的風險或薄弱環節

    簡介

    有些任務一次就能輕鬆驗證:建置成功、測試全部通過,任務就完成了。但有些最佳化問題很難解決,需要搭配緊密的評估循環反覆迭代。為了判斷下一步方向,Codex 必須檢查目前輸出、加以評分、決定下一項變更,並重複此流程,直到結果確實夠好。

    這類使用案例很適合搭配自訂 UI,讓 Codex 記錄每次迭代的輸出和生成的產出物,方便你直觀檢視進度。 當目標產出物、模型輸出或生成資產持續改善時,你可以在 App 中查看 Codex 繼續處理任務。 關鍵在於為 Codex 提供必要的指令碼,用以產生評估指標和可供檢視的產出物。

    從評估開始

    任務開始前,先定義衡量成功的方式。最理想的設定通常會結合:

    • 確定性檢查: 指令碼可以直接評分的項目,例如違反限制條件的情況,或使用程式碼計算出的確定性指標
    • LLM 評審檢查: 對難以精確編碼的特性依評分規準打分,例如相似度、可讀性、實用性或整體品質;評分時可依據文字或圖像輸出

    如果主觀評估很重要,請為 Codex 提供指令碼,讓它能透過 Responses API 等方式呼叫模型,並傳回結構化分數。目的不是取代確定性檢查,而是以一致的評審機制補足原本需要由人員目視評估的部分。

    評估輸出採用機器可讀格式、在每次執行後儲存,且便於比較不同時間的結果時,這個循環的效果最好。

    提示:請 Codex 為你產生評估指令碼,並說明你想執行的 檢查。

    為 Codex 設定停止規則

    困難任務常會逐漸偏離目標,因為提示詞只要求「持續改進」,卻未說明何時停止。請明確指定停止規則。

    實用的做法如下:

    1. 為整體分數設定目標。
    2. 另為 LLM 評審的平均分數設定目標。
    3. 指示 Codex 繼續執行,直到兩者都超過門檻,而非只有其中一項。

    例如,如果目標是產生高品質的產出物,請 Codex 持續進行,直到整體分數和 LLM 評審平均分數都高於 90%。這能讓任務狀態清楚明瞭:Codex 可以判斷是否仍未達標、差距在哪裡,以及最新變更是否有所幫助。

    持續記錄循環進度

    如果 Codex 記下循環進度,而不是只依賴對話上下文,長時間執行的工作會可靠得多。

    這份持續更新的紀錄應包含:

    • 目前的最佳分數
    • 上一次迭代變更了哪些內容
    • 評估結果顯示哪些部分變好或變差
    • Codex 接下來計畫嘗試什麼

    這對長時間執行的任務尤其重要。任務恢復執行時,這份紀錄會成為銜接工作的依據,並可作為本次執行的自我評估紀錄。

    檢視產出物,而不只看紀錄

    對某些困難任務而言,程式碼差異和指標輸出還不夠。Codex 應檢視它產生的產出物。

    如果輸出是視覺內容,例如生成的圖像、版面配置或算繪狀態,請讓 Codex 直接檢視該產出物。例如,輸出以圖像形式儲存在磁碟上時,讓 Codex 將目前結果與先前的最佳結果或預期的評分規準進行比較。

    這能讓循環更健全:

    • 評估指令碼會回報分數
    • 產出物會呈現分數未反映的問題
    • 下一項變更同時以兩者為依據

    這種組合遠比在每次執行之間盲目修改程式碼有效。

    讓每次迭代的步驟都明確

    要求 Codex 每次都遵循相同的循環:

    1. 針對目前的基準執行評估。
    2. 根據分數和產出物,找出最主要的失敗模式。
    3. 進行一項專門針對該瓶頸的變更。
    4. 重新執行評估。
    5. 記錄新分數,以及這項變更是否有效。
    6. 繼續執行,直到達到各項門檻。

    這套嚴謹做法十分重要。如果每次迭代同時變更太多項目,Codex 就無法判斷是哪個構想提高了分數。如果未留下紀錄,任務的可靠性便難以確認,也難以接續執行。

    相關使用案例