本系列從五個親身踩過的工程問題出發,記錄我如何從「我這邊明明正常」開始,查閱文件、保存證據、建立最小重現、重建事件軌跡,逐步搞懂需求定義、執行環境、資料契約、工具語意與非同步完成條件。這不是 30 天抓戰犯,而是把每一次踩雷整理成可重複使用的工程事故調查方法。It Works on My Machine 不是結論,而是事故調查與重新學習的起點:IDE 能跑,Terminal 卻失敗;語法完全合法,一個逗號卻悄悄把資料型別換掉;lint 與自動修正全數通過,ORM 查詢反而永遠撈不到資料;系統明明採用非同步 Pub/Sub,卻被要求立刻回答遠端指令成功了沒。
本篇是故事一的「踩雷」篇。 本篇要回答:技術問題問得很專業,為什麼專案仍可能從第一天就開始走偏? 當時發生了什麼 場景是 AOI(Automated Opt...
本篇是故事一的「查證」篇。 本篇要回答:需求走偏時,第一個該查證的不是規格,而是「誰真正承擔結果」——這件事當時被我簡化成什麼樣子? 當時發生了什麼 Day...
本篇是故事一的「重現」篇。 本篇要回答:如何把一句看似謹慎的「可以用 GigE 嗎」,重現成一個可以觀察、可以改寫的失效樣本? 當時發生了什麼 Day 01...
本篇是故事一的「理解」篇。 本篇要回答:為什麼「要用 Socket、Streaming 還是 MQTT」這個問題本身就有問題?技術選型的決策構面應該長什麼樣子...
本篇是故事一的「內化」篇。 本篇要回答:這五天的踩雷、查證、重現與理解,最後能收斂成哪一份可以重複使用的東西? 當時發生了什麼 把前四天排在一起看,故事一其...
本篇是故事二的「踩雷」篇。 本篇要回答:同一台電腦、同一份程式碼,為什麼會產生互相矛盾的測試結果? 當時發生了什麼 本機測試卡關了好一陣子,症狀清單長這樣:...
本篇是故事二的「查證」篇。 本篇要回答:懷疑執行環境不一致時,應該保存哪些證據,才能讓討論建立在事實上? 當時發生了什麼 Day 06 抓到了「兩個 Pyt...
Day 08|重現:把 IDE 與 Terminal 的執行路徑並排,問題才第一次現形 本篇是故事二的「重現」篇。 本篇要回答:如何建立一個最小重現,證明兩邊...
本篇是故事二的「理解」篇。 本篇要回答:把「IDE 與 Terminal 結果矛盾」拆成直接原因與促成因素,各自是什麼? 當時發生了什麼 證據到齊之後,誘惑...