
前一篇我們完成了三次的功能迭代開發,同時也明確的留下一個 Bug,也就是 index 的刪除 Bug。
所以今天我們要來聊聊 Vibe Coding 的 Debug 流程,從發現 Bug 到該怎麼引導 AI 修復,最後再驗收回歸 commit 出去。
當然,你可能會認為現代 AI 都這麼聰明了,哪有可能會遇到呢?
其實你錯了,不管 AI 有多聰明、多厲害,只要你不驗收、不去理解,那就會遇到這個狀況。
在開始之前,我想請你先去安裝一個 Chrome 擴充套件,叫做 Claude in Chrome。
為什麼需要這個套件呢?簡單來講...
讓 Claude Code 可以直接操作你的瀏覽器,讓他自己去 Debug,而不是你自己去描述給它聽。
搭配這個套件之後,你甚至可以叫 Claude Code 幫你去撈取 GMail 的信件、幫你去抓取網頁上的資料,甚至是幫你去操作你的專案,這些都是 Claude Code 可以做到的事情。
安裝完畢之後,我們繼續往下吧。
這邊要先聊一下,我自己開發上遇到最常見的 Bug 回報方式,通常會是這樣:
接收到這些資訊之後,身為工程師的我通常腦袋會快速這樣閃過這幾個念頭:
接著我自己實際操作卻又正常,只好從 Code 那邊找出可能的蛛絲馬跡,接著也找不出所以然又只能跟回報的使用者說:「我這邊測試沒問題,你可以再試試看~」然後就這樣來回了好幾次。
其實這個案例套用到 AI 也是一樣的道理,因為 AI 也需要你提供足夠的資訊,才能夠幫你修復問題,你不給他足夠的資訊,他只好跟人類工程師一樣瘋狂腦補可能的錯誤、瘋狂讀取程式碼(大量消耗 Token),然後你就會開始抱怨 AI 很笨、很慢,但其實本質上是「你根本沒有把問題描述清楚」。

它根本無法理解你操作了什麼、流程是怎樣、你看到的是什麼以及你預期是怎樣,那它盲猜硬改,然後你就反覆花很多時間驗證。
那這樣你跟玩踩地雷有什麼差別呢?
所以接著我將會給你一套公式、一套流程,讓你可以精準的跟 AI 說明以及驗證,讓你可以快速的修復 Bug。
這邊我將 Debug 這個行為定義成了三大步驟,分別是:
就這樣而已嗎?不,你也要盡可能要去附上圖片/操作影片。
Note
現在 AI 也可以直接讀取圖片,搭配文字描述,它可以更精準的理解你遇到的問題。

了解這除錯三劍客之後,接著把它套進昨天留下的那個刪除 Bug:
刪除功能有 bug,重現步驟如下:
1. 在空資料狀態,先新增昨天的午餐 120 元,分類是飲食
2. 再新增今天的飲料 60 元,分類是飲食
3. 清單顯示是新到舊排序:
- 今天的飲料
- 昨天的午餐
4. 我點了「午餐」那筆打開編輯表單,接著我直接按下刪除、再按確認
預期結果:午餐那筆消失
實際結果:午餐還在,消失的是「飲料」那筆
這個過程我沒有看到任何錯誤訊息,請你分析之後告訴我你認為的原因。
裡面其實有一個流程我是刻意不寫的,也就是「打開編輯表單」之後看到的資訊,這其實是在模擬使用者在提供資訊時,依然很容易遺漏的問題,如果你有認真看,你會發現畫面上實際帶入的資料是「飲料」的資料,而非午餐。
Note
這邊一樣建議使用 Plan Mode 模式,讓 AI 好好的分析找出問題。

