上一篇文提到了，為何「行為驅動開發 (Behavior-Driven Development, BDD)」必定會成為 Vibe Coding 的典範。

你還記得是為什麼嗎？這裡再簡單說一次
——因為 「行為驅動開發」是少數有指導你如何與 AI 建立需求共識、讓 AI 自己參考詳細規格、自己寫 code、自己試錯、自己跑測試，又能自己 debug、修 code 直到確保程式碼足夠正確的方法論！

「在這個時代下，哪個方法能夠更快地與 AI 建立共識，哪個方法能夠用目標導向的方式讓 AI 獨立工作，哪個方法就是王者。」反正未來 AI Agent 技術都會崛起，Agent 1, 2, 3, 4, 5 將在這幾年內陸續升級，那麼主要的瓶頸會落在哪？就是落在「人類如何與 AI 建立對目標、需求的共識」。

就算 Agent-5 出來了，哇！Agent 超級無敵聰明的，又怎麼樣？你仍然還是要想辦法講出 AI 聽得懂的話、能抓到方向感的目標。而這是很困難的，只要你沒有學過「實例化需求 (Spec by example)」，就難以做到這件事！

什麼是「實例化需求 (Spec by example, SBE)」？

實例化需求是行為驅動開發中最重要的一環，沒有做好實例化需求的話，那你後面工程階段不管做得再怎麼勤勞都沒用。

《不說廢話，直接來上教學吧》

簡單來說，實例化需求就是「幫需求舉例說明，用實際的例子來建立共識，讓需求更能逐步被完整理解」的意思。沒什麼特別的含意了！

那麼，如果是用在軟體系統需求上是什麼意思？
怎麼樣才能為系統需求做好實例化需求 (SBE)？

做法很簡單，就是這句話，要好好寫起來：

針對每一道功能 (Feature)（e.g., API, User story, ..等等），列舉每一種「情境 (Scenario)」的「實際行為 (Behavior)」，而不是只使用抽象的自然語言去描述。

關鍵就在於「列舉情境」，以及用「實際行為」來定義這個情境，這樣就能做好系統層面的 SBE。

範例：電商訂單優惠計價

舉個例子，好比以「電商訂單優惠計價」為例，其自然語言規格書可能長得像底下這樣：

1. 使用者可以在電商平台上購買多種商品，並將商品加入購物車。
2. 系統需自動計算訂單的總金額，並根據不同的促銷規則給予優惠。
3. 促銷規則包含：
   1. 滿額折扣：當訂單金額達到 1000 門檻時，給予 500元 的折價。
   2. 買一送一：每當購買化妝商品分類時，都會額外贈送同款商品。
   3. 訂單結帳時，系統需明確顯示每項優惠的計算方式與最終應付金額。
   4. 若同時符合多種優惠，需依照優惠規則的優先順序或疊加規則進行計算。
   5. 若訂單未達任何優惠條件，則以原價計算。

可是，自然語言不夠正規，所以仰賴先輩知識。

上述這個需求就算你用自然語言寫得再詳細，都還是需要一些先輩知識或是假設，才有可能精準理解。

好比：

1. 「滿額折扣」是指訂單總金額還是商品小計？
2. 「買一送一」是指同一項商品還是同類商品？
3. 「優先順序」是指先計算哪種優惠？
4. 「疊加規則」是指優惠可以同時使用還是只能擇一？
5. 「原價計算」是指商品原價還是已經計算過其他優惠的價格？

你想想，上面隨便列一下就發現，你一份純自然語言的需求下，有這麼多潛台詞啊啊啊啊，你在釐清需求會議時根本想像不到，只有下去實作時才會發現：「欸，等等，這裡⋯⋯應該是怎樣才對？」。

這些細節如果沒有明確的實例，就算是帶有豐富 kn0w-how 的資深工程師也可能理解錯誤，更別說是 AI 了。

那麼，人類的優點是至少「懂得提問」，可是啊，如果是 AI 的話就暫時沒有「主動提問」這項優點囉，AI 更容易自信滿滿地帶著自己的誤解埋頭苦幹，然後最後寫出那種 「80% 正確，20% 錯在細節」的程式碼。

吼～這種「80% 正確，20% 錯在細節」的程式吼，你真的能 Vibe 得起來嗎？他如此埋頭苦幹，卻要花你五倍的時間去 Code Review 才找得到這些錯誤！！

