AI x BDD：規格驅動全自動化開發術

BDD 是什麼？行為驅動開發完整介紹，為什麼 AI 出來後 BDD

水球潘 · 2026-09-16 · 37 分鐘閱讀

BDD（Behavior-Driven Development，行為驅動開發）是已經至今發展已有 20 年的軟體開發流程，甚至可以說是一個方法論。

但水球我認為，BDD 的時代已經來臨了。

BDD 解決了軟體工程一直以來遇到的「溝通問題」，這個溝通問題在軟體企業層出不窮，不管是 PM 對 RD、業務對 PM 還是 QA 對 RD，總之，只要有不同職能合作就會有一堆軟體開發的需求通靈 or 上線後返工的流程問題～。

最後搞得技術人員礙於需求不清楚、礙於不知道「要測什麼」，而導致最後很難「一次到位」地交付業務端或是 PM 端想要的軟體程式碼。

這個方法論已經存在 20 幾年了，

為什麼？分享一個在軟體企業中你八成也遇過的場景。

功能寫完了，測試也過了，上線。然後 PM 跑來說：「欸，這不是我要的。」

你把需求 Ticket 翻出來，白紙黑字，你做的跟他寫的一模一樣。但他要的確實不是這個。於是整包重做，兩個禮拜的工就這樣進了水裡。

以前這種事叫做「需求誤解」，發生在業務、PM、QA 跟 RD 之間；而現在呢？

「現在是所有人都在跟 AI 溝通，然後換成是 AI 誤解你提出的需求！」

你講一段話，就期望 AI 能幫你產出一整包程式碼，這怎麼可能？？

AI 大多數時候只是依照常識猜對了大方向，但 AI 很常在你沒講清楚的地方自己腦補了答案，上線之後才被 PM 抱怨說這不是他要的。

換個位置總是會換個腦袋，以前是 RD 希望 PM 把需求講清楚，現在 RD 自己也要開需求給 AI 了，結果自己也是需求講得不清不楚的。

「同樣的問題，只是換了不同的對象而已！」

可是 RD 和 PM 也都是相當無奈，現在變成 RD 夾在 PM 和 AI 中間，到底需求是 PM 寫還是 RD 寫？如果由 RD 寫的話，那我要 PM 幹嘛？如果由 PM 寫的話，那 PM 又會問你，他直接下給 AI 做 Vibe Coding 不就好了嗎？

現在哪一間有 PM、RD 的企業沒有這種問題？

這件事本質上就是全部人類的通病啦！沒有方法論的話，那 AI 開發的產能怎麼可能會起得來！

這代表，AI 來臨後，軟體企業迫切需要一個成熟的開發方法，而這個「注重上下游分工」的開發方法早就在二十年前就被提出來了，就是 BDD。

你如果沒有學過 BDD，你就幾乎不知道軟體企業要怎麼「轉型」。很多人總是在吹牛說現在 AI 產能可以是幾百倍，但問題是這些都是 Side Project 的產能，或是那些獨立專案、Individual Contributor 專案的產能，而不是企業核心專案的產能啊！

瓶頸是「需求上游怎麼被定義」，組織連需求怎麼定義都不知道，那 AI 的產能對組織來說意義有限，大多是無意義產出。

而 BDD 這個 20 幾年前就存在的方法論，剛好回答了這件事：當所有人都在跟 AI 溝通，你要怎麼確定 AI 寫出來的東西，就是你要的那個東西？

一、BDD 是什麼？行為驅動開發的一句話定義

BDD 一開始首次被整理在一本叫做「BDD in Action」的書。裡面內容很多，從各職能的軟體開發協作流程，一路講到「規格怎麼寫」再講到「自動化測試」。

但白話來說他是什麼？

BDD 就是完全專注於「系統行為怎麼被定義 or 測試」的方法。

這也是為什麼他被稱之為「行為」驅動開發。

他要求：不管是業務上游、PM 還是 QA 在與 RD 溝通時，都一定要著重在「系統行為到底要怎麼被定義 / 被測試」之上。並且圍繞在此來寫規格，寫出來的規格就被稱之為「可執行規格」，因為這些規格是圍繞在「可以自動化測試的系統行為」之上。那這樣的規格，你確實是可以是去執行它的。

就這麼簡單！

只要你能夠找到「系統行為」的定義方法，就能把這當成是「施力點」，一次槓桿整個開發的精準度。

因此，只要你學會 BDD 怎麼定義「系統行為的驗收標準」，然後再去學「怎麼做自動化測試」，你基本上就學完 BDD 了！

施力點 = 系統行為

BDD 是水球軟體學院認為，目前規格驅動開發（Spec-Driven Development, SDD）中最成熟、最可靠的一種實踐。

它跟其他的驅動開發方法一樣，都是在尋找軟體開發的一個施力點，或者你可以說是軟體開發的一些流程；這個流程可以去驅動出，讓你的軟體開發的成效比平常更可靠。