很有趣吧?我連除錯都開 Plan Mode 下去跑,是不是經過前面的功能開發你會誤以為 Plan Mode 只能用於功能開發呢?其實不全然,Plan Mode 也可以用於除錯,因為它可以幫你分析問題,並且給你一個修復的建議方向,讓你更站得住腳。
看完沒問題的話,一樣按下 「Yes, and use auto mode」 就可以讓 AI 開始幫你修正問題了。
另外你有沒有注意到這份診斷書裡面它有提到「這是刻意留下這個 bug」?這就是 Day 10 我們要它把計畫存進 docs/plans/ 的回報,因為昨天那一輪的計畫就躺在 docs/plans/03-修改刪除.md 裡面,它自己翻得到當初是怎麼決定的,你不用重講一次。
如果你發現它沒有主動去翻,你也可以直接跟它說「請你先讀 docs/plans/03-修改刪除.md」,但把先前做的某些事情給記錄下來,遠比你再去解釋一次要來得快。
講來講去其實就是想要讓你養成一些習慣,也就是問題描述清楚,讓 AI 可以理解你遇到的問題,不論是對人類工程師還是 AI 來說,都是一樣的道理,而剛好這個過程也是同時驗證了一件事情:
儘管你已經驗收過了,但不代表沒 Bug,只是剛好驗收情境沒有 Bug 而已。
所以很多工程師會希望你多提供一點資訊就是這樣,也不要再怪工程師 debug 很慢啦~
畢竟你根本沒把問題描述清楚他們又該怎麼快呢?
很多時候我們遇到 Bug 但也不會出現在畫面上,那這個時候該怎麼辦呢?
這邊就要先搞清楚開發情境了,畢竟不同的開發情境有不同的解決方式,以我們練習製作的記帳 App 來講,是一個 Web App,所以我們就可以打開瀏覽器的開發者工具,去看 Console 的錯誤訊息,通常這些訊息會告訴你有哪些問題,打開方式也很簡單:
F12
Cmd + Option + I
接著只需要切換到「Console(主控台)」分頁,就可以看到錯誤訊息了。
處理方式也很簡單,直接全部複製貼上給 AI 就對了,不要自己翻譯摘要、自己亂解釋,因為你覺得不重要的部分常常才是關鍵,直接給 AI 幫你處理最快。

Note
上面擷圖有些地方是屬於擴充套件的錯誤,因此如果發現 console 有很多紅字,不妨先把擴充套件關掉再測試一次(或無痕模式),這樣可以避免誤判。
接下來聊聊第二種,也就是比較難用文字描述的類型(畫面歪掉、顏色跑掉、文字大小不一等)這種會建議你直接截圖拖進去到 AI 的輸入框,然後一樣套用 Debug 流程,這樣就可以省下很多文字描述的時間。
當然,如果你能夠描述清楚還是最好的。
不管怎樣,AI 跟你說它修好了、沒問題了或者改好了,這些都不代表你沒事了,而是準備「換人接手」而已,因為你才是這個專案的主人。
驗收的時候一樣把剛剛的重現步驟拿出來,自己親手再走一次:
刪除功能有 bug,重現步驟如下:
1. 在空資料狀態,先新增昨天的午餐 120 元,分類是飲食
2. 再新增今天的飲料 60 元,分類是飲食
3. 清單顯示是新到舊排序:
- 今天的飲料
- 昨天的午餐
4. 我點了「午餐」那筆打開編輯表單,接著我直接按下刪除、再按確認
這次的預期結果:編輯表單帶出來的是午餐的 120 元,刪除後午餐消失、飲料還在。
依照你當初回報給 AI 的操作流程再檢查一次,畢竟你總要知道它有沒有把你剛剛給的 Bug 修好吧?而不是 AI 跟你說它修好了你就當作結束。
除此之外,你也要檢查舊功能有沒有壞掉,因為你剛剛改的地方可能會影響到其他地方,所以這個時候就要把舊功能也檢查一遍,確保它們還是正常的。
記住幾個鐵則:
以上都沒有問題這才叫做「修好」,接著這邊你就可以跟 AI 說:
我已經驗收過了,原本的 bug 消失、舊功能沒壞、已知的 TODO 都消失了,請幫我 commit。
到這邊為止,你已經完整走過一輪 Vibe Coding 的 Debug 流程了,這套流程不管是對人類工程師還是 AI 都是一樣的道理。
接下來來分享一下比較沒人講的情境,也就是「來回好幾次 AI 總是修不好」的情境。
在這個情境下我們不可能不做事,而是要先想好幾條退路,這邊我提供三條退路給你參考:
這三條退路都是在跟你講一件事情:
AI 修正 Bug/開發功能不是百發百中,設計好退路的人才走得遠。
因此這邊一整個收斂起來流程就像這樣:

聊到這邊,相信你對於除錯的過程應該有一定掌握了,所以就最後總結一下吧。
在 Vibe Coding 的時候,遇到問題不要怕,遵守以下流程:
明天來點開心的:讓數字自己說話,幫 App 加上統計頁跟圓餅圖。
希望這一篇有讓你修 bug 不再像抽獎哩~我們明天 Day 13 見囉~