訂閱
By 水球潘 in 規格驅動開發 —

AI x BDD 規格驅動全自動化開發術 - (3)： 一個 Prompt 讓 AI 自己寫測試、自己寫程式！

規格驅動開發最重要的就是「情境導向的全自動化開發」。 這一篇，我要直接帶你動手操作，讓你親眼看到 AI 是如何根據 Feature file 全自動完成開發的。

前兩篇文章中，我們已經學會了兩件事：

  1. 實例化需求 (SBE)：用情境案例來定義需求，而不是模糊的自然語言
  2. 可執行規格 (Executable Specification)：用 Gherkin 語法撰寫 Feature file，讓規格變成可以執行的測試

現在你手上已經有一份完整的 Feature file，裡面列舉了所有情境的 Given / When / Then。

那接下來呢？

難道我們還要自己一個一個去實作測試步驟（Step Definitions）？然後再自己去寫 production code？

不！在 AI 時代，這些通通不需要了。

這一篇，我要直接帶你動手操作，讓你親眼看到 AI 是如何根據 Feature file 全自動完成開發的。

不講理論了，直接上手吧！

步驟 1：感受一下 AI x BDD 軟體全自動化開發的基本運作

好，現在讓我們來感受一下，當你有了一份完整的 Feature file 之後，AI 能幫你做到什麼程度。

下載範例專案：訂單優惠模組

首先，請下載這個 Github 目錄（訂單優惠模組）下的所有檔案。

你可以用 git clone 的方式：

git clone https://github.com/SDD-TW/SDD.tw-Examples
cd SDD.tw-Examples/入會任務/訂單優惠模組

這個專案包含了：

  • order.feature：前兩篇文章提到的「電商訂單優惠」的完整 Feature file
  • ERD.png：實體關係圖，定義了資料模型
  • OOD.png：物件導向設計圖，提供設計參考
  • BDD.prompt：預先寫好的 BDD 開發 Prompt

沒錯，就是我們前面講的那些情境實例：

  • 單一商品無優惠 (Single product without promotions)
  • 滿額折扣 (Threshold discount)
  • 買一送一（不同商品）(Buy-one-get-one - multiple products)
  • 買一送一（相同商品）(Buy-one-get-one - same product twice)
  • 買一送一（與其他類別混合）(Buy-one-get-one - mixed categories)
  • 滿額折扣 + 買一送一同時套用 (Multiple promotions stacked)

現在，我們要讓 AI 把這些情境全部實作出來。

本文使用 Python + Behave 技術堆來示範。

準備你的 AI Assistant

開啟你的 AI 開發工具，可以是：

  • Cursor
  • Windsurf
  • Claude Code
  • 或任何支援對話式 AI coding 的工具

然後，在專案目錄下準備執行我們提供的 BDD Prompt。

執行 BDD Prompt

在專案目錄下，把底下這段 Prompt 貼給你的 AI Assistant：

# Task
請你嚴格遵照「行為驅動開發 (BDD)」的方式，來完成 @order.feature 中所有驗收情境的開發。
不可同時進行 BDD 開發流程中多個步驟也不能略過任何一步驟，必須一步一步扎實執行並確認每一步的結果。

# Context

## Design Guideline
- 參考 entities ERD: @ERD.png 以及 OOD 設計圖：@OOD.png 。兩張圖中所指示的類別屬性及操作只是基準，你可視情況增加新的類別、屬性或行為。

## Tech Stack
1. Language Env：Python 3.11+
2. BDD Test framework: Behave
3. Native test framework: pytest

## Application Environment
1. App 類型：純模組程式碼
2. 此 feature file 中的所有優惠邏輯存放至 OrderService 類別中
3. Source code root: src/
4. Feature files 位置: features/
5. Step definitions 位置: features/steps/

# BDD 開發流程
1. 先建置出 behave walking skeleton - 可順利運行 behave 以及至少一個 scenario，確認至少有一個 test case 被測試框架執行到。