這裡先把「施力點」這個詞立起來，因為它會貫穿整篇文章。你可以把它想成撬動一塊大石頭的那根槓桿：石頭很重，但只要施力點選對了，一個人就推得動。軟體開發「效率、可靠度」也是一塊大石頭，而每一種「驅動型」的方法論，都是在爭論那根槓桿該撐在哪裡。

不管是測試驅動開發、領域驅動設計，還是行為驅動開發，這種驅動型的方法所做的就是一件事情：找到對的施力點，用力投資下去，然後確保軟體最終產出是可靠的。

那行為驅動開發，它找到的施力點，就是「行為」這兩個字。（指的是系統行為，不是使用者的行為）

BDD 的全名與中文譯名


英文全名	Behavior-Driven Development
常見縮寫	BDD
中文譯名	行為驅動開發
提出者	Dan North

BDD 最早由 Dan North 提出，它是測試驅動開發（Test-Driven Development, TDD）的延伸，但有一個根本性的轉向：從「程式碼要通過什麼測試」，轉向「系統應該驗收什麼業務行為」。

再講完整一點：BDD 把關兩個東西

到底要怎麼用系統的行為來驅動開發？做法很簡單，就是把關兩個東西，這兩個把關好了就構成 BDD。

第一個，PM、QA 要制定好「要驗收的業務行為」是什麼。

你開發軟體一定是要配合業務，所以在軟體開發之前你就得先驗收好：說到底，我們期望的業務流程、業務行為是什麼。所以 PM 先制定好業務的行為。

第二個，工程師負責把業務的行為，精準翻譯成系統的行為，也就是要驗收的系統行為。

BDD 雖然它是一本書，裡面很多很多很多內容，但你深入淺出來看的話，其實就是一句話：

把業務行為翻譯成要驗收的系統行為，然後再用這個要驗收的一組系統行為，來去驅動、開發出你的程式。

好，快教我，怎麼定義系統行為：用「可執行規格 Gherkin」

假設你要做一個會議室預約系統，需求是：「員工可以預約指定會議室的指定時段；如果該時段已被預約，預約失敗。」

上面這句話是業務行為，把它翻譯成要驗收的系統行為之後，長這樣：

Feature: 會議室預約

  Rule: 同一會議室不可時間重疊
  
    Scenario: 無衝突時預約成功
      Given 會議室沒有人預約
      When 員工 "陳小美" 預約 "A101" 在 "3/20" "10:00-11:00"
      Then 預約結果為 "成功"
    
    Scenario: 完全相同時段預約失敗
      Given 員工 "王小明" 已預約會議室 "A101" 在 "3/20" "10:00-11:00"
      When 員工 "陳小美" 預約 "A101" 在 "3/20" "10:00-11:00"
      Then 預約結果為 "失敗"
      And 系統顯示該時段已被預約

關鍵在於：這不只是一份規格文件。 這份 Gherkin 規格可以直接綁定自動化測試，每一個 Scenario 就是一份可執行的測試案例。

沒有一行提到前端還是後端、用什麼框架、資料庫在哪裡，它只描述業務期望的行為，同時也是可以跑起來的東西；這就是「可執行規格」的意思。

二、BDD 和 TDD、DDD 差在哪？

這三個縮寫長得很像，但回到剛剛那根槓桿：它們的施力點撐在不同的地方。

TDD（Test-Driven Development，測試驅動開發）：先寫測試

TDD 的施力點是測試：先寫測試，再寫實作，讓測試逼出設計。

它的測試情境有一個經典思維結構，叫 3A：

步驟	做什麼
Arrange	準備好前置狀態
Act	執行受測的動作
Assert	驗證結果對不對

在 TDD 中，我們會透過 3A 來先制定好到底要測試什麼，先畫靶之後才射箭。

其中，3A 的每一個片段都是一段技術導向的測試程式碼，長得像這樣：

# 例如，我們要測試「建立一筆訂單」
def test_create_order():
    # Arrange：測試之前 -> 準備資料
    product_repository.save(Product(id=1, price=100))
    request = {"product_id": 1, "quantity": 2}

    # Act：測試執行 -> 呼叫 API
    response = client.post("/orders", json=request)

    # Assert：測試驗證 -> 查詢並驗證結果
    order = order_repository.find_by_id(response.json()["id"])

    assert response.status_code == 201
    assert order.total_price == 200

在沒有 BDD 的時候，有在實踐 Test-First 的工程師，大致上都會寫出這樣工工整整的測試程式碼。把測試寫好，對後端功能的正確性就至少能做一定程度的自動化驗證。那前端當然也做得到。

BDD（Behavior-Driven Development，行為驅動開發）：把測試需求寫成人看得懂的規格

BDD 是 TDD 的延伸。這裡是最容易搞混的地方，所以水球我直接把兩邊擺在一起給你看。

