這篇筆記對這個專欄的核心主張做一次誠實的「主張 vs 可佐證」拆解。哪些有研究/工程事實支撐、哪些是合理的工程意見、哪些是尚待釐清的問題——分清楚。這是本專欄區別「方法論說服」和「方法論論述」的核心承諾。
有實證或工程事實支撐的主張
✅ Spec-Driven Development 是 2025 年業界認可的 AI 輔助工程實踐
來源（可查驗）：
- Thoughtworks Technology Radar 2025：明確列出 Spec-Driven Development 為「AI 輔助工程的關鍵新實踐」（連結）
- Microsoft Developer Blog：稱 spec-first approach 為 AI-native engineering 的必要方法（連結）
注意：「業界認可」不等於「有隨機對照試驗證明它有效」。這是業界共識和實踐觀察，不是 RCT 數據。
✅ AI 結構化輸出（Structured Outputs）的失敗率有具體量測
來源（可查驗）：
- Rotascale（2025 production 觀察）：無約束 prompt 的 JSON parse 失敗率 8–15%；JSON Mode 降至 2–5%；Structured Outputs Strict Mode 降至 < 0.1%
- TianPan.co（2025 production 觀察）：同等級數據
注意：這些是工程師的 production 觀察，不是學術論文的嚴格實驗。各系統的任務類型、模型版本、prompt 設計不同，實際數字可能有差異。這是「數量級」層面的可靠數據，不是精確閾值。
✅ RAG 在特定條件下顯著降低 LLM 幻覺率
來源（可查驗）：
- Getzep（2025 multi-benchmark 彙整）：適當實作的 RAG 可降低幻覺率「最多 71%」（連結）
重要限制（本專欄誠實標示的）：「最多 71%」是多個不同任務類型 benchmark 的彙整。在「有明確文件可查的事實性問題」上效果佳；在「需要綜合推理」的問題上效果有限。不要把這個數字當作普遍保證。
✅ AI coding 在受控實驗中能加速特定任務
來源（可查驗）：
- GitHub 研究（2022–2023）：使用 GitHub Copilot 的開發者在受控 coding 任務上平均快 55%（連結）
重要限制： 這是受控的、獨立 coding 任務實驗，不是「完整功能從需求到 production 的全流程」。把「特定 coding 任務快 55%」外推到「整個軟體開發週期快 55%」，是過度推論。
✅ SWE-Bench 顯示頂尖模型在真實 codebase 任務上仍有大量失敗
來源（可查驗）：
- SWE-Bench（持續更新的公開 benchmark）：2025 年頂尖模型在 SWE-Bench 通過率約 40–50%；2026 年 6 月 Microsoft MAI-Code-1-Flash 在 SWE-Bench Pro 達到 51%
注意：SWE-Bench 的題目是「有明確答案的 GitHub issue」，是比開放式新功能開發更受控制的任務。即便如此，約一半仍失敗。
合理的工程意見（未量化但業界廣泛接受）
⚠️ 「方法論的槓桿比生成程式碼的速度更重要」
這是本專欄的核心主張。合理性很強（多個工程師、工程部落格、業界共識支持），但沒有隨機對照試驗比較「spec-first AI 開發 vs vibe-coding AI 開發」的長期 ROI、維護成本、技術債積累速度。
誠實評估：工程界普遍接受，但缺乏嚴格量化。如果有人要求「給我看一個 RCT 證明 spec-first 在 AI 時代比 vibe-coding 更好」，目前拿不出來。
⚠️ TDD 能減少 AI 生成程式碼的缺陷
邏輯合理：測試能在生成時驗證「是否達到驗收標準」，是 AI 生成物的有效約束機制。
未量化：「有 TDD vs 沒有 TDD 的 AI 輔助開發，缺陷率差多少」，沒有嚴格研究。
⚠️ AI 生成的技術債積累速度快於人工開發
合理推論：高速生成 + 低 review 密度 = 更多未審查的假設進入 codebase。但「技術債積累速度的倍增效應」目前沒有量化研究支持。
⚠️ 「人的品味是不可替代的」
功能性描述：識別「過度設計」、「長期維護困難」、「架構不一致」的能力，目前 AI 模型確實弱於有經驗的工程師。
但「不可替代」是強主張：模型能力持續進步。2026 年確實無法替代，不代表 2030 年無法替代。誠實的說法是「目前無法替代」。
未能找到充分支撐的主張
❌ 「70% 問題」作為精確統計數字
現實：「70%」是多位業界工程師對 AI 能力分佈的描述性概括（包括 Google Chrome 工程師 Addy Osmani 在 AI 編碼觀察中使用類似描述），不是精確量測的閾值。
本專欄使用它是為了描述一個真實的能力不均問題，不是引用一個有嚴格研究基礎的數字。「AI 在簡單任務成功率高、在複雜任務成功率低」是有觀察基礎的；「恰好是 70/30」是描述性便稱，不是實測值。
❌ AI 輔助開發的全流程生產力提升數字
目前沒有可靠的「AI 輔助 vs 非 AI 輔助，完整功能從需求到 production 的生產力對比」研究。GitHub 的 55% 數字是受控的獨立 coding 任務，不是全流程。
❌ spec-first 開發降低多少維護成本的具體數字
沒有找到「spec-first vs no-spec 開發，六個月後維護成本差多少」的量化研究，無論是否有 AI 輔助。
已知的不確定性
- 模型進步速度：「最後 30%」的難度閾值可能隨著模型代際推進而移動。今天需要人工介入的複雜邏輯，兩年後可能模型可靠處理。
- 方法論 overhead 的規模依賴性：完整的工程紀律對小型個人專案（1-2 人）的 overhead 是否合理，沒有好的數據。
- Spec 品質的客觀量測：目前缺乏「好 spec vs 壞 spec」的量化指標，spec 品質的評估仍主要依賴工程判斷。
為什麼要做這篇
方法論文章容易把「合理意見」寫成「業界共識」、把「業界共識」寫成「有研究支持的事實」。這種滑坡讓讀者誤以為方法論的每個主張都有嚴格基礎，從而無從判斷哪些值得認真對待、哪些是合理猜測。
清楚標示哪些是事實、哪些是意見，不是在削弱方法論的說服力——它是讓方法論更值得信任的前提。
延伸
- 本專欄的核心主張 → 程式碼變便宜了：什麼才值錢？
- 有更多可佐證內容的相關討論 → 幻覺、Evals 與品質保證
- 回到全景 → Engineering AI Coding Methodology 專欄首頁