事先揭露
偶正在參加寫心得賺 prompt 的活動，這是屬於【一日工作坊】AI x BDD 軟體全自動化開發方法的課後分享，但主要還是回顧自己一路以來的 AI 融入生活的軌跡。同時，水球軟體學院 也在舉辦著相關的讀書會活動。
從抗拒到接受：我的 AI 輔助開發之路
心態轉變與早期探索
以我個人來說，雖然 ChatGPT 已經發展了這麼久，但一直到最近一年才真的很認真在用這類工具輔助自己的開發工作。心態上的轉變其實很有趣——從一開始會擔憂自己的資料會不會被拿去額外挪用，到後來完全不管了，什麼鬼都往裡面塞，其實轉變過程沒有很久。特別是當你發現周遭朋友圈都對這類工具有蠻大的信任感之後，想想我們開發的東西其實沒有什麼機密可言。大部分都是一些例行性的事物，或是所謂的 CRUD，畢竟我也不是在需要高度保護機密資訊的產業。做的工作就跟一般以軟體作為服務載體的各行各業工作者一樣，對我們這類寫程式的工作者來說，要上手這樣的工具並沒有任何技術障礙可以阻擋我們，唯一阻止我們的只有心態上放不開這件事而已。
然而中間有一大段時間，我實在提不起興趣，像是滿多朋友在使用 API 並且精打細算地估算著要使用多少 token 就可以把事情做完，或是開始建立自己的 RAG 做各種嘗試。不管是個人的 side project 還是公司內部的小型專案，我對這類應用其實興趣不大。雖然在這期間也被公司指派過要研究一下相關內容，但那時候就是處於提不起勁的狀態，一直把這邊的發展晾在一邊。但至少還是有跟著大家學習寫一些簡單的提示詞，並且也製造了各種角色來輔助日常的工作。
在這個階段，所謂的 GenAI 生成式 AI 在我的生活中只是多了另一種更聰明的 Google 而已。所以我偶爾會使用 ChatGPT 與 Claude 的 Web Console 問問各種問題，當然也包含工作上會需要的寫程式議題。
智慧型編輯器的突破與實用選擇
在另一個時間線上，不同的朋友們已經開始在嘗試更聰明的 AI editor，但在那個太早期的時間點，Copilot 也不太能吸引我。因為總覺得要等它反應有點慢，特別是還要自己按 tab，有一點沒有耐性。至少以這個時間點做分界，換句話說，在我的朋友圈還沒有人喊出 Cursor 或 Windsurf 之前，我對於使用 AI 來輔助日常工作沒有太大的興趣。後續換了工作，公司也有購買 Copilot，但由於我本來就知道不太合我胃口就沒怎麼用。直到那些真正的智慧型編輯器出現——也就是能夠比較像人類行為去修改程式的編輯器——才開始對用它來寫程式有興趣。
在我們開始使用智慧型編輯器（我們姑且先把 Cursor 與 Windsurf 這一類的東西稱做智慧型編輯器），差不多是 Cursor 與 Windsurf 互相搶食市場、進入白熱化的階段，他們各自有不同的計費模型以及各種獲得免費額度的手段。說要真的很認真用，大概是去年底（2024）才開始。然後 Copilot 又出了 agent mode，就是仿照這些智慧型編輯器去寫程式的模式。
那他們智慧在哪呢？除了給你對話框可以讓你輸入需求之外，它會幫你開新的檔案、建立專案需要的各種資源，並且還可以幫你跑程式。跑壞了的話，它會幫你看 log message，並且從 log message 內找得到的資訊嘗試著修復程式的問題。以那個時候的標準，這樣就足夠稱之為有智慧，或是像個人了。
在那個時候，除了在實驗怎麼自動寫程式之外，還會實驗怎麼比較快的自動寫程式。結論很簡單，只要 token input 與 output 速度都很快就行了。所以除了公司購買的 Copilot 之外，我也另外使用了 Cline 再加上 Gemini Flash 2.0 去試作一些日常會使用的程式。
不過有些東西需要經過思考才能夠寫的，單純這樣就不太夠了。雖然可以使用 Copilot agent mode，但是它實在太慢了，慢到使用它的動力都快被磨光了。於是趁著 Cursor 與 Windsurf 搶客大戰的時候入手了 Windsurf，以那時候來說它的開發速度算是可以接受。
關鍵發現：給 AI 一個明確的「句點」
在這時候已經有個稍微粗淺的概念，你要讓東西可以好好的寫完，就要創造出一個可以明確結束的驗收條件，不管是形式上的完成還是實質上的完工。總之，你得給 AI 一個結束的訊號。所以最常寫在對話框內的結尾就是：pytest 能通過才算完工。
所以有了這個初步的概念之後，無論換到什麼樣的工具或轉換新的平台，都開始習慣這樣的思考模式：我可以讓它做很多事情，但是最後要告訴它怎麼去驗收，至少是一個明確毫無疑問的「句點」。
從 Vibe Coding 到 AI x BDD：尋找更系統化的解答
在對這個明確的結束條件有了一些概念之後，網路上某一天開始流行了 vibe coding，雖然我到現在還是對它到底是怎麼回事感到模糊，我就用我的偏誤來總結一下自己的理解：「大家要有迷之自信，相信 AI 替你寫的東西，你只要好好的描述需求，一直教他做人做事的道理，他就會把事情做出來了」。當然這只是我開玩笑的解說，我仍然把它當成一個流行語般的存在，遇見各種業內業外的朋友可以聊天的話題。
在這期間我們換了一個地方使用 GenAI，由原本的網頁介面換到了編輯器裡面，當然過去使用的提示詞技巧還是可以用，但又多了新的技法可以學。先不管那個 MCP 額外的延伸幫助你什麼，但大家開始注意使用智慧型編輯器工作產出的品質到底好不好？
讓我偶爾會在社群平台上發牢騷：又被智慧型編輯器浪費了一整天的時間。很顯然的，這是產出不如預期啊。使用 GenAI 開發產出的字數是很多，但不見得最後你都想留下，甚至你想要卯起來一字一句地去修它。這樣好像反而花了更多的時間，不然就像碰運氣一樣，總之叫他先生一下、先看看他的想法是什麼，大致上會對個七七八八，看完了一次別人的想法，只好擦掉自己重寫一次更精煉的版本。
在這個時期，除了時間被浪費掉的痛苦之外，偶爾還會有小確幸——它會產生出真的是自己想要的方向，這就好像兩個默契不太好的朋友，有時它會猜對你心中的想法、做出你預期的回應，有時又天差地遠。
學會結構化協作的技巧
但這個時候我們至少學會了一項實用的技巧，除了要使用 TaskMaster 之類的工具切割你那個遠大的目標之外，你也可以土砲 memory 的功能，叫它先把計畫寫成 TODOs 放在文件上，並且跟它說每做完一個進度就在 check list 上面打勾。
進展到這裡，大部分的人都知道需要把想要做的事情稍微做點計畫，不管是你個人提供計畫的內容，或是你只提供大綱叫 AI 提供計畫內容，都會比原本的簡單對話好上很多，你也比較有機會把事情做好。
但是要把每一個 action item 給訂一個明確的驗收條件，又是個相當大的難度。所以大部分的人寫的計畫都只是要求 AI 要做什麼事情，並沒有告訴它什麼樣才是做好。並且以自然語言來描述有沒有做好是非常困難的，但是我們有著開發者的優勢，如果你可以給它一個簡單的 script 讓它檢查有沒有做好，那就太方便了。
遇見 BDD：從廣告到深入理解
經過了一段時間的掙扎，最後遇上了讀書會的廣告。雖然廣告的宣傳術語總是誇大的，這件事我們先忽略它，但是其中有吸引我的關鍵字，那就是 BDD — Behavior Driven Development。
先勸大家不需要在 TDD 或者是 BDD 之間直接選邊站，你過去所有的開發經驗都是有價值的，你只要選擇你最舒適的方式就好了。
我們先以粗淺的外觀來說，BDD 嘛，開 Cucumber 寫 feature file 啊，把東西寫得很口語來描述我們的期望。
但這樣有什麼特別的呢？在試過了讀書會的初始專案後，開始覺得想得太粗淺了。開始回想起在前面說的智慧型編輯器讓 AI 可以像人一樣寫程式，這只是表層的描述。我們是做了小程式，我們執行這個程式，程式的運作不如預期，並且有 error，我們開始看 log message 再試著回頭改改程式，反覆的循環把它改對為止。
身為一個專業的開發者，我竟然從來沒想過要把這個人類的行為定義得再更細緻一點。舉例來說，蠻多人都讀過《重構》這本書，我們知道要重構程式的時候要經歷綠燈、紅燈、重構的循環，並且在每一步你可以做的事情是有規範的。依照這樣規範呆呆地把事情做完雖然無聊，但你會把東西做對。只是這麼無聊的節奏，大部分的人類是受不了的，所以脫離了初學之後你就會開始試著省略各種東西，除非你是對「特定的形式能夠反映在品質」這件事情上非常有執著，你才會如同剛學會的那一陣子一樣工作。
而在讀書會的初始專案裡面就把這件事情徹底的實踐了，它規範了智慧型編輯器的 AI 該如何運作，它有它的行為準則。
讀書會的收穫：系統化的 AI 協作方式
再來回應到我們先前提的「給工作定一個明確的結束條件」，再加上「替你的工作切割成適當的大小」，並且有一個完整的 TODOs，是與智慧型編輯器互動的良好方向。
在讀書會內，這些東西將被轉換成 Feature file。特別是在行為準則上要求實作的時候會一次只能實作一個情境的範圍，並且要依照 green-red-refactor 循環的節奏把事情做對。相信有唸過相似書本的同業，不管是《重構》還是《GOOS》，你腦中已經冒出了 ATDD 與 TDD 的大循環與小循環了（笑）。
透過這樣基本的設定，我們就能夠把事情做得比以前好上許多。如果你又有更多的專業知識，你還可以替 AI 提供更多的行為準則指引或是 domain know-how，特別是 domain model 的描述。在範例專案中給了我們一些簡單的圖片，提供核心模型的類別圖還有資料儲存的 ERD。這個東西它不一定要給，但是你給了能夠提升做事的品質。
但它不影響我們把事情完成，因為基本上我們有了加強版的 TODOs 以及更細緻的驗收條件。
單純以讀書會的初始專案，完全不包含工作坊的付費內容，就已經在我自己的工作上或是工作之外的 side project 都有著顯著的實作滿意度的提升。
如果以這個狀態為起點來看，工作坊就是展現一個現階段值得努力的最終型態。當然這個終點的標準會隨著時間一直往後拉長，至少在這個時間點我們先鎖定這個目標：用更少的力氣來做到更多的事情，並且事情做得更加精緻完美，我相信是可以期待的。
以我個人來看，使用智慧型編輯器來輔助開發主要著重在：任務切割到適中的大小讓進度可以掌握，並且每一個進度都有精確的驗收條件，而我們也告知 AI 應該有的行為準則，讓它能夠依我們的期望好好的做事，寫出符合我們內規的成品。當然你可以貢獻 domain knowledge 作為它的參考附件來提升實作的品質。
以上面這三個向度來說，如果讀書會的內容是一個 lo-fi 的 wireframe，那工作坊的內容就是 hi-fi 設計成果。如果你能夠達到 pixel perfect 一比一的復刻，那你就是真的非常善用智慧型編輯器的開發者。
課程推薦與問答
📌 課程中最震撼、最突破認知的部分？
儘管之前有想過要針對各種情境寫專用的 Prompt，但沒想到真的有人會將每一個可以拆分的情境都準備專屬的提示詞。看到講師用 BDD 的 Gherkin 語法，替個別的 Given、When、Then 都準備專屬的提示詞時，我才認知到原來真有人會這麼細緻地去思考和準備。
這樣的做法本質上是在做消歧義與 Context 切割的前置工作，既能提升平行處理效率，又能降低 Token 消耗。對我來說是個很大的啟發 — 原來 Prompt 工程可以做到這種程度的精細化。
📌 最欣賞講師教學的哪個地方？
講師有著一套自己的脈絡與對細節的執著。感受得到如果知識有邊界的話，他肯定已經用 BFS 與 DFS 在這個領域裡逛了好幾圈，才回來把這些經驗傳授給我們。
每一個細節都能感受到他對於知識的熱情與執著。不是那種表面功夫，而是真的把每個概念都消化透徹，然後用自己的方式重新組織和表達。這樣的態度挺讓人佩服的。
📌 為什麼這門課值得一上？你會推薦給哪一種工程師？
我會推薦給在自己專業領域已經有一定實戰經驗，技能熟練度足夠，能不依賴 AI 就獨立實作的工程師。這倒不是 Junior 或 Senior 的分別，而是你在自己的領域中要有足夠的熟悉度，不會再被基礎語法或寫作慣例卡住。
只有在你已經有穩健地基的前提下，才能有餘裕在上面堆疊 AI 與 BDD 的知識。這樣你才不會被基礎問題分散注意力，可以專心思考如何讓 AI 成為你在這個領域中更上一層樓的工具。