同一個「買家建立訂單」的測試情境，兩種寫法：

Gherkin（BDD）	3A（TDD）
Given 買家的購物車裡有商品	Arrange 建立商品 / Alice 的購物車資料
When 買家提交訂單	Act Alice 呼叫訂單 API endpoint
Then 訂單成立並套用優惠	Assert 驗證回應與資料庫狀態

Given, When, Then 對應 3A 的 Arrange, Act, Assert，語義幾乎可以說是 99% 一樣。

那差在哪裡？差在左右兩邊的「技術含量/資訊量」不一樣多！

左邊的 When 是「買家提交訂單」，PM 絕對看得懂。右邊的 Act 是「Alice 打 API」，測試必須指定清楚受測的 API endpoint 跟資料集，從測試來看就能推敲：這百分之百一定是在測後端，連資料的 Schema 都清清楚楚才能做好測試。

所以：

TDD 中的 "Test" 是寫給工程師看的，它從第一行就綁死了技術實作
BDD 中的 "Gherkin" 是寫給非技術背景的人看的，它到最後一行都還沒提到技術

這就是 BDD 多出來的那一層價值：業務人員在制定的時候，可以儘可能地去除模糊空間，因為它是透過舉例說明的方式來去定義。而 PM 寫完之後，那份東西不只是規格，它很容易被翻譯成自動化測試。

DDD（Domain-Driven Design，領域驅動設計）：施力點在領域模型

DDD 的施力點是領域模型。它跟前兩者處理的不是同一層問題：TDD 與 BDD 問的是「怎麼驗收」，DDD 問的是「這個業務領域本身該怎麼被理解與切分」，然後建構成好懂的知識模型，全團隊共享知識。

我們不特別介紹 DDD，它自成一個主題，而這篇是 BDD 的定義文。這裡只做一件事：把它跟 BDD、TDD 放在同一把尺上，讓你知道它們不是在互相取代。

三者的關係

	施力點	主要讀者	產出物
TDD 測試驅動開發	測試	工程師	自動化測試
BDD 行為驅動開發	系統的行為	業務＋工程師	可執行規格（同時是自動化測試）
DDD 領域驅動設計	領域模型	工程師＋領域專家	對領域的共同理解（通常會寫成領域模型文件）

它們不是互斥的。三個都是「驅動型」的方法，思想類似：透過明確的施力點作為 Single Source of Truth，讓你的軟體最後產出是可靠且可驗證的。差別只在那根槓桿撐在哪裡。

三、BDD 的核心：Given-When-Then 與 Gherkin

Gherkin 是什麼

Gherkin 是撰寫可執行規格用的一種特定語言。

BDD 一開始，他們整理了一些語言，用來描述業務的行為。因為你如果定義好業務的行為，但它必須要落地到程式碼的話，那你就必須要注意：如何把它翻譯成自動化的測試程式。

在那些語言裡，最主流的一個就叫 Gherkin。它專門用來描述「驗收業務行為的驗收標準」，而它的做法是透過舉例說明：

我的每一個功能，它的業務期望行為大概有哪些標準？ 我們的標準，是由很多例子來組成的。

Gherkin 是為了讓團隊的技術與非技術角色，都能聚焦在產品的 Outcome，而不是技術的 Outputs。

用 Gherkin 寫出來的檔案叫 Feature File（.feature），Feature File 指的就是 Gherkin 的檔案格式。

Given-When-Then 的寫法

Gherkin 用三個關鍵字描述一個情境（Scenario）：

關鍵字	描述什麼	對應 3A
Given	前置條件、系統當下的狀態	Arrange
When	觸發的那個行為	Act
Then	期望的結果	Assert

一個 Feature File 裡會有很多個 Scenario，而 Gherkin 裡的每個 Scenario，就構成了你整體的測試計劃。

如果你熟悉敏捷開發，這裡有一個對照可以幫你定位：一個 Feature 的規模大小，大致對應一則使用者故事，而底下的每個 Scenario，就是那則使用者故事的驗收條件。。 差別在於，傳統的驗收條件寫在票上、寫完就沒有下文；Gherkin 的驗收條件寫完之後會被綁成驗收測試，跑不過就是紅的。

實例化需求（Specification by Example, SBE）：用例子定義邊界

這是 BDD 最容易被跳過、卻最關鍵的一個實踐。

先看一個真實會發生的狀況。PM 跟工程師說：「同一間會議室，時間不能重疊。」工程師聽完就去寫了。結果上線後 PM 來找你：「欸，王小明訂了 10:00-11:00，陳小美要訂 11:00-12:00 怎麼會被擋？一場 11 點結束、一場 11 點開始，這不算重疊啊！」

一個「重疊」就造成了一次重工。不是 PM 說不清楚，也不是工程師不認真，而是自然語言本身就充滿歧義。你用中文寫、用英文寫都一樣，「時間重疊」到底包不包含首尾剛好相接，每個人腦中的定義可能不同。AI 也會腦補，就跟人類一樣。