2. 嚴格遵守 BDD 以及最小增量原則來開發所有程式碼，針對所有 scenario，一次開發一個 scenario，依序進行：
    A. 一次選擇一個 scenario 實作，除此 scenario 之外的測試全部都用 @skip 標記忽略。撰寫此 scenario 對應的 Steps (given, when, then)、開啟相關類別，但是每個類別的行為都不實作，並且執行測試，確認測試失敗 (test fail)，並且測試失敗的原因並非框架層級的錯誤，而是期望的「值」上的錯誤。嚴格確認這步驟完成後才能進行下一步的實作。
    B. 為了通過上一步所撰寫的測試程式碼，請實作相關類別所需的程式碼，並確認能讓所有的測試程式碼都通過。請嚴格確認有執行到測試程式碼，從 test report 中覆述一次目前 test passed 的數量。
    C. 遵守 clean code 原則，思考是否要重構每個類別的內部程式碼，如果必要重構的話，在重構完成之後，再執行一次測試，確保所有測試仍然通過，否則需修正邏輯直到測試全數通過。

這個 Prompt 的關鍵設計思維是什麼？

我們用「結果導向」的方式，只告訴 AI 要遵守 BDD 流程，以及參考 Feature file 和設計圖，其他的全部交給 AI 自己決定。

你沒有告訴 AI 要怎麼寫程式碼，也沒有告訴 AI 要怎麼實作優惠邏輯。

你只是告訴 AI：

  1. 嚴格遵照 BDD 方式開發
  2. 先建置 Cucumber walking skeleton（確保測試框架能運作）
  3. 一次開發一個 scenario
  4. 紅燈（寫測試）→ 綠燈（寫實作）→ 重構
  5. 不可略過任何步驟

剩下的，我們就交給 AI 自行測試驅動開發、自行搞定。

開始執行：體驗 AI x BDD

現在，在你的 AI Assistant 中執行你選擇的 Prompt。

這是本文最關鍵的部分，你要親自執行，親眼看到 AI 如何工作唷～

根據 BDD Prompt 的指示，AI 會一步一步完成開發流程。整個過程可能需要 10-20 分鐘，取決於你使用的 AI 模型。

預期 AI 會進行的執行流程：

  1. 建立專案結構

    • AI 會建立 Python 專案，設定 Behave + pytest 環境
    • 建立 src/ 目錄存放 production code
    • 建立 features/ 目錄存放 feature file 和 step definitions

  2. 讀取並理解需求

    • AI 會讀取 order.feature，理解六個情境
    • AI 會參考 ERD.png 和 OOD.png 來設計類別結構

  3. 逐一完成每個情境

    • 選擇一個 Scenario（其他標記為 @skip）
    • 寫測試步驟（Step Definitions）→ 紅燈
    • 寫實作（OrderService 等）→ 綠燈
    • 重構（如果需要）
    • 確認測試通過後，進入下一個 Scenario

  4. 完成所有情境

    • 所有六個情境的測試都通過
    • AI 會覆述測試報告

實際執行結果

執行完成後，你會看到類似這樣的總結輸出：
（以下是 Claude Code 的執行範例）

## Summary

I have successfully completed all 6 scenarios in the order.feature file using strict BDD methodology:

### Results
- ✅ 1 feature passed
- ✅ 6 scenarios passed
- ✅ 25 steps passed
- ✅ 0 failures

### Implementation Details

**Entities Created:**
- `Product`: name, unit_price, category
- `OrderItem`: product, quantity
- `Order`: items, total_amount, original_amount, discount
- `OrderService`: Main business logic for checkout and promotions
- `Promotion` (base class)
  - `ThresholdDiscountPromotion`: threshold, discount
  - `BuyOneGetOnePromotion`: category

**Key Business Rules Implemented:**
1. Basic order calculation without promotions
2. Threshold discount (e.g., spend 1000, get 100 off)
3. Buy-one-get-one promotion for specific categories
4. Multiple promotions can stack

All code follows clean code principles with clear naming, single responsibility, and no duplication.

你可以執行 behave 指令來確認所有測試都通過：

behave --no-capture

