Codex 爆火後，我學到的 5 個工程教訓

第一個撞上的真實場景：從原型到生產，Codex 程式碼突然“失憶”

去年夏天，我負責一個內部工具的原型開發—用 Codex 自動產生 API 呼叫程式碼。前兩週效果驚人：Codex 能根據自然語言描述直接輸出可運行的 Python 腳本，節省了大約 60% 的編碼時間。但當我試著把這個原型擴展到生產環境時，問題就出現了。同樣的提示詞，Codex 開始產生語法錯誤、遺漏關鍵參數，甚至創造出不存在的函數。最崩潰的一次，它把 requests.post 寫成了 requests.send，而後者壓根不存在。我花了整整半天調試，最後發現是上下文溢出——Codex 的上下文視窗只有 8K，當專案程式碼和對話歷史累積到一定長度，它開始「遺忘」最初約定的 API 細節。

這個場景讓我意識到，Codex 不是“寫代碼的 AI”，而是一個“根據局部上下文猜測程式碼的引擎”。它的輸出品質嚴重依賴你提供的資訊新鮮度和精確度。

改變我判斷方式的幾個結論

做完這個專案後，我徹底放棄了「Codex 能取代工程師」的幻想。三個關鍵結論：

1. Codex 擅長局部模式匹配，不擅長全域一致性。它能在 5 行內寫出漂亮的函數，但無法保證整個專案中的變數命名、錯誤處理風格統一。給相同任務的不同部分多次提示，結果可能互相矛盾。
2. 上下文管理和提示工程是硬門檻。不是「把需求寫清楚」那麼簡單。你需要主動控制上下文大小、分割任務、用註解錨定關鍵約束。這一步做不好，Codex 輸出就是垃圾。
3. 可測試和可重複使用是兩個不同維度。 Codex 產生的程式碼往往可測試（能跑通單元測試），但很難復用——它傾向於一次產生完整函數，而不是拆分成可組合的小模組。當你需要修改邏輯時，往往得重寫整個函數。

踩過的坑洞和修正方案

坑 1：過度依賴 Codex 進行程式碼審查。我以為讓 Codex 審查我寫的程式碼能發現邏輯錯誤，結果它經常「編造」不存在的 bug，或忽略真正的邊界條件。例如審查一個檔案讀取函數，Codex 說“缺少異常處理”，但實際程式碼裡明明有 try-except——它沒看到上下文。

修正：只用 Codex 做風格檢查和命名建議，邏輯審查必須靠人工或專門的靜態分析工具。

坑 2：把 Codex 輸出直接提交到程式碼庫。有一次，Codex 產生的排序演算法在測試資料上全對，但輸入包含 None 的清單時直接崩潰。因為測試資料沒有覆蓋空值情況。

修正：建立強制前置檢查清單：

• 輸入邊界檢查（空、極值、特殊值）
• 與現有程式碼的介面相容性檢查（函數簽名、傳回值類型）
• 錯誤處理完整性檢查（是否所有異常路徑都有處理？）
• 效能基線比較（產生程式碼是否比原方案慢 2 倍以上？）

坑 3：在需要全域修改時用 Codex 做批次重構。想用 Codex 把專案中所有的 print 改成 logging.info，結果改到一半上下文溢出，後半部沒改到，導致編譯失敗。

修正：重構任務必須拆成小步驟，每次只改一個模組，每次修改後都要用 CI 驗證。禁止一次給 Codex 超過 5 個檔案的內容。

最值得先照抄的步驟：建立 Codex 輸出預檢清單

如果你也在嘗試將 Codex 整合到工作流程，第一步不是追求更多功能，而是建立一份嚴格的輸出預檢清單。我的團隊目前使用以下清單：

• 代碼是否包含硬編碼敏感資訊（API key、密碼）？ ——Codex 有時會從訓練資料中「記憶」出密鑰。
• 是否有未定義的依賴或函數？ ——執行 import 檢查，確保所有外部呼叫都明確導入。
• 異常處理是否會覆寫文件中列出的所有錯誤類型？ ——調 API 時尤其重要。
• 與現有程式碼的樣式規則（PEP 8、Go fmt）是否一致？ ——用 linter 自動檢查，不要依賴 Codex。
• 單測覆蓋率是否達到專案要求？ ——Codex 產生的程式碼往往缺乏邊界情況的測試。

把這份清單寫在團隊 Wiki 的第一頁，每次提交 Codex 產生的程式碼前必須逐項通過。這看起來繁瑣，但能避免 90% 的線上事故。

什麼時候該繼續投入，什麼時候該換路線

繼續投入的場景：

• 任務是重複性、模式固定的編碼，例如：資料庫 CRUD、API 封裝、資料轉換腳本。
• 你能提供穩定且清晰的提示——上下文不超過 4K token，程式碼庫有統一的編碼規範。
• 團隊已經建立預檢和測試流程，能快速發現並修正 Codex 的錯誤。

立即換路線的號誌：

• Codex 開始頻繁產生語法錯誤或語意錯誤，且修改提示詞後仍不改善。這通常意味著上下文已經超出窗口，或者任務本身需要跨文件理解。
• 輸入輸出需要嚴格的一致性和版本管理，例如涉及付款、安全認證的核心邏輯。
• 你發現維護 Codex 產生的程式碼的時間，超過了手寫程式碼的時間。這往往發生在程式碼需要頻繁修改的場景下——因為生成程式碼難以理解，每次改都要重寫。

一個真實的決策案例：我同事用 Codex 生成一個微信支付集成模組，第一次生成用了 2 小時，但後續因為支付接口變化，Codex 重新生成花費了 4 小時，並且仍有一處簽名錯誤沒被發現。最後他決定手寫，只花了 6 小時，後續修改變得可控。

總結

Codex 是一個強大的程式碼補全工具，但它的能力邊界比表面看起來窄得多：只適合局部、模式化、情境穩定的任務。真正的工程價值不在於讓 Codex 寫更多程式碼，而是建立讓 Codex 輸出安全落地的流程。如果你正在考慮把 Codex 引入團隊，先寫好那份預檢清單。

下一步，如果你希望系統性地掌握 Agent 工程中的上下文管理、提示工程和評估策略，可以關注我們的高品質原始付費文章和 AI 程式設計進階課程。