你說說 Code Review 的人真的會開心嗎？你真的會相信 AI 能繼續開發出正確的程式碼嗎？就算 AI 再怎麼樣聰明，只要他不小心犯了 20% 的錯誤，你都會帶著痛苦的懷疑在做 Code Review。

這都是因為你不懂得「逐步建立共識」。

如果遵守「實例化需求」原則來定義需求的話，那麼就可以至少在需求規格上將上述模糊空間表達得清清楚楚，請看底下實際做法！

電商訂單優惠計價案例（Spec by Example）

底下為上述優惠計劃的多個情境撰寫示範，每個情境都有定義出「具體的系統行為」，什麼叫「具體」？那就是具備底下三者要素：

1. 有實際的資料舉例
2. 有講清楚這個情境是在給定的什麼前提下執行的
3. 有直接的規則/步驟舉例

因此，我們來想想，訂單優惠的規則下，到底有哪些重要的情境？

那麼，也許是：

1. 最基本的，沒有任何優惠
2. 滿額折扣：基本範例
3. 買一送一：基本範例
4. 買一送一：優惠商品連續買兩件
5. 多項優惠疊加等等

你得想辦法先學會把需求拆解成情境，以「情境實例」作為與 AI 建立共識的顆粒度。所以你可以試著先列出底下的情境（我下一篇文再教你如何實作）。

情境 1：單一商品無優惠

商品名稱	數量	單價	小計
T-shirt	1	500	500

• 結果：
  • 訂單總金額為 500 元
  • 獲得底下商品：
    • T-Shirt x 1

情境 2：滿額折扣（門檻 1000 元）

商品名稱	數量	單價	小計
T-shirt	2	500	1000
褲子	1	600	600

• 折價：滿 1000 元折 100 元
• 結果：
  • 訂單總金額為 1600 - 100 = 1500 元
  • 獲得底下商品：
    • T-shirt x 2
    • 褲子 x 1

情境 3：買一送一（化妝類商品） / 多項化妝品一併買

商品名稱	數量	單價	小計
口紅	1	300	300
粉底液	1	400	400

• 計算：口紅 300 + 粉底液 400 = 700 元
• 買一送一贈送：口紅 1 個 + 粉底液 1 個
• 結果：
  • 訂單總金額為 700 元
  • 獲得底下商品：
    • 口紅 x 2
    • 粉底液 x 2

情境 3-1：買一送一（化妝類商品）/ 同一項化妝品買兩件

商品名稱	數量	單價	小計
口紅	2	300	600

• 計算：口紅 300 x 2 = 600 元
• 買一送一贈送：口紅 1 個
• 結果
  • 訂單總金額為 600
  • 獲得底下商品：
    • 口紅 x 3

情境 3-2：買一送一（化妝類商品） / 混合多類商品

商品名稱	數量	單價	小計
襪子	1	100	100
口紅	1	300	300

• 計算：襪子 100 + 口紅 300 = 400
• 買一送一贈送：贈送口紅 1 個
• 結果：
  • 訂單總金額為 400 元
  • 獲得底下商品
    • 襪子 x 1
    • 口紅 x 2

情境 4：多重優惠疊加

商品名稱	數量	單價	小計
T-shirt	3	500	1500
口紅	1	300	300

• 計算：T-shirt 1500 + 口紅 300 = 1800 元
• 買一送一贈送：贈送口紅 1 個
• 折價：滿 1000 元折 100 元
• 結果：
  • 訂單總金額為 1800 - 100 = 1700 元
  • 獲得底下商品：
    • T-shirt x 3
    • 口紅 x 2

以上就是實例化需求的基本示範，有沒有注意到每個情境都一定會有「具體的資料」？如果沒有具體的資料的話，那就不算是「實例」了。

當然，還有很多組織實務上的思路細節都收錄在 《Spec by example》的書籍中。不過我認為如果你只是想要掌握 AI x BDD 全自動化開發的方法的話，看我的文就能先建立一定的認知了，先往下走吧。

結語

以此類推，有沒有覺得上述這樣列舉情境說明之後，規格就挺清楚了？

有沒有覺得：「哎呀，這舉例說明不是什麼顯而易見的事嗎，竟然能兜出一個方法論嗎？」

