Spec-Driven Development (SDD)是什麼？一個學習者的完整理解筆記

哈囉大家好，我是 Boson。這週跟我一起來學習什麼是 Spec-Driven Development (SDD) 規格驅動開發！

你有沒有過這種經驗？同事走過來說「幫我買一台貼紙機，要可以遠端列印」，然後你問他「什麼叫貼紙機，遠端列印的用途是什麼？」，他說「就...你懂的，貼在包裹的貼紙機？」。我真心不懂。

我當工程師最怕的不是技術問題，而是這種「通靈需求」。沒有人說清楚到底要什麼，做出來了對方才說「不是這個意思」。

後來我研究 Spec-Driven Development (SDD)，才找到一個面對這種困擾的框架。

什麼是 SDD？

在我研究 Vibe Coding、使用 Openclaw（以下簡稱龍蝦）的過程中，最常遇到的痛點是：AI 做出來的東西常常需要修正，有時候做一件小事情，這個錯那個錯，修復起來反而浪費了幾小時。做是做出來了，到底有沒有符合我最初的構想？還要持續優化嗎？怎麼樣才算完成？

SDD 就是針對這個問題的解法。

這時候專屬於程式開發觀念的 SDD 出現在我眼前——規格驅動開發！ 只要一開始用自然語言把規格訂清楚，AI 就會照著走，幫你產出需要的東西。這個邏輯就是 SDD 的核心。

這是解決「上下文過長」導致 AI 幻覺的最佳解法。在龍蝦身上很常見——對話一長，它開始用簡體中文或英文回應你，就代表它的「上下文」差不多滿了。執行架構、寫數百上千行程式，要 AI 完全不幻覺？幾乎不可能。

所以 SDD 出現了。核心理念很簡單：先把規格訂清楚，AI 就會照你的方式一步步完成，並檢驗有沒有達到你說的內容。

其實在實作之後，比對之前的用法（先用 Claude 進行對話、設定意圖並撰寫執行規劃，再貼給龍蝦執行以避免它隨機發散），SDD 有一部分相似，但更嚴謹——它會在過程中進行各項功能測試，也具備回退機制。這能大幅避免盲目試錯的時間成本與系統技術債。

SDD 完整流程：6 個步驟（spec-kit 實作擴展版）

以下流程以 SDD 專用開源工具 spec-kit 作為實作示範。spec-kit 的官方核心流程為 5 步（Constitution → Specify → Plan → Tasks → Implement），以下是我在實際使用後，加入 Clarify 與 Analyze 兩個補充步驟的個人擴展版本，共 6 步。

1. 產生 Constitution 憲章 (/speckit.constitution) 告知 AI 什麼必做、什麼不能做，這是專案的最高指引。

Constitution 並非所有 SDD 工具的標準步驟，但在 spec-kit 的實作中，它是整個流程的最高指引，我把它列為第一步。

2. 執行 Specify 建立規格 (/speckit.specify) 用自然語言敘述，由 AI 產出詳細規格，在 Review 之後再進行刪減添加，調整成你的需求。

Specify 完成後，有一個關鍵的 review checkpoint——/speckit.clarify：

• Clarify 釐清需求：這是 SDD 最有價值的地方之一。AI 會反向對你進行「靈魂拷問」，找出規格中的模糊地帶、邊界情況與邏輯衝突。「AI 不會盲目通靈，而是強迫人類把意圖想清楚」。

3. 產生 Plan 計畫 (/speckit.plan) 你預計用哪些架構來設計？你公司還是個人習慣用什麼資料庫、什麼語言？或是假設我要架設網路核心架構，我可以在這邊撰寫我需要「VPN 使用 WireGuard 方案」之類的技術決策。

4. 產生 Tasks 任務清單 (/speckit.tasks) Plan 計畫完了，當然就要來設計要執行哪些動作。依照順序，是否可拆分？是否可以同步作業？做完應該要再進行哪些檢驗？

除了幫你做以上項目，我覺得最好的是：系統甚至會自動標記哪些任務可以「同步／平行作業 ([P])」，以及嚴格規範執行的先後依賴順序。如果以人的工作來舉例，就是它會幫你把執行的先後順序排列好，並且有 [P] 的任務可以分派給不同人同時去做，到時候再進行匯總。

5. 執行 Analyze 交叉分析 (/speckit.analyze) 這是實作前的品質閘門，AI 會讀取 spec.md、plan.md、tasks.md，檢查整體架構是否有覆蓋缺口或邏輯衝突。

Analyze 同樣是我個人擴展加入的步驟，spec-kit 官方流程中為補充指令，但我認為在正式實作前多一道交叉驗證非常值得。

6. 進行 Implement 實作 (/speckit.implement) 在上述都沒問題之後，進行最後的實際執行動作。

在一般我們執行專案或開發時，測試常常被忽略。但在 SDD 中，Implement 階段會嚴格遵守 TDD（測試優先）原則。AI 會先根據任務清單寫出「測試檢驗腳本」，再寫「實作程式碼」，確保「規格 → 測試 → 程式碼」三者完全對齊。

舉例來說：我要設定 VPN，根據任務清單，AI 會先寫出檢驗腳本（遠端筆電是否能正常連線、所需的應用程式是否能正常開啟等測試清單），讓你有一個明確的驗收標準。

它不只是軟體工具——底層邏輯是什麼

「真相的翻轉 (Truth Inversion)」 通常我們進行專案寫程式碼，或是在執行一些行程規劃時，文件通常寫完就過時了。但在 SDD 框架下，「規格 (Spec) 才是唯一真相 (Single Source of Truth)」。

如果測試失敗或需求改變，你不應該重新回去更改之前的專案計劃書或是程式碼，而是必須回頭去修改 spec.md，再讓 AI 重新產出計畫與程式碼。這確保了專案永遠有一份最新、可以直接拿出來用的數位資產。

為什麼要這樣做呢？大家有沒有想過，AI 產出的速度已經非常快速且準確，所以你只要以「規格需求為中心」，它產出的東西一定都會是合規且可用的。因此，原有的專案計畫與程式碼，已經可以變成「用完即丟」的產物！

舉例：只要回去修改規格（我改個網路硬體需求與 VPN 協議），是不是就可以重新產出完整的方案？不用再重新檢視更換硬體或協議會需要修改哪些範圍、擔心哪些沒修改到而產生困擾。

總結

在了解這個邏輯後，我發現 AI 並不是難用，而是你沒有真正了解應該要如何發揮它的專長。你沒有描述清楚，就想要它做好，這就跟同事跟我提需求與問題一樣，都是憑感覺，每次我都要通靈。

這個方法實作起來並不會讓你更輕鬆，因為每個階段 AI 都會產出你可能沒想過的細節與內容，你都需要閱讀一次是否符合要求。但在追求事情完整、以及建立有規範且可重複使用的知識架構與程式時，這能達到真正的「知識內化」。而且因為內容的詳細，也可以直接產生實際操作流程的 SOP，而不是像之前給 AI 一次性的解答，用完即丟。

希望大家對這篇內容有點幫助，有興起一點點想要了解更多 SDD 的想法。

如果這篇對你有幫助，歡迎訂閱我的電子報。每週一篇，分享一個你可能沒想到的技術技巧或工作流程。
💬 或直接來信交流 [email protected]