轉念學 – 敏捷三叔公的學習之旅

BDD 是否可以用 skill + AI Agent 來落實？

敏捷三叔公

這份 skill 是什麼

thebushidocollective/han/bdd-principles 是一份放在 playbooks.com 上的 Claude Code skill：一個 SKILL.md 檔，agent 在遇到 BDD、Gherkin、feature 檔這類任務時會自動載入，照裡面的規則做事。它本身不是測試框架，而是一份濃縮的 BDD 教材，內容包括 Discovery → Development → Delivery 三段框架、Three Amigos 每個角色該問的問題、Example Mapping 四色卡、Ubiquitous Language 詞彙表、Outside-in 開發，以及一組「常見誤解」的糾正：BDD 不是 Cucumber 測試、不是先寫測試再寫程式、不是每個行為都要情境、不是只有測試人員寫情境。它標記為「不可由使用者直接呼叫」，純粹當 agent 的背景知識。同一類的還有 tessl.io 上的 pantheon-ai/bdd-testing，偏執行面，多了一組 NEVER 規則：不准把實作細節寫進步驟、不准跳過 Three Amigos 就寫關鍵情境、不准寫模糊的 Then、不准讓情境有執行順序依賴。

這類 skill 值得看，是因為它把 Specification by Example 二十年來靠教練叮嚀的紀律——先談再寫、不寫 UI、一個情境一件事——變成工具的預設行為。下面用一個台灣讀者熟悉的需求，走一遍 agent 載入這份 skill 之後會怎麼做。

需求：台灣高鐵早鳥票

假設 PO 丟進來的 story 只有一句：

身為旅客，我希望提前訂票時能享有早鳥折扣，這樣長途旅行可以省錢。

下面的對話是模擬的 Claude Code 對話，專案裡已裝好這份 skill。skill 本身沒有固定腳本，實際對話會因模型和專案而異，但主要轉折點——先問再寫、紅卡要停、宣告式情境、UI 步驟被擋——是 skill 明寫的規則，會穩定出現。對話中的高鐵規則（折扣檔次、截止日、改期處理）是依公開資訊整理的教學用版本，實際以高鐵現行規定為準。

逐回合對話

標示方式：**使用者（人）**是人打的 prompt；**Agent（skill 生效）**是 AI 照 skill 規則的回覆，每段前面註明是哪條規則在起作用。

回合 1：使用者丟需求

使用者（人）： 幫我做高鐵早鳥票的功能。旅客提前訂票可以打折。先把 feature 檔寫出來。

Agent（skill 生效）： 不直接產檔。起作用的規則：skill 把「只有測試人員寫情境」「直接寫情境」列為誤解，並規定 Three Amigos 各角色該問的問題。

我先不直接寫 feature 檔，因為「提前訂票可以打折」還不是能寫成情境的規則。先用 Three Amigos 的三個角度把規則問清楚：

業務角度

  1. 早鳥可以提前多久訂？開放訂位是乘車日前幾天？
  2. 折扣有幾檔？各是幾折？
  3. 是「先訂先得、額度有限」，還是「期限內一律同折扣」？
  4. 限哪些車廂／座位？自由座、商務車廂適用嗎？
  5. 可以跟敬老、愛心、學生等身分優惠併用嗎？

開發角度 6. 「前 N 天」以乘車日 00:00 起算，還是以班次發車時刻起算？ 7. 某一檔額度售完，是自動落到下一檔，還是顯示售完？ 8. 同一訂單多張票，可不可以一張 65 折、一張 8 折？

測試角度 9. 早鳥有沒有截止日？ 10. 早鳥票改期或退票，折扣怎麼處理？

回答到哪算哪，確定的做成規則，不確定的留成問題卡。

回合 2：使用者回答一部分

使用者（人）： 1. 乘車日前 28 天開放。 2. 三檔：65 折、8 折、9 折。 3. 額度有限，先訂先得。 4. 只有標準車廂對號座。 5. 不能併用。 7. 65 折賣完就自動用 8 折，都賣完就原價。 8. 可以，每張票各自算。 9. 乘車日前 5 天截止。其他我不確定。

Agent（skill 生效）： 整理成四色卡。起作用的規則：Example Mapping（黃卡故事、藍卡規則、綠卡範例、紅卡問題）。

故事：旅客提前訂票享早鳥折扣

規則

  • R1 訂票日須在乘車日前 28 天至前 5 天之間
  • R2 折扣三檔 65 折／8 折／9 折，依該班次剩餘額度由低到高自動套用，全部售完回原價
  • R3 僅限標準車廂對號座
  • R4 不與身分優惠併用
  • R5 同一訂單每張票各自決定折扣檔

