核心論點
許多人認為「代碼已經很便宜了，交給 AI 產就好」，但實際上只是「打字」這件事變便宜。引用 Matt Pocock 的觀點：”AI 時代，軟體工程基本功不是變得不重要，而是比以前更重要”。
問題與現狀
不清晰的需求、缺乏設計、命名不一致、測試不完整、模組邊界混亂——這些問題不會因為 AI 變強而消失，反而會被 AI 放大。關鍵洞察：
以前一個工程師一天大概只寫出一點技術債。現在，AI 可以幫你一天生出一整片技術債森林。
乾淨 Codebase 的優勢： AI 成為 10 倍放大器 混亂 Codebase 的危害： AI 只會認真地將混亂複製和擴散
為什麼保留對「Specs-to-Code」的看法
Spec 是工程流程的入口，但不是唯一的駕駛座。如果僅寫好規格卻不看代碼、不管架構、不設計測試，這只是「高級版的 Vibe Coding」。
健康的 AI Coding 流程（四大要素）
1. 先讓 AI 問問題，再寫代碼
- 讓 AI 扮演 SA 或 Tech Lead，不斷追問細節
- 建立雙方共同理解而非直接生成代碼
- 推薦使用 Matt Pocock 的 Claude Code Skill：grill-me
grill-me 的核心特性：
- 沿決策樹分支往下走，每次只問一個問題
- 附帶建議答案避免迴圈
- 優先查看 Codebase 而不是猜測
體驗要點：”很多時候你以為自己想清楚了，被它問三輪你就知道沒有”
2. 建立團隊的共同語言
利用 DDD（Domain-Driven Design）中的 Ubiquitous Language 概念——團隊、文件、代碼、AI 都用同一套語言。
命名不只是美感問題，更是系統可理解性的問題。不同系統中 User、Account、Wallet 等詞語義不同，AI 容易寫出語法正確但語意錯誤的代碼。
3. 縮短回饋迴路
AI 最容易失控的情境是一次改太多檔案。應有的工具鏈：
- TDD（測試驅動開發）
- Type Check（類型檢查）
- Lint（代碼檢查）
- Unit Test（單元測試）
- Integration Test（整合測試）
- Playwright E2E（端到端測試）
這些不是老派儀式，而是「AI Coding 的煞車系統」。真正好的協作不是一次完成整個功能，而是讓 AI 小步前進，每一步都能被驗證。
4. 持續改善模組邊界
參考 John Ousterhout《A Philosophy of Software Design》：
深模組： 功能多，介面簡單 淺模組： 功能少，介面複雜
AI 害怕淺模組遍布、小函式遍地但無清楚抽象邊界的 Codebase——它不知道真正該改哪裡，只好到處動刀。
工程師在 AI 時代的新價值
工程師不是被取代，而是工作重心被重新拉升，從執行層轉向守住設計邊界：
- 哪些邏輯應該封裝？
- 哪些介面要穩定？
- 哪些規則不能外洩？
- 哪些流程一定要測試？
- 哪些決策要寫成 ADR（架構決策記錄）？
- 哪些內容要放進 CLAUDE.md 讓 AI 下次不要再猜？
工作重心轉變
以前花時間在： 打字、查語法、搬資料、寫樣板
未來更重要的是： 需求拆解、系統設計、測試策略、模組化、把團隊隱性知識整理成 AI 能遵守的規則
評估 AI Coding 的正確問法
不該只問：
「你有沒有用 AI？生產力提升幾倍？」
更該問：
- 「你有沒有用 AI 建立更好的工程流程？」
- 「AI 產出的 Code 有沒有測試可以證明？」
- 「Codebase 是否變得更容易被人與 AI 理解？」
- 「團隊有沒有把隱性知識整理成共同語言與規範？」
重要洞察：”AI 不會自動讓團隊變成熟。但成熟的工程團隊，會因為 AI 變得更快、更穩、更有槓桿”
結論
AI 沒有讓軟體工程基本功過時。它只是讓基本功不好的人，問題暴露得更快。
不是把 AI 當成程式碼老虎機，而是把它變成工程流程的一部分——讓 AI 一起理解需求、對齊語言、驗證結果、改善架構。這才是真正的 AI 協作。