🎯 什麼情境該想到我
當你在 review 一個「看起來合理」的修法（upsert、retry、try-catch、加鎖…），想判斷它是真的修好還是只是把症狀藏起來時。
⚙️ 怎麼用
- 先問「為什麼這裡會有這個問題？」 而不是「這個修法對不對」。
- 例：不是問「upsert 寫得對嗎」，而是「為什麼這裡會需要 upsert」。
- 順著症狀跨系統往上追因果：worker 症狀 → MQ 時序 → sender 的 transaction 邊界。
- 判斷準則：如果這個修法讓 error 消失、但根本的錯誤狀態仍然存在（只是不再噴錯），它就是掩蓋，不是修復。
- 掩蓋型修法要擋下來——症狀消失後就沒人會再發現真正的問題。
🧪 我實際套用的紀錄
- 2026-07-13：（待填）
⚠️ 注意 / 什麼時候不適用
- 緊急止血時可先用掩蓋型修法擋住，但必須開票追 root cause，別讓它變成永久補丁。
- 核心心法：不要比 AI 更會 coding，要比它更會 reasoning。
🔗 相關工具
- 工具-用判斷力而非蠻力 —— 同一取向，與其埋頭多寫幾層防護，不如把根因判斷對