為什麼這個問題現在會跑出來
最近很多工程師遇到同一種尷尬：AI 看起來會讀程式、會解釋錯誤、會直接改 code，但同一個 bug，簡單講就是程式裡讓結果不符合預期的問題，你講了 3 次，它還是在修旁邊那塊。第一次它改了型別，第二次它補了 null check，第三次它把錯誤包起來，畫面是不爆了，可是資料還是錯。很煩。 這篇的核心判斷很簡單：多數時候，AI 不是完全沒聽懂你在說什麼，而是它修了「看起來最像問題」的地方，卻沒有拿到足夠線索判斷 root cause，用白話文講就是真正讓 bug 發生的原因。它像接到一張只拍到煙的火警照片，看得到煙，但不一定知道火源在哪。這才是卡點。 我自己最常看到的場景，是同事貼一段錯誤訊息給 AI，然後加一句「幫我修」。AI 很快吐出一段 patch，簡單講就是一小段修改建議，看起來很像答案，但跑完之後 bug 變形了：原本是 500，後來變成資料少一筆；原本是測試掛掉，後來變成畫面流程不對。它有回應，但沒有真的定位。這差很多。 問題會在現在變明顯，是因為 AI coding 工具已經從「幫你補幾行」走到「可以讀多個檔案、提出改法」的階段。能力變強後，錯覺也跟著變強：你會以為它能看見整個執行現場。但目前多數情況下，它看到的是你貼給它的文字與它能讀到的檔案，不是你本機跑起來時的全部狀態。它沒有你的眼睛。
真正的原因不在表面
真正的誤判點在這裡：你以為你在問「這個 bug 怎麼修」，AI 實際收到的可能只是「這段錯誤訊息附近哪裡最可疑」。這兩件事差很多。前者要理解流程，後者只是在找表面症狀。差在現場。 stack trace，用白話文講就是程式錯誤發生時一路呼叫到哪裡的紀錄。它很重要，但它常常只指出最後摔倒的位置，不代表那一行就是罪魁禍首。像付款流程最後在 render 畫面時爆掉，原因可能是後端回傳少了欄位；測試最後在 assertion 掛掉，原因可能是前面 mock 資料跟真實資料差一個格式。AI 如果只看到最後一行，就容易把最後一行當成答案。這很常見。 reproduce step，簡單講就是讓同一個錯誤再次出現的操作路徑。它是 AI 判斷 bug 類型的關鍵，因為「每次都能重現」跟「偶爾才發生」是兩種完全不同的問題。前者常常是邏輯或資料格式，後者可能牽涉時間、快取、併發、外部服務回應。你如果只說「有時候會壞」，AI 通常只能猜。猜就會飄。 runtime，用白話文講就是程式真的跑起來時的狀態：環境變數、輸入資料、API 回傳、資料庫內容、時間點、使用者操作順序。AI 在聊天視窗裡通常看不到這些。你看到的是畫面卡住、log 滾動、某個值在 debugger 裡變成 undefined；它看到的是你打出來的幾句話。資訊落差就在這裡。很現實。 所以同一個 bug 跟 AI 講 3 次它都修不好，不一定代表模型理解能力差。更常見的是任務規範沒有講清楚：你希望它找原因，它卻以為你要它快速消除錯誤；你希望它保留現有行為，它卻改了資料流；你希望它先分析，它直接動手補防呆。方向一偏，後面每次追問都只是在同一條錯路上修補。越修越亂。 這也是為什麼有些 AI 改法看起來很聰明，卻會留下新的坑。它可能把錯誤訊息消掉了，但沒有驗證原本業務邏輯還在；它可能讓測試通過了，但只是把測試改得比較寬；它可能補了一個預設值，但那個預設值在真實資料裡根本不該出現。表面安靜，不等於修好。要分清楚。
現在先做什麼
現在先做的事，不是把同一句話換 5 種說法問 AI。先把「錯誤現場」整理成一段它能判斷的文字。你可以把輸入固定成 4 塊：完整 stack trace、reproduce step、你已經試過什麼、你希望它先分析還是直接改。不要只丟一張煙霧照片。要給火場平面圖。 我會這樣寫：「這是錯誤訊息與 stack trace；重現方式是登入測試帳號後，進到訂單頁，點第 2 筆資料會出錯；我已經試過把 amount 轉成 number，但錯誤還在；請先判斷最可能的 2 個原因，不要先改 code。」這段話不花 1 分鐘，但會把 AI 從亂補改成先推理。差很多。 如果你用的是能讀專案的 coding assistant，簡單講就是可以讀取程式檔並提出修改的 AI 寫程式工具，也不要假設它知道你在意什麼。你要明講：「先看資料從哪裡進來，再看哪裡被轉型，最後只改最小範圍。」這不是在限制它變笨，而是在避免它為了修一個錯誤，順手重構半個模組。範圍要講。 另一個好用做法，是要求它先給「證據鏈」。也就是請它說明：哪一行錯誤訊息指向哪個函式，哪個輸入值可能造成這個結果，哪個檔案最值得先看。這不是要它寫作文，而是讓你看出它有沒有根據。只要它開始說「可能是某某問題」卻沒有對應 log 或程式路徑，你就知道它在猜。先抓猜測。 跑完 AI 的修法後，也不要只看「錯誤消失了」就收工。比較穩的檢查是回到原本 reproduce step，再補一個相近但不一樣的案例。例如原本第 2 筆訂單會爆，就再測第 1 筆正常資料與一筆缺欄位資料。你不是在做大測試，只是在確認它沒有把 bug 藏到下一個路口。這一步很省事。
常見的陷阱跟誤解
第一個陷阱，是把 AI 的自信語氣當成定位完成。它講得順，不代表證據夠；你要看它有沒有引用錯誤訊息、資料流、重現路徑。語氣不是證據。 第二個陷阱，是每次追問都只貼新的錯誤，卻不貼你剛剛改了什麼。AI 會失去前後差異，只能把每次錯誤都當成新問題處理。改動也要交代。 第三個陷阱，是太早要求它「直接修」。debug，簡單講就是找出程式問題的原因並驗證修法，前半段其實比後半段重要。原因沒抓穩，直接修只是加速走偏。先問原因。 第四個陷阱，是讓 AI 一次改太大。當它同時改資料格式、錯誤處理、UI 顯示與測試，你後面很難知道哪個改動真的有效。小改比較好查。別貪快。 第五個陷阱，是忽略版本與環境。框架版本、套件版本、執行環境不同，同一段建議可能差很多。至少貼出相關版本，AI 才不會拿別的時代的解法來補現在的坑。版本很關鍵。
下次再遇到時可以怎麼判斷
下次同一個 bug 跟 AI 講到第 2 次還修不好，先停，不要急著開第 3 輪改法。你可以問自己一個判斷題：我現在給 AI 的，是錯誤現場，還只是錯誤截圖？如果只有錯誤訊息，多半還不夠。先補現場。 比較實用的小框架是這樣：如果錯誤能穩定重現，先整理 reproduce step 與輸入資料；如果錯誤偶爾出現，先補 log、時間點與環境差異；如果 AI 的改法開始變大，先要求它縮回最小修改範圍。不同情境走法不同。沒有單一答案。 AI 可以是很強的 debug 夥伴，但它需要你把 runtime 翻譯成文字。你負責提供現場、限制範圍、驗證修法；它負責幫你整理線索、提出假設、找到可能路徑。這樣配合，修 bug 才不會變成跟 AI 一起猜謎。下次先補現場。
