前言：AI 寫錯歸屬，是不是比人類還離譜？

「AI 連『這個概念是誰提出的』都能搞錯，這種基本常識級的錯誤，是不是代表它根本不可靠？」

聽起來很嚴重，但這條系列從 Day 24 開始就在講：AI 犯的錯，很多時候不是「編造了不存在的東西」，是「把兩個經常一起出現的名字搞混了」——這是一種特定的、可以被理解、也可以被系統性抓出來的錯誤型態。今天用一個真實的、公開可查證的技術史案例，具體拆解這種錯誤是怎麼發生的，以及怎麼查核。

一個真實的歸屬錯誤：測試替身分類法是誰提出的

軟體測試領域有一套廣為人知的「測試替身」分類法：Dummy、Stub、Fake、Spy、Mock 五種類型,各自回答不同的驗證問題。這套分類法經常被引用時掛在 Martin Fowler 名下,因為他 2007 年那篇廣為流傳的文章《Mocks Aren't Stubs》,詳細討論了這五種類型的差異,也是很多人第一次接觸到這套分類的地方。

但如果追到最早的出處,這套分類法其實是 Gerard Meszaros 在《xUnit Test Patterns》這本書裡系統性提出的。Fowler 的文章是引用並闡述這套分類,用來說明 state verification（狀態驗證）跟 behavior verification（行為驗證）的差異,不是原創者。

這正是 AI 容易犯的那種歸屬錯誤:兩個名字經常一起出現在同一段技術討論裡,AI 學到的是「這個概念常常跟誰的名字綁在一起」,而不是「這個概念最早是誰提出的」。 因為 Fowler 的文章流傳更廣、更容易被搜尋到,AI 在生成內容時,會傾向把「引用者」的名字直接當成「原創者」寫進去——這不是編造,是張冠李戴。

為什麼會發生：搜尋到的是「引用」,不是「原始出處」

用一組對照來看這個差異:

❌ 只看「這個概念常常跟誰的名字一起出現」：
「Martin Fowler 在《Mocks Aren't Stubs》裡
 把測試替身分成 Dummy/Stub/Fake/Spy/Mock 五種類型」
→ Fowler 的文章確實討論了這五種類型,搜尋引擎也最容易
  找到這篇文章,但這句話把「引用討論」寫成了「提出分類」

✅ 追到最早提出的原始出處：
「Gerard Meszaros 在《xUnit Test Patterns》裡提出的
 五種測試替身分類,後來被 Martin Fowler 在
 《Mocks Aren't Stubs》裡引用討論」
→ 區分清楚「誰最早提出」跟「誰讓這個概念更廣為人知」,
  兩者都值得提,但角色不同

AI 容易把「誰讓這個概念被更多人看到」跟「誰最早想出這個概念」搞混,因為兩者在搜尋結果裡經常糾纏在一起——越常被引用的二次闡述,搜尋排名往往比原始出處更高。

怎麼查核這類錯誤：不能只看「誰的名字最常出現」

查核歸屬類主張時,單純搜尋「這個概念+誰提出」容易被最常見的引用來源誤導,因為那篇引用文章本身也會在搜尋結果裡大量出現,形成一種「大家都這樣講,所以應該沒錯」的假象。更可靠的做法是:

1. 直接找到被懷疑是「原創者」的那篇文章/著作本身,看它有沒有明講「這個分類是我自己想出來的」還是「這是引用某某人的說法」。
2. 查證那篇文章發表的時間,跟另一個候選出處比對先後順序——如果 A 的著作比 B 的文章早出版,B 引用 A 的可能性遠高於反過來。
3. 看原始出處本身有沒有被廣泛認可為「這個概念的發源地」——技術社群裡通常會有共識,只是這個共識常常被更容易搜到的二次闡述蓋過去。

這個查核方式跟系列主題句的關係

歸屬錯誤是一種特別容易被忽略的錯誤型態,因為讀起來完全通順、語氣完全自信,不會讓人直覺懷疑哪裡不對——這正是這個系列反覆強調的:AI 開發工具（包含事實查核這件事本身）需要清楚的驗證機制,不能只靠「讀起來合理」當作正確的標準。 一句話讀起來越權威、越像是「大家都知道的常識」,反而越需要回頭確認它的原始出處。

今日思考題

回想你寫過或讀過的技術文章裡,有沒有哪個「大家都這樣講」的歸屬說法,你其實從來沒有追到過最原始的出處?下次遇到類似的引用,你會怎麼查證?

今日重點回顧

• 測試替身五分類法（Dummy/Stub/Fake/Spy/Mock）源自 Gerard Meszaros《xUnit Test Patterns》,Martin Fowler 的《Mocks Aren't Stubs》是引用闡述,不是原創
• AI 容易把「這個概念常跟誰的名字一起出現」誤判成「誰提出了這個概念」,因為二次闡述在搜尋結果裡經常比原始出處更顯眼
• 查核歸屬類主張要直接找原始出處本身、比對發表時間先後,不能只看誰的名字出現頻率最高
• 歸屬錯誤讀起來通順自信、不會引發直覺懷疑,越是這種「聽起來像常識」的主張,越需要回頭查證原始出處

明日預告

明天要換一種案例:CLAUDE.md 裡的規則,不是一次寫完就定案的——看一次真實的規則演化過程,一條規則怎麼被一次次糾正,逐漸長成現在的樣子。