本篇是故事四的「查證」篇。

本篇要回答：自動修正類事故需要保存哪些證據？以及——證據已經散失時，誠實的寫法是什麼？

當時發生了什麼

寫這個系列時，我很想把 Day 16 的細節寫滿：工具名、版本、規則編號、修改前後的程式碼。然後發現一件難堪的事：我拿不出來。當時急著修好往前走，diff 沒有存檔、規則編號沒有記錄，只剩下「查詢壞了又修好了」的記憶梗概。

這就是本篇最重要的一次自我抓包：我在寫一個關於證據保存的系列，而我自己的事故檔案是空的。記憶告訴我「大概是布林比較被改寫」，但記憶的置信度會隨時間衰減，還會被事後的理解不斷改寫——三年後的回憶，是三年來每次轉述的疊加，不是當天的現場。

我原本怎麼判斷

當時的心態是「修好比記錄重要」。這在救火當下沒錯；錯在火滅之後沒有回頭補採證，讓一次昂貴的學習只剩下不可對質的印象。工程上的差別很具體：有 diff，這個案例可以變成回歸測試與規則設定；只有印象，它只能變成一句「大家小心自動修正」。

我怎麼查證或重現

如果時間倒回，事故當下應該保存的完整清單：

• 修改前後的程式碼與 Git Diff——自動修正一結束就先 commit 或 stash，讓 diff 永遠可取。
• 工具名稱、版本與完整設定檔。
• 觸發的規則編號與說明連結。
• 執行的確切命令與完整輸出。
• 啟用的安全／不安全修正選項。
• ORM 與 Python 版本。
• 事故查詢前後實際產生的 SQL。
• 測試資料與查詢結果的對照。
• 自動修正前後的回歸測試結果。

這份清單的成本大約是十分鐘，而它買到的是：可重現、可歸因、可轉成防再發措施的完整案例。

區分證據等級——這一篇自己就是示範：已確認事實：查詢曾在自動修正後失效並修復（結果記憶，置信度高）。合理推論：機制與布林表達式改寫有關（與 Day 18 的可驗證機制吻合）。已不可考：確切 diff、工具版本與規則編號——本系列不假裝擁有它們。

今天留下什麼方法

本篇結論：

事故調查的第一個自我抓包，是承認自己的記憶不等於發生過的事。

下一篇（Day 18）用可執行的最小案例補上機制那一塊：從 Python 原始碼，一路追到資料庫真正收到的 SQL。