分享最前沿的軟體工程知識及方法，不再窮忙於程式細節，成為 AI 時代下受到企業重用的 Top 1% 開發高手。
BDD（Behavior-Driven Development，行為驅動開發）是已經至今發展已有 20 年的軟體開發流程，甚至可以說是一個方法論。 但水球我認為，BDD 的時代已經來臨了。 BDD 解決了軟體工程一直以來遇到的「溝通問題」，這個溝通問題在軟體企業層出不窮，不管是 PM 對 RD、業務對 PM 還是 QA 對 RD，總之，只要有不同職能合作就會有一堆軟體開發的需求通靈 or 上線後返工的流程問題～。 最後搞得技術人員礙於需求不清楚、礙於不知道「要測什麼」，而導致最後很難「一次到位」地交付業務端或是 PM 端想要的軟體程式碼。 這個方法論已經存在 20 幾年了， 為什麼？分享一個在軟體企業中你八成也遇過的場景。 功能寫完了，測試也過了，上線。然後 PM 跑來說：「欸，這不是我要的。
上篇我們聊到，GitHub 推出的 SpecKit 在規格驅動開發的工具層面做了不少事；但我想問一個問題：工具再好，如果你寫出來的規格本身就是模糊的，那工具能幫你什麼？ 這就像你買了一台頂級的 GPS 導航系統，但你輸入的目的地是「那個好吃的店」。GPS 再強，也沒辦法帶你到對的地方啊。 SpecKit 解決的是「流程自動化」的問題，但它沒有回答一個更根本的問題：你的規格，到底夠不夠精確？ 而這，正是行為驅動開發（BDD）方法論真正在處理的事情。 接下來這篇，水球我要用一個「請假審批系統」的案例，帶你看看 AI 時代軟體開發的三大痛點，以及 BDD 如何從根本上解決它們。 還沒看上篇？ 規格驅動開發（SDD）不夠用？從 SpecKit 的三個瓶頸談 BDD（上） 目錄 1. AI
週五下午，你用 AI 在三十分鐘內生出了一個完整的功能模組。程式碼跑起來了，Demo 也過了，你帶著滿足感關上筆電，準備放假。 週一早上回來，發現有個邊際案例沒覆蓋到。你打開那段程式碼，由於是請 AI 寫的，第一時間還有些看不太懂。你試著請 AI 修，它改了 A 壞了 B，修了 B 又動了 C。 三個小時後，不禁懷疑：「我自己寫，是不是還比較快？」 根據 CodeRabbit 針對 470 個開源 GitHub PR 的分析，AI 協作產出的程式碼平均產生 1.7 倍的問題數量，其中 XSS 等安全漏洞更高達 2.74 倍。
規格驅動開發最重要的就是「情境導向的全自動化開發」。現在，你手上已經有一份完整的 Gherkin Spec，裡面列舉了所有情境的 Given / When / Then。 接下來，難道我們還要自己一個一個去實作測試步驟？然後再自己去寫業務邏輯的程式碼？ 不！在 AI 時代，這些通通不需要了。 這一篇，我要直接帶你動手操作，讓你親眼看到 AI 是如何根據 執行規格全自動完成開發的。 不講理論了，直接上手吧！
就是這「可執行規格」，讓行為驅動開發 (BDD) 變成 Vibe Coding 時代下的寵兒！如果一份「需求規格」可以作為測試被執行，那只要我們訂好規格，就能命令 AI 開發出完全符合規格的程式碼，你不再需要花一堆時間擔心 AI 寫錯 Code，因為全部都被「可執行規格」這份「測試」給保護了。
你如果寫得出所有情境，AI 就能全自動化地開發出整個系統。 實例化需求絕對會是 Vibe Coding 的典範，因為如果你不列舉「實例」來定義「需求」，那 AI 根本不可能搞懂你的意思。此篇文會用電商的例子來讓你明白實例化需求有多麽重要！
這篇文會描述 BDD 的三大環節，以及為什麼每位軟體工程師只要開始學習 AI x BDD 的方法，就能掌握 Vibe Coding 未來的典範，真正活在未來而不是焦慮於現況。
如果不能用一個個的細胞組出一朵花，那為什麼我們又會想要一行一行程式碼地去理解複雜系統的原始碼呢？這篇文提出開放原始碼最系統性的分析及快速理解架構的兩道關鍵思維（意圖 x 問題）。