BDD 的解法是：不要用抽象描述，改用具體的例子來定義規格。這個做法叫做實例化需求（Specification by Example, SBE）。

而它有一個必須遵守的原子化原則：每個 Rule 只描述一個具體規則，不合併多個驗證邏輯。

回到會議室的例子，BDD 不會只寫「時間不能重疊」，而是這樣寫：

Rule: 同一會議室不可時間重疊

  Scenario: 部分重疊預約失敗
    Given 員工 "王小明" 已預約會議室 "A101" 在 "3/20" "10:00-11:00"
    When 員工 "陳小美" 預約 "A101" 在 "3/20" "10:30-11:30"
    Then 預約結果為 "失敗"
    And 系統顯示 "該時段已被預約"

  Scenario: 首尾相接不算重疊
    Given 員工 "王小明" 已預約會議室 "A101" 在 "3/20" "10:00-11:00"
    When 員工 "陳小美" 預約 "A101" 在 "3/20" "11:00-12:00"
    Then 預約結果為 "成功"

看到了嗎？「10:30 開始被拒絕」和「11:00 開始預約成功」，兩個具體的例子直接把邊界定義清楚了。PM 一看就知道：時段有交疊才算重疊，首尾剛好相接不算。工程師不用猜，AI 也不用腦補。

這份 Gherkin 就是 PM、QA、工程師三方的共同語言。PM 看得懂，因為它就是中文加上簡單的 Given / When / Then 結構；QA 看得懂，因為每個 Scenario 就是一個測試案例；工程師看得懂，因為它可以直接對應到程式碼。三個角色看同一份文件，對齊同一個理解。

前後端開發：PM 和 RD 怎麼用 AI x BDD 全端協作？

而有些工程師可能就會想問，那如果是做 Full-Stack 開發的話該怎麼寫 Gherkin？

做法很簡單，那就是我們會先請 PM 用 Gherkin 寫一個「通用」的業務流程，作為總驗收標準（可以視為是該 Sprint 的 Acceptance Critieria)。然後再靠 AI 將其拆解成前端的 Feature File 跟後端的 Feature File。

由於前後端的自動化測試是分別執行的、是隔離開來的，因此要維護兩組 Feature Files。

如此一來，只要拆解到位，那前後端都能夠有強勁的 AI 開發施力點，而且都不必再通靈 PM 要的需求到底是什麼。

翻譯到位，Gherkin 對了測試就對、程式碼的正確率就會超高度提升，更容易 one-shot！

也因為前後端的測試語義不一樣：前端測試的是「使用者流程 (User Flow)」、後端測試的是資料邏輯和複雜業務邏輯驗證，因此整個 Gherkin 就會拆成前後端兩份。不要想用同一份 Gherkin 涵蓋兩邊不同技術端點。

前端的 Gherkin 可能長這樣，著重在使用者流程：

Feature: 不合格退回前站

  Rule: 不合格送出後畫面回退回薄板沖壓

    Example: 平面度 0.52 退回薄板沖壓
      Given 工單 "MO-FR-27-005" 已完成第 1 次薄板沖壓
      And "李檢驗" 已在「沖壓品檢站」按「開始」
      And "李檢驗" 已打開已綁定「沖壓品檢站」的工位終端
      When "李檢驗" 按「不合格」並送出以下欄位：
        | 欄位        | 值                    |
        | 抽檢數      | 200                   |
        | 平面度 (mm) | 0.52                  |
        | 判定        | 不合格                |
        | 不良代碼    | DEF-FLAT（平面度超標） |
        | 合格數      | 0                     |
        | 重工數      | 10000                 |
        | 報廢數      | 0                     |
        | 退回工序    | 薄板沖壓              |
      Then 系統回覆 "判定不合格。工單不能結束。請退回「薄板沖壓」重做。焊接尚未開始。"

後端的 Gherkin 可能長這樣，著重在資料和複雜業務邏輯驗證：

Feature: 部分不合格分流與結案

  Background:
    Given 產線 A 已有以下製程定義：
      | 順序 | 工序     | 站點       | 類型 |
      | 1    | 薄板沖壓 | 沖壓線     | 生產 |
      | 2    | 沖壓品檢 | 沖壓品檢站 | 品檢 |
      | 3    | 雷射焊接 | 雷射焊接站 | 生產 |
      | 4    | 清洗     | 清洗站     | 生產 |
      | 5    | 成品品檢 | 成品品檢站 | 品檢 |
    And 工單 "MO-FR-27-005" 產品為 "FR-27-BZ-A"、計畫數量 10000、狀態為「進行中」

  Rule: 部分不合格後主批可到焊接、重工批回沖壓第 2 次、報廢不再流動

    Example: 合格 9200、重工 500、報廢 300
      Given 工單 "MO-FR-27-005" 本批全部產出 10000 個都已送檢
      And "李檢驗" 已在「沖壓品檢」按「開始」
      When "李檢驗" 送出以下品檢判定：
        | 欄位     | 值               |
        | 判定     | 部分不合格       |
        | 合格數   | 9200             |
        | 重工數   | 500              |
        | 報廢數   | 300              |
        | 不良代碼 | DEF-BURR（毛邊） |
        | 報廢原因 | SCR-UNREPAIRABLE |
        | 退回工序 | 薄板沖壓         |
      Then 工序「沖壓品檢」狀態為「已完成」
      And 主批 9200 個可到「雷射焊接」
      And 重工批 500 個回到「薄板沖壓」重新排隊（第 2 次）
      And 報廢 300 個不再流動

