假設月末結算時，營運端回報財務匯出的訂單明細少了五筆。核對條件後，確認這五筆交易應該包含在內，但作業正常結束，日誌也沒有例外。使用相同條件重新匯出，這次卻正常了。

我們把相關程式、規格與執行紀錄交給AI分析，它提出了幾個可能方向，但還沒有足夠證據確認原因。既然重跑正常，接下來要從哪裡查？

偶發錯誤最難的地方，是同一段程式大部分時間正常，出錯時卻多了某個尚未掌握的條件。可能是特定資料、兩個操作的先後順序、不同Server的狀態，或當時的外部服務反應。只讀程式，未必能還原那次執行。

比較成功與失敗，找出值得追查的差異

與其繼續重跑、期待錯誤再次出現，可以先保留失敗與成功的匯出檔，連同查詢條件、執行時間與相關訂單資料，請AI協助比對。

這次兩份檔案使用相同條件，核對資料異動紀錄後，也沒有發現相關訂單在兩次匯出之間被新增或修改。差異集中在幾張訂單：它們在第一次沒有出現，第二次則正常。

接著把缺少的訂單與其他資料放在一起比較，發現它們的建立時間，都與另外幾張訂單完全相同。這不表示時間相同就一定會漏資料，卻提供了一個能沿著程式追查的線索：這個欄位參與了哪些處理？

AI可以協助比對欄位與查找用途，也可能主動發現這個共同點。開發者理解欄位的用途，便能一起判斷哪些差異與匯出流程有關，而不只是得到一份資料差異清單。

找到共同點，還要確認它與錯誤的關係

沿著建立時間查下去，AI發現匯出程式依這個欄位排序、分批讀取。當多筆訂單的建立時間完全相同，且沒有再以唯一欄位（如主鍵ID）決定先後時，資料庫並不保證這些訂單在每次查詢中都有相同的排列。

如果分批讀取是依筆數跳過前面的資料、取得下一批，排列改變就可能讓第一批已讀取的訂單落入第二批，另一筆尚未讀取的訂單卻被跳過，造成批次交界的重複或遺漏。

這讓「缺少的訂單有相同時間」成為值得追查的線索。但找到一個說得通的解釋，還不能認定就是原因。接下來可以比對各批取得的訂單編號，確認遺漏是否真的發生在交界處，以及是否伴隨重複資料。

如果沒有找到根本原因的修改，都是賭博

AI能追蹤程式、整理資料、提出假設，也能協助補上觀察與設計驗證。開發者則把實際執行條件帶進討論，理解流程依賴哪些前提，一起核對證據是否足以支持目前的判斷。

偶發錯誤即使沒有修改程式，下一次執行也可能正常。無論AI提出幾種方案，逐一套用後都沒再出錯，也可能只是每次測試都沒有碰到觸發條件。若只憑「這次正常」就認定修好了，其實是在賭下次也不會出事。

要確認修正有效，需要把原因、修改與驗證連起來：原本的錯誤如何發生？修改處理了哪個條件？哪些證據顯示同樣的問題已被解決？

AI第一時間找不到原因時，就從成功與失敗的差異繼續查。理解系統如何運作，再取得能分辨假設的證據，才能逐步縮小原因的範圍，而不只是多試幾種修改。

「AI給了三種改法，我都試了，測試全過。」
「那原本那版呢？」
「也過了。」
「所以你最後選哪版？」
「AI說第二版比較穩。」
「有什麼依據？」
「Build成功、單元測試全過、整合測試全過、壓力測試全過。」