OpenAI 近期釋出了一份他們如何使用 Codex 的文件，可以當作使用上的參考，以下為文件的中文翻譯內容：
引言
Codex 每天被 OpenAI 的許多技術團隊所使用，例如安全團隊（Security）、產品工程（Product Engineering）、前端（Frontend）、API、基礎設施（Infrastructure）、與效能工程（Performance Engineering）。這些團隊運用 Codex 來加速各種工程任務，從理解複雜系統與重構大型程式碼庫，到在緊迫時限內發佈新功能與處理故障事故。
從與 OpenAI 工程師的訪談與內部使用資料中，我們整理了用例與最佳實踐，凸顯 Codex 如何幫助各團隊更快前進、提升工作品質、並在大規模系統中管理複雜性。
用例（Use Cases）
用例 1：程式碼理解（Code understanding）
Codex 幫助我們的團隊在不熟悉的程式碼區域中快速上手，例如在新人導入（onboarding）、除錯（debugging）、或是調查事故時。
它常被用來定位某個功能（feature）的核心邏輯、繪出服務或模組間的關係、追蹤系統中資料流向。它也能揭露架構模式或是缺少的文件說明，如果沒有 Codex，這些通常需要大量人工工作來完成。
在事故回應（incident response）期間，Codex 幫助工程師迅速熟悉新的區域，透過揭露元件間的互動或追蹤失敗狀態在系統中的傳播方式。
團隊的例子：
-
「當我要修一個錯誤時，我用 Ask 模式（Ask mode）看程式庫中還有哪裡可能出現相同問題。」 — 效能工程師（Performance Engineer），檢索系統（Retrieval Systems）
-
「當我值班(on-call)時，我貼上 stack trace 並問 Codex 認證(auth)流程在哪裡。它直接跳到正確的檔案，讓我可以快速 triage。」 — 站點可靠性工程師（Site Reliability Engineer），API 平台（API Platform）
-
「Codex 回答我在不同 repo 中 ‘我會在哪裡做這件事?’，從 Terraform 與 Python 的 repo 問答，比 grep 快很多。」 — DevOps 工程師，基礎服務（Infrastructure Services）
可嘗試的提示（sample prompts）：
-
這個 repo 中的認證邏輯是在哪裡實作的？
-
總結請求從入口點 (entrypoint) 到回應 (response) 是如何通過這個服務流動的。
-
哪些模組與 [插入模組名稱] 有互動，以及失敗情況是如何被處理的？
用例 2：重構與遷移（Refactoring and migrations）
Codex 常被用來處理跨多個檔案或套件（packages）的變更。例如在更新 API、改變某種設計模式的實作方法、或移轉依賴項（dependency）時，Codex 可以協助一致性地應用變更。
當相同的更新需要在數十個檔案中被執行，或是更新需要對結構與依賴有敏銳意識但這些依賴不容易用正則表達式（regex）或簡單的搜尋替換做到時，Codex 特別有用。
它也被用於程式碼清理，例如拆分過大的模組、用現代的模式替換舊有模式，或為更好的可測試性 (testability) 做準備。
團隊的例子：
-
Codex 在幾分鐘內就替我們把所有 legacy 的某模式換成新的服務模式，並提出 pull request，這如果人工做要花好幾小時。 — 後端工程師，ChatGPT Web
-
當我們有啟動性 (launch) 阻礙問題時，我請 Codex 搜尋所有舊模式的實例，寫 Markdown 彙總影響，然後開 PR 做修正。 — 產品工程師，ChatGPT Enterprise
可嘗試的提示：
-
按關注範疇（concern）把這個檔案拆成多個模組，並為每一個模組生成測試。
-
把所有以 callback 為基礎的資料庫存取轉為 async/await。
用例 3：效能優化（Performance optimization）
Codex 被用來辨識與解決效能瓶頸。
在效能調整（tuning）或可靠性 (reliability) 的工作中，工程師會提示 Codex 分析較慢或佔用大量記憶體的程式碼路徑，例如效率不佳的迴圈、冗餘操作、或代價高昂的查詢 (queries)，並建議優化替代方案，常常能帶來明顯的效率與可靠性改善。
Codex 也用來支持程式碼健康（code health），找出風險高或過期模式（deprecated pattern）還在被活躍使用的情況。我們的團隊仰賴它來減少長期的技術債務並主動預防回歸（regressions）。
團隊的例子：
-
「我用 Codex 搜 repeated expensive DB calls。它很擅長標出 hot paths 並草擬出可批次處理的查詢 (batched queries) 等我再做調優。」 — 基礎設施工程師 (Infrastructure Engineer)，API 可靠度 (API Reliability)
-
「Codex 很快指出效能問題 — 我花 5 分鐘提示問題，就能省掉 30 分鐘的工作。」 — 平台工程師，Model Serving
可嘗試的提示：
-
優化此迴圈以提升記憶體效率，並解釋為何你的版本較快。
-
找出這個 request 處理器中重複且昂貴的操作，並建議可以快取 (caching) 的機會。
-
為這個函式找一種更快的批次 DB 查詢方式。
用例 4：提升測試覆蓋率（Improving test coverage）
Codex 幫工程師更快地撰寫測試 — 特別是在測試覆蓋率薄弱或完全缺失的地方。
在修 bug 或重構時，工程師常常請 Codex 建議涵蓋邊界條件或可能失敗的情況 (failure paths) 的測試。對新程式碼，它可以根據函式簽名 (function signature) 與周邊邏輯產生單元測試 (unit tests) 或整合測試 (integration tests)。
Codex 尤其有助於發現那些常被遺漏的邊界條件，例如空輸入 (empty inputs)、最大長度 (max length)、或是不太常見但仍合法的狀態。
團隊的例子：
-
「我把 Codex 指向測試覆蓋率低的模組，隔天醒來就看到可運行的單元測試 PRs。」 — 前端工程師，ChatGPT Desktop
-
「當 mono-repo 的分支切換很麻煩時，我讓 Codex 寫測試，啟動 CI（持續整合）流程，同時我繼續處理我的分支。」 — 後端工程師，Payments & Billing
可嘗試的提示：
-
為這個函式撰寫單元測試，包括邊界情況與失敗情況。
-
為這個排序工具 (sorting utility) 產生 property-based test。
-
擴充這個測試檔案以涵蓋有關空輸入與無效狀態的情況。
用例 5：加快開發速度（Increasing development velocity）
Codex 通常幫助團隊更快行動，加速開發週期的開始與結束。
當要啟動新功能時，工程師會用它來快速生成 boilerplate（樣板程式碼）— 建立資料夾、模組與 API stub，讓程式碼能快速跑起來，而無需手動搭建每一部分。
當專案接近發布階段時，Codex 幫忙處理小但重要的任務，如 triage bugs、補齊最後的實作細節、生成 rollout 腳本、遙測鉤子（telemetry hooks），或是配置檔案。
它也常被用來把產品反饋 (product feedback) 變成起始程式碼。工程師會貼上使用者請求或規格 (spec)，讓 Codex 先產出初稿，之後再修正。
團隊的例子：
-
「我整天開會，但還是靠 Codex 在背景幫我合併了 4 個 PRs。」 — 產品工程師，ChatGPT Enterprise
-
「Codex 幫忙發佈 backlog 中那些低優先度的修正，好幾項如果沒有它可能會一直拖下去。」 — 全端工程師，Internal Tools
可嘗試的提示：
-
搭建新 API 路由 (POST /events) 的 boilerplate，包括基本驗證與日誌記錄（logging）。
-
為追蹤新加入流程成功／失敗的情況生成 telemetry hooks。
-
根據規格（spec 或產品反饋）產生 stub 實作。
用例 6：保持工作流程不中斷（Staying in flow）
當工作時間被打斷或排程被切碎時，Codex 幫助工程師保持生產力。
它可以用來捕捉未完成的工作，把筆記變成可工作的原型 (prototype)，或是啟動探索性的任務，之後再回來繼續。這樣即使在值班(on call)或開很多會議的情況下，也比較不會失去上下文 (context)。
團隊的例子：
-
「如果我看到一個臨時的修正(drive-by fix)，我就開一個 Codex 任務，而不是切換分支去 review PR，等我空時再弄。」 — 後端工程師，ChatGPT API
-
「我常把 Slack 討論串、Datadog traces、Issue 等資料轉給 Codex，這樣我可以繼續專注做重要的事。」 — API 工程師／基礎設施觀察能力 (Infrastructure Observability)
可嘗試的提示：
-
為此服務生成一個重構（refactor）計畫，並把它拆成較小的模組。
-
暫時 stub 出 retry 邏輯，加個 TODO — 我稍後補 backoff 的部分。
-
總結這個檔案，讓我隔天可以馬上接續做我昨天中斷的部分。
用例 7：探索與構思（Exploration and ideation）
Codex 也很適合用在開放式的工作 (open-ended work)，例如找替代方案（alternative solutions）或驗證設計決策 (design decisions)。你可以提示它嘗試不同的解題方式、探索不熟悉的程式設計模式、或對假設前提進行壓力測試 (pressure-test)。這幫助發現折衷 (trade-offs)、擴大設計選項並讓實作選擇更清晰。
它也能用來識別相關 bug：給定已知問題或過時的方法 (deprecated method)，Codex 可以找出程式中類似的模式，幫助我們抓到可能的回歸，或完成清理（cleanup）工作。
團隊的例子：
-
「Codex 幫我解決 cold-start 問題 — 我貼上 spec 與文件，它幫我 scaffold 程式碼或指出我漏了什麼。」 — 產品工程師，ChatGPT Desktop
-
「我修完一個 bug 後會問 Codex 哪些相似 bug 可能還藏在哪裡，然後開後續任務。」 — 效能工程師，檢索系統 (Retrieval Systems)
可嘗試的提示：
-
如果系統是事件驅動 (event-driven) 而不是 request/response，它會怎麼運作？
-
找出所有手動組 SQL 字串 (manually build SQL strings) 的模組，而不是用我們的查詢建構器 (query builder)。
-
用一種更函式式 (functional) 的風格重寫這部分，避免 mutation（變異）和副作用 (side effects)。
最佳實踐（Best Practices）
Codex 在給予良好結構、上下文與迭代空間時表現最好。以下是 OpenAI 各團隊在日常工作中培養，以從 Codex 獲得穩定價值的習慣。
-
從 Ask 模式開始：對於大型變更，先以「計劃實作（implementation plan）」為目標使用 Ask 模式，之後在切換到 Code 模式 (Code Mode) 作後續提示。這個兩階段流程幫助保持 Codex 的輸出有根有據並避免錯誤。
-
Codex 的任務大小要適中：任務範圍最好是你或你的同事約一小時可以完成，或是幾百行程式碼的變更。隨著模型改進，預期它能處理的任務會越來越大。
-
漸進改善 Codex 的開發環境：設置啟動腳本 (startup script)、環境變數 (environment variables) 與網際網路存取 (internet access) 能顯著減少 Codex 出錯的比例。當你運行任務時，注意編譯錯誤 (build errors) 可以在 Codex 的環境配置中修正。這可能需做幾次調整，但長期能帶來效率提升。
-
提示要有結構地撰寫：類似你在 GitHub Issue 中怎麼描述一個變更那樣來撰寫提示（prompt），包括檔案路徑、元件名稱、差異 (diffs)、文件片段 (doc snippets) 等相關資訊。若合適，提示中可說 “按照 [模組 X] 的方式實作”。這樣可以提升輸出的準確性。
-
使用 “Best of N” 功能來改善輸出：這個功能可讓你對一個任務同時產生多個回應（responses），快速探索不同解法並挑出最好的。對於比較複雜的任務，你可以審查幾個版本，甚至把不同回應中的部分結合起來，以得到更佳的結果。
前瞻（Looking Ahead）
Codex 目前仍處於研究預覽階段 (research preview)，但已經對我們的建構方式產生實質影響，幫助我們更快地前進、寫出更好的程式碼，並承接那些本來可能從未被優先處理的工作。
我們對未來的潛力感到興奮 — 隨著模型愈來愈好、Codex 更深度地整合進我們的工作流程，我們期待能解鎖更多強大的軟體開發方式。我們也會繼續沿路分享我們所學到的。