一個完整可執行的實例

Gherkin 寫完之後，它怎麼變成真的會跑的測試？靠兩個東西。

第一個是 BDD 測試框架，例如 Cucumber。

要把 Gherkin 變得「可執行」，那背後肯定要有測試框架支撐，否則 Gherkin 和 Markdown 一樣都只是沒用的計畫。

Gherkin 在主流的技術語言裡面都有 BDD 的框架支援。它會去看懂你的 Gherkin，然後透過掃描去幫你去綁定自動化測試的程式碼。

那如果你用的是 Python 的話，我們推薦使用的 BDD 套件叫做 behave，它們是專門用來把這些 Gherkin 的規格檔案，綁定到測試程式碼裡面的技術。

第二個是 Step Definition，也就是 Glue code（膠水程式碼）。

Glue 就是「把可執行規格黏到自動化測試的膠水」。每一個語言的 BDD 測試框架，都支援在測試函數上透過「標註」把 Feature File 的每一句話，表達式匹配到一個測試函數。

這樣一來的話，當你執行一份 Gherkin，就等同於執行一系列的測試函數，就是因為這樣 Gherkin 才被稱之為「可執行規格」，他可以被當成是「自動化測試」來執行。

所以標準的技術工作流是這樣：

1. 先寫 Feature File（.feature）        # Gherkin，業務語言
2. 再寫 Step Definition                # 把每一句話綁到測試函數
3. 跑 Cucumber / behave                # 框架幫忙綁定 Gherkin 到測試                
4. 測試跑起來                            # 這時候規格才真的「可執行」

所以 RD 只要接收到業務人員寫的那份 Gherkin 規格，請 AI 做完系統規劃之後，AI 去生成每一句話對應的 Step Definition （測試函數），最後透過 BDD 相關測試框架技術，就可以把它綁定到程式碼裡面的自動化測試，這樣就構成了剛剛所謂的「把業務行為翻譯成要驗收的系統行為」，這個技術的部分就直接落地成功了。

BDD 總歸來說，就是讓業務人員的業務規格，跟你的程式碼，可以直接落地成自動化測試的一種開發流程。

活文件（Living Documentation）

這也帶出 Gherkin 的第三個價值：活文件（Living Documentation）。

為什麼說「活」？因為這份文件同時是測試。如果文件的內容和程式碼的行為不一致，測試就會失敗。換句話說，Gherkin 這種 Feature File 只要有 CI 做測試保護，就可以確保它並非過時，它本身就和程式碼有一樣的生命週期，所以非常不容易過時。

所以半年後你要在會議室預約系統加「重複性預約」功能時，你不用去翻程式碼，只要先打開 Feature File，光請 AI 去看那些 Rule 的標題，就知道這個系統現在有哪些業務規則，AI 幾乎不用讀 Code 就知道要怎麼幫你先去改好 Gherkin 規格、改測試。

四、BDD 怎麼實作？三個大環節

BDD 的落地被拆成三個環節，而且要依照 Discovery、Formulation、Automation 的順序，不可跳過、不可重排。

傳統 BDD 最被詬病的地方有兩個，而 AI 恰好能在這兩個痛點上提供巨大的加速：

行為邊界的探索極度依賴人力，邊際案例常常是「拍腦袋在想」，想不到就漏掉
從 Gherkin 到可執行測試之間的 Glue code (Step Definition) 要 RD 自己撰寫，這個過程既繁瑣又容易出錯

上述這兩項就是以前為什麼 BDD 不紅的原因，成員需要大量訓練才能導入。但現在有 AI 之後，每一步都可以靠 Agent Skill 就做得比人還好。

Discovery（探索）：讓 AI 幫你釐清需求

拿到一則使用者故事之後，立刻就可以與 AI 共同探索、需求釐清。

AI 能夠從你收到的這個使用者情境，推演出大量的邊際案例：什麼叫「時間重疊」？完全相同、部分重疊，還是一場整個包住另一場？首尾剛好相接算不算？已取消的預約時段，可以被重新預約嗎？系統化地把這些問出來，讓你跟團隊有足夠的討論素材。

