前言

「這個技術細節我們踩過坑,親身經歷過,還需要另外查證嗎？」

親身經歷過的踩坑經驗,證明的是「在那個特定情境下,某個現象確實發生了」,不代表對這個現象的原因解釋一定正確。人在事後回憶踩坑過程時,很容易把當時的猜測、聽別人轉述的說法、甚至事後合理化的推論,跟親眼驗證過的事實混在一起,變成同樣篤定的語氣寫進文章裡。這篇要講的是,為什麼「我們真的遇過」不能取代「查證過官方文件」。

今日目標

• 理解「親身經歷過」跟「原因解釋正確」是兩件不同的事
• 看到記憶怎麼在事後不知不覺地把猜測跟事實混在一起
• 掌握查核技術主張時該找什麼等級的來源,以及來源等級之間的優先順序
• 知道發現錯誤之後,客觀事實錯誤跟判斷空間大的地方要分開處理

記憶會把猜測跟事實混在一起

寫踩坑經驗最容易出現的問題,不是完全捏造,而是「有一部分是真的驗證過,有一部分是當時聽人說、自己合理推測」,但事後回憶時這兩者的語氣聽起來一樣篤定。舉例來說,遇到一個資料庫效能問題,當下的解法是照著某種操作方式避開了問題,這個操作本身是真的做過、也真的解決了；但「為什麼這樣做有效」的原因解釋,如果當時只是憑經驗猜測、沒有真的去查官方文件驗證,這個原因解釋就屬於「沒有查證過的部分」，跟「真的做過的操作」在記憶裡卻是同一件事,寫作時很容易一起用肯定語氣帶過。

• ❌ 只憑記憶寫技術主張：「我們踩過這個坑,原因是 XX 機制導致的」——把當時的猜測性解釋，跟真正驗證過的操作結果，用同樣篤定的語氣寫出來
• ✅ 標示清楚驗證程度,再去查證：先誠實區分「這是真的做過並解決問題的操作」跟「這是我對原因的理解,但沒有真的查過官方說法」,對後者去查官方文件或權威來源核對,查完再決定怎麼寫

查核來源的優先順序

查核技術主張時,不是所有來源都同等可信。優先順序大致是：官方文件/規格（語言/框架的 manual、資料庫官方文件、協定規格)最優先，因為這是行為的第一手定義來源；其次是主流技術媒體/知名工程部落格，這類來源通常已經過一輪查證跟編輯；來源不明的論壇貼文不能當唯一佐證，因為論壇上同樣充滿「憑印象寫得很篤定但其實沒查證過」的內容，用來源不明的說法佐證另一個沒查證過的說法，等於什麼都沒查證。

今日思考題

回想你上一次寫一段技術主張時,那段內容裡有多少比例是你真的查過官方文件驗證的,又有多少比例是「聽說」「印象中」「應該是」這種沒有明確來源的內容？

今日重點回顧

• 「親身經歷過某個現象」不代表「對這個現象的原因解釋是正確的」,記憶容易把兩者混在一起用同樣篤定的語氣寫出來
• 查核前先誠實拆解:哪部分是真的驗證過的操作,哪部分是事後才加上去的原因解釋
• 官方文件/規格優先,其次是主流技術媒體,來源不明的論壇貼文不能當唯一佐證
• 這是動筆前就該做的檢查,不是等讀者質疑才回頭補查

明日預告

Day 11 會用一個真實案例,講怎麼用分批派工的方式,查核多篇文章裡累積下來的技術主張。

寫在最後

回頭檢查自己過去寫過的技術內容,最容易發現的問題不是明顯錯誤，而是那種「聽起來很合理、但其實從沒真的查過來源」的句子——這類句子最危險,因為它們讀起來完全不像需要被懷疑的內容。