本篇是最後五天方法回顧的第四篇。

本篇要回答：為什麼「找到根因」經常是調查提前結束的藉口？原因分析的固定格式長什麼樣？

找戰犯的引力

事故調查有一股天然引力：找到一個可以指著的東西——一行程式、一個設定、一個人——然後宣布結案。這股引力有兩個來源：指出戰犯讓其他所有人安全，以及「單一根因」的敘事最省力。

但五個故事沒有一個能誠實地壓成單因：逗號後面站著缺席的型別檢查與只驗「不拋例外」的測試；lint 改寫後面站著跳過的 diff review 與缺席的回歸測試；環境分岔後面站著只寫「執行 pytest」的文件。把任何一案寫成「某某疏忽」，剩下的促成因素就原封不動等著下一位。

固定格式：四本帳

直接原因——最接近失效結果的技術機制。特徵：修掉它，這一次的症狀立即消失。（逗號、interpreter 分岔、表達式改寫、布林介面。）

促成因素——讓問題容易發生、難以察覺或擴大影響的條件。特徵：它們單獨存在時無害，疊加時把小失誤放大成事故。每案通常五到七條，這是正常值而非調查失焦。

系統性缺口——需求、流程、測試、工具治理、責任或架構設計層面的問題。特徵：它們不屬於這一次事故，它們屬於「這一類事故為什麼在這個組織可行」。（驗證體系缺「資料契約」這個類別；沒有區分語意敏感區域；完成語意從未被定義。）

尚未排除——現有證據不足以確認的替代解釋。這一欄的存在防止報告本身犯下 Day 26 的擴張解讀：調查也有自己的證據邊界。

四本帳的處置差異

分帳的意義在於處置方式完全不同：直接原因修一次；促成因素逐條變成措施（Day 15、Day 20 的表格就是範例）；系統性缺口需要的是體制動作——加一個檢查類別、劃一條治理邊界、定義一種語意；尚未排除則轉成待辦的驗證項。把四本帳混記，產出就會退化成「修掉那一行＋下次注意」。

本篇結論

找到出錯的那一行，不代表已經找到為什麼這類問題可以一路通過整套系統。

最後一篇（Day 30）處理整個循環的最後一塊，也是最常被跳過的一塊：改善措施自己也需要驗收——修好不等於不再發生。