往往在這個階段就會發現，許多語言的歧異與認知誤解，進而能在實作前，就促成團隊達成對產品的共同想像。

這一步不產出程式碼，只記錄每一輪的問答和最新的規格內容，它著重的是人之間或是與 AI 之間，對業務行為的共識，水球這裡要強調：沒有這一步，後面兩步都是在把誤解變成自動化。

那這一步當然也可以使用 Matt Pocock 的 /grill-me skill 來實踐，只是你的下游接的不是 Markdown spec，而是 Gherkin spec。

Formulation（規格化）：把規則寫成 Gherkin

AI 向你靈魂拷問一般，釐清完需求之後，接著就要讓 AI 來產出初版 Gherkin——透過 Gherkin 舉例說明的方式把整個驗收標準定義得清清楚楚。

在撰寫 Gherkin 的過程一樣也會請 AI 進行 Clarify，畢竟舉例說明的過程中，很有可能 AI 又會發現認知漏洞，這時他不該腦補，而是該問你問題。

而你 or PM or QA 做的事情是「審查」，順順地讀過去每一個 Gherkin Scenario 的描述是否正確、有沒有符合業務情境。這個審查的過程，就是在幫 AI 畫靶，也確保你仍對產品的邊界有足夠的認知。

Formulation 有沒有落地，判準很單純：那就是此次開發的重要業務情境是不是都找得到特定的 Gherkin 描述，並且 Gherkin 中遵守「Spec by example」原則，用舉出實際業務資料的方式來定義系統行為的預期。

Automation（自動化）：AI 根據規格自動產出程式碼

規格確認之後，把 Gherkin(Feature File) 交給 AI，請 AI 做系統規劃之後，AI 多少就會知道 Gherkin 裡面的每一句業務語意要怎麼翻譯成適當的測試程式碼，讓它產出對應的測試程式碼和實作程式碼。

這一步水球我的做法是會再請 AI 產一個 dsl.md，dsl.md 裡面會記錄每一句 Gherkin step 要怎麼落地成自動化測試。

那當然這部分就是見仁見智，也是系統分析師的競爭堡壘所在之處。

那只要確保測試寫對，接著你就能夠透過這一排大量精準的測試，讓 AI 做全自動開發—— AI 自己跑測試，有錯自己 Debug、自己修錯、再跑測試，直到全部測試都通過才能就收工。

一但全部測試都通過了，就代表 PM/QA 制定的一系列驗收標準都被自動化驗證通過了。

整個過程中，你做的事情是：定義規格、審查規格、確認測試程式碼語意正確。

PM 和 QA 的重心轉移到「需求端、驗收端」，而 RD 呢？被取代了嗎？當然不是，RD 是很關鍵的系統分析師，他必須確保 PM/QA 定義的驗收標準 (Gherkin) 能夠被精準翻譯成多個不同系統端點的測試計劃和程式碼。

好比說 Gherkin 翻譯成前端＆後端的測試程式碼這一段，過程其實是有含金量的，你要是不懂自動化測試怎麼落地，非技術背景的人是做不來這一段的。

五、BDD 在 AI 開發時代為什麼重要

回到文章一開頭那個場景：「功能上線了，PM 卻說這不是他要的。」

既然現在大家都在跟 AI 溝通，那麼 BDD 就是用來去除腦補的一個非常重要的一個流程。它做的是兩件事：

不管是 PM 還是 RD 還是 QA，你先寫 Gherkin，絕對是會提升可靠度的。 因為它本身就是透過舉例說明的方式來定義，你到底要驗收什麼樣子的業務行為，那些規則都會寫得非常清楚，白紙黑字寫得非常清楚。
如果可以把它精準地翻譯成測試程式碼，那就可以透過這個測試程式碼，來去逼迫 AI 一次到位地開發出我們要的程式。 只要你確定業務行為是對的、確定要驗收的系統行為是對的，那最後開發出來的程式碼就也會是很高可靠度的。

換一個角度說：規格不再只是寫給 AI 看的輸入（input），而是驗證程式碼是否正確的標準。

因此，以前 BDD 是用來溝通、把產業知識變成軟體知識的一個方法；但現在，我們會把 BDD 當成是「組織全員轉型」的跳板。

這個跳板讓組織全員把重點放在「如何驗收」，而不是「AI 如何寫 Code」。

這也是為什麼水球我會相信，BDD 會是目前規格驅動開發中最完整的實踐。

想看完整的論述，也就是 BDD 為什麼會是 Vibe Coding 的典範、它跟 AI 不可控之間的關係，這一篇只講到這裡，完整版在 BDD 為什麼會是 Vibe Coding 的典範。

六、常見問題

BDD 一定要用 Cucumber 嗎？

不一定。 Cucumber 只是最廣為人知的支援 BDD 的技術。

