前言：一個目前還沒有答案的真實 issue

「這個 bug 有回報步驟、有錯誤訊息、有環境資訊，資料這麼齊全，AI 應該一下就能抓到根因吧？」

昨天講完 AI 定位 bug 的一般流程，今天要老實面對一件事：不是每個 issue 都能在一篇文章裡走到「找到根因、修好」的結局。 今天要用的案例——PHPUnit & Pest Test Explorer 的 issue #430——到我寫這篇文章的當下，還是一個開著、還沒有任何留言回覆、也還沒有結論的真實 issue。這正好是個好機會，講清楚「資料齊全」跟「根因明確」中間，還隔著一段 AI 得自己一步步縮小範圍的距離。

今日目標

• 看一個真實、目前仍未解決的 coverage 路徑 bug 回報
• 理解「回報資料齊全」不等於「根因已經浮現」
• 學會怎麼把一個模糊的錯誤訊息拆解成幾個可以分別驗證的假設
• 認識誠實呈現「還在調查中」比硬掰一個結論更有價值

這個 issue 實際回報了什麼

Issue #430 的標題是「Code coverage not working: Test file "../coverage-00000000-0.xml" not found」。回報者描述：這個擴充套件的程式碼覆蓋率功能原本可以動，某次之後就不行了；不開覆蓋率、或用偵錯器執行測試都正常，只有「執行測試並收集覆蓋率」這個組合會壞掉。

輸出頻道的錯誤訊息是：

🚀 PHPUnit 12.5.34 by Sebastian Bergmann and contributors.
❌ PHPUnit 12.5.34 by Sebastian Bergmann and contributors.
Test file "../coverage-00000000-0.xml" not found

環境資訊也附得很完整：Linux Mint、VSCodium 1.126.04524、擴充套件版本 3.9.40、PHP 8.3.6、PHPUnit/Pest 版本 12.2，還附了專案結構（phpunit.xml、src、vendor、tests 平行放在專案根目錄）。

這份回報幾乎符合一份好 issue 該有的所有要素——重現步驟、確切的錯誤訊息、環境版本、專案結構。但截至目前，這個 issue 底下的留言數是零。沒有人（包含維護者）回覆過，也還沒有任何後續驗證。

為什麼「資料齊全」不等於「根因明確」

先把錯誤訊息拆開來看：Test file "../coverage-00000000-0.xml" not found。這句話本身透露出兩層資訊：第一，系統期待在某個路徑找到一個叫 coverage-00000000-0.xml 的檔案；第二，那個路徑是用 ../ 這種相對路徑表示法組出來的，而且找不到。

光憑這一行，AI 能提出幾個可以分別查證的假設方向，但還沒有一個是確定的答案：

• 相對路徑的基準點錯了：../ 是相對於哪個目錄算的？如果覆蓋率報告的輸出路徑跟這個相對路徑計算時假設的工作目錄不一致，組出來的路徑自然就是錯的。
• 檔名裡的 00000000-0 是某種產生中的暫存檔案：這串看起來像是流程 ID 或暫存序號，如果是在覆蓋率收集完成前就被提前讀取，檔案當然還不存在。
• 平台相關的路徑處理差異：回報者用的是 Linux，路徑分隔符號跟 Windows 不同，如果程式碼裡有寫死某種分隔符號假設，跨平台時容易出這類問題。

這三個方向都只是「值得先驗證的假設」，不是結論。 在沒有更多資訊（例如維護者能不能重現、有沒有相關的除錯 log）之前，誠實的做法是把這三個方向列出來、標注優先驗證順序，而不是挑一個聽起來最合理的直接當成答案寫進報告。

AI 在這種情境下該做的事，跟不該做的事

❌ 過早收斂成一個結論：
「這是路徑分隔符號在跨平台情境下處理錯誤導致的，
 已經確認是這個原因。」
→ 事實上沒有任何留言、任何額外資訊能支撐「已經確認」這個講法，
  這只是三個假設裡的其中一個

✅ 誠實呈現查證進度：
「根據錯誤訊息，目前有三個可能方向：相對路徑基準點、
 暫存檔案時序、跨平台路徑差異。回報裡沒有足夠資訊排除任何一個，
 需要維護者確認能不能重現、或請回報者補充更多執行環境細節。」
→ 誠實標注「目前查得到什麼、查不到什麼」，
  下一步該做的是縮小範圍,不是硬凑一個看起來合理的答案

一個 bug 回報資料再齊全，AI 也不該把「有材料可以推理」誤當成「已經有答案」——這正是這個系列從 Day 01 開始反覆講的同一件事：AI 給出的結論，只在它實際查證過的範圍內成立，而「查證過」跟「推理出一個聽起來合理的假設」是兩回事。

對這個具體 issue 來說,AI 能貢獻的價值,是把「怎麼縮小範圍」講清楚——例如建議回報者補充：問題發生時專案是不是剛切換過分支或工作目錄、coverage-00000000-0.xml 這個檔名的數字部分是不是每次執行都不同（判斷是不是流程 ID）。這是機械性、可以直接派上用場的工作；至於這個 bug 最終的根因是什麼、要花多少資源去追，是維護者的判斷。

今日思考題

如果你手上也有一個「回報資料齊全、但暫時沒有答案」的 issue，你會怎麼跟回報者或團隊溝通目前的查證狀態？是含糊帶過「還在看」，還是像上面那樣明確列出「目前有哪些假設、還缺什麼資訊」？

今日重點回顧

• issue #430 是一個真實、目前仍開著、零留言的案例——回報資料完整,但根因還沒有答案
• 從一句錯誤訊息可以拆解出多個可查證的假設方向，但假設不是結論
• AI 該做的是把假設列清楚、排出驗證優先順序，不該挑一個看起來合理的方向就當成已確認的答案
• 誠實呈現「查證進度」比編造一個聽起來完整的結論更有價值，這是主題句在除錯情境的具體體現

明日預告

明天要換一個風險完全不同的維護工作：寫文件。AI 幫忙修 README、marketplace badge 這類看起來低風險的瑣事,效益跟風險分別是什麼。