輸出會顯示每個情境的執行細節：

@order_pricing
Feature: E-commerce Order Pricing Promotions
  As a shopper
  I want the system to calculate my order total with applicable promotions
  So that I can understand how much to pay and what items I will receive
  
  Scenario: Single product without promotions
    Given no promotions are applied
    When a customer places an order with:
      | productName | quantity | unitPrice |
      | T-shirt     | 1        | 500       |
    Then the order summary should be:
      | totalAmount |
      | 500         |
    And the customer should receive:
      | productName | quantity |
      | T-shirt     | 1        |

  Scenario: Threshold discount applies when subtotal reaches 1000
    Given the threshold discount promotion is configured:
      | threshold | discount |
      | 1000      | 100      |
    When a customer places an order with:
      | productName | quantity | unitPrice |
      | T-shirt     | 2        | 500       |
      | 褲子          | 1        | 600       |
    Then the order summary should be:
      | originalAmount | discount | totalAmount |
      | 1600           | 100      | 1500        |
    And the customer should receive:
      | productName | quantity |
      | T-shirt     | 2        |
      | 褲子          | 1        |

  # ... 其他情境

1 feature passed, 0 failed, 0 skipped
6 scenarios passed, 0 failed, 0 skipped
25 steps passed, 0 failed, 0 skipped, 0 undefined
Took 0m0.001s

AI 自動生成的檔案結構

AI 會自動建立以下完整的專案結構：

.
├── features/
│   ├── __init__.py
│   ├── order.feature           # Feature 檔案
│   └── steps/
│       ├── __init__.py
│       └── order_steps.py      # Step definitions
└── src/
    ├── __init__.py
    ├── product.py              # 產品模型
    ├── order_item.py           # 訂單項目模型
    ├── order.py                # 訂單模型
    ├── promotion.py            # 促銷模型（包含各種促銷類別）
    └── order_service.py        # 訂單服務（包含促銷邏輯）

各位軟工夥伴，你要觀察的重點大概是底下這些：

  • AI 如何從 Feature file 中提取資訊
  • AI 如何設計類別結構（Order, OrderItem, Promotion, OrderService 等）
  • AI 如何實作不同的優惠邏輯（threshold discount, buy-one-get-one）
  • AI 如何處理多重優惠疊加的複雜規則

然後，你也要特別關注，完成後你會得到什麼：

  • 完整的測試步驟程式碼（Step Definitions）
  • 完整的 production code（OrderService, Order, Promotion 等）
  • 所有測試通過的綠燈報告
  • 一個能正確計算訂單優惠的系統

感受「結果導向」的開發方式

看到這裡，你應該能感受到了：

這就是所謂的「結果導向」開發方法。

你只需要用 Feature file 這類 scenario-based 的格式來訂定極其清楚的系統行為預期結果，接著全部交給 AI 就行了。

基本上，你會慢慢地不再需要：

  • 自己寫測試步驟
  • 自己寫 OrderService 的邏輯
  • 自己處理滿額折扣的計算
  • 自己處理買一送一的邏輯
  • 自己處理多重優惠疊加的複雜規則

那麼，身為軟體工程師的我們只需要做什麼呢？

那麼，身為軟體工程師的我們只需要做什麼呢？

很重要：只需要檢查一下測試程式碼有沒有寫對就好。

這部分對 AI 來說通常最簡單，因為「測試步驟」就是把 Feature file 中的描述翻譯成程式碼而已。

你只要快速對照一下值的部分沒錯就好：

  • Given 的資料有沒有正確建立？
  • When 的操作有沒有正確執行？
  • Then 的驗證有沒有正確比對？

整個測試程式碼的意圖是否符合產品該情境的意圖？

至於 production code 的實作細節？不怎麼需要去看！

因為測試會幫你確保程式碼是否滿足「功能性需求」。只要測試通過，代表 AI 寫的 production code 就是符合規格中的「功能性需求」的，也就是功能至少都照著驗收條件進行啦！

