OpenAI 會如何使用 Codex
Codex 每天都被使用於 OpenAI 的眾多技術團隊中，例如安全、產品工程、前端、API、基礎架構和效能工程。團隊正利用它來加速各類工程任務，從理解複雜系統、重構大型程式碼庫，到交付新功能，以及在緊迫的時限下處理事故。
根據對 OpenAI 工程師的訪談與內部使用資料，我們整理出使用案例與最佳實務，說明 Codex 如何協助團隊加快工作速度、提升工作品質，並有效管理大規模的複雜性。
Codex 可協助我們的團隊在新人到職、偵錯或調查事件時，針對程式碼庫中不熟悉的部分快速上手。
他們經常使用 Codex 來找出某項功能的核心邏輯、梳理服務或模組之間的關係，並追蹤資料在系統中的流向。它也有助於找出架構模式或文件中缺漏的部分，否則往往需要投入大量人工才能整理出來。
在事件回應期間，Codex 會透過呈現元件之間的互動關係，或追蹤故障狀態如何在各系統間傳播，協助工程師快速熟悉新的領域。
來自我們團隊的案例分享
「當我修正錯誤時，我會使用 Ask 模式，看看程式碼庫中還有哪些地方可能也會出現相同問題。」
這個儲存庫中的驗證邏輯是在哪裡實作的？
總結請求如何從進入點到回應流經此服務。
哪些模組會與 [插入模組名稱] 互動，以及如何處理失敗情況？
Codex 常用於進行跨多個檔案或套件的變更。例如，當工程師在更新 API、調整模式的實作方式，或遷移至新的相依套件時，Codex 能讓他們輕鬆一致地套用變更。
當需要在數十個檔案中進行相同更新，或是當更新需要掌握不容易單靠 Regex 或尋找與取代就能處理的結構與相依性時，這會特別有用。
他們也用它來進行程式碼清理，例如拆分過大的模組、以現代模式取代舊有模式，或讓程式碼更易於測試。
來自我們團隊的案例分享
「Codex 將所有舊版的 getUserById() 替換為我們新的服務模式，並建立了 PR。」它在幾分鐘內就完成了原本需要數小時才能完成的工作。
依關注點將這個檔案拆分成不同模組，並為每個模組產生測試。
將所有以 Callback 為基礎的資料庫存取轉換為 Async/Await。
Codex 用來識別並解決效能瓶頸。
在進行效能調校或可靠性改善時，工程師會使用提示詞指示 Codex 分析執行緩慢或耗用大量記憶體的程式碼路徑，例如低效率的 Loop、冗餘操作或成本高昂的 Query，並提出最佳化的替代方案，通常能顯著提升效率與可靠性。
Codex 也用於支援程式碼健康，透過識別仍在積極使用中的高風險或已淘汰模式。我們的團隊仰賴它來協助減少長期技術債，並主動防止功能退化。
來自我們團隊的故事分享
「我使用 Codex 來掃描重複且成本高昂的 DB 呼叫。」它很擅長標記高頻路徑，並草擬我之後可以調整的批次查詢。」
將這個迴圈最佳化以提升記憶體使用效率，並說明你的版本為何更快。
找出此請求處理常式中重複且成本高昂的作業，並建議可採用快取的機會。
建議在這個函式中以更快的方式批次處理 DB 查詢。
Codex 協助工程師更快速地撰寫測試，尤其是在測試覆蓋率不足或完全缺失的地方。
在修正錯誤或進行重構時，工程師經常會請 Codex 建議涵蓋極端情況或可能失敗路徑的測試。對於新程式碼，可根據函式簽章與周圍邏輯產生單元測試或整合測試。
Codex 對於識別邊界條件特別有幫助，例如空輸入、最大長度，或是不尋常但有效的狀態，而這些情況在初始測試中經常被忽略。
來自我們團隊的故事分享
「我會在晚上把 Codex 指向測試覆蓋率較低的模組，隔天醒來就能看到可直接執行的單元測試 PR。」
為此函式撰寫單元測試，包括邊界情況和失敗路徑。
為此排序工具建立屬性測試。
請擴充此測試檔案，補上 null 輸入和無效狀態等遺漏情境的測試。
Codex 透過加速開發週期的起點與終點，幫助團隊加快開發速度。
開始開發新功能時，工程師會用它來搭建樣板程式碼框架——產生資料夾、模組和 API 存根，快速產出可執行的程式碼，而不必手動串接每個部分。
隨著專案接近發布，Codex 能透過處理較小但不可或缺的任務來因應緊迫的時程，例如分類錯誤、填補最後一哩的實作缺口，以及產生部署腳本、遙測掛鉤或設定檔。
它也可以用來將產品回饋轉化為起始程式碼。工程師經常貼上使用者請求或規格，讓 Codex 產生初稿，之後再回頭修改和潤飾。
「我一整天都在開會，但還是合併了 4 個 PR，因為 Codex 一直在背景中運作。」
為新的 API 路由 POST /events 建立支架，並加入基本驗證與日誌記錄。
使用此範本（插入您的遙測程式碼範例），為追蹤新版導入流程的成功/失敗情況生成遙測掛鉤。
根據此規格建立初步實作：[插入規格或產品回饋]。
Codex 幫助我們的工程師即使在行程零碎且經常被打斷的情況下，仍能維持生產力。它可用來記錄尚未完成的工作、將筆記轉化為可運作的原型，或拆分出可於日後再回頭處理的探索性任務。這讓他們更容易在不會失去上下文脈絡的情況下暫停及恢復工作，尤其是在值班待命或有很多會議時。
「如果我發現有個順手修一下的小問題，我就會啟動一個 Codex 任務，而不是切換分支，等有空時再審查它的 PR。」
Codex 也很適合用於開放式工作，例如探索替代方案或驗證設計決策。您可以用提示詞詢問不同的解題方式、探索不熟悉的模式，或針對假設進行壓力測試。這有助於突顯其中的取捨、拓展設計選項，並明確化實作上的選擇。
它也可用來識別相關的錯誤。給定已知問題或已淘汰的方法，Codex 可以識別程式碼其他地方的類似模式，讓您更容易發現回歸問題或完成清理工作。
「Codex 幫我解決冷啟動問題，我貼上規格和文件後，它會產生程式碼骨架，或指出我遺漏的部分。」
如果系統採用事件驅動而非請求/回應模式，這會如何運作？
找出所有手動組合 SQL 字串，而不是使用我們查詢建構器的模組。
將這段內容改寫成更偏函數式的風格，避免變更狀態與副作用。
當 Codex 被賦予明確的結構、充分的上下文，以及反覆迭代的空間時，最能發揮效益。以下是 OpenAI 團隊正在培養的一些習慣，幫助他們在日常工作中持續從中獲得穩定價值。
對於大型變更，請先使用 Ask 模式向 Codex 提示實作計畫，當切換到 Code Mode 時，該計畫將成為後續提示的輸入內容。這個兩步驟流程可讓 Codex 維持穩健，並有助於避免輸出錯誤。Codex 最適合處理範圍明確的任務，例如你或隊友約一小時可完成的工作，或需要撰寫數百行程式碼才能實現的內容。隨著模型持續改進，可預期其能承擔的任務規模也會隨之增加。
設定啟動指令碼、環境變數和網際網路存取權，可明顯降低 Codex 的錯誤率。執行任務時，請留意可在 Codex 的環境設定中修正的建置錯誤。這可能需要幾次迭代，但長期而言可帶來顯著的效率提升。
當提示詞貼近你在 PR 或 issue 中描述變更的方式時，Codex 的回應會更好。也就是說，在相關情況下應包含檔案路徑、元件名稱、差異內容和文件片段。使用像「用與 [module X] 相同的方式實作這個功能」這樣的模式來撰寫提示詞，能改善結果。
啟動任務來記錄延伸想法、部分完成的工作或順手修正的問題。不必有壓力一次產生完整的 PR。Codex 很適合作為暫存區，等你重新專注時可以返回。
維護 AGENTS.md 檔案，以協助 Codex 在儲存庫中跨提示詞更有效地運作。這些檔案通常包含命名慣例、業務邏輯、已知特殊情況或相依性，而這些都是 Codex 無法僅從程式碼本身推斷出來的。詳情請參閱文件，了解如何組織 AGENTS.md 檔案。
Best-of-N 功能可讓您針對單一任務同時產生多個回應，以快速探索多種解決方案，並選出最佳方案。對於較複雜的任務，你可以檢視多次迭代的結果，並結合不同回應中的部分內容，以獲得更好的結果。
Codex 仍處於研究預覽版階段，但它已經對我們打造產品的方式帶來實質影響，幫助我們加快開發速度、寫出更好的程式碼，並承接原本可能永遠不會被排上優先順序的工作。
我們對未來的潛力感到振奮——隨著我們的模型持續進步，且 Codex 更深入整合到我們的工作流程中，我們期待解鎖更多更強大的軟體開發方式。我們將持續分享我們一路上學到的內容。