範例（每條之後會變成一個情境）

  • R1：10/31 訂 11/20 → 適用；11/16 訂 11/20（前 4 天）→ 不適用
  • R2：65 折有額度 → 65 折；65 折為 0、8 折有 → 8 折；三檔皆 0 → 原價
  • R3：商務車廂 → 原價
  • R4：敬老旅客選早鳥 → 要求擇一
  • R5：訂 2 張、65 折只剩 1 張 → 第一張 65 折、第二張 8 折

問題（待確認，先不寫情境）

  • Q1 「前 5 天」截止時刻：23:59 還是發車時刻？（影響 R1 邊界）
  • Q2 改期是否保留原折扣？退票手續費依票面價還是折扣價？
  • Q3 「前 28 天」的 00:00 是台灣時間？海外旅客的時區？

Q1 會直接影響日期邊界的情境，我需要答案才能寫對。要我先用「23:59」的假設寫並標註，還是你先去確認？

回合 3：給邊界答案，要求產檔

使用者（人）： Q1 以乘車日前 5 天的 23:59 為準。Q2、Q3 先不管。寫 feature 檔。

Agent（skill 生效）： 寫出 features/early_bird_pricing.feature。起作用的規則：一個情境一個行為、業務語言、不寫 UI、情境自備前提（Ubiquitous Language、宣告式情境）。

# language: zh-TW
功能: 早鳥優惠計價
  背景:
    假設 存在 11 月 20 日 08:00 台北到左營的班次，標準車廂原價 1490 元
  場景: 早鳥期間內且 65 折尚有額度
    假設 該班次 65 折額度為 10 張
    而且 今天是 10 月 31 日
    當 旅客訂購 1 張標準車廂對號座
    那麼 該張票價應為 969 元
    而且 套用的折扣檔應為 65 折
  場景: 65 折售完時自動改以 8 折計價
    假設 該班次 65 折額度為 0 張，8 折額度為 10 張
    而且 今天是 10 月 31 日
    當 旅客訂購 1 張標準車廂對號座
    那麼 套用的折扣檔應為 8 折
  場景: 乘車日前第 5 天 23:59 仍適用早鳥
    假設 該班次 65 折額度為 10 張
    而且 現在是 11 月 15 日 23:59
    當 旅客訂購 1 張標準車廂對號座
    那麼 套用的折扣檔應為 65 折
  場景: 乘車日前不足 5 天不適用早鳥
    假設 該班次 65 折額度為 10 張
    而且 現在是 11 月 16 日 00:00
    當 旅客訂購 1 張標準車廂對號座
    那麼 該張票價應為 1490 元
    而且 不應套用任何早鳥折扣
  場景: 早鳥不與敬老優惠併用
    假設 旅客具敬老身分
    而且 該班次 65 折額度為 10 張
    而且 今天是 10 月 31 日
    當 旅客同時選擇早鳥優惠與敬老優惠
    那麼 系統應要求旅客擇一
  場景: 同一訂單多張票各自決定折扣檔
    假設 該班次 65 折額度為 1 張，8 折額度為 10 張
    而且 今天是 10 月 31 日
    當 旅客訂購 2 張標準車廂對號座
    那麼 第 1 張套用 65 折
    而且 第 2 張套用 8 折

Agent（skill 生效）附帶兩個提醒： 969 元是 1490 × 0.65 無條件捨去，高鐵實際的進位規則它不知道，這是第四張問題卡 Q4；它沒有寫「前 29 天尚未開放」，因為那屬於「訂位開放時間」的 feature。起作用的規則：紅卡要留下、「不是每個行為都要情境」。

回合 4：使用者踩線，agent 擋回來

使用者（人）： 再加一個情境：使用者在網頁上勾選「早鳥優惠」核取方塊，按「查詢班次」，列表要出現折扣價。

Agent（skill 生效）： 擋回來並改寫。起作用的規則：NEVER 把實作細節寫進步驟。

這條我建議不要寫進 feature 檔，因為它描述的是 UI 操作（勾核取方塊、按查詢、列表），不是業務行為。UI 一改這條就壞，而且 PO 看不出它在驗什麼規則。它其實在驗的「查詢時會顯示折扣價」已經被第一個情境涵蓋。如果你要的是「查詢結果頁要標示早鳥」這個可見行為，我改寫成：

  場景: 查詢結果標示早鳥折扣
    假設 該班次 65 折額度為 10 張
    而且 今天是 10 月 31 日
    當 旅客查詢 11 月 20 日台北到左營的班次
    那麼 該班次應標示為「早鳥 65 折」

「勾選核取方塊」「按查詢」放到 step definition 裡實作，feature 檔不碰。

