「事實查核流程已經講完了，實際跑起來，真的會抓到東西嗎？還是走個形式、確認『大致上沒問題』就結案？」
從這篇開始，用幾個具體案例把前面 23 天講過的原則串起來看。第一個要處理的問題就是這個：一套跑真的查核流程之後，實際抓到的錯誤，到底長什麼樣子？如果只是空泛地說「查核很重要」，讀者很難建立直覺。今天就把實際查核抓到的問題，分成四種型態逐一講清楚。
AI 寫技術文章時，經常需要引用某個概念的出處（誰先提出這套分類、誰寫了這篇奠基性的文章）。這類引用最容易出現一種特定的錯誤：把「後來闡述、引用、發揚光大的人」誤植成「原始提出者」。
這種錯誤特別難靠直覺抓，因為兩者確實有真實的關聯——後來的人真的討論過這個概念，內容描述本身也可能完全正確，只是「誰先提出」這一件事張冠李戴了。查核時要做的不是「這個概念的描述對不對」，而是額外多問一句「這個出處的歸屬，跟原始文獻對得上嗎」。
寫系列文章時，常常會想呼應「前面某一天講過的內容」來加強連貫性。但如果引用時只憑印象、沒有實際回頭確認，很容易發生兩種變形：引用到一篇根本沒有那段內容的文章，或者把另一個系列的內容誤植成這個系列自己講過的東西。
後者特別危險，因為兩個系列如果主題相近，內容讀起來會很自然，不會讓人一眼看出「這其實是另一篇文章的句子」。這種錯誤只能靠實際打開被引用的那一篇，逐字核對有沒有真的講過那段話，沒有捷徑。
這是最容易造成實質傷害的一種——不是措辭不夠精確，是整個技術主張的方向就是反的。例如講某個工具或機制在特定情境下的行為，實際查證後發現跟原文描述完全相反：文章說「這個機制會靜默失敗」，查證後發現它其實會立刻明確報錯；文章說「這個攔截點拿不到某個資訊」，查證後發現它其實預設就會帶那個資訊。
用一組對照來看這個差異：
❌ 未經查核，憑印象寫出方向相反的主張：
「這個機制遇到異常情況時，會靜默略過，不會有任何提示。」
→ 讀起來合理、語氣自然，但如果查證後發現實際行為
剛好相反（會立即明確報錯），讀者照著這個錯誤描述
去判斷自己專案的行為，會做出完全錯誤的預期
✅ 查核後確認方向，或標注查證來源：
「這個機制遇到異常情況時，會立即丟出明確的錯誤，
不是靜默略過（已核對官方文件的行為說明）。」
→ 陳述的方向跟查證結果一致，讀者可以放心依此判斷
這種錯誤特別容易在「順手類比兩個工具/機制」時發生——寫作時想著「這兩個東西應該是類似的行為」，順手就寫下去了，但沒有真的分別查證過兩邊的實際行為是不是真的一樣。
跟前三種「查了就知道對錯」不同，這種型態比較微妙：內容本身沒有捏造，但措辭超出了原始資料實際涵蓋的範圍。例如原始資料裡只提到某件事「可能發生」，文章寫成「一定會發生」；原始資料只涵蓋一部分情況，文章寫成「所有情況都是如此」。
這類錯誤最考驗查核的細緻度，因為表面上讀起來完全合理，只有真的把原始資料攤開來逐字比對，才會發現「這句話講得比原始資料能撐住的還要多」。 修正方式通常不是整段改寫，只需要把「一定」改成「多半」、把「所有情況」改成「多數情況下」這類程度副詞的調整，卻能讓陳述重新對齊查證得到的實際範圍。
這四種型態有一個共通點：它們讀起來都很流暢、很合理，不會讓人在通讀時本能地停下來覺得「這裡怪怪的」。人工複查習慣捕捉的是「讀起來卡卡的地方」，但這幾種錯誤恰恰不會產生這種閱讀阻力——句子結構完整、邏輯通順，唯一的問題是跟外部事實對不上，而這件事只有主動去查證來源才會發現。
這正是這個系列反覆強調的模式：AI 對著一段自己寫出來的內容,給出「讀起來沒問題」的信心，但這份信心涵蓋的只是「語言通順度」，沒有涵蓋「跟外部事實對不對得上」——這兩件事完全獨立，前者高不代表後者也高。
回想你上一次自己寫或審查一篇技術文章：有沒有哪一句話，你當下讀起來覺得「合理，應該沒錯」，但其實從來沒有真的去查證過它跟原始來源對不對得上？
明天要更深入講第一種型態——技術主張的歸屬錯誤，看一個具體案例：連 AI 自己都會把兩個人的貢獻搞混,而且錯得理直氣壯。
iThome鐵人賽
看影片追技術