iT邦幫忙

2026 iThome 鐵人賽

DAY 12
0
Vibe Coding

老闆不會教你的 Vibe Coding 實戰 30 天系列 第 12

老闆不會教你的 Vibe Coding 實戰 30 天|Day 12:畫面壞了怎麼辦?!來聊聊 Debug 流程

  • 分享至 

  • xImage
  •  

https://ithelp.ithome.com.tw/upload/images/20260923/20119486ZEVsoPFsos.png

前言

前一篇我們完成了三次的功能迭代開發,同時也明確的留下一個 Bug,也就是 index 的刪除 Bug。

所以今天我們要來聊聊 Vibe Coding 的 Debug 流程,從發現 Bug 到該怎麼引導 AI 修復,最後再驗收回歸 commit 出去。

當然,你可能會認為現代 AI 都這麼聰明了,哪有可能會遇到呢?

其實你錯了,不管 AI 有多聰明、多厲害,只要你不驗收、不去理解,那就會遇到這個狀況。

暫停一下!

在開始之前,我想請你先去安裝一個 Chrome 擴充套件,叫做 Claude in Chrome

為什麼需要這個套件呢?簡單來講...

讓 Claude Code 可以直接操作你的瀏覽器,讓他自己去 Debug,而不是你自己去描述給它聽。

搭配這個套件之後,你甚至可以叫 Claude Code 幫你去撈取 GMail 的信件、幫你去抓取網頁上的資料,甚至是幫你去操作你的專案,這些都是 Claude Code 可以做到的事情。

安裝完畢之後,我們繼續往下吧。

最爛的 Bug 回報方式

這邊要先聊一下,我自己開發上遇到最常見的 Bug 回報方式,通常會是這樣:

  • 「刪除功能壞了。」
  • 「畫面不會動了。」
  • 「我點了按鈕沒反應。」

接收到這些資訊之後,身為工程師的我通常腦袋會快速這樣閃過這幾個念頭:

  • 是什麼東西刪除壞了?
  • 畫面不會動是指什麼不會動?是指不會更新還是不會跳轉?
  • 按鈕點了沒反應是因為你沒填寫欄位導致不能點還是真的沒反應?

接著我自己實際操作卻又正常,只好從 Code 那邊找出可能的蛛絲馬跡,接著也找不出所以然又只能跟回報的使用者說:「我這邊測試沒問題,你可以再試試看~」然後就這樣來回了好幾次。

其實這個案例套用到 AI 也是一樣的道理,因為 AI 也需要你提供足夠的資訊,才能夠幫你修復問題,你不給他足夠的資訊,他只好跟人類工程師一樣瘋狂腦補可能的錯誤、瘋狂讀取程式碼(大量消耗 Token),然後你就會開始抱怨 AI 很笨、很慢,但其實本質上是「你根本沒有把問題描述清楚」。

https://ithelp.ithome.com.tw/upload/images/20260923/201194866ycP59oTss.png

它根本無法理解你操作了什麼、流程是怎樣、你看到的是什麼以及你預期是怎樣,那它盲猜硬改,然後你就反覆花很多時間驗證。

那這樣你跟玩踩地雷有什麼差別呢?

所以接著我將會給你一套公式、一套流程,讓你可以精準的跟 AI 說明以及驗證,讓你可以快速的修復 Bug。

除錯三劍客:重現、預期、實際

這邊我將 Debug 這個行為定義成了三大步驟,分別是:

  1. 重現步驟:你是怎麼操作的,導致這個 Bug 發生的
  2. 預期結果:你預期的結果是什麼
  3. 實際結果:實際發生的結果是什麼

就這樣而已嗎?不,你也要盡可能要去附上圖片/操作影片。

Note
現在 AI 也可以直接讀取圖片,搭配文字描述,它可以更精準的理解你遇到的問題。

https://ithelp.ithome.com.tw/upload/images/20260923/201194864LxwNFADv0.png

了解這除錯三劍客之後,接著把它套進昨天留下的那個刪除 Bug:

刪除功能有 bug,重現步驟如下:
1. 在空資料狀態,先新增昨天的午餐 120 元,分類是飲食
2. 再新增今天的飲料 60 元,分類是飲食
3. 清單顯示是新到舊排序:
  - 今天的飲料
  - 昨天的午餐
4. 我點了「午餐」那筆打開編輯表單,接著我直接按下刪除、再按確認

預期結果:午餐那筆消失
實際結果:午餐還在,消失的是「飲料」那筆

這個過程我沒有看到任何錯誤訊息,請你分析之後告訴我你認為的原因。

裡面其實有一個流程我是刻意不寫的,也就是「打開編輯表單」之後看到的資訊,這其實是在模擬使用者在提供資訊時,依然很容易遺漏的問題,如果你有認真看,你會發現畫面上實際帶入的資料是「飲料」的資料,而非午餐。

Note
這邊一樣建議使用 Plan Mode 模式,讓 AI 好好的分析找出問題。

https://ithelp.ithome.com.tw/upload/images/20260923/20119486RHuq6R3b3E.png

很有趣吧?我連除錯都開 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 很慢啦~

畢竟你根本沒把問題描述清楚他們又該怎麼快呢?

找線索該去哪找:console 或截圖

很多時候我們遇到 Bug 但也不會出現在畫面上,那這個時候該怎麼辦呢?

