【開發雜談】Vibe Coding 2.0：從文件驅動 (DDD) 進化到規格驅動 (SDD)，讓 AI 真正為你所用
發布於 2025年12月29日 (更新於 2025年12月29日) · 約 2 分鐘閱讀 · Vibe Coding SDD AI Software Engineering GitHub Spec Kit
Hi 大家好，我是 ChiYu！
最近在社群和鐵人賽裡，我們聊了很多關於 Vibe Coding 的話題。那種「指尖在鍵盤上飛舞，AI 像讀心術一樣把程式碼一行行噴出來」的感覺，確實很容易讓人上癮，對吧？
但身為一個在代碼海裡打滾多年的資深工程師，我相信你在激情過後，一定也遇過這種「賢者時間」： 看著 AI 幫你寫出來的那幾千行程式碼，雖然能跑，但結構鬆散、變數命名隨意，甚至埋了一些你現在看不出來、但下個月會讓你加班到天亮的 Bug。
我們之前談過 DDD (Document Driven Development，文件驅動開發)，強調「先有文件，才有 Code」，這是我們馴服 AI 的第一步。但今天，我要帶大家進入更深一層的領域。
如果說 DDD 是我們跟 AI 簽訂的「君子協定」，那麼今天要介紹的 SDD (Spec Driven Development，規格驅動開發)，就是把協定升級成「法律條文」。
準備好了嗎？我們來聊聊，為什麼你需要 SDD。
一、 回顧 DDD：我們為什麼要「左移」？
在進入新世界前，我們不能忘本。DDD 的核心價值在於 Shift-Left (左移)。
傳統的開發模式（或者是失控的 Vibe Coding），往往是「右移」的：
- 有一個模糊的想法。
- 直接開始寫 Code (或是叫 Copilot 寫)。
- 發現邏輯不通。
- 打掉重練 (Refactor)。
這個「打掉重練」的成本是巨大的。DDD 告訴我們：「在寫 Code 之前，先用自然語言把邏輯理清楚。」
在文字階段（Document）修改邏輯，成本趨近於零；但在程式碼階段（Code）修改邏輯，成本是指數級上升。所以我們寫文件，我們建立 SSoT (Single Source of Truth，單一真理來源)，讓 AI 有所依據。
但是，DDD 還有一個致命的弱點。
那就是 「文件與程式碼的同步性 (Sync Rot)」。 人是懶惰的，AI 是被動的。當專案趕上線的時候，你改了 Code 修 Bug，卻往往忘了回頭去改文件。久而久之，文件變成了「僅供參考」的歷史遺跡，AI 讀了過期的文件，寫出了過期的 Code。
這時候，我們需要一種更強制的手段。
二、 SDD：規格即真理，程式碼只是投影
SDD (Spec Driven Development) 的出現，就是要解決「文件」與「實作」脫鉤的問題。
在 SDD 的哲學裡，規格 (Spec) 不再只是給人看的「說明書」，它是給機器看的「藍圖」。
試想一下建築業：建築師畫了一張藍圖（Spec），這張藍圖標示了樑柱的位置、水電的走法。工人（AI）不是「參考」這張圖去蓋，而是必須「嚴格遵守」這張圖。如果樑柱位置不對，房子會倒（編譯失敗）；如果水電接錯，驗收不會過（測試失敗）。
SDD 的三大核心支柱：
規格結構化 (Structured Specs) DDD 的文件可能是 Word 或 Markdown 的純文字描述，雖然易讀，但容易有模糊地帶。 SDD 的規格通常具備更嚴謹的結構。它可能是 OpenAPI (Swagger) 定義 API 介面，可能是 JSON Schema 定義資料結構，或者是特定的 DSL (Domain Specific Language)。 重點是：它消除了「我覺得應該是這樣」的通靈空間。
單向驅動 (Unidirectional Flow) 在 SDD 流程中，Spec 是上游，Code 是下游。 你想要修改功能？禁止直接改 Code！ 你必須先去修改 Spec，然後讓工具或 AI 根據新的 Spec 重新生成或調整 Code。這確保了 Spec 永遠是最新的，永遠是那個 Single Source of Truth。
可驗證性 (Verifiability) 這是 SDD 最強大的地方。因為規格是結構化的，我們可以寫程式去檢查規格。
- 「有沒有遺漏的錯誤處理？」
- 「輸入的資料型態對不對？」 甚至，我們可以根據 Spec 自動生成測試案例 (Test Cases)。如果 AI 寫的 Code 通不過這些由 Spec 生成的測試，那就代表實作錯誤。
一句話總結 SDD：我們不再手寫「實作細節」，我們專注於撰寫「系統行為」。
三、 為什麼 AI 時代更需要 SDD？
你可能會問：「ChiYu，這聽起來好硬核，以前沒有 AI 我們也在寫程式啊，為什麼現在一定要 SDD？」
問得好！正是因為 AI 太強了，所以我們才需要 SDD。
以前我們自己寫 Code，我們的腦袋就是 Context（上下文），我們知道這行 Code 跟上一行 Code 的關係。但現在是 AI 在寫，AI 的記憶（Context Window）是有限的，而且它很會「一本正經地胡說八道 (Hallucination)」。
如果你只給 AI 一個模糊的指令：「幫我寫個購物車。」 它會給你一個購物車，但可能用的是你沒看過的 Library，或是完全忽略了資安問題。
但如果你給 AI 的是 SDD 規格：
- Schema: 商品資料結構長這樣。
- Flow: 結帳流程是 A -> B -> C。
- Constraint: 庫存不能為負數，必須使用 Optimistic Locking。
這時候，AI 就從一個「創意過剩的藝術家」，變成了一個「精準執行的工程師」。SDD 就是我們控制 AI 「發散（創意）」與「收斂（精準）」 的閥門。
四、 預告：GitHub Spec Kit —— SDD 的終極實踐框架
講了這麼多心法，我知道大家手癢了。「那到底要用什麼工具？」
以前做 SDD 很痛苦，要自己寫 YAML，自己架驗證工具。但現在，GitHub 官方推出了一個開源的神級框架 —— GitHub Spec Kit (github/spec-kit)。
它不是一個簡單的 Plugin，它是一套完整的 SDD 工作流框架。Spec Kit 提出了一個非常有趣的開發哲學，它把開發分成了幾個階段，而這些階段完美對應了 SDD 的精神：
- 憲法 (Constitution)： 這是最高指導原則。你可以定義：「本專案所有的變數命名都要用駝峰式」、「一定要寫單元測試」。這就像是阿西莫夫的機器人定律，AI 絕對不敢違抗。
- 規格 (Specify)： 它會引導你把模糊的需求，轉化成一份結構嚴謹的
spec.md。這份檔案會包含 User Stories、Edge Cases（邊界案例）。注意喔，這時候還沒開始寫 Code！ - 計畫 (Plan)： 有了規格，Spec Kit 會要求 AI 生成一份
plan.md。它會詳細列出：「我預計要修改哪幾個檔案、新增哪些函數」。 這就是我們人類介入的最佳時機！ 我們審查計畫，就像審查建築圖紙一樣。計畫通過，才准動工。 - 執行 (Task & Execute)： 最後，才是讓 AI 去寫 Code。因為前面的規格和計畫都確認過了，這裡的寫 Code 就只是單純的體力活。
結語：下集預告
SDD 不是要限制你的創造力，而是要釋放你的大腦。
當我們可以把「確保實作正確性」這件事交給 Spec 和 AI 去處理時，我們人類工程師的價值，就昇華到了「設計架構」、「定義問題」和「審查邏輯」上。這才是資深工程師該做的事，不是嗎？
這篇文章我們先把 SDD 的觀念拉齊。我知道你們一定很想知道：
- 「GitHub Spec Kit 具體怎麼裝？」
- 「那個 plan.md 實際上長什麼樣子？」
- 「怎麼用它來開發一個真實的功能？」
別急！在下一篇文章中，我將會手把手帶大家實戰 GitHub Spec Kit。我們會從零開始，安裝環境、設定憲法，並實際用 SDD 的流程跑一次功能開發。
請準備好你的 VS Code 和 GitHub 帳號，我們下一篇見！