那當然你可以稍微喵一下 production code 有沒有什麼愚蠢的設計問題，如果你是使用推理模型來實作業務邏輯程式碼的話，基本上不會有太大的問題。如果設計上有問題，那通常代表你的 Scenario 寫得不夠多，這部分符合測試驅動開發的初衷——用更多測試情境來驅動出更長久、成熟卻高效益的設計，不多不少，剛剛好滿足功能情境。

這就是「結果導向」的威力：我們不在乎 AI 怎麼寫程式碼，我們只在乎結果對不對。

步驟 2：迭代下一個 User Story——雙十一優惠

好，剛才你已經看到 AI 如何根據 Feature file 全自動完成開發了。

但那是我們幫你準備好的範例專案。

現在，輪到你自己動手了！

新需求來了：雙十一優惠

想像一下，你正在負責電商系統的開發，突然 PM 丟了一個新需求給你：

「欸，下個月要搞雙十一活動，老闆說要來個特別的優惠！規則是這樣的⋯⋯」

規則如下：

如果啟動了雙十一優惠活動，則訂單享有底下優惠規則：

  • 同一種商品每買 10 件，則該 10 件同種商品的價格總和會享有 20% 的折扣

聽起來有點複雜？沒關係，PM 很貼心地給了你三個範例：

範例一：購買 12 件襪子

購買 12 件要價 100 元的襪子，則訂單總價為：

  • 前 10 件：10 × 100 × 80% = 800 元
  • 剩餘 2 件：2 × 100 = 200 元
  • 總價：1000 元

範例二：購買 27 件襪子

購買 27 件要價 100 元的襪子，則訂單總價為：

  • 第 1 個 10 件：10 × 100 × 80% = 800 元
  • 第 2 個 10 件：10 × 100 × 80% = 800 元
  • 剩餘 7 件：7 × 100 = 700 元
  • 總價：2300 元

範例三：購買 10 件不同商品

購買商品 A, B, C, D, E, F, G, H, I, J 各一件（總共十件商品），每一件價格皆為 100 元，則訂單總價為：

  • 10 件不同商品：10 × 100 = 1000 元
  • 總價：1000 元（沒有折扣，因為並非同一種商品）

好，需求清楚了吧？

現在，在傳統開發方式下，你會怎麼做？

你可能會：

  1. 打開 OrderService 的程式碼
  2. 開始思考要怎麼實作這個邏輯
  3. 寫一堆 if-else 判斷
  4. 寫一堆迴圈來計算折扣
  5. 寫測試來驗證
  6. Debug 到天荒地老

但在 AI x BDD 的開發方式下，你完全不需要這樣做。

練習：將需求轉換成 Feature file

現在，請你自己動手，將上述優惠規則寫成 Feature file。

記得，每個範例都是一道情境（Scenario），需要用 Given / When / Then 的格式來描述。

這裡給你一些提示：

Scenario 標題

每個 Scenario 要有清楚的情境描述，好比：

Feature 雙十一優惠

  Scenario: 雙十一優惠 - 購買 12 件相同商品
    ...

  Scenario: 雙十一優惠 - 購買 27 件相同商品
    ...

  Scenario: 雙十一優惠 - 購買 10 件不同商品
    ...

現在，試著把三個範例都寫成完整的 Scenario 吧！

如果你不確定怎麼寫，可以參考前兩篇文章中的 Feature file 範例，或是參考步驟 1 中下載的專案裡的 order.feature。

練習：用 BDD Prompt 讓 AI 實作

當你寫好 Feature file 之後，接下來就是見證奇蹟的時刻了。

請在你的專案目錄下，再次執行步驟 1 中的 BDD Prompt。

然後，就讓 AI 開始工作吧！

重點來了：你不需要去想怎麼實作這個邏輯，不需要去改既有的 OrderService 程式碼，只要寫好 Feature file，AI 就會自己搞定一切。

AI 會：

  1. 讀入你新增的雙十一優惠情境
  2. 撰寫對應的測試步驟（如果需要新的步驟）
  3. 修改 OrderService 來支援雙十一優惠邏輯
  4. 一個一個情境地完成測試
  5. 確保之前的六個情境測試也還是通過的