回合 5：進入實作

使用者（人）： 好。開始實作。

Agent（skill 生效）： 固定順序實作。起作用的規則：Outside-in Development。

照 outside-in 走：

  1. 先跑 cucumber-js --dry-run，列出 8 個未定義的步驟
  2. 寫 step definition，句子對應業務語言，例如「旅客訂購 {int} 張標準車廂對號座」呼叫 bookingService.book(...)，不碰 DOM
  3. 讓第一個情境「65 折尚有額度」跑到紅燈
  4. 往內建 EarlyBirdPricing.selectTier(train, date, quotas)，用單元測試補額度剛好 1 張、日期邊界的分支
  5. 綠燈後跑下一個情境

skill 在這段對話裡改變了什麼

回合沒有 skill 時多數模型的做法有 skill 時的做法對應的 skill 規則
1直接產一份看起來很像樣的 feature 檔，規則自己腦補拒絕直接寫，先問十個問題常見誤解：「只有測試人員寫情境」；Three Amigos 各角色的提問
2對不確定的事假設一個答案往下做問題卡阻擋相關情境，回來問Example Mapping 的紅卡
3情境裡混入頁面、按鈕；幾個規則塞一個情境宣告式、自備前提、一條規則一個情境；主動切掉不屬於這個 feature 的東西「不是每個行為都要情境」；Ubiquitous Language
4照使用者要求加 UI 步驟擋回來並改寫成業務行為NEVER 把實作細節寫進步驟
5從 model 或 UI 開始寫dry-run → step → 失敗情境 → 往內 TDDOutside-in Development

它沒辦法改變的：回合 2 回答問題的還是同一個人。真正的 Three Amigos 裡，Q1 的答案是票務的人說的，Q4 的進位規則是財務說的；在這段對話裡，agent 把問題問得很好，但答案全來自同一個腦袋。

好處

  1. 把紀律外包給工具。 SbE 最難的不是寫 Gherkin，是「先談再寫」「不寫 UI」「一個情境一件事」這些要靠人自律的事。skill 把它們變成預設行為，教練不在場也會發生。
  2. 問題被逼出來的時機變早。 「前 5 天到底幾點截止」這種問題，傳統流程常常是上線後客訴才知道；agent 在寫任何程式之前就把它列成紅卡。
  3. 新手可以直接做出像樣的東西。 沒學過 BDD 的開發者照著對話走，產出的 feature 檔形式上接近受過訓練的團隊。
  4. 可審查。 規則、範例、問題都是文字，PO 可以看，不像「開發者腦中的假設」看不到。

壞處

  1. 協作被模擬掉了。 Three Amigos 的價值在三個不同腦袋的摩擦；skill 讓 agent 分飾三角，問題問得很好，但答案來自同一個人。使用者如果本身是開發者，回答「業務角度」問題時其實是在猜。形式齊全，本質是單人作業。
  2. 紅卡容易被「合理假設」吞掉。 skill 說要留問題卡，但 agent 的本能是把事情做完。回合 2 它問「要不要先用 23:59 的假設寫」，很多使用者會說好，問題卡就變成註解，然後被遺忘。
  3. 流程變重。 一個簡單的改價需求也要過十個問題、四色卡、八個情境。skill 自己也承認「不是每個行為都需要情境」，但判斷哪些需要還是靠人。
  4. 產出看起來太好。 八條漂亮的情境會讓人以為需求已經清楚，實際上 Q2、Q3、Q4 還沒答。AI 會把你的誤解寫得很漂亮。
  5. skill 本身還很粗。 tessl 那份的參考檔是空的、品質評分 76；playbooks 那份是教材不是操作指令。它們能約束模型，是因為模型本來就懂 BDD，skill 只是提醒；換一個弱一點的模型，效果會差很多。

為什麼很多團隊沒有這樣做

從近幾年的研究和調查看，原因很一致，而且都不是技術問題：

  • 成本被感受到、好處感受不到。 開源專案的研究發現，受訪開發者雖然理解 BDD 框架的用意，但多數人是寫程式時或之後才寫測試，因為 BDD 「相當耗費心力」（Visaggio 等）。Discovery 省下的返工是看不見的，Gherkin 的維護成本是每天看得見的。
  • 沒有人有權力把三方關進同一個房間。 2025 年的案例研究指出，採用 BDD 時發現的唯一問題是利害關係人之間的溝通（SCITEPRESS 2025）。PO 不來、業務沒空，開發和測試只好自己演。skill 沒有解決這個，它只是讓「自己演」演得更像。
  • 組織把它當測試工具引進。 很多團隊是從「我們要做自動化測試」開始，選了 Cucumber，然後反過來學 BDD。路徑一開始就是測試團隊的事，業務從沒被邀請。Digital.ai 的 State of Agile 調查只有 19% 團隊做 BDD，Tricentis 的成熟度模型指出其中大部分停在工具層。
  • Gherkin 的硬傷。 Glasgow 大學的論文指出業務人員很難用 Gherkin 表達領域概念；Bern 大學的研究指出大量情境只是換參數複製。當規格語言本身讓業務不想讀，「業務參與」就變成口號。
  • 沒有即時回饋。 人類教練不可能坐在每個開發者旁邊說「這條別寫 UI」。所以規則知道歸知道，寫的時候還是走捷徑。這一點倒是 skill 真正補上的。

