Spec-Driven Development (SDD) 是一種結構化的開發方法論，透過將技術決策轉化為可審查、可演進的規格文件，來協助團隊在使用 AI 編碼工具時維持程式碼品質與架構一致性。這個方法特別適合用於全新專案開發、現有系統的功能擴充，以及遺留系統的現代化改造。社群對此方法論的看法相當兩極：支持者認為它能有效解決「Vibe Coding」帶來的程式碼品質問題，而批評者則質疑它增加了前期規格撰寫的負擔，可能違反敏捷開發的精神。
什麼是 Spec-Driven Development？
Spec-Driven Development 並不是要你撰寫冗長無聊、沒人會讀的需求文件。它也不是瀑布式開發，更不是透過大量規劃來預測未來的做法。相反地，SDD 是關於讓你的技術決策變得明確、可審查且可演進。
想像一下這個情境：你的團隊正在開發一個通知系統，產品經理認為「通知偏好」意味著每個頻道都有獨立開關；後端工程師則建立了一個簡單的開/關按鈕；前端開發者假設它會整合使用者的作業系統通知設定；設計師則設計出需要重建半個使用者服務的介面。這不是溝通失敗，而是共享脈絡的缺失。每個人都基於不完整的資訊做出合理假設，而 SDD 提供了一種輕量級方式，讓這些假設在早期階段就浮現出來。
這個方法論對於依賴 AI agents 來建構產品的流程特別重要，因為共享脈絡成為能夠引導 AI 代理找到正確解決方案的寶貴資產。由於規格本身與程式碼分離，你甚至可以輕鬆創建多種變體實作。
Spec-Driven Development 的核心階段
SDD 將開發過程分為三到四個不同階段，每個階段都有特定的目標和產出：
| 階段 | 焦點 | 關鍵活動 |
|---|---|---|
| Specify（規格制定） | 定義「是什麼」和「為什麼」 | 提供高層次描述，讓 AI 編碼工具生成詳細規格，定義使用者旅程、體驗和成功標準 |
| Plan（技術規劃） | 確定「如何做」 | 提供技術堆疊、架構和限制條件，AI 生成全面的技術計畫 |
| Task（任務分解） | 可實作的具體任務 | 將計畫分解為可實作、可測試的部分，每個任務都有明確的成功標準 |
| Implement（實作） | 程式碼生成 | AI 根據規格和計畫生成程式碼、測試和文件 |
這種結構化的工作流程將需求轉化為詳細的可執行規格，消除了模糊性。與傳統需求文件不同，可執行規格包含了實作層級的細節，讓團隊成員不會有不同的理解。
GitHub Spec Kit：開源的 SDD 工具包
GitHub 在 2025 年推出了 Spec Kit，這是一個開源工具包，旨在幫助開發者開始使用 Spec-Driven Development。這個工具包強調幾個核心哲學：
意圖驅動開發
規格定義「是什麼」，而不是「怎麼做」。這讓 AI 編碼工具能夠根據你的意圖生成最適合的實作方式。
豐富的規格創建
使用護欄和組織原則來建立詳細的規格。這不是隨意寫寫就好，而是有結構化的方法。
多步驟精煉
不是從提示一次生成程式碼，而是透過多個階段逐步精煉。這個過程更像是與 AI 協作，而不是單純下指令。
依賴先進 AI 模型
Spec Kit 高度依賴先進的 AI 模型能力來解讀規格。這意味著你需要使用像 GPT-4、Claude 或其他最新的大型語言模型。
Spec-Driven Development 的三大應用場景
根據 GitHub 和社群的實踐經驗，SDD 在三種場景中特別有效：
全新專案開發（零到一）
當你開始新專案時，很容易就直接開始寫程式。但少量的前期工作來建立規格和計畫，能確保 AI 建構的是你真正想要的東西，而不只是基於常見模式的通用解決方案。這個階段特別適合採用 MVP 與精實創業的思維。
現有系統的功能開發（N 到 N+1）
這是 SDD 最強大的應用場景。在複雜的現有程式碼庫中新增功能很困難，透過為新功能建立規格，你可以強制釐清它應該如何與現有系統互動。計畫則編碼了架構限制，確保新程式碼感覺像是系統的原生部分，而不是硬加上去的。
遺留系統現代化
當你需要重建遺留系統時，原始意圖往往已經遺失在時間中。透過 Spec-Driven Development 流程，你可以在現代規格中捕捉核心業務邏輯，在計畫中設計全新架構，然後讓 AI 從頭重建系統，而不會帶著繼承的技術債。
社群如何看待 Spec-Driven Development？
社群對 SDD 的討論相當熱烈，意見也相當分歧。
支持者的觀點
許多開發者認為 SDD 是「Vibe Coding」的必要演進。Vibe Coding 指的是直接用自然語言提示 AI 生成程式碼，但這種方式常常導致程式碼品質不穩定、難以除錯，甚至出現災難性的不可靠行為。SDD 透過結構化的流程，讓 AI 生成的程式碼更可靠、更易維護。
有開發者分享了使用 GitHub Spec Kit 的正面經驗，表示「我試用了 GitHub Spec-Kit，結果得到了一個真正可用的網站」。這種結構化方法特別適合需要長期維護的專業專案。
批評者的疑慮
然而，不是所有人都認同這個方法論。Reddit 上有一篇標題直接了當的討論串：「Spec-driven development for AI is a form of technical masturbation」（Spec-Driven Development 是一種技術自慰）。批評者認為像 Spec-kit、bmad、Openspec 這類框架都是無用的。
主要的批評點包括：
人為因素的挑戰：一位有超過 10 年開發經驗的工程師表示，「我很少經歷過需求在實作前就完全制定好的專案」。開發者往往是「有效率的」，但更誠實的說法是「懶惰的」。SDD 要求開發者精確地指定他們的意圖，但這正是模型面臨的最大挑戰。
規格飄移問題：如果程式碼改變了但規格沒有更新，信任就會崩潰。這需要團隊維持紀律，持續更新規格文件。
增加前期負擔：有些開發者質疑這種方法是否真的減少了開發時間，還是只是創造了一個自己製造的問題——管理 AI 生成的程式碼品質——可能會因為程式碼架構優化不佳和規格撰寫的額外負擔，導致長期挫折。
Spec-Driven Development vs. Vibe Coding
這兩種方法論代表了使用 AI 輔助開發的兩個極端：
Vibe Coding：直接用自然語言提示 AI，快速獲得結果，但程式碼品質不穩定。這種方法適合快速原型開發和實驗性專案。
Spec-Driven Development：透過結構化的規格和計畫，確保 AI 生成的程式碼符合架構標準和業務需求。這種方法適合需要長期維護的專業專案。
有趣的是，社群中有聲音認為這不是非黑即白的選擇。平衡才是關鍵——AI 應該作為協作者，而不是替代品。使用「vibe」來加快速度，但讓測試、程式碼審查和真正的工程紀律來維持品質。
實務挑戰與最佳實踐
從社群討論中，我們可以歸納出一些實務上的挑戰和最佳實踐：
規格的演進問題
有開發者在 GitHub Spec Kit 的討論區提出疑問：「Spec-driven development 似乎表示規格是系統的真相來源，但 Spec Kit 讓我為每個新功能創建新的規格」。這引發了一個問題：規格應該是長期存在的真相來源，代表目標狀態，還是應該與功能分支對齊，代表增量變化？
複雜專案的應用
對於複雜的功能豐富的棕地系統（Brownfield），如何使用 Spec Kit 仍然是一個開放的問題。社群正在探索如何將 SDD 應用於大型現有專案。
工具整合
雖然 Spec Kit 設計為與 GitHub Copilot 等工具整合，但社群中也有人在使用其他 AI 編碼工具，如 Cursor、Windsurf 等。這些工具的整合品質參差不齊，許多新的 AI 工具整合來自社群的貢獻請求，創造了不一致的品質。
技術獨立性與企業限制
GitHub Spec Kit 的一個重要目標是技術獨立性。它試圖驗證一個假設：Spec-Driven Development 是一個流程，不綁定於特定技術、程式語言或框架。
這對企業來說特別重要：
- 你可以在規格中納入組織限制（雲端供應商、技術堆疊、工程實踐）。這讓 SDD 能夠適應企業的現有架構和合規要求。
- 支援企業設計系統和合規需求。這意味著生成的程式碼不只是能用，還要符合公司的標準和政策。
- 展示關鍵任務應用程式的開發。SDD 不只是玩具專案，它能夠支援真正的生產級應用。
未來發展方向
社群和工具提供者正在探索幾個方向：
平行實作探索
驗證平行實作探索的概念。你可以基於同一個規格，要求 AI 生成多個不同的實作（例如一個用 Rust，另一個用 Go），然後比較效能。
迭代功能開發工作流程
提供強健的迭代功能開發工作流程。讓規格成為活文件，隨著程式碼一起演進。
Constitution.md 的使用
許多人建議在開始使用 Spec Kit 之前，先定義專案的不可妥協慣例，放在一個 constitution.md 檔案中。這個檔案包含團隊特定的指導原則（如編碼慣例、技術選擇）和專案特定的指導原則。
我應該使用 Spec-Driven Development 嗎？
這個問題沒有簡單的答案，取決於你的專案類型和團隊需求。
適合使用 SDD 的情況：
你正在建構需要長期維護的專業應用程式：如果你的專案會持續演進數月或數年，SDD 提供的結構化方法能幫助團隊保持一致性。
你的團隊需要跨部門協作：當支付團隊需要參考使用者管理規格來了解確切的資料結構和 API 合約時，規格成為共享的真相來源。
你需要加速新成員的上手過程：新開發者可以透過閱讀可執行規格快速變得有生產力，這些規格包含了完整的系統知識。
可能不適合 SDD 的情況：
你正在做快速原型或實驗性專案：在這些情況下，程式碼品質相對不重要，Vibe Coding 可能更有效率。
你的團隊沒有撰寫詳細規格的習慣或意願：如果強制實施 SDD，可能會造成反效果。
你的專案需求經常快速變化：在這種情況下，維護規格和程式碼的同步可能會成為負擔。
如同一位經驗豐富的開發者所說：「我會繼續在我的專案中實驗 Spec-Driven Development，並在方法論和工具成熟時發布更新」。早期跡象顯示，雖然 SDD 增加了前期規格撰寫的負擔，但對於將 AI 輔助開發擴展到原型級應用之外可能是必要的。
結論
Spec-Driven Development 代表了 AI 輔助開發的一個重要演進方向，它試圖在「快速開發」和「程式碼品質」之間找到平衡點。雖然社群對此方法論仍有不同意見，但越來越多的證據顯示，對於需要長期維護的專業專案，結構化的規格驅動方法能夠帶來實質的好處。
關鍵在於找到適合你的團隊和專案的平衡點。你不需要在 Vibe Coding 和 Spec-Driven Development 之間做出非黑即白的選擇——結合兩者的優點，使用規格來確保關鍵功能的品質，同時在原型階段保持靈活性，可能是最實用的做法。
隨著 AI 編碼工具的持續發展，以及像 GitHub Spec Kit 這樣的開源工具變得更加成熟，我們可以預期 Spec-Driven Development 會在企業級應用開發中扮演越來越重要的角色。無論你選擇哪種方法，重要的是理解工具的局限性和潛在風險，並保持人類的創造力、批判性思維和解決問題的能力。
準備好讓 AI 輔助你的開發流程了嗎？
在 Tenten，我們專精於協助企業導入最新的 AI 開發工具與方法論。無論你是想採用 Spec-Driven Development 來提升團隊效率，還是需要建構能夠長期維護的高品質應用程式，我們的專業團隊都能提供客製化的解決方案。
我們的服務包括：
- AI 輔助開發工具導入與培訓
- Headless CMS 與現代化網站架構設計
- 開發流程優化與最佳實踐建議
- 從概念到上線的全方位技術支援
想了解更多關於如何運用 AI 提升你的開發效率嗎？立即預約諮詢，讓我們一起探索最適合你團隊的 AI 開發策略。
作者觀點
身為長期關注 AI 開發工具演進的實踐者，我認為 Spec-Driven Development 並不是要取代現有的敏捷開發方法，而是為 AI 時代的軟體開發提供一個新的思考框架。
最讓我印象深刻的是 SDD 如何將「思考的版本控制」這個概念具體化。在過去，我們有 Git 來追蹤程式碼的變化，但技術決策的「為什麼」往往散落在 Email、會議記錄或某個人的腦海中。SDD 透過規格文件，讓這些決策變得可見、可討論、可演進。
然而，我也同意社群中的一些批評聲音。如果規格撰寫變成了形式主義的官僚作業，那確實會扼殺創新和敏捷性。關鍵在於把規格當作「思考工具」而不是「交付物」——它的價值在於幫助團隊對齊理解，而不是產出完美的文件。
對於想要嘗試 SDD 的團隊，我的建議是：從小處開始。選擇一個中等複雜度的功能，用 SDD 的方法走一遍完整流程。觀察它如何影響團隊協作、程式碼品質和新成員上手速度。然後根據實際經驗，調整出適合你團隊的「輕量版 SDD」。
記住，任何方法論都只是工具，真正重要的是它能否幫助你的團隊更有效地交付有價值的軟體。如果 SDD 能做到這點，那就值得採用；如果它變成了負擔，那就勇於調整或放棄。這才是真正的工程思維。
想要了解更多關於 AI 輔助開發的實踐經驗，歡迎參考我們在 Tenten 的其他文章，包括 MVP 與精實創業、Headless CMS 開發心得 以及 Kiro Spec 驅動開發實戰技巧。
關於作者：我是一名專注於 AI 工具整合和現代 Web 開發的技術顧問，在 Tenten 協助企業進行數位轉型和產品開發。如果你對 Spec-Driven Development 或 AI 輔助開發有任何問題，歡迎透過 Tenten 的諮詢服務與我們聯繫。
