01外包踩坑
「我那時候花了台幣 5 萬，我印象很深刻。結果呢，就是對方做得很糟糕。」
想加功能只能用講的，「人家可能也比較忙，他可能沒有辦法這麼 real-time 的去給你做更改或是反饋」。
關於 Mike
Mike 是執業醫師，經營金蘋果美學診所 診所網站曾外包花費台幣 5 萬，「結果對方做得很糟糕」 他決定自己研究——後來「我的網站可能會是我同行中真的是做得非常好的」
醫師
本業看診，非工程背景
1→5
開了網站公司，工程師拓展到五個人
2
門課雙修：軟設＋AI x BDD
10
個視窗並行狂跑 BDD
「網站對我們這種美業來說是非常重要，因為它是你需要去投廣告，你需要去找 SEO，你需要給人家一個很好的 layout。」 「這種核心技術我實在不太想掌握在別人身上。我就想要自己去研究。」 研究出成果後，他開了一家公司，在看診以外的時間幫別人做網站，一路做到完整的前後端系統。
見證訪談
Mike金蘋果美學 創辦人醫師
×
水球潘水球軟體學院執行長
這場訪談從「老闆怎麼會來學這堂課」問起：外包踩坑、vibe coding 的臨界值、兩門課怎麼搭配，到把開發變成看診時也能跑的長任務。
訪談主題與時間點
0:00開場：Mike 是一間診所的老闆
0:10從很沒有章法的 vibe coding，到認識 BDD
1:16「漸漸脫離 vibe coding 的身份」——最大的身份改變
2:35外包網站花 5 萬的教訓，決定自己研究
3:46複雜度過了 threshold，vibe coding 突然變得很痛苦
4:30學以致用：團隊對 spec 要有一個共識
5:38最喜歡的部分：發想，與落實成 Gherkin
6:54開十個視窗狂跑 BDD 五六個小時，同時看診
7:40客製自己的前端流程：軟設的 UML 與 class diagram
9:55UI 測試兩關卡：Playwright 與 Chrome DevTools MCP
11:15推薦企業的三線測試：本地 Docker → Vercel → 遠端 sandbox
11:57解放時間的原理：需求要說清楚
13:46推薦什麼樣的人來上這門課
上課前，Mike 遇到了哪些問題
「就是很亂」——沒有章法的 vibe coding，撐得過小專案，撐不過臨界值。
02沒有章法
「常常就是你改了 A 卻 B 卻出問題，非常非常地混亂。」
自學寫 code 很有興趣，但「很沒有章法，像是 vibe coding 這種，就是很亂」。
03牽一髮動全身
「框架變得很大時候，改一個簡單的功能，卻牽一髮動全身。」
「令我很苦惱這樣子。」
04複雜度臨界值
「只要過了一個 threshold，vibe coding 突然就是一個很痛苦的事情。」
「如果不大複雜的，vibe coding 會很像神。」但做完整的前後端、框架很大的時候，就突然變得很痛苦。
一開始聽課，他以為是「程式版的心靈雞湯」
「很像在聽某種玄學」
「前面怎麼好像都不是在講跟 coding 有關的 professional 的東西，好像都在講一些很業務邏輯的東西。」
聽了四五堂課之後
「才發現就是，是自己太笨、太廢，才覺得這是一個心靈雞湯。」
全面提升
「它的這個整個框架的完整度、穩定性，還有可擴充性，我都覺得是一個很大的程度的全面提升。」
學完之後，他現在怎麼開發
AI x BDD
把 spec 寫好，讓 AI 狂跑五六個小時
「我最驚人是有時候，是把 spec 寫好之後，可能寫了很多 spec，然後呢，我可能一次開十個視窗，比如說 Claude Code 或是最近的 Agent，Codex Agent，直接開十個視窗，然後狂跑 BDD。」
發想＋寫好 spec（Gherkin）
十個視窗並行狂跑 BDD
兩關卡驗證 UI 測試
10
個視窗並行。Claude Code、Codex Agent 同時開，各自照 spec 狂跑 BDD。
5～6 小時
長任務自動執行。「這五六個小時我就在這邊看診。然後呢我看完診以後，AI 也做好了，然後我確實做品質是非常好。」
3
線測試才上 production：本地 Docker 測試過 → Vercel 測試也過 → 遠端 sandbox 正式環境測試也過。
UI 測試的兩道關卡
「以前在 vibe coding 的時代，你就只能點開把 localhost:3000 打開，人用肉眼看。我覺得這個很煩，老實說很煩。」
第一關｜不開瀏覽器
「單純就是不需要打開瀏覽器的 Playwright 的 testing。」
第二關｜真的打開狂點
「最完整版的就是它真的會直接用 Chrome DevTools MCP 這個整個直接打開，然後呢，直接自己在上面點，狂點。」
上游一樣是 Gherkin 的測試計畫奠基——「有這個工具以後，AI 可以狂看。」
「看完診以後，AI 也做好了，品質是非常好。」
兩門課怎麼搭配
AI x BDD｜穩定性
「BDD 它就是大幅提升你 vibe coding 的穩定性。」
「我覺得 AI x BDD 是可以讓你按照 spec 把它完成。」它可以很清楚地跟你說現在錯在哪、怎麼解決，然後一直一直往下走——這是長任務跑得動的原因。
軟設｜可擴充性
「軟體設計那個是大幅提升你的可擴充性，因為它就是讓你一直很適當去解耦它。」
「我後來客製的這個前端的 BDD 其實參用了很多軟設的東西，尤其是前面那個 UML 的這個部分。」把 class diagram 搭配 Gherkin 文字一起餵給 AI，「它可以更知道這個父子繼承的關係，還有前後依賴的關係」。
發想｜AI 給你沒想過的點子
「AI 它相對來說它知識庫很大，在 discovery 的過程中，其實 AI 很容易可以給你很多你完全沒有想過的點子。」
「人你再怎麼聰明，其實你想到的東西其實是很局限的。」發想之後，再把它落實成 Gherkin 這種有標準的表達方式，「而不是那種隨便亂講」。
團隊溝通｜對 spec 有共識
「大家對 spec 要有一個共識，不然很容易就是你做你的我做我的。」
工程師拓展到五個人之後，每個人習慣的 testing 方式都有落差。「我就很喜歡用這門課提供給我們的這個 AI x BDD 的這個 kit」——這是溝通上給他最大的幫助。
長任務執行的大前提
「不論是哪一種方法，它必須都要有一個大前提，而且我就覺得前提應該是亙古不變的，就是你的需求要說清楚。」
聘人來做，很貴；丟給其他工具做，出錯率比人高，而且「只要中間有一點問題，它們中間幾乎會停下來」，你也看不到整個錯誤的大局觀。「AI x BDD 是它可以很清楚的跟你說你現在錯在哪，然後呢怎麼去解決這個錯誤，然後呢它可以很一直一直的往下走。」
Mike 推薦誰來上
喜歡 vibe coding、想更進一步的人
「與其你去上什麼某種 JavaScript 的那種語法課，我倒覺得你真的可以直接先來上這個 AI x BDD。讓那些枯燥的語法讓 AI 可以幫你處理」——「你會從 vibe coding 直接跨到下一個某個階段去。」
工程師
「首先工程師我當然是非常推薦啦。」在課堂上，水球對 Mike 的評價是：「我每次聽你發問我都覺得說，哇你問的問題其實都還蠻有工程師水準的。」
常接觸工程師的 PM
「你可以讓工程師更知道你在做什麼，而且甚至在你做的這個 prototype 上面繼續往上做。」以前用嘴砲用講的，工程師不知道你在講什麼；現在可以用比較有效率的方式直接把它做出來。
「他真的不需要什麼我大學一定要念什麼資工系，我覺得不用。」——但如果只是拿 vibe coding 解決日常生活中的小問題，「那我覺得不一定要上這麼完整的框架課」。