AI 在編碼任務上的能力分佈不均勻。對「生成一個符合明確描述的函式」、「把某段邏輯翻譯成另一種語言」、「根據現有模式補全一段 boilerplate」這類任務，現代模型的成功率很高。但一旦任務涉及跨多個文件的語意一致性、深嵌套的業務規則、長期可維護性、或「必須在這組特定約束下工作」的系統脈絡，錯誤率就快速升高。
這個現象，業界工程師常用「70% 問題」來描述：AI 能漂亮地處理大多數編碼工作，但最後那 30%——也往往是最難、最核心、最影響系統健康的部分——模型很容易提供聽起來正確但實際上不對的答案。
誠實說明： 「70%」不是一個精確量測到的統計數字，而是多位業界工程師（包括 Google Chrome 工程師 Addy Osmani 在其 AI 編碼觀察中提及）對 AI 能力分佈的描述性概括。實際比例因任務類型、模型版本和工程環境差異很大。此處使用它是為了描述一個真實的能力不均問題，不是引用一個有嚴格研究基礎的閾值。
AI 擅長什麼
高成功率的任務類型：
- 根據清楚描述生成標準化模式（CRUD、REST endpoint、資料結構定義）
- 翻譯（語言間、框架間、模式間）
- 補全已有足夠上下文的函式
- 根據範例生成測試（但測試本身是否測到正確的事，是另一問題）
- 解釋已知邏輯、重構命名、消除重複
這些任務有一個共同特點：問題本身已經被充分定義，正確答案的形狀是明確的。
AI 卡在哪裡
低可靠性的任務類型：
複雜業務規則的完整性 跨多個場景的業務規則，AI 容易生成「對一般案例有效、但對特定邊界案例靜默失敗」的實作。問題在於：模型無法知道它不知道什麼。它沒有你的領域知識、沒有你的例外清單、沒有你從過去的 bug 裡學到的教訓。
長期架構一致性 AI 在當下的 context window 裡工作。當程式碼涉及多個模組的協定、命名慣例、data flow 設計原則——這些散佈在整個 codebase 的隱性約定——模型可能生成功能上可運作但架構上不一致的程式碼。
「不能做什麼」的知識 規格裡說要做什麼，但沒說不能做什麼。AI 不知道你的系統有哪些已知的限制、哪些繞路是禁止的、哪些看起來可行但會引發安全問題的做法。這些「負向知識」（negative knowledge）很少被寫在 spec 裡，但對正確性至關重要。
維護時的脈絡遺失 AI 生成的程式碼，如果沒有清楚的文件和測試保護，未來修改時就像在沒有地圖的地方施工。「這段 AI 生成的程式碼，我能快速讀懂並修改嗎？」是一個常被忽略的品質問題。
為什麼「最後 30%」特別危險
最後 30% 不只是難——它往往是最重要的部分：
- 邊界 case 通常是安全漏洞的所在
- 架構一致性決定系統的長期可維護性
- 業務規則的完整性決定產品是否正確運作
而且「最後 30%」的錯誤有一個特別壞的性質：它們常常不是立刻顯現的。功能測試能通過、本地環境能跑——但在特定輸入、特定時序、或特定規模下，問題才暴露。這讓「看起來 AI 寫得很好」和「AI 寫得確實很好」之間的落差很難在交付時察覺。
SWE-Bench 數據的啟示
SWE-Bench 是一個標準化的 AI coding 評估基準，測試模型在真實 GitHub 問題上的 patch 成功率。2023 年 Claude 2 和 GPT-4 在 SWE-Bench 上的通過率是個位數；2025 年頂尖模型已到 40-50%（2026 年 6 月 Microsoft MAI-Code-1-Flash 在 SWE-Bench Pro 達到 51%）。
這個進步很顯著，但反過來看：即使最好的模型，在真實的程式碼庫問題上，有將近一半無法正確解決。SWE-Bench 的題目都是已有明確答案的 GitHub issue，比「寫一個新功能」更受控制——在更開放的任務上，失敗率更高。
方法論如何回應這個問題
承認 AI 的「70% 問題」不是要回頭不用 AI，而是要以工程紀律填補那 30%：
- Spec 先行：把「正確的樣子」定義清楚，讓 AI 有可核對的標準
- TDD：用測試把驗收標準化為可執行形式，在生成時就能驗
- Code review：人工識別「看起來對但不對」的部分
- Doubt-driven：對任何「我確定 AI 這裡沒問題」的時刻，採取主動懷疑態度
見 方法論支柱：可操作的工程紀律 的完整清單。
延伸
- 具體的失敗模式有哪些 → AI 生成程式碼的失敗模式
- 方法論怎麼填補這個缺口 → 方法論支柱：可操作的工程紀律
- 這些數字的可信度分析 → 客觀檢視：主張 vs 可佐證
- 回到全景 → Engineering AI Coding Methodology 專欄首頁