[整理分享一些關於 Spec-Driven Development (SDD) 的看法和內容]
Spec-Driven Development (SDD) 是什麼? 簡單說講就是在用 AI 寫程式之前，先讓 LLM 生成一大堆規格文件: 產品需求 → 技術設計 → 任務清單，然後才交給 coding agent 執行。目前有幾個工具在推這套流程: GitHub 的 Spec-Kit、AWS 的 Kiro、還有 Tessl。
社群討論其實非常兩極。正面看法認為遠比 vibe coding 可靠、適合要上線維護的真實專案、開發速度中期來看其實更快。負面看法則認為這就是 Waterfall 2.0、過度工程化、扼殺創造力。我自己從一開始就不太看好，最近看到幾篇深度分析文章，更加印證了我的看法。
第一篇: Spec-Driven Development: The Waterfall Strikes Back
作者 François Zaninotto 認為 SDD 試圖解決一個錯誤的問題:「如何把開發者從軟體開發中移除」。他列出實際使用的痛點:
- 脈絡盲區: SDD agent 跟 coding agent 一樣透過文字搜尋來理解脈絡，常常漏掉需要更新的既有功能
- Markdown 地獄: 產出太多文字，開發者花大部分時間在讀冗長的文件，從看似專業的文字海中找出基本錯誤
- 雙倍 Code Review: 技術規格裡已經有程式碼，要先審查規格再審查實作，審查時間直接翻倍
- 虛假的安全感: Agent 不一定照規格走，他看到 agent 把「驗證實作」標記完成，卻只寫了手動測試說明而非單元測試
- 邊際效益遞減: 專案越大，規格越容易失準，對大型既有程式碼庫幾乎無法使用
他主張用自然語言小步迭代，像 Lean Startup 那樣識別風險假設、設計最小實驗、快速驗證，這才是 coding agent 的正確用法。
第二篇: Spec Driven Development – revenge of Waterfall or BDD taken to new level?
BDD 大師 Gojko Adzic 的觀察是:
- 規格太高層次: 產出的驗收條件用 Given-When-Then 格式，需求用 must/should/could 分級，但都太抽象，比較像工作範圍而非真正的規格
- 文件是給工具用的: 過程中產生大量文字，大部分是讓工具追蹤自己進度用的，不是給人讀的，他們最後都只是快速掃過或直接跳過
- 缺少範圍定義階段: 沒有明確的 scoping 步驟，導致工具想做太多事然後失控，產出大量測試和程式碼，human in the loop 變得不可行
- 所謂可執行規格其實是測試: 真正的規格最後都變成單元測試和整合測試，只有開發者看得懂
結論: 有潛力值得關注，但目前離可執行規格的承諾還很遠，需要更明確的範圍定義階段來促進迭代交付。
第三篇: Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl
Thoughtworks 的 Birgitta Böckeler 發表在 Martin Fowler blog 上，他花大量時間評測三個工具，她把 SDD 分成三個層次:
- Spec-first: 先寫好規格，用於當下的開發任務
- Spec-anchored: 任務完成後規格保留下來，持續用於功能的演進和維護
- Spec-as-source: 規格成為主要的原始檔，人類只編輯規格、不碰程式碼
理想上第 2 和第 3 層才是 SDD 的終極願景，但她發現目前的工具大多只停在第 1 層。
他的觀察:
- 一套流程打天下? 她用 Kiro 修一個小 bug，結果被拆成 4 個 user story、16 條驗收條件，完全是殺雞用牛刀
- 寧願審查程式碼: Spec-kit 產出大量重複冗長的 Markdown，與其讀這些文件不如直接看程式碼
- 虛假的控制感: 即使有模板和檢查清單，agent 還是經常忽略指示或執行過頭。例如研究步驟收集了既有類別的資訊，結果 agent 當成新規格重新生成一遍，產生重複程式碼
- 讓人想起 MDD: Model-Driven Development 當年也想用規格生成程式碼，最後沒成功。LLM 解決了一些限制，但也帶來非確定性的新問題
她用了一個德文詞 Verschlimmbesserung: 在試圖改善的過程中反而把事情搞得更糟。
其他看法
宝玉(AI大V) 說: 我个人是不喜欢用 spec-kit，不是好的上下文工程： 小项目没必要、大项目描述不清楚、一大坨文档反而占用上下文影响生成、文档不保持及时更新反而会误导 Agent [4]
swyx (AI Engineer Summit 大會主辦人) 給了一個簡短的 tweet: Spec Driven Development is Wishful Thinking「SDD 只是一廂情願」 [5]
SDD 小結
SDD 的終極願景很美好: 人類只維護規格、AI 負責生成程式碼，規格成為長期維護的 source of truth。
但現實是殘酷的，目前這些工具都只停在 Spec-first 的層次，規格寫完用完就丟，跟傳統的需求文件沒什麼兩樣，只是多了一堆 Markdown 要讀。
過去敏捷開發已經證明，緊密協作比詳盡文件更有效。現在 coding agent 讓我們可以直接用自然語言描述需求、即時看到結果，為什麼要走回頭路去寫一堆規格文件?
SDD 的初衷是想讓 AI 更受控，但目前實際上是用更多文件換來更多負擔，卻沒有換到相應的品質保證。
第四篇: Vibe Engineering (Simon Willison)
相較於 SDD 想用規格文件流程來馴服 AI，Simon Willison 大大(Python Django 共同發明者) 提出了另一種以開發者專業為本的方向:「Vibe Engineering」，這不是隨便亂寫的 vibe coding，而是資深工程師運用 LLM 加速工作，同時對產出的軟體品質負責。
Vibe Engineering 跟 SDD 有什麼不同? 兩者都有要先做計畫，但形式差很多:
- 文件份量: SDD 產出大量結構化 Markdown（requirements.md → design.md → tasks.md），Vibe Engineering 的計畫比較輕量，強調可以快速迭代
- 流程僵固度: SDD 有固定的多階段流程，Vibe Engineering 更強調靈活組合各種工程實踐
- 核心理念: SDD 想用規格文件來「控制」AI，Vibe Engineering 認為應該靠工程師的判斷力和既有的工程實踐來確保品質
- 責任歸屬: SDD 傾向讓流程和文件來保證品質，Vibe Engineering 明確說工程師要對產出的軟體「proudly and confidently accountable」
Simon 指出 LLM 會獎勵既有的頂級軟體工程實踐:
- 自動化測試: 有完整測試套件的專案，coding agent 可以放心跑；沒測試的話 agent 可能宣稱完成但根本沒驗證
- 事前規劃: 先有高層次計畫再交給 agent，而且可以先迭代計畫本身
- 完善文件: 好的文件讓模型能直接使用 API 而不用先讀完所有程式碼
- 良好的版本控制習慣: LLM 很擅長 Git，能自己翻歷史追 bug，善用 git bisect
- 有效的自動化流程: CI/CD、自動格式化、linting，agent 也能受益
- Code Review 文化: 擅長審查程式碼的人，跟 LLM 協作會順暢很多
- 手動 QA 能力: 除了自動測試，還要能預測和挖掘邊緣案例
簡單說，AI 工具會放大既有的專業能力，軟體工程技能越強，從 LLM 得到的結果就越好越快。