用行為驅動開發（Behavior-Driven Development, BDD）方法論解決 AI 時代軟體開發三大痛點（下）
上篇我們聊到，GitHub 推出的 SpecKit 在規格驅動開發的工具層面做了不少事；但我想問一個問題：工具再好，如果你寫出來的規格本身就是模糊的，那工具能幫你什麼？
這就像你買了一台頂級的 GPS 導航系統，但你輸入的目的地是「那個好吃的店」。GPS 再強，也沒辦法帶你到對的地方啊。
SpecKit 解決的是「流程自動化」的問題，但它沒有回答一個更根本的問題：你的規格，到底夠不夠精確？ 而這，正是行為驅動開發（BDD）方法論真正在處理的事情。
接下來這篇，水球我要用一個「請假審批系統」的案例，帶你看看 AI 時代軟體開發的三大痛點，以及 BDD 如何從根本上解決它們。
還沒看上篇？ 規格驅動開發（SDD）不夠用？從 SpecKit 的三個瓶頸談 BDD（上）
目錄
- AI 結合 BDD：做對的規格，並提升開發速度
- 痛點一：AI 開發的程式碼不便修改及迭代
- 痛點二：業務和開發共識不同造成開發重工
- 痛點三：Legacy code 維護不便
- 如何透過 AI x BDD 探索整套流程並加速
- 導入企業跨團隊的最佳解方
- 《AI x BDD：規格驅動全自動開發術》課程四大特色
一、AI 結合 BDD：做對的規格，並提升開發速度
理解了 BDD 的核心之後，一個自然的問題是：BDD 很好，但它和 AI 有什麼關係？
答案是：AI 不只是能和 BDD 結合，AI 正在解決 BDD 過去最大的痛點。
傳統 BDD 最被詬病的地方有兩個，而 AI 恰好能在這兩個痛點上提供巨大的加速：
- 行為邊界的探索極度依賴人力。 邊際案例常常是「想到才有」，想不到就漏掉。
- 從 Gherkin 到可執行測試之間的膠水程式碼（glue code），將自然語言映射到程式碼；這個過程既繁瑣又容易出錯。
以下我們將用三個開發流程的常見痛點，舉例說明 BDD 會如何改變開發體驗。
二、痛點一：AI 開發的程式碼不便修改及迭代
先講一個場景。你用 AI 生出了一個請假系統，基本的特休申請功能跑起來了，PM 很開心。
隔天 PM 跑來說：「我們追加病假功能，而且病假連續超過 3 天要附醫生證明。」
你打開 AI 產出的程式碼，發現假別的邏輯散落在三、四個檔案裡，特休的判斷和病假的判斷糾纏在一起。你改了病假的邏輯，特休的測試卻莫名其妙壞了。你花了兩個小時 debug，才發現 AI 當初把所有假別的餘額共用了同一個變數。
但你還記得嗎？是你當初只給了 AI 一句「幫我寫一個請假功能」。 在需求不明確的情況下，AI 就自己決定了內部架構。所以當你的需求一變，這個架構就不符期待了。
我們認為，SpecKit 能幫你把需求文件管理得很整齊，但是它沒辦法保證 AI 產出的程式碼在改了之後還能正常運作。它缺少了一個關鍵，而那恰巧是行為驅動開發（BDD）的主打特色——可執行規格。
一套可維護的系統：當規格即測試
行為驅動開發的做法完全不同。你不是寫一份「給人看的需求文件」，你寫的是一份同時給人和機器看的規格，我們稱之為「可執行的測試規格」。
它會被 BDD 框架（如 Cucumber、behave）綁定為測試程式碼，在每次程式碼變更後自動驗證系統行為是否符合預期。
規格不再只是寫給 AI 看的輸入（input），而是保護程式碼的防線（guardrail）。 這代表當 AI 生成的程式碼不符合行為定義時，測試會立刻失敗，不需要等到 QA、上線後使用者回報——規格本身就是那道關鍵防線。
用 Gherkin 語法來寫請假系統的規格，長這樣：
Feature: 特休假申請
身為員工，我想要申請特休假，以便安排個人休假。
Scenario: 餘額充足時成功申請
Given 員工「王小明」的特休餘額為 10 天
When 王小明申請特休 3 天
Then 申請結果為「核准」
And 王小明的特休餘額變為 7 天
Scenario: 餘額不足時拒絕申請
Given 員工「王小明」的特休餘額為 2 天
When 王小明申請特休 3 天
Then 申請結果為「拒絕」
And 系統顯示「特休餘額不足」
And 王小明的特休餘額仍為 2 天
依照這套語法撰寫的規格，不只是一份規格文件。這份 Gherkin 規格可以直接綁定自動化測試，每一個 Scenario 就是一個測試案例。
所以當 PM 追加病假規則的時候，你加上新的 Rule 和 Scenario，讓 AI 去實作。AI 寫完之後，你就可以跑一次全部的測試：
- 特休的 Scenario 仍然是綠燈：你就知道改動並沒有弄壞原本的功能
- 測試紅燈了：你也能馬上知道壞在哪裡
水球我常講一個比喻：這就像先畫靶再射箭。 你先把靶（規格）畫好，AI 射箭（寫程式），射完看有沒有中靶（跑測試）。沒中？讓 AI 再射一次。整個過程你不用自己下場寫程式碼，你只需要確保靶畫得夠精確。
SpecKit 幫你管理靶（規格）的檔案，但 BDD 幫你把靶畫得精準，還幫你的箭裝上自動導航系統。 這是工具和方法論的根本差異。
三、痛點二：業務和開發共識不同造成開發重工（Rework）
第二個常見痛點，是業務和開發對於需求的理解不同，卻在開發後才發現。
當 PM 跟工程師說：「病假超過 3 天要附醫生證明。」工程師聽完就去寫了。結果上線後 PM 來找你：「欸，怎麼請 3 天也要證明？我說的是超過 3 天，3 天本身不用啊！」
一個「超過」就造成了一次重工，這種事在每個團隊每天都在發生。
不是 PM 說不清楚，也不是工程師不認真，而是自然語言本身就充滿歧義。 你用中文寫、用英文寫都一樣，「超過 3 天」到底包不包含 3 天，每個人腦中的定義可能不同。
SpecKit 讓你把需求寫成 Spec 文件再交給 AI，但如果 Spec 裡面寫的還是「病假超過 3 天需附醫生證明」這種自然語言，歧義依然存在。AI 也會腦補，就跟人類一樣。
實例化需求（Specification by Example, SBE）：跨團隊協作直接對應需求
BDD 的核心流程，是由團隊不同角色，一起共同以具體範例來探索需求的邊界。
對於需求釐清、降低語言誤會的解法是：不要用抽象描述，改用具體的例子來定義規格。這個做法叫做實例化需求（Specification by Example, SBE）。
在滿足實例化需求的前提下，必須遵守原子化原則，亦即：每個 Rule 只描述一個具體規則，不合併多個驗證邏輯。
回到病假的例子，BDD 不會寫「超過 3 天要證明」，而是這樣寫：
Rule: 病假連續超過 3 天需附醫生證明
Scenario: 病假 3 天以內免證明
Given 員工「李小華」的病假餘額為 30 天
When 李小華申請病假 3 天且未附醫生證明
Then 申請結果為「核准」
Scenario: 病假超過 3 天未附證明被拒絕
Given 員工「李小華」的病假餘額為 30 天
When 李小華申請病假 5 天且未附醫生證明
Then 申請結果為「拒絕」
And 系統顯示「病假超過 3 天需附醫生證明」
看到了嗎？「3 天免證明」和「5 天未附證明被拒絕」，兩個具體的例子直接把邊界定義清楚了，並且符合需求原子化的原則。
PM 一看就知道：3 天不用證明，超過 3 天才要。工程師不用猜，AI 也不用腦補。
以上的 Gherkin 語法案例，就是 PM、QA、工程師三方的共同語言：
- PM 看得懂，因為它就是中文加上簡單的 Given / When / Then 結構
- QA 看得懂，因為每個 Scenario 就是一個測試案例
- 工程師看得懂，因為它可以直接對應到程式碼
三個角色看同一份文件，對齊同一個理解。認知對齊之後再動工，重工再也不是問題。
四、痛點三：Legacy code 維護不便
你半年前寫的請假系統，現在要加一個新功能：超過 5 天的假需要主管審批。
你打開程式碼，看到一堆 if-else，變數名稱當初隨便取的，註解早就跟實際邏輯對不上了。你不確定改了這裡會不會影響那裡，只好戰戰兢兢地改，改完之後心裡發毛，電腦旁邊放一堆綠色乖乖——因為你實在不知道會改壞哪裡。
Legacy code 的痛，是因為你已經不知道這段程式碼當初到底要做什麼。
文件？早就過時無人維護。註解？也早已跟程式碼脫節了。你唯一能信任的，只有程式碼本身——但程式碼告訴你的是「我在做什麼」，不是「我為什麼這樣做」，所以你很難延伸去思考如何維護產品的品質。
活文件（Living Documentation）：當規格即文件
上述所寫到的，用 Gherkin 語法寫成的 Feature File，它的特性是它生來就是一份活文件（Living Documentation）。
為什麼說「活」？因為這份文件同時是測試。如果文件的內容和程式碼的行為不一致，測試就會失敗。
換句話說，Feature File 永遠會是「最新的」，因為它不是人手動維護的文件，而是每次部署都會被執行驗證的規格。只要它出錯，你立刻會知道。
回到請假系統，半年後你要加主管審批功能。你不用去翻程式碼，只要先打開 Feature File：
Rule: 特休假餘額檢查
（兩個 Scenario：餘額充足核准、餘額不足拒絕）
Rule: 不同假別有獨立額度
（Scenario Outline：特休、病假各自獨立計算）
Rule: 病假連續超過 3 天需附醫生證明
（三個 Scenario：3 天免證明、超過 3 天未附被拒、附了就核准）
光看這些 Rule 的標題，你就知道這個系統現在有哪些業務規則。
要加主管審批？新增一個 Rule，寫幾個 Scenario，讓 AI 去實作，跑測試確認沒壞掉原本的邏輯，完工。
這就是 BDD 最厲害的地方：你的規格、你的測試、你的文件，三者合一。 不會有「文件沒更新」的問題，因為文件就是測試，測試沒過就代表文件是錯的。
五、如何透過 AI x BDD 探索整套流程並加速
講完痛點和解法，接下來分享在 AI 時代下，怎麼實際操作 BDD。
在《AI x BDD：規格驅動全自動開發術》課程的實踐中，我們將完整流程分成三個階段：Discovery（探索）、Formulation（規格化）、Automation（自動化）。BDD 的每個階段，都用 AI 來加速。
第一步：Discovery（探索），讓 AI 幫你挖掘需求邊界
拿到一則使用者故事後，立刻就可以與 AI 共同探索。
AI 能夠從你收到的這個使用者情境探討：餘額剛好等於申請天數怎麼辦？同時申請兩種假別呢？假期跨月怎麼算？ 透過系統化地推演出大量的邊際案例，讓你跟團隊有足夠的討論素材。
搭配我們課程中所分享的工作流與工具，你會更順暢地與 AI 和跨團隊成員進行規格邊界的探索。往往在這個階段就會發現，許多語言的歧異與認知誤解，進而能在實作前，就促成團隊達成對產品的共同想像。
第二步：Formulation（規格化），把規則寫成 Gherkin
討論完之後，就讓 AI 來產出初版 Gherkin，你做的事情是「審查」：確認每個 Scenario 的邊界是否正確、有沒有遺漏的情境。
這個審查的過程，就是在幫 AI 畫靶，也確保你仍對產品的邊界有足夠的認知。
第三步：Automation（自動化），AI 根據規格自動產出程式碼
規格確認之後，把 Feature File 交給 AI，讓它產出對應的測試程式碼和實作程式碼。
跑測試，全綠燈就收工。紅燈？把失敗的 Scenario 丟回給 AI，讓它修。
整個過程中，你做的事情是：定義規格、審查規格、確認測試結果。 你不需要自己寫程式碼，但你完全掌控系統的行為。
六、導入企業跨團隊的最佳解方
所以 AI x BDD 不只是工程師的工具，它天生就是一個跨角色協作的框架，也是水球我認為在 AI 時代，最適合團隊導入的方法論。
因為 Gherkin 的語法設計初衷，就是讓非技術人員也能讀懂。PM 寫使用者故事，工程師和 PM 一起把使用者故事轉成 Gherkin Scenario，QA 審查 Scenario 的完整性。三個角色圍繞同一份 Feature File 工作，不需要再經過「需求文件、技術規格、測試案例」的三層翻譯。
中間每多一層翻譯，就多一次資訊流失的風險。 BDD 把翻譯的次數降到零，讓 Feature File 本身就是需求文件、技術規格、測試案例三合一。
對企業來說，這意味著：開發重工減少、跨部門溝通成本降低、交付品質提升。
如果你正在評估把這套方法導進整個團隊，我們有專門的企業方案：
七、《AI x BDD：規格驅動全自動開發術》課程四大特色
- 【強調軟工方法論+結果導向】
- 我們認為談 AI coding 不談軟工方法論，是不學無術
- 破除無謂期待：期待 AI 能理解你的自然語言，我們稱作燒紙錢拜拜的祈禱式開發
- 人類累積了幾十年的軟工方法，你不站在巨人的肩膀上，那你當然效率低落
- 強調結果導向的開發方法：只要訂好驗收標準，就可以 One-Shot 開發到位！
- 【強調最完整的 SDD 概念與實作】
- 目前市面上最完整的 SDD 課程，一次教你 Skills, SDD, TDD, BDD 的知識與實踐，讓你輕鬆實踐高效可靠全自動開發
- 解決東學西學不知如何整合的困境
- 【強調企業級實戰】
- 企業級實踐與導入，讓你不只學會工具，更知道如何舉一反三完全客製化企業專案需求
- 上完課程，你會非常清楚對 SDD 的每一個步驟的標準，並且可以有辦法客製化控管流程
- 成為高手的企業級 SDD 實戰，軟工知識、系統分析基礎知識、務實的軟工實踐直接拆解給你看
- 【強調課程教學方式與物超所值】這是一堂理論、實務跟實戰三者兼具的線上課程，帶給學員工作坊級別的學習體驗，而且不是只是教概念，不是教你怎麼用，而是直接帶你做。已有 1000+ 名以上學員加入。
- 包含五大章節、60 個單元，超過 20 小時影音課程
- 線上手把手跟練系統：就像在上 workshop 一樣，我們提供課程即時跟練的平台，老師講到哪，你就跟著做到哪，這是我們在企業內訓、實體工作坊收斂出最有效果的教學方式。
- 實戰演練道館：每個章節最後，都會有實戰練習，我們稱之為「道館」。你將在道館題目中，實際透過有挑戰性的題目，驗收自己的學習成果；繳交自己的作業後，都能獲得我們的參考詳解，去比對你自己的思考過程。
- 開放 MCP：課程內容直接開放 MCP endpoint，你只要讓你的 AI 接上這個 tool，基本上算是你的 AI 也跟著你了解這門課，你就可以與 AI 即時討論交流，也可以更直接地實作、整合到自己的專案之中。
- 課程Repo 全面開放：這絕對是最超值的部分，團隊花了一整年研發的實作流程，成功導入企業的版本。跟著課程，你也能將這套流程客製化成最實際可使用的版本。
- 高能量學員社群：有問題即時討論，老師與其他學員都會在群組中互相交流。
