用行為驅動開發（Behavior-Driven Development, BDD）方法論解決 AI 時代軟體開發三大痛點（上）
週五下午，你用 AI 在三十分鐘內生出了一個完整的功能模組。程式碼跑起來了，Demo 也過了，你帶著滿足感關上筆電，準備放假。
週一早上回來，發現有個邊際案例沒覆蓋到。你打開那段程式碼，由於是請 AI 寫的，第一時間還有些看不太懂。你試著請 AI 修，它改了 A 壞了 B，修了 B 又動了 C。
三個小時後，不禁懷疑：「我自己寫，是不是還比較快？」
根據 CodeRabbit 針對 470 個開源 GitHub PR 的分析，AI 協作產出的程式碼平均產生 1.7 倍的問題數量，其中 XSS 等安全漏洞更高達 2.74 倍。而 GitClear 針對大規模程式碼的分析也發現，AI 協作讓程式碼的重複率明顯上升，重構的比例卻反而下降。AI 幫我們寫了更多程式碼，但花在整理上的時間卻更少了。
問題有多嚴重？據 NBC News 報導，Fiverr 平台上 WordPress 錯誤修復需求在半年內暴增 712%；而 404 Media 的調查也揭露，越來越多工程師專門以「清理 AI 產出的程式碼」為業，修復費用往往比一開始就請人寫還高。
而在 2025 年中，規格驅動開發（Spec-Driven Development, SDD） 逐漸在軟工圈中提升能見度，說明未來在撰寫程式碼前，你必須先把規格寫清楚，再讓 AI 動手。
目錄
一、規格驅動開發（Spec-Driven Development, SDD）：把規格做對
既然 AI 腦補是問題的根源，業界給出的回應是：「在讓 AI 寫程式之前，先把規格寫清楚。」
這個思路被稱為規格驅動開發（Spec-Driven Development, SDD），正在成為 AI 輔助開發中最受關注的方法論之一。
什麼是規格驅動開發？從 Vibe Coding 到 Spec-Driven Development 的轉變
規格驅動開發的核心主張很直接：在生成程式碼之前，先撰寫一份結構化的規格文件，作為 AI 開發的「唯一事實來源」。
這個概念其實不新，但在 AI 寫程式的時代獲得了新的生命。原因在於，當開發者用自然語言跟 AI 對話來寫程式——也就是所謂的 Vibe Coding，效率看似提升了，但問題也跟著來：
- 你講的是一句話，AI 理解的是另一件事——自然語言本身就充滿模糊空間，AI 只能靠猜來填補你沒說清楚的部分
- 就算 AI 猜對了大方向，細節上的邊界案例和業務規則往往是錯的，因為這些隱含知識從來沒有被寫下來
- 更麻煩的是，每一輪修改對話都可能讓 AI 在修 A 的同時破壞 B，程式碼的一致性越改越差
SDD 的回應方式是：與其讓 AI 猜你要什麼，不如先把需求寫成機器也能讀懂的結構化規格。 用這份規格來約束 AI 的行為，讓它在明確的框架內施工。
不過，「先寫規格」這件事在實際做法上有深有淺。從目前業界的嘗試來看，可以大致分成三種程度：
- 最基本的做法是開發前先寫一份規格，寫完就交給 AI 去實作，規格本身在功能完成後可能就不再維護了——這比 Vibe Coding 好，但規格的生命週期很短，下次改需求時又要重來一遍。
- 進階一點的做法是讓規格持續活著，功能完成後規格不丟掉，而是隨著系統演進持續更新，成為團隊長期維護的參考文件。
- 極端的做法則是人類只寫規格、完全不碰程式碼，所有程式碼都由規格自動生成，開發者不再直接改 code。這聽起來很理想，但目前還沒有成熟的工具能穩定做到這件事。
目前大多數 SDD 工具（包括 SpecKit、Kiro）都還停留在第一種程度，也就是「寫完規格就交給 AI」的階段。
| 層次 | 做法 | 規格的角色 |
|---|---|---|
| Spec-first（規格優先） | 開發前先寫規格，完成後規格可能丟棄 | 單次任務的指引 |
| Spec-anchored（規格錨定） | 規格在功能完成後持續保留，隨功能演進更新 | 長期維護的參考文件 |
| Spec-as-source（規格即原始碼） | 人類只編輯規格，程式碼完全由規格自動生成 | 唯一的維護對象 |
規格驅動開發如何減少 AI 寫程式的反覆修改？
為什麼有了規格，AI 就能減少反覆修改？來看一個對比。
沒有規格時（Vibe Coding）：
你：「幫我做一個員工出勤打卡功能。」
AI 生成了一個基本的打卡按鈕和時間紀錄。但你的系統其實需要區分上班打卡和下班打卡、遲到要自動標記，而且跨日夜班的打卡時間計算邏輯完全不同。
於是你開始一輪又一輪的修改對話，每次 AI 都只改了你提到的部分，又在別的地方造成新問題。
有規格時（SDD）：
先在spec.md中定義：打卡分為上班／下班兩種類型、上班時間超過 09:00 標記為遲到、夜班跨日以班表起始日為基準計算、每人每日限打卡兩次。
AI 根據這份規格一次生成符合所有條件的實作，因為它不需要猜測任何隱含需求。
這就是 SDD 減少反覆修改的核心概念：
- 減少 AI 的「腦補」空間：規格把模糊的自然語言轉換成結構化的需求描述，AI 不再需要自行填補資訊空白
- Token 效率提升：當指令精確時，AI 不需要反覆試錯，Token 用量會明顯下降
- 開發流程標準化：SDD 將開發拆分為「定義、規劃、分解任務、實作」四個階段，每個階段都有明確的檢查點，錯誤能在早期被攔截，而不是累積到最後才爆發
二、SpecKit 用規格引導 AI，但這樣就夠了嗎？
SDD 的概念聽起來合理，但實際用起來呢？
目前最具代表性的 SDD 工具是 GitHub 開源的 SpecKit。它把上述的 SDD 理念落地成一套具體的工作流程。
水球我先講結論：在工具層面，它能夠高效地協助你拆解與管理規格、提出技術方案並產出任務清單，AI 再按清單逐項實作。因此在開發者社群中引起不少討論。讓我們快速看看它做到了什麼，又留下了什麼無解的問題。
SpecKit 的四階段流程解決了什麼？
SpecKit 將 AI 輔助開發標準化為四個階段，每個階段都必須經過開發者驗證才能進入下一步：
| 階段 | 做什麼 | 產出 |
|---|---|---|
| Specify（定義） | 用自然語言描述需求與成功定義 | spec.md |
| Plan（規劃） | AI 根據規格提出技術方案與架構設計 | plan.md |
| Tasks（分解任務） | 拆解為 15–30 分鐘可完成的小任務 | 任務清單 |
| Implement（實作） | AI 按任務清單逐項完成程式碼 | 功能模組 |
這套流程的價值在於：它強迫開發者在寫程式之前先想清楚需求，也讓 AI 在明確的框架內工作，而不是自由發揮。對全新專案（Greenfield）和為既有系統新增功能的場景來說，這確實比 Vibe Coding 有效率得多。
SpecKit 在實戰中遇到的三個瓶頸
不過，當開發者真正把 SpecKit 用在實際專案中，幾個問題很快浮現。
瓶頸一：審閱疲勞，文件比程式碼還難讀
SpecKit 在每個階段都會生成 Markdown 文件。一個中型功能（約 3–5 個使用者故事）下來，產出的 .md 檔案數量多到讓人覺得負擔很大。
這些文件彼此重複、與程式碼內容重疊，而且後續只能靠 Ctrl+F 來查找——維護成本反而比直接審閱程式碼更高。 換句話說，原本是為了提升品質才導入的文件流程，結果反而讓效率越改越糟。
瓶頸二：規格寫了，不代表 AI 會照做
即使有了詳盡的規格，AI 仍然會忽略指令或過度執行規則。
在實測中，Agent 有時會無視現有類別的描述而重新生成重複的程式碼，有時則漏掉需要一併更新的既有函式。SDD 工具確實能把開發的精準度拉高一大截，但剩下的那一部分仍然需要開發者手動介入，而那往往是最棘手的，因為會花費更多時間修改。
瓶頸三：規格寫出來了，但沒人驗證「寫對了沒」
這是最根本的問題。
SpecKit 擅長的是「把規格寫出來」和「按規格切分任務」，但它缺少一個關鍵環節：自動化驗證規格本身是否正確。
規格文件是靜態的 Markdown，它無法自己告訴你「這條需求描述是否真的涵蓋了所有業務場景」。當規格本身有遺漏或偏差時，後面再精確的流程也只是在把錯誤的東西做得更快。
這就引出了一個更根本的問題：重點不是把規格寫出來，而是怎麼確認 AI 做出來的到底對不對。 如果規格本身沒有被驗證的機制，那我們只是把「猜測」換了一個更正式的格式而已。
要解決這個問題，需要一套完全不同的思維。
三、寫規格其實是假議題？真正重要的是「做對的規格」
目前為止，我們與 AI 協作開發的路上，經歷了以下路徑：
- AI 確實為軟體工程突破效率瓶頸，但我們累積的是未來高昂的維護成本。
- 規格驅動開發（SDD） 強調：「先把規格寫清楚，再交給 AI 開發」。
- SpecKit 把 SDD 工具化了，但碰到了瓶頸；那就是：「寫清楚規格」和「寫對的規格」是兩件不同的事。
你可以把每個 API endpoint 的參數、回傳格式、錯誤處理都鉅細靡遺地寫出來，讓規格看起來非常「清楚」。但如果使用者真正需要的行為和你定義的功能有落差呢？
這就是為什麼水球我認為，我們需要回到一個已經被驗證超過十年的方法論：行為驅動開發（Behavior-Driven Development, BDD）。
行為驅動開發最早由 Dan North 提出，它是測試驅動開發（Test-Driven Development, TDD）的延伸，但有一個根本性的轉向：從「程式碼要通過什麼測試」，轉向「系統應該展現什麼行為」。
BDD 的三個核心主張
一、從使用者行為出發定義需求，而非從技術架構出發
用一種叫做 Gherkin 的領域特定語言（Domain-Specific Language, DSL），讓團隊的技術與非技術角色，都能聚焦在產品應該發生的效果，而不是技術細節。
二、用實例化需求（Specification by Example, SBE）強調協作與範例
BDD 的核心流程不是一個人關起門來寫規格，而是開發者、測試人員、產品經理一起用具體範例來探索需求的邊界。
三、可執行規格（Executable Specification）：規格就是測試
這是 BDD 和 SDD 最關鍵的區別。 當 AI 生成的程式碼不符合行為定義時，測試會立刻失敗；規格自己會告訴你「這段程式碼不對」。
AI 在這個流程中的角色，將會從一個寫 code 的角色，轉變為從需求探索就開始參與、貫穿整個開發流程，實踐「用 AI 幫你找到對的規格，再用規格保護 AI 產出的程式碼」。
但是，讓 AI 輔助的 BDD 具體實作到底長什麼樣？用什麼工具？怎麼運行的？一個真實的開發場景從頭到尾該怎麼走？
這些問題的答案，我們放在系列文的下一篇。如果你已經感受到「寫對規格」比「寫清楚規格」更重要，那下一篇將帶你看到：當 BDD 遇上 AI，開發效率的天花板會被推到什麼程度。
