「這個 bug 我已經照著回報的重現步驟修好了，測試也綠燈，可以關 issue 了吧？」
這句話聽起來很合理，卻是 open source 維護裡最容易踩的一個陷阱——AI 修 bug 時，天然只會針對「回報者描述的那個情境」去驗證，不會主動去想「這個情境還有沒有變體」。 今天用一個示範情境，具體走一次這種「修好了表面症狀、卻漏看了 edge case」的過程，以及回報者怎麼在後續留言裡把這個落差指出來。
這篇是基於這個專案真實 issue 型態設計的示範情境，不是逐字對應到某一個特定的真實 issue——我查過幾個有多輪留言討論的真實 issue（例如多環境測試除錯的來回過程），但沒有找到情節完全對應「AI 判斷不完整、被指正後才補齊」的真實案例，所以誠實改用示範情境，技術細節依然貼著這個專案真實會遇到的問題型態設計，不是憑空捏造。
假設有一個回報：在單一 workspace 底下，執行某個巢狀資料夾內的測試檔案時，Test Explorer 顯示的路徑跟實際檔案路徑對不上，導致點擊「執行測試」沒有反應。回報者附上了明確的重現步驟：一個 workspace、一個測試檔案放在兩層巢狀資料夾裡。
AI 依照這個重現步驟追查，找到路徑解析邏輯裡確實有一段假設「測試檔案最多只巢狀一層」的邏輯，修正後用回報者提供的步驟重新驗證，行為正確，也補上了一個對應的測試案例，PR 送出、合併。
PR 合併幾天後，回報者（或另一位剛好也遇到類似狀況的使用者）留言：他的專案設定其實是 multi-root workspace（VS Code 裡同時打開多個根目錄的模式），套用了新版本之後，原本回報的巢狀路徑問題確實修好了，但換到 multi-root workspace 情境下，路徑解析又用了另一種錯誤的方式失敗——因為修法裡把「巢狀層數」的判斷寫死成相對於單一 workspace 根目錄，multi-root 情境下每個 root 各自有一份相對路徑基準，這段邏輯完全沒考慮到。
這正是「照著重現步驟修」最容易漏掉的地方：回報者給的重現步驟，只代表他遇到問題的那一種組合，不代表這類問題的全部變體。 AI 驗證時只用了回報者提供的那組條件，沒有主動去想「這個路徑解析邏輯，還會被哪些其他設定方式觸發到」。
用一組對照來看這個差異：
❌ 只驗證回報者提供的重現步驟：
「回報的情境是單一 workspace、兩層巢狀路徑，
照著這個情境修正、驗證通過，關閉 issue。」
→ 修法只保證在「回報者描述的那一種組合」下正確，
沒有檢查這段邏輯還會被哪些其他組合方式觸發
✅ 修完後反過來想「這個邏輯還有哪些變體會踩到」：
「這段路徑解析邏輯依賴的是『workspace 根目錄』這個概念，
除了單一 workspace，VS Code 還支援 multi-root workspace，
這種情境下『根目錄』不是單一固定值，
我修的這版邏輯有沒有把這個可能性也考慮進去？」
→ 從「這個回報的具體情境」往上一層，
想清楚這個功能/設定在這個生態系裡實際上有哪些變體
AI 驗證一個修法對不對，天然的判斷依據是「有沒有讓回報的重現步驟變成預期行為」——這個判斷邏輯本身沒有錯，但它的查證範圍完全被回報者提供的情境框住了。 回報者不是這個專案的維護者，通常也不會知道「這個功能在其他設定方式下還會不會踩到同樣的邏輯」，他只會描述自己實際遇到的那一種組合。如果 AI 沒有主動把查證範圍從「這一個回報」擴大到「這個功能在整個專案支援的使用情境裡還有哪些變體」，這個落差就會一直留到下一個踩到的人重新回報。
這跟這個系列反覆講的模式是同一件事：AI 給出的「已驗證修好」，可信度只到它實際驗證過的範圍——而那個範圍，很容易被回報者提供的單一情境不知不覺地框限住。
這個案例留下一條具體的紀律：任何修法牽涉到「這個專案支援多種設定方式」的功能（例如單一 workspace vs multi-root workspace、單一測試框架 vs 多種測試框架並存），驗證完回報的情境之後，要多問一句「這個邏輯的假設，在其他支援的設定方式下還成立嗎」，而不是驗證通過就結案。 這條紀律的成本很低——多花幾分鐘檢查一次專案文件裡列出的支援情境清單，但省下的是使用者要重新回報、維護者要重新追查一次的成本。
回想你上一次修一個回報的 bug：你驗證修法的依據，是回報者提供的那一種具體情境，還是這個功能在你專案裡支援的所有情境？如果只驗證了前者，你有把握這個修法在其他情境下也一樣正確嗎？
明天是另一種案例：一個長期沒人處理的舊 issue，AI 怎麼幫忙重新評估它現在還算不算優先事項。
iThome鐵人賽
看影片追技術