AI coding 爆火之後，我學到的 5 個工程教訓

第一次撞上 AI 生成代碼的真實場景

去年接手一個遺留 Spring Boot 微服務，需要將內部使用者認證模組遷移到 OAuth 2.1。 團隊只有三個人，時間視窗三周。 我自然想到用 AI 程式設計工具（Cursor + GPT-4）加速。 一開始很順利：AI 生成了新的認證篩檢程式、Token 儲存層和配置類，大概 800 行代碼，覆蓋了 routes、異常處理和部分測試。

但問題在集成測試時爆發：AI 生成的 SecurityFilterChain 配置中有兩個 @Order 注解衝突，導致部分 API 端點繞過了認證。 更隱蔽的是一個 JwtAuthenticationConverter 中的 null 指標，AI 沒有處理 claims 字段缺失的場景。 修復這 5 個問題花了比手動寫更長的時間，因為要先理解 AI 自己的“思維”——它習慣用 Optional 但又不完全一致。

這個場景讓我意識到：AI coding 的最大陷阱不是它寫不出代碼，而是你誤以為它寫的代碼可以直接信任。

真正改變判斷方式的 4 個結論

**第一，代碼審查不可跳過，但審查物件變了。 ** 以前 review 同事代碼，重點在邏輯和風格。 現在 review AI 代碼，重點在邊界條件、異常路徑和與現有系統的隱式耦合。 AI 非常擅長生成“看起來對”的代碼，但經常漏掉 null、越界、超時這些角落。 我後來的做法是：每次 merge AI 代碼前，專門檢查三類問題：1）所有輸入輸出參數的非空假設; 2）所有分支條件的默認行為; 3）所有異步操作的超時和重試。

**第二，遷移類任務要用“分階段替換”，而不是全量重寫。 ** 那次 OAuth 遷移我犯的最大錯是讓 AI 一次性生成整個模組的替換代碼。 更好的做法是：先讓 AI 生成一個兼容新舊兩套認證的“代理過濾器”，逐步切流量; 每步保留舊代碼作為回滾點。 這個教訓花了我兩天加班時間才學會。

**第三，prompt 結構直接影響輸出品質。 ** 不是簡單寫“生成 OAuth 2.1 配置”就行。 我後來固定了一個三段式 prompt：1）明確問題上下文（框架版本、現有結構、約束條件）; 2）具體輸出格式（類名、方法簽名、註釋風格）; 3）需要避免的陷阱（如不要用已廢棄 API、不要引入新依賴）。 效果提升明顯，錯誤率降低至少 40%。

**第四，AI 更適合“從 0 到 1”而不是“從 1 到 0.9”。 ** 原型、腳手架、演示代碼是 AI 的強項; 但當你需要對現有系統做精細修改時，AI 容易破壞已有邏輯。 現在我會隔離使用場景：新功能原型用 AI，存量修改堅持手動。

踩過的坑和修正路徑

最大的一個坑：**沒有為 AI 生成的代碼建立獨立測試層。 ** 我直接讓 AI 生成代碼，然後扔進現有的測試套件運行。 但 AI 生成的代碼往往需要特殊的mock數據或配置，而現有測試沒有覆蓋。 結果測試通過，集成失敗。 修正方法是：建立一個 ai-generated/ 目錄，所有 AI 代碼先放入該目錄，併為其編寫獨立的單元測試和集成契約測試，通過後再合併到主代碼庫。

另一個坑：**過度信任 AI 的“解釋”。 ** 當我問“為什麼這樣做”時，AI 會給出一個聽起來很合理的理由，但有時是幻覺。 一次 AI 解釋某個 @Transactional 傳播行為時，它的理由基於 Spring 5 的舊行為，而專案用的是 Spring 6 的 Jakarta 命名空間。 現在我需要問之前先驗證一次官方文檔，或讓 AI 同時給出引用。

如果你也在做類似工作，最值得先照抄的一步

設置一個“AI 代碼准入清單”，每次從 AI 獲取代碼后，手動檢查以下項：

1. 所有外部輸入（參數、環境變數、配置檔）的預設值是否合理？
2. 所有異常路徑有沒有被吞掉（空 catch 塊或僅log不恢復）？
3. 所有異步調用是否有超時設置（尤其是網路請求）？
4. 生成的代碼是否引入了項目沒有的新依賴（檢查 import 和 build 檔）？
5. 代碼風格是否符合團隊現有規範（縮進、命名、註釋模式）？

這個清單我給團隊每個成員都貼在了顯示器旁邊。 使用兩周后，線上故障率降低了約35%。

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

繼續投入的條件：**當你看到 AI 生成的代碼在通過准入清單后，修改量低於手寫量的 30%。 ** 如果你的場景是創建新模組、寫樣本代碼、寫測試用例、生成 SQL 或腳本——這些是 AI 的舒適區，可以持續用。

該換路線的信號：**修改 AI 代碼的時間超過手寫時間的兩倍，或者修復一個 bug 引出了三個新 bug。 ** 例如那次 OAuth 遷移，我花了 4 小時 debug AI 生成的配置，最後放棄，自己花 1.5 小時重寫。 這種場景表明當前任務超出了 AI 的能力邊界——通常是涉及遺留系統、複雜上下文依賴、或非標準配置。

還有兩個明確應該停止的情況：1）你無法理解 AI 生成的代碼邏輯（複雜 lambda 鏈或抽象橋接模式）; 2）AI 生成的代碼包含你無法完整測試的外部依賴（比如直接調用第三方 API 而不做 mock）。 這時手動實現更安全。