你只要坐著，看 AI 工作就好囉～這段時間當然可以去運動啊，什麼的...。

觀察結果：測試全部通過了嗎？

當 AI 完成工作之後，你會看到 AI 的總結報告：

## BDD Development Complete - Summary Report

### Test Results
**ALL SCENARIOS PASSING!**
- **1 feature passed**, 0 failed, 0 skipped
- **9 scenarios passed**, 0 failed, 0 skipped  
- **37 steps passed**, 0 failed, 0 skipped, 0 undefined

### Scenarios Implemented

1. ✅ Single product without promotions
2. ✅ Threshold discount
3. ✅ Buy-one-get-one (multiple products)
4. ✅ Buy-one-get-one (same product twice)
5. ✅ Buy-one-get-one (mixed categories)
6. ✅ Multiple promotions stacked
7. ✅ Double Eleven (12 items)
8. ✅ Double Eleven (27 items)
9. ✅ Double Eleven (10 items)

執行 behave 指令可以看到詳細的測試結果：

behave --no-capture

1 feature passed, 0 failed, 0 skipped
9 scenarios passed, 0 failed, 0 skipped
37 steps passed, 0 failed, 0 skipped, 0 undefined
Took 0m0.001s

讓我們來驗證結果：

1. 所有新增的雙十一優惠情境測試都通過了

三個範例情境：

  • 購買 12 件襪子 → 總價 1000 元 ✅
  • 購買 27 件襪子 → 總價 2300 元 ✅
  • 購買 10 件不同商品 → 總價 1000 元（無折扣）✅

2. 之前的六個訂單優惠情境測試也還是通過的

這很重要！這代表新功能沒有破壞舊功能。

  • 單一商品無優惠 ✅
  • 滿額折扣 ✅
  • 買一送一（不同商品）✅
  • 買一送一（相同商品）✅
  • 買一送一（與其他類別混合）✅
  • 滿額折扣 + 買一送一同時套用 ✅

如果測試失敗了怎麼辦？

沒關係，這是正常的！

把錯誤訊息複製下來，貼給 AI，然後說：

「測試失敗了，請根據錯誤訊息修正程式碼。」

AI 會分析錯誤訊息，找出問題，然後修正程式碼，直到測試通過為止。

這就是 BDD 的保護網：測試會告訴你哪裡錯了，AI 會根據測試失敗訊息自己 debug。

補充說明：AI Assistant 可能會中途停止工作

有些時候，你可能會遇到 AI Assistant 在開發到一半時就停下來等你的指示，測試還沒有完全通過就結束了工作。

這是正常的！

因為市面上的 AI 工具（如 Cursor、Windsurf）通常會擔心消耗太多 token 而造成你的費用負擔，所以當測試情境較多時，AI 可能會先完成一部分開發就暫停下來，等待你的進一步指示。

這個時候你只要繼續跟它說：

「請繼續開發，直到所有測試程式碼都通過。如果你判定測試的程式碼有問題，或是原始的 feature file 有問題，請停下來告訴我，並且主動釐清問題。」

AI 就會繼續工作，直到所有測試通過為止。

結語

好了，看到這裡，你已經親手體驗過完整的 AI x BDD 流程了。

讓我們回顧一下你做了什麼：

  1. 下載範例專案，執行 BDD Prompt，看到 AI 自動完成六個訂單優惠情境的開發
  2. 自己動手寫 Feature file，定義雙十一優惠的三個情境
  3. 再次執行 BDD Prompt，看到 AI 自動完成新需求的開發

你有沒有發現，整個過程中你完全沒有寫任何 production code？

你只是定義了需求（Feature file），剩下的全部是 AI 完成的。

那麼，問題來了：

你自己的專案呢？

你有沒有想過，哪些功能可以用這種方式開發？

也許是：

  • 用戶註冊登入的各種情境
  • 購物車的加減商品邏輯
  • 訂單狀態的流轉規則
  • 權限控制的各種角色情境
  • 報表產生的各種篩選條件
  • ⋯⋯

