如果你是還在考慮要不要購買預購課的夥伴，可以參考這篇文的介紹。

這門課不是一般的工具課，卻只跟你收工具課的價格。

你的 AI x BDD 預購課新台幣花得值不值？

這門課是方法論、概念、實戰、技術細節的「超級融會貫通」。

可是——這些東西要怎麼教才能行雲流水，才能讓知識像是音符一樣飛進大家的腦袋中？
我想我不會在第一天就有答案。

我雖然有快 8 年的教學經驗，但面對全台灣各種背景的軟體工程師，大家來自不同產業，有些人寫過自動化測試，有些人沒寫過，有些人是初學者——我沒辦法一開始就知道每個人需要什麼樣的教材。

所以，請容許我用混合式交付的方式，和你們一起完成這門課。

為什麽預購期間我只出直播課？

在預購期間我們採取直播 + 圖文實戰 + Github 實戰教材來做混合交付。

混合式交付的內容只會更多，不會更少，預購學員將擁有底下權利。

預購學員必讀：你的上課方式

課程介紹

課程拆解：規格驅動開發三維大展開

把規格寫清楚，只是個假議題

不釐清規格，AI 開發成效如何？

Discovery → Formulation 魔法實戰

用模型思維釐清完規格了，AI 開發成效又如何？

Gherkin Language 模型教學

【總結】規格驅動開發的前提｜主流工具都做不到

請遵照底下 SOP 進行即可存取 SDD.os 的原始碼

如何存取 SDD.os 原始碼？

【回饋問卷】AI x BDD：規格驅動全自動開發術

規格驅動開發的前提

60% 自動化：AI 協作式開發的低效率

第二章內容介紹 (Intro)

第二章：共學回放影片列表

課程在預購期間（也就是完整出完課程影片之前）每週二晚上八點，會透過 Zoom （會將 Zoom 報名連結放在 水球軟體學院的 VVIP LINE 社群中）舉行線上的共學活動。

此文件放置所有共學影片的連結。

第二章：共學回放影片列表

各位*規格驅動全自動開發術*的魔法初學者們好！

在第一章，我們建立了規格驅動開發的前提：**規格要能夠精準翻譯成測試程式**，然後把測試程式透過自動化測試工具作為 AI 的自動審查機制，讓 AI 能夠自行修 code、自行 debug，直到所有測試通過為止。

但這只是開頭而已。

當你開始寫規格時，你會發現一個更深層的問題：**如何讓不同角色的人看懂同一份規格？**

領域驅動設計：沒有「抽象」就沒法「協作」

這個單元中，我來教你一個很重要的思維。

記得之前說的模型思維吧？只要有模型襯底，釐清規格就是一件簡單的事。

那要從什麼模型下手，我們才能快速把整個翻譯鏈無論是向 Problem Domain 或是 Solution Domain 打通呢？

答案就是：「事件風暴」的流程模型囉！


事件風暴模型：貫穿問題及解法領域 - 規格的共同語言

在上一個單元中，我們建立了 Event Storming 的兩種系統邊界模型：

1. **修改型操作（Command Operation）**
2. **查詢型操作（Query Operation）**

這兩個模型很強大，它們讓業務人員和工程師能在同一個模型上協作。但是啊，這些模型還不是可執行規格，它們還只是圖、討論的結果。

> **Event Storming → Gherkin 的翻譯，就是把「團隊的共同語言」轉化成「機器可執行的測試規格」，這就是規格驅動開發的核心精神。**

那麼問題來了：我們要如何把這個系統邊界模型，翻譯成可執行的 Gherkin Feature Files？

這就是本單元要探討的內容。

用「事件風暴」來定義「Gherkin」的 Given/When/Then

如果你現在跟 AI 說：「請你幫我從這個 DSL-Level 的 Feature File 規格生成測試程式碼」的話，會發生什麼事情？

那當然，**AI 在把 DSL 翻譯成測試程式碼的過程中一定會有腦補的，因為 DSL-Level Gherkin 的語法還是太高階了，無法直接映射到技術的實作上**。