Gherkin 這個文件格式，在主流的技術語言裡面都有對應的 BDD 框架，它們做的事情是一樣的：看懂你的 Feature File，然後幫你綁定自動化測試的程式碼。Python 有 behave，其他語言也各自有自己的實作。

重點不在框架叫什麼名字，在於你有沒有真的把 Gherkin 綁到測試程式碼上。 沒綁，那份 Feature File 就只是一份漂亮的文件，不是可執行規格。

小團隊值得導入 BDD 嗎？導入 BDD 的時機是什麼？

導入 BDD 這件事，確實是有一個投資報酬率的判斷在那邊。

但這裡有一個常見的誤解要先拆掉：

什麼時候會適合導入 BDD？基本上第一個要看的，其實並不是團隊的規模，第一個要看的其實是你產品的階段。

不適合的情況：如果你開發的這個程式碼是屬於一個創新階段，完全還沒有想要投入長期的維護、中長期維護，好比說這個產品可能連上線都還沒有上線，甚至還沒有確定它一定會落地、成為要長期維護的重要組織資產。

那這個時候，確實會增加工程的一些成本，畢竟我們就是要為它去寫相較詳盡的 Gherkin 規格。所以這個時候是不適合導入 BDD 的。

適合的情況：只要你的產品開始，你想要投入維護它了，你開始相信這個程式碼接下來都是有價值的，不管是它拿到第一個訂單、開始有人在使用這個產品、開始有客服，還是怎麼樣。只要進入到這個階段，你就會需要開始提升你整體程式碼的可靠度。

所以判準是產品階段，不是團隊人數。一個三人團隊在維護一個有付費客戶的產品，比一個二十人團隊在做還沒上線的 MVP，更需要 BDD！

寫規格 or BDD 會不會讓開發變慢？這是大家一直都有的盲點

很多人直覺會認為：前期多花時間寫規格，開發一定會被拖慢，甚至覺得規格是很厚重的。

在 AI 出來之前，其實以前這種批評聲浪就已經見怪不怪。

以前要求大家寫自動化測試，跑測試驅動開發時，也是有很多人一直以為寫測試反而是寫雙倍程式，那速度會更慢。

但是啊，實話實說吧，如果你去看這些人 Live Coding，你會發現他們的寫 Code 技巧性其實很差，產能本來就不夠好，這些認為「速度更慢」的人，幾乎都是訓練不到位的人。

這時他們需要的不是一個魔法般的方法，可以讓他們「做更少事，卻有更好的產出」，他們需要的是訓練，讓他們搞懂軟工的抽象，在更短的時間內做更多事。

那現在 SDD, BDD 出來了，你想也知道，一定也會有一堆人批判說「寫一堆規格有夠厚重，這樣只會更慢，不是嗎？」

一樣，你去讓這些人手寫規格給你看，他們一定寫得亂七八糟。

有些事根本不是「好重、好慢，幹嘛要用？」，而是「你根本沒把事情想清楚，追求前面的快速，但也只有前面快而已，你遲早會親手殺死自己的專案，越做越慢。」

這就像是很多新手一開始 AI Coding 時總感覺自己很快很快，但是不用多久就會遇到瓶頸，這就是 AI Coding 的愚昧山丘。

BDD 充其量只是請你「先把驗收標準定義好，再去寫 Code」的方法而已，你從這句話去評論就會知道你幾乎想不到任何拒絕或是反駁他的理由。

當你目標清楚，整個開發量能更專注，且更容易一次到位的時候，到底是會因為「前期定義更多標準」而變慢，還是會因為「把標準定義得更清楚而反而整體加速？」

連個驗收標準都定義不好的組織、主管、團隊，幾乎根本不可能在 AI 的時代下有多卓越的產能。產出不代表可靠，可靠才代表產能。

所以水球我對這些聲浪的批判就是：「不要因為沒有經過訓練，就抨擊一個步驟較多的流程，錯在你能力不足和你習慣不好。」

如果人可以憑自己的「感覺」就 Vibe 來 Vibe 去，那說實在的你的專業價值又何在？很多專業的工作都是因為「反人性而卓越」，那些順著人性就可以做好的工作，哪一個是有價值的？

我對不重視規格的 RD 的批判：以為 Simple is best，但其實是 Lazy

尤其是 RD，往往有更大的盲點，認為 "Simple is best"，所以一直堅持使用比較簡單的流程，好比只用輕量的 skill，但實際上，我會請你思考一件事，這世界上能造福人類的科技，哪一個真的很 Simple 的？

作業系統很 Simple 嗎？半導體很 Simple 嗎？LLM 很 Simple 嗎？

Simple is best 指的往往是 "用更簡單的視角去看待秩序"，能簡化就不要過度複雜，但這壓根兒是有個判準在那邊的。

工程師在面對 SDD/BDD 時，如果對其排斥，通常最大的盲點是：以為步驟較多的流程就更複雜，但卻低估了「開發流程一致性」反而才是組織真正的簡化。

