Day 13

今天開始進入實作，但問題來了：我可以跟 AI 說「我想要一個 Telegram bot 可以幫我海巡 Threads，以及自動發文的功能」，然後剩下全權交給 AI。平心而論，這樣其實沒什麼問題，Vibe Coding 本來就該平易近人，讓沒有工程經驗的人也能馬上體驗到做出一個產品的感覺。

不過根據經驗，沒意外的話就要出意外了。隨著功能越加越多，常常會出現「改 A 壞 B」或是「解 bug 一直繞圈圈出不來」的問題。

舉個實際例子：假設你請 AI 寫一個發文功能，它正常運作了。隔天你又請 AI 加上「hashtag 過濾」功能，結果 AI 在處理 hashtag 時改動了文字處理邏輯，導致原本的 emoji 突然消失了。你跟 AI 說「emoji 不見了」，AI 修好了 emoji，卻又把 hashtag 弄壞。就這樣來回三、四次，你開始懷疑人生。

如果一開始有一個簡單的測試：「發文時 emoji 必須保留」，那麼當 AI 改壞時，測試會立刻失敗並提醒 AI 修正，根本不會讓錯誤的程式碼被提交。

至於 bug 一直解不掉的問題，網路上可能有看過許多解法，說換一個 model 就可以解決，但長久下來還是會影響開發體驗，不是長久之計。況且，如果需要使用不同的 model，這代表產出其實不是很穩定，需要更多人工介入。如果要實行一人自動化公司，這可謂大忌。

我們都知道，注意力現在已經是非常稀缺的資產。如果 AI 常常出 bug，或是沒有依照你的預期實作，代表你需要花更多的注意力來捕捉錯誤。搞到最後，可能會花比你自己親自動工還要更久的時間，這樣反而本末倒置。

那麼有沒有什麼方法能夠避免這件事情？先說結論：有。

不過在提出解法前，先讓我分享一下軟體新創的流程。通常需求會從高層那邊來，接著就會有 PM、Designer、甚至是 TPM 一起討論功能、流程。接著會開一個 sync 會議，包含相關工程師及 QA 確認需求細節，然後工程師埋頭施工。

偶爾遇到沒定義清楚的東西就去問 PM 確認，但不會每個瑣碎的問題都去問，因為會沒完沒了。所以很可能是依照前朝做法，或是看哪樣比較方便實作，不然就可能自己挖坑擴大 scope。

所以交付時，QA 經常會來問：「這個平台的行為怎麼跟另一個平台不一樣？」最常發生的就是 error handling 沒有被明確定義，所以各自解讀。

然而這並不是誰的問題，因為需求的確認是永無止境的。我們能改善的是盡量在開發前期就把能想到的東西都拿出來討論，這樣是降低開發成本最直接的方式。

如果借鏡這個方式的話，那麼想要解決 Vibe Coding 遇到的問題，我們需要把時間投資在一開始，並且盡可能地把功能「具體化」。這就是前一陣子常見的 SDD 的由來。

所謂具體化是指：在什麼情境下，使用者操作什麼，應該預期要有什麼結果。我們稱之為 BDD（Behavior Driven Development）開發。

例如：使用者在登入頁面，輸入了密碼 123，應該顯示錯誤訊息密碼太短。

再來，為了應對「改 A 壞 B」的問題，避免每次都要重頭檢查一次，工程師傾向寫測試。測試就是用程式來確保另一個程式執行結果始終如一，如果測試沒過，代表有改壞東西，那麼就應該要修復到所有測試通過。

這時有另一個常見的流派提倡：我們應該先寫測試後寫實作，逼迫工程師規劃好應該如何撰寫程式，而不是寫完主程式後發現不好寫測試等等狀況。我們稱之為 TDD（Test Driven Development）。

既然這些東西都已經是老生常談，也是軟體界行之有年的方法論，那豈不是跟 Vibe Coding 堪稱絕配？而且尤其適合沒有任何包袱的新專案。

SDD + BDD + TDD 的方式需要 credit 給 @waterballsa.tw。一開始聽到非常有共鳴，畢竟這把我之前的經驗全部串在一起，一切水到渠成。

明天來講我是如何把 AI + SDD + BDD + TDD 串在一起。

以上單純根據我個人的經驗，歡迎大家分享其他看法。 另外附上前輩 SDD 好文 https://kaochenlong.com/sdd-spec-driven-development