這邊就要先搞清楚開發情境了,畢竟不同的開發情境有不同的解決方式,以我們練習製作的記帳 App 來講,是一個 Web App,所以我們就可以打開瀏覽器的開發者工具,去看 Console 的錯誤訊息,通常這些訊息會告訴你有哪些問題,打開方式也很簡單:

  • Windows / Linux: F12
  • macOS: Cmd + Option + I

接著只需要切換到「Console(主控台)」分頁,就可以看到錯誤訊息了。

處理方式也很簡單,直接全部複製貼上給 AI 就對了,不要自己翻譯摘要、自己亂解釋,因為你覺得不重要的部分常常才是關鍵,直接給 AI 幫你處理最快。

https://ithelp.ithome.com.tw/upload/images/20260923/20119486dSW1Zfae5D.png

Note
上面擷圖有些地方是屬於擴充套件的錯誤,因此如果發現 console 有很多紅字,不妨先把擴充套件關掉再測試一次(或無痕模式),這樣可以避免誤判。

接下來聊聊第二種,也就是比較難用文字描述的類型(畫面歪掉、顏色跑掉、文字大小不一等)這種會建議你直接截圖拖進去到 AI 的輸入框,然後一樣套用 Debug 流程,這樣就可以省下很多文字描述的時間。

當然,如果你能夠描述清楚還是最好的。

修完不是結束,一樣回歸驗收

不管怎樣,AI 跟你說它修好了、沒問題了或者改好了,這些都不代表你沒事了,而是準備「換人接手」而已,因為你才是這個專案的主人。

驗收的時候一樣把剛剛的重現步驟拿出來,自己親手再走一次:

刪除功能有 bug,重現步驟如下:
1. 在空資料狀態,先新增昨天的午餐 120 元,分類是飲食
2. 再新增今天的飲料 60 元,分類是飲食
3. 清單顯示是新到舊排序:
  - 今天的飲料
  - 昨天的午餐
4. 我點了「午餐」那筆打開編輯表單,接著我直接按下刪除、再按確認

這次的預期結果:編輯表單帶出來的是午餐的 120 元,刪除後午餐消失、飲料還在。

依照你當初回報給 AI 的操作流程再檢查一次,畢竟你總要知道它有沒有把你剛剛給的 Bug 修好吧?而不是 AI 跟你說它修好了你就當作結束。

除此之外,你也要檢查舊功能有沒有壞掉,因為你剛剛改的地方可能會影響到其他地方,所以這個時候就要把舊功能也檢查一遍,確保它們還是正常的。

記住幾個鐵則:

  • AI 說「我修好了」不算數,要你親手驗過才算
  • 舊功能有沒有被改壞,也一樣要你自己確認

以上都沒有問題這才叫做「修好」,接著這邊你就可以跟 AI 說:

我已經驗收過了,原本的 bug 消失、舊功能沒壞、已知的 TODO 都消失了,請幫我 commit。

到這邊為止,你已經完整走過一輪 Vibe Coding 的 Debug 流程了,這套流程不管是對人類工程師還是 AI 都是一樣的道理。

修不好的時候:三條退路

接下來來分享一下比較沒人講的情境,也就是「來回好幾次 AI 總是修不好」的情境。

在這個情境下我們不可能不做事,而是要先想好幾條退路,這邊我提供三條退路給你參考:

  1. 換方向問: 不要重複「東西還是壞的」這種沒用的描述,多操作幾次,把你新觀察的過程給 AI,例如...「刪第一筆正常,刪第二筆就錯」,有時候新線索有助於找出問題。
  2. 縮小範圍: 先請 AI 驗證資料流的部分,先請他不要管畫面,把刪除前跟後的資料內容呈現出來看,把問題切成資料跟畫面,畫面通常是基於資料去驅動的,所以先確認資料對不對,畫面才有意義。
  3. git 回到單一檔案: 跟 AI 連續來回幾次之後,請 AI 幫你還原到最後一次 commit 的版本,每一次的功能開發 commit 都是為了這個時刻存的,請 AI 先列出哪些檔案被改過,你看過再點頭,只還原壞掉的那一個檔案,而不是把今天辛苦做的進度整包清光。

這三條退路都是在跟你講一件事情:

AI 修正 Bug/開發功能不是百發百中,設計好退路的人才走得遠。

因此這邊一整個收斂起來流程就像這樣:

https://ithelp.ithome.com.tw/upload/images/20260923/201194866zxMMEdalz.png

結語

聊到這邊,相信你對於除錯的過程應該有一定掌握了,所以就最後總結一下吧。

在 Vibe Coding 的時候,遇到問題不要怕,遵守以下流程:

  • 描述用除錯三劍客:重現步驟、預期、實際;有紅字貼完整、畫面問題丟截圖。
  • 開 Plan Mode 讓它先診斷問題再動手。
  • 修完自己驗收:原 bug 真的消失、舊功能沒被改壞,過了才 commit。
  • 修不好三退路:換方向問、縮小範圍、只針對特定檔案復原。

明天來點開心的:讓數字自己說話,幫 App 加上統計頁跟圓餅圖。

希望這一篇有讓你修 bug 不再像抽獎哩~我們明天 Day 13 見囉~


上一篇
老闆不會教你的 Vibe Coding 實戰 30 天|Day 11:功能迭代之一次一個的 Prompt 拆法
系列文
老闆不會教你的 Vibe Coding 實戰 30 天12
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言