現在有多少人在這樣做

分兩層看。

「用 AI 寫 Gherkin」已經很普遍。 SmartBear、Tricentis、SpiraPlan、TestQuality 這些測試管理工具 2024 年起都內建了 user story → 情境的生成；RMIT 2026 年的論文資料集就是從四個工業產品拿的，代表企業內部已經有相當規模的 LLM 生成情境在用。這部分比這個 skill 做得更自動——只是通常跳過了 Discovery，直接從 story 生成，正好把 skill 最有價值的部分拿掉。

「用 skill 約束 agent 照 BDD 紀律做」還很早。 這些 registry 2025 年才出現，skill 評分普遍不高、參考檔不完整，看起來是少數人把課堂教材搬進去，還沒有企業級的採用報告。多數實際在用 Claude Code、Cursor 的團隊，是在 CLAUDE.md 或 AGENTS.md 裡寫幾條「測試用 Gherkin」「驗收條件要可執行」的規矩，效果類似但沒有這麼完整。

所以誠實的答案是：照這份 skill 的形式做的人還很少；做它後半段（AI 生成情境）的人已經很多；做它前半段（先談出範例）的人，不管有沒有 AI，一直都很少。AI 沒有改變這個比例，只是讓後半段更便宜，而更便宜的後半段會讓更多人覺得前半段可以省。

結語

當 agent 問出那十個問題時，你會去找 PO，還是自己回答？多數人的答案，就是 Specification by Example 在業界的現況。skill 能強迫 agent 「不跳過 Three Amigos」，卻沒辦法把 PO 拉進會議室。AI 扮演的 Three Amigos，算不算 Three Amigos？這個問題值得每個正在用 AI 寫規格的團隊自己回答。

參考來源

這兩份 skill

  1. thebushidocollective/han/bdd-principles — playbooks.com
  2. pantheon-ai/bdd-testing — tessl.io（含 NEVER 規則與好壞 Gherkin 對照）

BDD / SbE 的定義與方法

  1. Adzic, G. (2011). Specification by Example: How Successful Teams Deliver the Right Software. Manning. O’Reilly
  2. Automation Obsession: Are You Automating the Wrong Things? – Gojko Adzic — Pragmatic Coders
  3. Example Mapping – Steering the conversation — Xebia
  4. Using Specification by Example / BDD for your refinements — Xebia, 2026
  5. BDD Example Mapping — Automation Panda

業界採用與實務落差的研究

  1. Visaggio, C. A. et al. Demystifying the adoption of behavior-driven development in open source projects
  2. Guidelines for Adopting Behavior-Driven Development (BDD): A Case Study — SCITEPRESS, 2025
  3. Perception of Professionals Regarding BDD: A Descriptive and Statistical Study — SCITEPRESS, 2025
  4. Patkar et al. (2022). An Exploratory Study on the Usage of Gherkin Features in Open-Source Projects — University of Bern
  5. Islam, M. (2024). PhD thesis: BDD in a large-scale safety-critical organisation — University of Glasgow
  6. Alshammari (2025). On the use of user interface specific domain Gherkin in BDD — University of Glasgow
  7. Tricentis BDD Maturity Model（引用 Digital.ai State of Agile 的 19%）
  8. State of Behavior Driven Development — SmartBear 調查

AI 生成 Gherkin 與工具產品化

  1. Rathnayake et al. (2026). Behaviour Driven Development Scenario Generation with Large Language Models — arXiv:2603.04729, RMIT
  2. A Comparative Study of LLMs for Gherkin Generation — SBES 2025
  3. Generative AI and BDD （SpiraPlan 案例） — EuroSTAR
  4. How to Generate AI Gherkin Test Cases — TestQuality
  5. T0082: BDD in the Age of AI-Assisted Programming — University of Bern SEG

對話中的高鐵早鳥規則為教學用簡化版本，非台灣高鐵公司的正式規定。

發佈留言