大多數的團隊總是採用輕量的 skills（好比 OpenSpec, grill-me)，當 skill 本身沒有扛太多職責，那職責就會落在 RD 自己身上，這下就是每個人「各憑本事」，有人產能好、有人產能不好，但大家都講不出好壞的原因。

請問這很 Simple 嗎？不，這恰恰是 Complicated。

當成員未經訓練，思想過度簡單，他們以為的「Simple」其實是「Lazy」，而這反而讓組織變得非常 Complicated。

我想，連定義驗收標準都排斥的人，這不叫 Simple，這叫 Primitive and Lazy。

只是個驗收標準而已，卻不去訂定，那你到底要如何才能真正跟 AI 進行大規模分工？

BDD 是先苦後甘的專業軟體開發工作流

因此水球我必須說，只有在團隊對流程還不熟悉時，欠缺訓練時，你才會覺得多了一道工；一旦團隊熟練這套方法，整體開發速度反而會大幅提升。

真正拖垮團隊產能的，從來不是「寫規格的時間」，而是大規模迭代時的混亂與返工。

特別是當產品跨過 MVP 階段、開始大量借助 AI 開發新功能時，團隊往往會陷入最致命的痛點——「改 A 壞 B」。每加一個功能，就提心吊膽舊邏輯被改壞；PM、工程師與 QA 陷入無止境的確認與修復循環，開發速度直接雪崩。

這正是為什麼在 AI 時代，我們強烈在推廣 BDD（行為驅動開發）實踐：

將規格化為可執行的安全網：BDD 不只是一套自動化測試，更是「活文件（Living Documentation）」。每一份規格都忠實反映系統的驗收標準與商業意圖，跨角色對齊無時差。
讓 AI 迭代快又準：當 PM 提出新規則（例如新增「取消預約」），工程師只需在規格中補上相應的 Rule 與 Scenario，直接交由 AI 生成程式碼。跑一次全套測試——原本重疊的情境依然綠燈，就知道歷史功能安然無恙；一旦紅燈，AI 也能精準鎖定問題立刻修正。
大幅拉高產能上限：每一次迭代都建立在高可靠度之上，團隊與 AI 就能放開手腳全速推進。

企業導入實績

然而，這也不是理論空談，水球在 2024 年之後就開始拜訪諸多軟體企業，其中有一間客戶也十分相信 BDD 並且在導入後也證實了實際成效。

過去一個涉及多方角色參與、連續審查邏輯極為複雜的業務流程，業主原先評估即便讓 PM 與 RD 配合 AI 來回摸索開發，至少也要花上整整一個月。即使透過 AI Coding 多角色之間協作的流程還是錯綜復雜，仍然需要 2~3 週左右的開發工程（算上返工成本）。

但導入 AI x BDD 之後，就將整體工程縮短到一個禮拜內就高品質交付上線。

這一週的時間內，SA 花了 3 天與 PM 密切溝通 Gherkin 的規格，定義好 Gherkin 後，接下來花 2 天時間就讓 AI 去開發，和做一些 Code Review。

隨著團隊對這套工作流越來越熟練，交付速度還能再向上提升。

慢在前期釐清共識，快在後期全速狂飆。 想要兼顧 AI 的產出速度與產品的極致穩定，BDD 才是真正讓開發從根本提速的關鍵引擎。

七、懶人包：五句話帶走 BDD

讀到這裡，如果你只想記五件事，水球我幫你整理好了：

BDD 的全名是 Behavior-Driven Development，中文叫行為驅動開發，由 Dan North 提出，是 TDD 的延伸。
它就是一句話：把業務行為翻譯成要驗收的系統行為，再用那組系統行為驅動、開發出你的程式。
它的施力點是「系統行為的自動化驗收」，這是它跟 TDD（施力點在測試）、DDD（施力點在領域）最大的差別。
落地靠 Gherkin：用 Given-When-Then 把規則寫成具體的例子，再用 Cucumber、behave 這類框架綁成自動化測試。這時候規格、測試、文件三者合一。
該不該導入，看的不是團隊規模，是產品階段。 產品進入維護期、開始大量用 AI 加功能，那就是導入的時機。

那麼，問題來了：你自己的專案呢？

如果你打開現在手上那份規格文件，卻沒辦法說清楚驗收標準是什麼，那你跟 AI 之間，就還隔著一層各自解讀的空間。

延伸閱讀

想知道什麼	去哪一篇
BDD 為什麼會是 Vibe Coding 的典範	BDD 初探
實例化需求（SBE）怎麼寫	AI x BDD（一）實例化需求
可執行規格的完整說明	AI x BDD（二）可執行規格
讓 AI 自己跑測試	AI x BDD（三）Automation

想把 BDD 真的導進團隊、不只是知道它是什麼，歡迎來看看《AI x BDD：規格驅動全自動開發術》

想完整學會 AI x BDD 全自動開發？

看課程方案 →