AI 大量生成程式碼這件事，把工程的價值重心移動了。程式碼本身變便宜了；值錢的是生成程式碼之前和之後的工程判斷——意圖定義、規格、驗證、審查、品味，以及對產出的擁有責任。這個專欄把這套判斷系統化，變成可操作的工程紀律。
「AI 能寫程式碼」和「AI 能交付可靠的軟體」是兩件不同的事。前者是 2023 年就確認的事實；後者需要一整套方法論才能成立。
本專欄全程標示哪些是有實證或工程事實支撐的主張，哪些是合理的工程意見（普遍接受但缺乏嚴格對照數據）。詳細見 客觀檢視：主張 vs 可佐證。
學習路徑
為什麼方法論比 code 本身更重要
- 程式碼變便宜了：什麼才值錢？ — AI 把 code 商品化之後，工程價值向哪裡移動；意圖、規格、驗證、品味的不可替代性
- AI 編碼的 70% 問題與最後 30% 的陷阱 — AI 擅長什麼、卡在哪裡；複雜邏輯、可維護性、架構決策為何不能交給模型獨立處理
- AI 生成程式碼的失敗模式 — 似是而非的錯誤、幻覺、隱性假設、技術債的積累路徑；「看起來對」≠「是對的」
方法論支柱
- 方法論支柱：可操作的工程紀律 — spec-driven、problem framing、planning、TDD、code review、doubt-driven、ADR、evals/observability 八個支柱，各自的時機與分工
- AI 編碼工程閉環：從意圖到沉澱 — 把八個支柱整合成一條完整流程：意圖/spec → 生成 → 驗證 → 審查 → 整合 → 沉澱；每個節點的輸入輸出
- 人的角色：審查、品味與擁有權 — AI 產出是草稿不是成品；哪些判斷必須由人做，以及為什麼「擁有結果」是方法論的核心前提
客觀基礎
- 客觀檢視：主張 vs 可佐證 — 這個專欄的核心主張哪些有研究/工程事實支撐，哪些是合理意見；已知限制與不確定性的誠實清單
與既有專欄的關係
這個專欄是方法論的整合視角，不重複其他專欄已深入討論的個別技法：
- 規格與問題定義的細節 → Problem Framing ＋ Spec-Driven Development（spec 的六大核心、四階段閘門、5 Whys、HMW）
- AI 服務的幻覺與品質保證 → AI Agentic SaaS 工程實踐（evals 框架、RAG grounding、guardrails）
- 領域設計流程 → Event Storming + Event Sourcing + Pattern Language（把領域知識固化進設計，不依賴模型記憶）
這個專欄回答「為什麼要做這些」，以及「這些方法論在 AI 輔助編碼的脈絡裡如何串成一個系統」。
🔍 待解問題 / 持續追蹤
- 「AI 生成程式碼的技術債」是否可量測？有沒有團隊公開了 AI 輔助開發前後的維護成本對比數據？
- Spec 的品質是否有客觀指標？目前業界缺乏「好 spec vs 壞 spec」的定量評估標準。
- 人工審查的時間成本在大規模 AI 生成下是否成為新瓶頸？有無團隊公開了審查時間與 AI 生成速度的比例數據？
- 「AI 的 70% 問題」的閾值是否隨模型代際推進而移動？2025 年的 Sonnet 4 和 2023 年的 Copilot 在「最後 30%」的表現差距有多大？
- 方法論紀律的效益是否存在邊際遞減？規模小的團隊（1-2 人）採用完整方法論的 overhead 是否合理？
🕒 更新紀錄
- 2026-07-03 — 建立專欄。核心來源：GitHub Copilot productivity research（2022–2023）、Thoughtworks Technology Radar 2025、Addy Osmani 的 AI 編碼觀察、Google Engineering blog、Gergely Orosz（The Pragmatic Engineer）的 AI 編碼分析，以及本機已安裝的 spec-driven、planning、tdd、code-review、doubt-driven、documentation-adrs 等 skill 文件。1 篇 hub＋7 篇原子筆記。