用 Codex 升級 API 接入

你是 Codex API 升級規劃顧問，幫我規劃把程式碼安全遷移到新版本 API，處理好破壞性變更。

【角色】
你知道怎麼用 Codex 升級 API 接入、怎麼識別破壞性變更、怎麼小步遷移並回歸驗證。

【輸入】
- 要升級的 API 和目標版本：___
- 目前的接入方式和涉及範圍：___
- 是否有破壞性變更說明：___
- 現有測試覆蓋：___

【工作流程】
1. 先盤點受影響的接入點
2. 識別破壞性變更，列出要改的地方
3. 小步遷移，每步可驗證
4. 升級後做迴歸驗證

【輸出規範】
▌一、受影響接入點盤點
▌二、破壞性變更清單
▌三、小步遷移方案
▌四、迴歸驗證

【硬約束】
- 破壞性變更逐項處理，不漏
- 小步遷移、每步驗證，不一次全換
- 升級前確認目標版本相容性
- 測試不足先補關鍵路徑
- 不確定的變更標註需查 API 官方文件
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述

OpenAI API 升級通常不只是把 model name 改掉。API 引數、prompt 寫法、tool 假設、response shape 和模型行為都可能變化。

推薦流程

flowchart LR
    Inventory["inventory"] --> Docs["official docs"]
    Docs --> Plan["minimal migration plan"]
    Plan --> Change["code / prompt / tools"]
    Change --> Evals["tests / evals"]
    Evals --> Review["human review"]

適合 Codex 的 API 升級任務：

• 盤點儲存庫裡所有 OpenAI 呼叫點。
• 查目前官方模型、API 和 prompt guidance。
• 找到最小遷移方案。
• 更新程式碼、prompt、tool assumptions 和 response parsing。
• 標出需要人工 review 的行為變化。
• 構建 evals pipeline。

不適合：

• 只把 model string 換成“最新版”。
• 不看 response shape 就改解析邏輯。
• 不跑測試和 evals 就上線。
• 把遷移期間的行為變化當成“模型更聰明”而不記錄。

起始提示詞

請使用 OpenAI 官方 docs，把這個 OpenAI integration 升級到目前受支援、適合本專案的模型和 API 能力。

要求：
- 先盤點儲存庫裡目前使用的 models、endpoints、tools、response parsing 和 prompts
- 查目前官方 model guidance、prompt guidance 和 migration notes
- 制定最小遷移方案
- 除非新 API 或新模型明確要求，否則保持現有業務行為不變
- 標出需要人工 review 的 prompt、tool 或 response-shape 變化
- 跑現有 tests，並建議最小 evals 集合

這個 prompt 的核心是先查官方文件，再看儲存庫現狀。不要直接說“換成最新模型”。

為什麼不能只改 model name

模型升級經常牽動三類變化：

• API 變化：引數、tool calling、streaming、structured output 或 response shape 可能不同。
• 行為變化：輸出偏好、推理深度、tool 使用方式可能不同。
• prompt 變化：舊 prompt 在新模型上可能還能跑，但不一定仍是推薦寫法。

因此遷移時至少要同時看程式碼、prompt、tool assumptions 和評估結果。

盤點內容

讓 Codex 先列出：

• OpenAI SDK 版本。
• endpoint / API surface。
• model names。
• temperature、reasoning、response format 等引數。
• function / tool schemas。
• system、developer、user prompts。
• response parsing。
• retry、timeout、rate limit 策略。
• tests 和 evals 覆蓋情況。

盤點結果儲存成短報告，作為 migration diff 的依據。

推薦遷移順序

1. 盤點呼叫點和行為契約。
2. 查目前官方 docs 和 migration guidance。
3. 寫最小遷移計劃。
4. 修改 API 引數和模型呼叫。
5. 更新 prompt，但保留業務目標和輸出契約。
6. 標出 prompt、tool、response shape 變化。
7. 執行現有測試。
8. 增加或執行 evals。
9. 對失敗樣例做差異分析。
10. 人工 review 行為變化後再擴大 rollout。

Evals pipeline

每次改整合都應該跑一次 evals，確認關鍵 workflow 沒有行為退化。

最小 evals 覆蓋：

• 代表性輸入。
• 期望輸出或評分標準。
• tool calling 是否仍按預期發生。
• response shape 是否相容下游解析。
• 關鍵業務場景是否保持質量。
• 失敗樣例是否能解釋。

沒有 evals 的模型升級，很容易變成“程式碼能跑，但業務行為變了”。

驗收清單

• 官方 docs 已核對，連結記錄在遷移說明裡。
• 所有呼叫點、prompts、tools、response parsing 已盤點。
• 改動是最小遷移，不是順手重構。
• 測試和 evals 已執行。
• 行為變化和未驗證項寫清。
• 回復路徑明確。

官方資料

• Codex: API integration migrations
• Latest model guide
• Prompt guidance
• OpenAI Docs MCP
• Evals guide