AI 生成程式碼的失敗模式

AI 生成程式碼的失敗不像傳統編譯錯誤——它不會立刻崩潰、不會丟出明顯的例外。最危險的失敗是靜默的：程式碼能跑、測試能通過、部署能上線，但在某個條件下、某個時序下、某個邊界輸入下，它就錯了。

失敗模式一：似是而非的正確性

AI 語言模型的訓練目標是生成高概率的下一個 token，不是「確保生成物在你的系統脈絡下是正確的」。這導致一個特殊的失敗模式：模型生成的程式碼，在語法上完全正確、在邏輯上乍看合理，但在你的具體情境中是錯的。

常見場景：

這類錯誤的共同特點：在 code review 中需要領域知識才能發現，純靠語法分析或表面邏輯看不出來。

AI 在生成程式碼時，根據 prompt 的訊號和訓練資料，自動填補了大量「你沒有明說的假設」。這些假設不會寫在程式碼裡，只以「這樣設計」的形式存在。

範例：

你問「幫我寫一個 user authentication」→ AI 假設了 session-based、假設了某個 hash 演算法、假設了某個 token 存放位置——你看到的程式碼這些決定都已經做了，但你可能還沒意識到
你問「優化這個查詢」→ AI 假設了你的索引結構、假設了查詢頻率模式、假設了資料規模
你問「加一個 retry 機制」→ AI 假設了哪些錯誤應該 retry、哪些不應該

隱性假設不一定是壞的——有時候 AI 的假設和你的需求正好符合。危險在於：你不知道它做了哪些假設，也就無法在假設錯誤時察覺。

Spec 先行的作用之一就是把假設顯性化：在寫任何程式之前，先把「我正在假設這是 Web App，不是原生 mobile；認證使用 JWT；資料庫是 PostgreSQL」這些假設列出來（見 Spec-Driven Development：規格先行）。

幻覺在 AI 生成程式碼的情境裡有幾個特定形態：

函式/方法幻覺：生成對一個不存在的 API 或 library 函式的呼叫。在 Python 或 JavaScript 這類動態語言裡，編譯器不會攔截，只有在執行到那行時才會發現。

工具呼叫幻覺：在 agent 架構裡，模型可能呼叫不存在的 tool、把不正確的參數傳給正確的 tool（e.g., 一個不存在的 ID、一個格式錯誤的 timestamp）。2025 年業界觀察顯示，當可用 tool 超過 10-15 個時，準確率明顯下降。

版本幻覺：把不同版本的 API 混用。模型知道某個函式存在，但它在訓練資料裡的版本和你現在用的版本可能有破壞性差異。

相關資料：ai-agentic-saas 專欄的幻覺、Evals 與品質保證對 LLM 幻覺有更完整的工程層面討論，包括 RAG grounding、citation enforcement 等降低手段。

AI 生成程式碼的速度，是技術債積累速度的倍增器。

沒有 spec、沒有測試、沒有 review 的 AI 生成程式碼，在功能層面可能「能跑」，但：

這些問題在第一天不影響功能。在第六個月，當你需要在這個基礎上加新功能、修一個奇怪的 bug、或者換一個工程師接手時，代價才會顯現。

（這是失敗模式一到四的綜合體現，見 AI 編碼的 70% 問題與最後 30% 的陷阱）

對簡單、受限、定義清楚的任務，AI 成功率高。但任何任務裡有「複雜業務規則」、「跨模組約束」、「安全邊界」、「長期可維護性」的部分，AI 的靜默失敗率就上升。

問題是：這兩種部分常常混在同一個任務裡。你無法在事前清楚知道 AI 在哪個 30% 上靜默失敗了。

對應每個失敗模式，都有對應的工程實踐：

失敗模式	工程回應
似是而非的正確性	Code review（有領域知識的人審查）
隱性假設	Spec 先行（把假設寫出來，讓人審核）
幻覺	TDD / 自動測試（執行時驗證）
技術債積累	Planning + incremental implementation（小步、可回顧）
靜默失敗	Doubt-driven（主動懷疑，對抗式審查）