什麼是規格驅動開發（SDD）？
規格驅動開發（Spec-Driven Development, SDD）可以說是工程師版的「氛圍開發（Vibe Coding）」。
不同於一般人隨興輸入提示詞的做法，工程師版本的 Vibe Coding 採用傳統軟體工程的方法，將指令以「規格文件」的形式組織起來。
也就是先撰寫完整的產品需求文件（Product Requirements Document, PRD），再讓生成式 AI 依據文件內容，逐步完成各階段產出，最終以系統化方式建構出可執行的軟體。
SDD 強調結構化與意圖導向的開發流程，其核心包括：
- 意圖導向的開發
在思考「如何做」之前，先透過明確的規格定義「要做什麼」。 - 完整的規格撰寫
利用標準化指引建立一致且可重複的規格文件。 - 多階段的精煉過程
不依賴單一提示，而是經由逐步細化與反覆修正產出成果。 - 高度仰賴進階 AI 能力
讓 AI 理解與詮釋規格，並據以生成設計與程式。
傳統開發流程類型
在傳統的循序式開發流程中，會先進行需求分析並撰寫產品需求文件，接著依序產出系統分析、架構設計與模組設計文件。每個階段都有對應的驗證活動，如用戶驗收測試、系統測試、整合測試與單元測試。
每一階段的輸出同時也是下一階段的輸入，形成明確的開發與驗證對應關係。
規格驅動開發（SDD）的工具
由於 SDD 仍處於起步階段，以下先簡要介紹目前較受關注的幾個專案：
BMAD-METHOD
BMAD-METHOD 將傳統開發的角色分工與流程結構，結合 AI agent 的協作能力，使 AI 不只是單一模型，而能組成一支具有角色分工的「AI 團隊」。內建的角色包括：
- 產品經理（Product Manager）
- 分析師（Analyst）
- 產品負責人（Product Owner）
- 架構師（Architect）
- 開發人員（Developer）
- 測試人員（Test Architect & Quality Advisor）
- Scrum Master
- 使用者體驗專家（UX Expert）
在不同階段與不同角色的 AI agent 討論及協作，產出該階段的規格。
Spec Kit
Spec Kit 將規格驅動開發劃分為五個步驟：
- 制定專案原則（constitution）
建立專案管理與開發指南，例如程式碼風格、測試標準等，使後續開發有一致依循。 - 建立功能規格（specify）
描述系統要提供的功能，而不涉及技術實作。如 AI 對需求理解不足，則進一步澄清與細化。 - 制定計畫（plan）
明確定義技術架構與開發框架，例如使用的平台、程式語言與框架。 - 產生任務清單（tasks）
依計畫拆解需求，形成可執行的具體任務。 - 實作（implementation）
依任務逐步開發功能，完成規格所定義的系統。
Kiro
AWS 的 Kiro 提供了整合性的 AI 開發環境，也支援規格驅動的開發流程。其主要步驟包括：
- 需求階段
以結構化描述定義使用者故事與驗收條件。 - 設計階段
記錄技術架構、流程圖與實作考量。 - 實作規劃階段
將工作分解為可追蹤任務，並明確描述輸出目標。 - 執行階段
追蹤任務進度，並根據需求持續更新與修正規格。
SDD 的好處
傳統開發中，需求文件往往在初期完成後便鮮少更新。開發人員通常直接修改程式碼以反映變更，導致文件與實際系統逐漸脫節，最終難以信任。
若要了解系統邏輯，只能從程式碼反推，但除非程式碼的結構良好，編寫整潔規範，不然這並非簡單的事。另外程式碼往往缺乏變動原因與設計背景，也會造成知識斷層。
而 SDD 以規格為中心，透過規格驅動實作，使規格與系統持續保持同步。當程式碼由規格生成時，文件也能自動更新為最新版本，讓規格重新成為可靠的知識來源與溝通基礎。
SDD 的挑戰
規格驅動開發與生成式 AI 一樣仍在發展階段，導入前應審慎考慮以下挑戰：
AI 產生的程式碼仍會出錯
雖然 SDD 比 Vibe Coding 更具結構，但生成式 AI 仍可能產生幻覺或邏輯錯誤。提示詞能降低出錯率，但並非能完全避免。
因此仍需人工檢查與修正，而這又可能導致規格與實作重新出現落差。
SDD 僅解決「規格與實作」間的問題
軟體開發最難的往往不是規格撰寫，而是「決定要建造什麼」。若使用者需求定義不清，即使規格與實作完美對應，最終成果仍可能無法產生價值。
自然語言表達的精準度有限
許多事物僅能意會，無法言傳。文字表述天生有模糊性及侷限，難以完全避免誤解。AI 目前也無法超越語意限制，仍可能誤讀需求或生成偏離意圖的結果。
放棄思考的風險
AI 生成的文件對人類而言仍可能模糊不清。若開發團隊與需求方僅靠「看文件」溝通，而不透過互相討論驗證，誤解便難以消除。
更重要的是，寫作本身是一種思考與重構知識的過程。若把這個過程全交給 AI，對於需求的理解將停留在「閱讀」而非「創造」，難以察覺錯誤或盲點。
適用性限制
生成式 AI 的能力來自龐大的訓練資料，對於高度創新或模糊的專案，缺乏可參考樣本時，AI 便無法自動做出合理判斷，仍需人工決策介入。
成本考量
SDD 通常需要多個及多次 AI agent 協作，且頻繁讀寫大量上下文，導致模型呼叫次數與 token 成本顯著提高。
當前建議
- 單人作業
若將 SDD 作為主要開發流程，現階段較適合需求單純的獨立開發者或小型新創。 - 多人協作
當多人分工時，建議仍依循原本做法，透過團隊與需求方面對面溝通建立人工初版規格，再由 AI 輔助檢查文字精確度或邏輯一致性。
AI 的角色應是「輔助核查者」，而非「規格主導者」。
最後規格底定，任務展開後，再由開發人員逐步讓 AI 依規格生成程式碼並驗證其產出。
當有一天，AI 能直接與使用者協作生成 100% 正確且可執行的系統時，才算是真正實現了理想的「規格驅動開發」。
