本篇是故事二的「理解」篇。

本篇要回答：把「IDE 與 Terminal 結果矛盾」拆成直接原因與促成因素，各自是什麼？

當時發生了什麼

證據到齊之後，誘惑是寫下一句結案報告：「IDE 選錯 interpreter，改掉就好。」它不算錯，但它只回答了「這一次為什麼壞」，沒有回答「為什麼這類問題可以存在這麼久、還這麼難發現」。

我原本怎麼判斷

修好當下的第一反應是鬆一口氣，第二反應是想把這頁翻過去。事故調查的紀律恰好相反：修好之後才是分析的開始，因為只有這時候你才有完整的證據可以分帳。

我怎麼查證或重現

把證據攤開，分成兩本帳。

可能的直接原因（最接近失效結果的機制，個案中至少命中第一項）：

• IDE 與 Terminal 使用不同的 Python interpreter。
• 套件安裝進了另一個環境。
• pytest 執行檔不屬於當下這個 Python。
• 兩個環境的 Python 或相依套件版本不同。

促成因素（讓問題容易發生、難以察覺、修好又復發的條件）：

• 文件只寫「執行 pytest」，沒有指定在哪個環境、用哪種形式執行。
• pip 與 python -m pip 混用，安裝目標取決於當下 PATH。
• 專案沒有固定 Python 版本，每台機器各自解讀。
• IDE 的 interpreter 設定只存在個人電腦上，不在版本控制裡，也沒人審查。
• 測試輸出不含 interpreter 資訊，事後想查也沒有紀錄。
• 整條流程依賴人工記得啟用虛擬環境——依賴記憶的步驟，遲早被忘掉。

兩本帳的差別在於處置方式：直接原因修一次就好；促成因素不處理，同一類事故會換一套皮膚回來——下次可能不是 pytest，是 formatter、是部署腳本、是任何依賴「哪個 python」的東西。

區分證據等級。已確認事實：兩份清單中的機制皆可在任何機器上重現驗證。合理推論：個案的長期卡關由「直接原因＋多項促成因素疊加」解釋，而非單一失誤。

今天留下什麼方法

留下一句可以貼在測試報告旁邊的話，也是本篇結論：

「在我電腦可以跑」若沒有附上 interpreter、版本與依賴條件，只是一句無法重現的環境描述。

下一篇（Day 10）把促成因素逐條變成防再發措施：不要只叫大家記得 activate，讓專案自己說明怎麼跑。