核心概念

Matt Pocock（「Claude Code for Real Engineers」課程作者）在 AI Engineer 大會的結論：AI 越強，軟體基礎反而越重要，而非 deprecated。

這與「specs to code」流行論述直接對立。Specs to code 的邏輯是：寫規格 → AI 生 code → 出 bug 不看 code 回去改規格 → 再跑一次。Pocock 實測：第一次尚可、第二次略爛、第三次更爛、第四次垃圾。

根源在 John Ousterhout《A Philosophy of Software Design》：複雜的 code = 難以理解和修改的 code。Pragmatic Programmer 稱之為 software entropy（軟體熵）——每次只考慮當下改動、不顧整體設計，codebase 逐步崩壞。Specs to code 把這個過程自動化：每跑一次 compiler，code 就亂一點。

四個失敗模式與解法

① 你以為想清楚了，AI 做出來的不是你要的

Frederick Brooks《The Design of Design》提出 design concept——協作雙方腦袋裡飄著的「我們要做什麼」共識，說不出口也寫不進文件。你跟 AI 從未對齊過這個東西。

解法：「grill me」skill——讓 AI 沿著 design tree 每個分支拷問你，直到所有決策依賴都解完。對話結束後整理成 PRD 或 issue 讓 agent 接手。比 Claude Code 預設的 plan mode 更徹底：plan mode 太急著生 markdown，grill me 是逼你先挖乾淨腦袋裡飄忽的東西。

② AI 太囉唆，不在同一個頻道

與領域專家協作時本就有語言落差，AI 也一樣。DDD（Domain-Driven Design）的解法：維護一份 ubiquitous language（共用語彙），code 裡、討論時、寫文件全用同一套術語。

Pocock 寫了一個 skill 自動掃描 codebase、產出共用語彙 markdown table，規劃時隨時開著引用。AI 的 thinking trace 開始用更精準、更短的語言思考，實作也更貼近設計。

③ AI 寫了，但跑不起來

即使有 static types、TypeScript、自動化測試，AI 習慣一次寫一大坨最後才想到 check。Pragmatic Programmer：「The rate of feedback is your speed limit.」AI 預設一直在超速駕駛。

解法：TDD——先寫測試、讓它 fail、寫最小 code 讓它過、再 refactor。但 TDD 能跑的前提是 codebase 好測，好測的前提是好設計，所以這三件事互相依賴。

④ 你的腦袋跟不上 AI 的速度

AI 傾向產出 shallow modules：功能不多但介面複雜、彼此牽扯的小零件，到處都是依賴。AI 自己回頭探索這種 codebase 時也找不到路，每次改動都容易歪掉。

對比 Ousterhout 的 deep modules：簡單介面藏著豐富實作，外部只需理解介面。Pocock 的「improve codebase architecture」skill 掃描 codebase，把散落各處的相關 code 整合成 deep module，讓邊界乾淨、TDD 得以落地。

關鍵要點

  • Code is not cheap. Code is important：壞 code 從來沒這麼貴——只有好 codebase 才能拿到 AI 的全部紅利
  • 設計介面，委派實作（Design the interface, delegate the implementation）：把 module 當灰盒，介面嚴格設計，實作交給 AI，外面寫測試驗行為；金流、安全相關除外
  • Invest in the design of the system every day（Kent Beck）：Specs to code 是從系統設計裡抽走（divest），不是投入
  • Module map 納入 ubiquitous language：寫 PRD 時明確指出哪個 module 被改、介面如何變動
  • AI 是「戰術士兵」：地面執行快，戰略（打哪個山頭）靠你

實務應用

對非工程師背景的產品人：不需要手寫每一行，但要能設計介面、判斷模組邊界、知道什麼時候介入。這份能力跟工程師被訓練 20 年的東西完全一樣——AI 沒讓它 deprecated，反而讓它成為槓桿：懂的人得到 10x，不懂的人讓 AI 加速 codebase 崩壞。

相關頁面：Harness Engineering、Claude Code 工作流程設定、AI 輔助後端工程師技能地圖、AI 編碼工具的程式碼過載效應

延伸觀點

軟體熵有實證數據支撐。GitClear 對 211 個 repo 的分析顯示，AI 編碼工具普及後 code churn（兩週內被改掉的 code）從 2021 年的 3.31% 飆升至 2024 年的 6.87%，翻了一倍；同期 refactoring 比例下降近 13 個百分點，複製貼上的 code 增加超過 3 個百分點。57% 的 code 複製塊（clone）與 bug 相關。這正是 Pocock 描述的熵增——AI 讓你更快加 code，但也更快累積技術債。

TDD 在 AI 時代扮演「行為規格書」的角色。來自多位開發者的實踐共識：測試不只是驗證工具，更是你給 AI 的具體目標——先寫 fail 的測試等於告訴 AI「這個行為必須存在」，比任何自然語言 prompt 都精確。AI 可以生成語法正確但邏輯有誤的 code；預先寫好的測試是第一道防線，立刻攔截這類錯誤。反饋速度決定你的速限，TDD 把這個速限調到最快。

「AI 是 copilot，不是 autopilot」已成業界共識。Addy Osmani（Google Chrome DevRel）的訪談整理：生產環境有三類 AI 翻車模式——功能測試過了但實際負載崩潰、邏輯錯誤（如 truthy check 寫反）悄悄滑過、以及 AI 寫出的 spaghetti code 最終需要整個重寫。他的結論與 Pocock 一致：架構決策、模組邊界判斷、安全敏感邏輯，必須由人負責；AI 安全代勞的是原型、模板、一次性腳本。

反向連結

以下頁面引用了本頁：