只要是能夠用「情境案例」清楚定義的功能，都可以用 AI x BDD 的方式來開發。

不用再花時間寫一堆 if-else，不用再想破頭怎麼實作複雜的業務邏輯，不用再 debug 到天荒地老。

你只需要學會一件事：如何把需求轉換成清楚的情境案例。

這就是前兩篇文章教你的「實例化需求 (SBE)」和「可執行規格 (Executable Specification)」。

最後，邀請你把練習完之後的心得分享至：Discord 社群

讓我們一起交流，看看大家在實踐 AI x BDD 的過程中遇到了什麼有趣的挑戰，又是如何解決的。

好了，現在你已經掌握完整的 AI x BDD 流程了。

去你的專案試試看吧！

對規格驅動開發而言，精準度，會是接下來最重要的戰場

上述的 AI x BDD 做法只是基本中的基本。

許多夥伴在體驗到 AI x BDD 的威力之後，應該已經開始感受到：也許解放雙手最好的方式，就是把你的關注點放在 scenario-based 的規格上，而不再是繼續在程式碼中進行瑣碎的開發工作。

不過，接下來你可能會擔心：

AI 寫出來的測試程式碼，它的精準度夠高嗎？

我還是需要一行一行去檢查測試程式碼是否真的滿足產品的意圖吧？

這部分當然還有得學。怎麼可能一篇文章就解決所有問題呢？

但這也不代表這些問題無法解決，只是你還有進階的技巧要學。如果想學的話，接下來我就大概跟你說一下怎麼做。

規格的光譜：達到 100% 測試程式碼正確率

主要的做法叫做 「規格的光譜」，這是水球老師我在規格驅動開發（SDD）中提出的超高精度做法。

核心概念是：透過一層一層的翻譯，來保證你的測試程式碼能夠絕對反映整個產品的測試意圖。

甚至可以做到：

今天你的 Feature file（可執行規格）一旦寫完，就能保證工具所產出的測試程式碼是 100% 的正確率。

不需要再一行一行檢查，不需要再擔心 AI 理解錯誤，完全自動化，完全可信，畢竟幾乎大多數主流的業務流程需求都可以被寫成可執行規格中。

水球我認為呢，市面上未來只會有兩種人而已，第一種人知道如何做到 100% 精準度，第二種人只知道一天到晚用 Vibe，但卻做到連精準度都算不來的程式。

我會和你說啊，如果你和我一樣想要把軟體工程師的價值無限延續，那精準度就是我們的戰場。

想學的話有兩種方式

如果你對這套方法有興趣，有兩種學習方式：

方式一：速成班 - AI x BDD 規格驅動全自動開發術課程

想要快速掌握完整技巧的話，可以直接來上我們的線上課程：

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

課程中會完整教你：

  • 如何設計高精度的規格
  • 規格的光譜是什麼
  • 如何達到測試程式碼 100% 正確率
  • 如何建立可維護的自動化開發流程
  • 實戰演練各種複雜業務場景

方式二：加入 SDD.tw 讀書會 - 每周二線上研討

如果你想要免費學習、與社群一起成長，歡迎加入我們的線上讀書會：

台灣規格驅動開發研究組織 (SDD.tw)

  • 時間：每周二晚上
  • 形式：線上研討會
  • 內容：AI x BDD、規格驅動開發、全自動化實踐經驗分享
  • 對象：對全自動開發術有興趣的魔法初學者與資深開發者

加入方法寫在我們的官網上：sdd.tw

基本上最後都會導到水球軟體學院的 Discord 社群就是了，因為水球我辦的所有高含金量活動都會在我自己的社群中發生。

歡迎各位全自動開發術的魔法初學者，一起來探索 AI 時代的軟體開發新境界！

💡
AI-BDD 全篇系列文章請瀏覽此連結

訂閱 水球軟體學院：部落格

立即訂閱水球軟體學院部落格的電子報，接收最前沿的軟體工程方法學問
jamie@example.com
訂閱