行為驅動開發 (BDD) 絕對會是 Vibe Coding 未來的典範（前導文）
這篇文會描述 BDD 的三大環節，以及為什麼每位軟體工程師只要開始學習 AI x BDD 的方法，就能掌握 Vibe Coding 未來的典範，真正活在未來而不是焦慮於現況。
如果你，現在開始實踐行為驅動開發，
產值就能超越市面上 99% 的工程師；
如果你的組織，現在開始實踐行為驅動開發，
平均單位軟體產值就能碾壓市面上 99% 的組織。
這兩句話會發生在接下來的一年內。
前言
今年三月開始，Vibe Coding 在網路上爆紅，各種分享文、教學影片如雨後春筍。
但至今 (2025 年 7月）——市面上 99% Vibe Coding 的實踐都仍在錯誤的方向上，太多「過度注重軟實力」卻「缺乏軟體工程知識」的做法。好比說：過度強調「如何下 prompt」卻完全不參考軟工做法，這些 Vibe Coding 的做法都嚴重缺乏工程效率。
Vibe Coding 兩大關鍵錯誤
- 99% 的人，仍然「過度強調與 AI 協作的過程」。強調如何下 Prompt、陪 AI 寫 Code、改 Code、修 Code。但是，你是否想過你到底希望 AI Agent 「完整代理」什麼？如果是代你寫 code，那為什麽需要你在旁邊監督？
- 99% 的組織，仍然不敢花夠時間訂定「明確的系統需求脈絡及驗收規格」。你是否想過，如果沒有「需求的完整脈絡 (Context)」 能讓 AI 直接參照，那麼你又要如何期待 AI 像人類一樣獨立工作？
所以，真正高效的 Vibe Coding 不是「跟 AI 一起寫」
而是：「定義好超清楚的工程規格 → 丟給 AI → 你轉頭去做別的事」
Vibe Coding 的正解 — 行為驅動開發 (BDD)
為什麼有將近 99% 的人都沒找到正解？很簡單，因為大家都沒聽過這個「超級冷門」的軟體開發方法 — 行為驅動開發 (Behavior-Driven Development, BDD)。
BDD 是什麼？
在 AI 時代下，誰能說出最精準、正規的需求，哪個方法更懂得去「與 AI 建立精準共識」，誰就是軟體開發的王者，這是一個極其簡單的道理。BDD 剛好就做到了這件事。
BDD 是什麼？長話短說，BDD 就是教你如何用「中文/英文」加上一組標準化的格式，來精準定義清楚「需求的驗收規格」，並以此驗收規格綁定測試框架，來驅動整體程式開發的方法論。
懶人包：BDD 三大環節 ——學完立刻落地
非常簡單，BDD 我就不講全貌了，你只要搞懂底下幾個環節就能立刻落地回自己的專案。
- 實例化需求 (Spec by example)：白話文來說，就是用「舉例」的方式來去定義每一道功能的「實際行為」，而不是只使用抽象的自然語言去描述，無論是拿實際資料來舉例，或是拿實際執行步驟來舉例，反正就是舉越多例越好。
- 可執行規格 (Executable Specification)：舉完例子之後，就要把這些例子透過技術（e.g., Cucumber）變成可執行的測試程式。那這樣這些實例化需求就不再只是放著長灰塵的文件了，而是能作為整份專案的測試保護，永遠保護程式正確運作的「可執行的規格」。
- 驗收測試驅動開發 (Acceptance Test-Driven Development, ATDD)：把上述的可執行的規格當成「自動化驗收測試」的話，那就能使用「驗收測試驅動開發」這個開發流程，來快狠準的地實作每個功能，達成每個情境驗收行為。
上面的部分我會拆成接下來三篇文章來講，可是白話文來說呀，BDD 基本上講的就是：
- 用某種「測試」，與 AI 建立絕對的需求規格共識。
- AI 既然對需求有與你完全一致的理解，那他就能自己下去開發，你不必在旁邊監督。
- 既然有測試保護，那 AI 就能自己寫 code、自己測試、自己試錯、自己修正，直到通過所有的測試程式。
以上三者，如果做到，就能解放人類在開發過程中的勞動力。
你想像到了嗎？
比起「快」，AI 更大的價值是「開發的平行度」
我問你，你覺得 AI 最大的價值是什麼？是他生成程式碼的速度比你快百倍嗎？很多人會回覆：「不，就算速度快百倍，可是如果你餵垃圾給他吃，那他就會產出一百倍的垃圾。」
因此我們都知道，AI 的價值不在於「快」，那麼是在於什麼？肯定是在於「開發的平行度」啊！AI 就像是用更便宜的價格請到軟體工程師當你的下屬。根據你的預算你可以同時請好多好多下屬來開發不同的模組。
可是不管怎樣，在 AI 開發的過程中，就是必須要透過一些聰明方法讓他獨立作業，不然就失去這個價值了。那這個聰明方法就是 BDD。
- 會 BDD 的人懂得花時間先把「驗收規格」定義清楚，然後叫 AI 必須針對每一道功能的每一道情境都「先寫測試、再寫程式」地做好測試驅動開發。
- AI 開工之後，你要把它放在背景，完全不管 AI 開發過程中是否有犯錯。反正你有測試保護啊！相信我，幾個小時之後 AI 就會帶著 90 幾條完全通過的驗收測試回來找你。
因為 BDD 是用「完整的可驗收規格」來逼 AI 「自己找出正確且可靠的程式碼」，而不是靠「人工下 prompt」來與 AI 協作，所以你的勞動力就被解放了。
這就像什麼？就像是「目標導向」的管理方法，面對下屬時，你不該「微管理」你的下屬，也不該在下屬「犯一次錯」之後就氣急敗壞。你更該做的——是訂定極其清楚的目標，然後讓 AI/下屬 自己去試錯，直到通過所有測試！
是的，如果 Agent 可以獨立工作，就可以同時雇用好多好多 Agent，那就能同時做好多個專案——產能直接乘十甚至百倍。
因此，Agent 現在的技術發展都是往哪裡發展，你有沒有意識到了呢？
Background Agent？Multi-agent？是的，這些技術全部都是在迎接「行為驅動開發 (BDD)」的到來。
你知道還有誰相信 BDD 是 Vibe Coding 的典範嗎？
《持續交付》的作者：DevOps 教父 Dave Farley！
Dave Farley 與我們有不謀而合的想法，他說：
「未來的軟體開發，必須建構在一種能描述需求的語言上——而 BDD 正是這樣的方法。」
當然，其實就算不仰賴權威人士的喊話，我也毫不懷疑 BDD 這個方向是正確的。
再說一次，在 AI 的時代下，哪個方法能說出一口充分且精準的需求，誰就是王者，我已經想了好幾千次這句話有沒有錯，但目前為止，這句話聽起來正確無誤。
AI x BDD 方法對你的意義？ 熱愛軟工的你不用再擔心被取代了，你一定會得到千倍的重視。
首先，如果你問我說現在 AI 技術是否已經夠成熟了嗎？真的能夠做到高度自動化開發嗎？
我會和你說：「對，AI 技術已經夠成熟了，只要你方法對就能做到 80% 自動化開發。」但是只要你熱愛軟工，你就不用太害怕這項知識，這項知識反而會綻放你的價值。
畢竟行為驅動開發 (BDD) 本來就是「軟體工程的方法」，BDD 的勝利就象徵著，果然，還是得靠可靠的軟工方法才能可靠地 Vibe Coding 嘛！果然！一般那種過度靠「溝通黑魔法」在做 Vibe Coding 的做法既不可靠也無法複製。
BDD 勝利就是咱軟體工程師的勝利。
換句話說，那就是：「軟體工程師的價值並不會被消滅掉，只是左移到需求分析的那端」。
軟工的關注點被左移到更接近需求的核心，以後軟體工程師可能會更像是「架構師、分析師」，負責制定大方向的工程方向，並透過 BDD 訂定極其清楚明確的需求驗收規格，讓 AI 做足 80% 程式碼的開發，人為介入補足一些優化細節。
如果你和我一樣，熱愛軟體工程、堅信軟體工程方法的價值，那麼你一定要立刻與我們一起泡在研究中，從中綻放自己身為軟體工程師的靈魂，在這個 AI 亂世下撥亂反正。
閒聊
為什麼到目前為止都沒有太多人推廣 AI x BDD ？
我對了身邊的朋友做了非常大量的認知研究，去探索各位軟體工程師的認知邊界，我發現，大家是真的不怎麼相信有一套方法能夠訂定足夠可靠的需求，來讓 AI 獨立且高度自動化開發。
為什麼？其實——
原因說複雜也不算複雜，有四者：
- 軟體產業組織過度分工之下，大多數軟體工程師並不認同自己應該要與業務人員坐在一塊，大多數人對「需求導向」的實踐沒什麼興趣，覺得開 Scrum 會議又煩又沒效率只想成天埋頭寫 Code。
- 軟體工程師們太希望能從寫 code 的過程中找娛樂，因此在做 AI 研究的時候都不小心把自己放進了「過程中」：就我在 2025 年 3~6月這段期間的觀察，99% 的軟體工程師都把「自己」給放進去「 AI 的開發協作工作流」中了。大家都在追求「與 AI 高效率的協作方式」，但卻忘記了一個關鍵：「如果你不敢讓 AI 取代你自己，你就不可能找到最高效率的 AI Agent 開發方法，那麼如果你真的找到了一種高效率的方式讓 AI 取代你，那你就一定沒什麼寫 Code 的娛樂可言。」
- BDD 這個方法本來就很小眾，只有長年關注「需求導向」軟工實踐 (TDD, ATDD, DDD, CA, ...）的人才會不小心發現 BDD 這個方法論的存在。
- 就算你知道 BDD 好了，你也一定不怎麼熟悉 BDD 的技術工具，好比：Cucumber。就算你用過 Cucumber 也很難堅持使用他，更不容易待過熟悉且導入 Cucumber 的公司，因為 Cucumber 真的是不太好寫，如果不是靠 AI 我完全不想要自己寫他。
以上四者，somehow ——就讓行為驅動開發 (BDD) 這項寶藏成為了軟體工程師的藍海。
為什麼水球對 AI x BDD 這個方法這麼有自信？
水球不是整天坐在閣樓研發知識的人，我是經營一間軟體技術公司的技術創業者，我自己授課的線上課程平台，就是靠尚可的軟工實踐帶領團隊開發出來的，所以我同時兼具創業者和軟體工程師兩者的視角，並且每個月都在實踐前沿軟工學問於組織內部。
- 我過往一年都在團隊各處都實踐 BDD，當時 AI Agent 還沒有崛起，可是 BDD 其「訂定需求以及凝聚需求共識」的方式就已經對團隊凝聚力有極高度的幫助。在數十個專案下，我都是經由 BDD 的需求訂定流程快狠準帶領團隊交付 Sprint Goal。
- 然後 BDD 的其中一環：「驗收測試驅動開發 (ATDD)」對後端程式的可靠性又有數倍的加成，公司後端人員嚴格遵循 ATDD 寫出的程式幾乎沒什麼 hot-fix，整個很可靠。
雖然自己的組織不算大，但不管是什麼樣的團隊，我發現都能靠 BDD 率領得挺不錯。無論團隊裡是一排 Junior，還是 Senior / Junior 混合，還是一排雜牌軍，我都能用 BDD 帶得挺好的，讓每個工單都能可靠交付。
因此，水球我的想法真的很簡單，全是經驗談。既然 BDD 能讓一群「有情緒的人類」都能精準交付，那肯定就更能讓「完全不帶情緒」的 AI 精準交付每一道功能。
當然，職位可能會變得比較少，這也沒辦法，但至少你就喝了這碗雞湯吧。
軟體工程師的一切並不會被全然沒收，至少，留下了 BDD 這個方法。
那我們就，勇敢地一起轉型吧，不要再當工程師螺絲釘了，接下來我們要當需求工程專家。
如果想要在六個小時內立刻掌握 AI x BDD，該怎麼做？
要在六個小時內掌握 AI x BDD 全自動化開發的做法，只靠自己摸石頭前進是不可能的。
就算讀完了《BDD in Action》這本書，就算對於 BDD 的各個工程環節都有所掌握，也仍距離 AI 全自動化開發有一大距離。
如果真的想要讓 AI 能夠依照 BDD 的指示，精準且可靠地把每一步驟做好，有太多的細節需要留意：
- 該怎麼做實例化需求，寫到什麼程度才能保證 AI 看得懂？
- 看懂實例之後？用什麼測試架構，才能保證 AI 產出絕對與需求一致的測試？
- 測試架構的設計如何釋放 AI 的效率？AI Agent 把測試寫得越來越肥，效率越來越差了，該怎麼辦！
- 實例化需求的重用該怎麼做？規格上做「情境重用」，可是技術上該如何讓 AI 也懂得「情境重用」？
- AI 寫完 given / when / then 之後要做什麼？如何讓 AI 自己寫 code、自己試錯、自己修正，做到獨立作業？
- 就算 AI 已經能做到 BDD 獨立開發了，到底又要怎麼樣讓他不眠不休地連續工作好幾十個小時？做到「全自動化開發」？
這些全部都是智慧的結晶啊！每一個環節都需要花費超級大量時間研究，才能找出正確的方法。如果你不想花費半年時間來研究的話，那就直接上課吧！
《AI 時代的 1% 工程師：用「行為驅動開發 (BDD)」 實現百倍效率的 Vibe Coding 》是水球老師精心製作的一日工作坊課程，現正熱賣中。
如果要想要用 6 小時工作坊的時間，立刻速成學會如何用 BDD 來讓 AI 全自動化開發？那就上課吧！
實體場：https://www.accupass.com/event/2506110435103759406480
線上場：https://www.accupass.com/event/2506160524377577825710