那我就問你一句，如果這件事這麼淺顯易見，那為什麼大家到現在都還在鑽研「下 prompt」，不去鑽研「舉例說明」、「與 AI 建立實例共識」的標準化系統規格格式？

大多數人仍然花較多時間在鑽研下 prompt 的做法，好比過度在 Vibe Coding 的過程中在乎要怎麼樣列 meta prompt 等等的，而不是專注透過「列舉情境說明」的方式在做 Vibe Coding。

是的，在不同的領域中，有很多先進已經透過瘋狂舉例的方式在控制 AI 的輸出品質。可是，在軟體領域中，恰巧，目前仍然較少人這樣做，就連我們熟知的 user story，都很少團隊願意把他的 Acceptance Criteria （驗收標準）寫清楚，那又怎麼可能會願意用「列舉情境說明」的方式來定義規格？

原因很簡單嘛，因為列舉情境案例是一件「超・級・無・敵・累的事。」。要做這麼累的事，拉長會議時間，那得到的好處是什麼？——不清楚！

什麼？你說這樣就能讓「工程師變得更厲害、寫 code 更容易正確？」？組織才不信呢，這種「無形的好處」誰信啊！看不到具體好處的事，又怎麼會用力導入到每個團隊中？

啊哈——那麼，現在呢？時代已經不同了喔！在現在 AI Agent 遍地滿天飛的這個時代，難道 SBE 還沒有「具體的價值」嗎？

是的，很多組織不懂的事情是，在 AI Agent 的魔法崛起之後，實例化需求的完整好處被徹底指數級解放了，這已經不是什麼「無形的好處」了。

如果你進一步讓工程師學習 SBE，讓他們幫忙把需求的幾十道功能，都透過「情境案例」列舉，然後，再讓 AI 把每一條情境都先照著寫成「自動化測試」的話，那麼 ，在這麼多自動化測試的保護之下，是不是 AI 就能幫你「全自動化開發」？

這時，你還想像不到有多少好處嗎？

這可不是軟實力呢，這是硬實力！

想像還是不夠多？沒關係，我們繼續往下一個單元學習吧！

下一個單元，就要教你什麼叫做「可執行規格 (Executable Specification)」，列完情境之後，我們就要用「技術」來把這些情境變成可以直接執行的程式碼囉！

---

如果想要在六個小時內立刻掌握 AI x BDD，該怎麼做？

要在六個小時內掌握 AI x BDD 全自動化開發的做法，只靠自己摸石頭前進是不可能的。

就算讀完了《BDD in Action》這本書，就算對於 BDD 的各個工程環節都有所掌握，也仍距離 AI 全自動化開發有一大距離。

如果真的想要讓 AI 能夠依照 BDD 的指示，精準且可靠地把每一步驟做好，有太多的細節需要留意：

1. 該怎麼做實例化需求，寫到什麼程度才能保證 AI 看得懂？
2. 看懂實例之後？用什麼測試架構，才能保證 AI 產出絕對與需求一致的測試？
3. 測試架構的設計如何釋放 AI 的效率？AI Agent 把測試寫得越來越肥，效率越來越差了，該怎麼辦！
4. 實例化需求的重用該怎麼做？規格上做「情境重用」，可是技術上該如何讓 AI 也懂得「情境重用」？
5. AI 寫完 given / when / then 之後要做什麼？如何讓 AI 自己寫 code、自己試錯、自己修正，做到獨立作業？
6. 就算 AI 已經能做到 BDD 獨立開發了，到底又要怎麼樣讓他不眠不休地連續工作好幾十個小時？做到「全自動化開發」？

這些全部都是智慧的結晶啊！每一個環節都需要花費超級大量時間研究，才能找出正確的方法。如果你不想花費半年時間來研究的話，那就直接上課吧！

《AI 時代的 1% 工程師：用「行為驅動開發 (BDD)」 實現百倍效率的 Vibe Coding 》是水球老師精心製作的一日工作坊課程，現正熱賣中。

Posts

如果要想要用 6 小時工作坊的時間，立刻速成學會如何用 BDD 來讓 AI 全自動化開發？那就上課吧！

實體場：https://www.accupass.com/event/2506110435103759406480
線上場：https://www.accupass.com/event/2506160524377577825710