AI 並不會回過頭向你澄清技術問題，它會「自行隨意腦補」技術實作細節，然後給你一個看似合理、但可能完全不符合你系統架構的測試程式碼。

測試程式碼的抽象：DSL-Level Gherkin vs. ISA-Level Gherkin

100% 全自動化開發的脈絡：規格的光譜

70% 自動化：測試驅動開發

第三章：共學回放影片列表

課程在預購期間（也就是完整出完課程影片之前）每週二晚上八點，會透過 Zoom （會將 Zoom 報名連結放在 水球軟體學院的 VVIP LINE 社群中）舉行線上的共學活動。

此文件放置所有共學影片的連結。

第三章：共學回放影片

UT vs. E2E 自動化測試策略

後端規格驅動開發的規格一致性要求


各位規格驅動全自動開發術的魔法初學者們好！

在前面的章節中，我們學會了如何用 Event Storming 建立系統邊界模型，並將它翻譯成 Gherkin 規格。現在你手上已經有了一份完整的 DSL-level Feature File，接下來要做什麼？

**直接把規格丟給 AI，請它一次全部開發出來？**

不，這不是可靠的工程方法。

**如果你不懂開發流程，你就無法有效地切分任務，也就無法駕馭 AI 進行高品質開發。**

這就是為什麼我們要學習 **AI x 測試驅動開發（AI x Test-Driven Development, AI x TDD）**。

TDD 循環基礎概念：先畫靶後射箭

各位規格驅動全自動開發術的魔法初學者們好！

上一個單元學完 TDD 的三步驟（Red-Green-Refactor），現在你知道要先寫測試了。但問題來了：

**你會寫測試嗎？從 Gherkin 規格要怎麼翻譯成測試程式碼？**

這就是本單元要解決的核心問題！水球我會教你如何用**映射思維**（意思就是...照著規則對應翻譯就對了），輕鬆將 Gherkin 語句轉換成高品質的測試程式碼。

在第二章「事件風暴 → Gherkin」的翻譯中，我們已經完成了從事件風暴部位（Aggregate、Command、Query、Event）到 Gherkin 語句的精準映射。

那麼，在「Gherkin → 測試程式碼」這一步，咱們就能直接從 Gherkin 識別事件風暴部位，然後一步到位翻譯成測試程式碼。


從 Gherkin 到測試程式碼：事件風暴部位的直接翻譯

大家好，接下來的這個單元啊，就要手把手帶各位來實戰練功了！
練什麼功？

那當然就是我們要來學習，如何與 AI 協作，來做到「超快速」的 AI x 測試驅動開發了。

在前幾個單元中，我們都還只是學習「測試驅動開發」的開發流程以及指導，讓你了解測試程式碼怎麼寫，TDD 三步驟循環怎麼做，最小增量開發是什麼感覺。


AI x TDD：4 大 Prompts 手把手實戰篇

80% 自動化：行為驅動開發

用 AI x BDD 開發一個  MVP 全端應用程式（畫面隨意）

AI x BDD (UT 層級）- 實戰演練篇 (1/2)

Al x BDD (UT 層級) - 實戰演練篇(2/2)

AI x BDD (E2E 層級) - 實戰演練篇 (1/3)

AI x BDD (E2E 層級) - 實戰演練篇 (2/3)

AI x BDD (E2E 層級) - 實戰演練篇 (3/3)

透過 BDD-Discovery 來撰寫後端三巨頭規格

API-First 戰法：前端先 Mock、後端走 AI x BDD

Prompt Engineering 的軟實力複利講堂

完整演練：流程 → Gherkin → API-First + AI x BDD (1/3)

完整演練：流程 → Gherkin → API-First + AI x BDD (2/3)

完整演練：流程 → Gherkin → API-First + AI x BDD (3/3)

80% 自動化：行為驅動開發 (BDD)

90% 自動化：指令集架構之可執行規格

用 AI x BDD 開發一個微服務應用程式（畫面隨意）