Peter Wason 在 1960 年做了一個實驗，至今仍讓認知科學家談起來心有戚戚焉。
他給受試者看三個數字：2、4、6，告訴他們這組數字符合某個規律。受試者的任務是猜出規律，方法是自己提出新的三個數字，由 Wason 告訴他們「符合」或「不符合」，直到他們有信心說出答案為止。
大多數受試者立刻有了猜測：「應該是偶數」，或者「每次加 2」。然後開始驗證：
- 8、10、12：「符合」
- 14、16、18：「符合」
- 100、102、104：「符合」
「找到了！規律是每次加 2 的偶數！」
Wason 的規律其實是：任意三個遞增的數字。1、2、3 符合。1、50、1000 也符合。受試者幾乎從未試過這些。他們只問了那些答案會是「符合」的問題，從來沒有主動去問一個可能讓自己假設崩潰的問題。
這就是確認偏差最純粹的形態：不是刻意造假，而是連「試著否定自己」這個念頭都沒有升起過。
認知偏差不是偶然的失誤，是大腦處理資訊方式中內建的系統性 Bug。這 7 種，是在數據分析和決策過程中最容易讓你走偏的。
24. 確認偏差（分析階段）（Confirmation Bias）：只看你想看的
Wason 的受試者並不笨，他們只是從來沒想到要「試著推翻自己」。我們傾向於尋找、解釋和記憶那些支持我們預設觀點的資訊，而忽略或低估反對證據。
在產品開發中，這個偏差極為致命。當你對某個功能有強烈的情感投入，你會不自覺地只截取好評發群組，把差評當成水軍或不懂產品的用戶。確認偏差在這裡的危險不只是你會做出錯誤的結論，而是你的決策過程看起來完全正常，你也在收集反饋、也在分析數據，只是你的過濾器在你看不見的地方運作。
在 A/B 測試中，如果結果不如預期，帶有確認偏差的人會嘗試「拷問數據」，直到找到某個細分維度顯示新版本「其實還不錯」，然後把這解釋成成功。
對抗確認偏差最強的方法是：主動尋找反證。在做出任何結論前，花同等精力去問「有什麼證據能證明我是錯的」。
25. 錨定效應（Anchoring Bias）：第一眼看到的數字會控制你
想像你在評估一個新系統的效能。工程師告訴你的第一個數字是「目前的延遲大約是 500ms」。這個「500ms」就成了一個錨點。之後的測試中，如果延遲降到了 400ms，你會覺得「哇，性能提升很大！」。但如果一開始的錨點是 100ms，你對 400ms 的評價就會完全不同，「怎麼這麼慢？」
在預算規劃和工時評估中，錨定效應無處不在。一旦有人先喊出了一個數字（例如：「這個功能大概要做 3 天吧？」），後續的所有討論都會圍繞這個數字進行微調，而難以跳脫出來進行客觀評估。即使我們知道第一個數字是不合理的，大腦還是會不由自主地被它「錨定」。
解法：在聽到任何數字之前，先讓自己獨立估計。讓第一個錨點是自己的，而不是別人給的。
26. 可用性啟發法（Availability Heuristic）：容易想起來的 ≠ 發生機率高的
為什麼我們覺得飛機比開車危險？因為飛機失事的新聞總是畫面驚悚、報導連篇，這些生動的記憶在我們腦海中更容易被提取（Available）。大腦錯誤地認為：「容易想起來的事情 = 發生機率高的事情」。
在工程環境中，我們常高估某些 Bug 的嚴重性，只因為那個 Bug 導致了一次印象深刻的半夜 On-call 經歷。同時，我們可能低估那些頻發但影響輕微、沒什麼「戲劇性」的慢性性能問題，儘管後者造成的用戶流失可能遠高於前者。
可用性啟發法讓我們的風險判斷被記憶的生動性劫持，而不是被真實的發生率驅動。
27. 代表性啟發法（Representativeness Heuristic）：刻板印象覆蓋了真實機率
這是經典的「琳達問題（Linda Problem）」：琳達 31 歲，單身，直言不諱，非常聰明。她主修哲學，學生時代非常關心歧視和社會正義問題，也參加過反核示威。以下哪個選項更可能為真？
A. 琳達是銀行出納員
B. 琳達是銀行出納員，並且是活躍的女權主義者
大多數人選 B，因為 B 的描述「更像」琳達。但從邏輯上，B 是 A 的子集，B 的機率不可能大於 A。我們因為「描述像不像」而忽略了統計上的基準率。
在技術評估中，我們常根據「描述像不像」來判斷機率。看到「思考邏輯嚴謹、不愛社交、使用 Linux」的工程師，我們直覺認為他更可能是後端工程師。但如果前端工程師的基礎數量更大，這個判斷就違反了基準率。刻板印象是啟發法的燃料，而啟發法和機率計算不是同一件事。
28. 麥納馬拉謬誤（McNamara Fallacy）：只量可以量的，忽略不可量的
越戰期間，美國國防部長羅伯特·麥納馬拉建立了一套嚴格的量化指標系統來評估戰爭進展：敵軍死亡人數、轟炸次數、控制地區面積。他完全忽略了「士氣」、「民心」、「戰略目標達成度」這些無法量化但至關重要的因素。
結果：美軍在數字上「贏了」每一場戰役，卻輸掉了整場戰爭。麥納馬拉後來在晚年承認，他們犯的根本錯誤是把「可以被測量的東西」當成了「真正重要的東西」的替代品。
在產品開發中，這個謬誤以 DAU（日活躍用戶數）的形式出現。用戶可以每天打開 App 又立刻關掉，DAU 完美，但用戶從產品中得到的實際價值可能是零。我們用「代碼行數」衡量工程師產能，卻忽略了代碼品質和架構設計，結果是工程師為了讓指標好看，開始寫更多更冗長的代碼。
麥納馬拉謬誤的結構是：找到可以測量的指標 → 把它當作真正目標的代理 → 開始優化指標 → 指標變好了，真正的目標在惡化。
29. 古德哈特定律（Goodhart’s Law）：指標一旦成為目標，就不再是好指標
這和麥納馬拉謬誤不同，但緊密相關。麥納馬拉謬誤是「只量可以量的，忽略量不到的」；古德哈特定律是「量了之後，指標本身被腐化了」。
客服團隊用「平均回應時間」作為考核指標。客服開始快速關閉工單，問題沒解決，工單關了，指標完美。客戶滿意度暴跌。
SEO 過去用關鍵字密度衡量內容品質，網站開始塞滿關鍵字的垃圾文章，關鍵字密度很高，讀者體驗極差。Google 的排名算法被迫不斷演化，正是為了對抗古德哈特定律的效應。
用 App Store 評分衡量 App 品質，公司開始在關鍵時刻彈出「給個五星吧」的請求，刻意選在用戶最高興的時候。評分看起來很高，但它代表的已經不是真實的用戶評價，而是「用戶在被請求時有多配合」。
古德哈特定律不是人性的問題，它是系統的問題。當一個指標和獎勵掛鉤，優化指標就成了理性行為，無論代價是什麼。設計激勵制度時，理解這個定律是基本功。
30. 路徑依賴（Path Dependence）：走過的路，限制了你能走的路
初期的決策限制了後續的選項。這不只是工程架構的問題，更是一個認知陷阱：即使有新數據顯示當前方向是錯的，人們也往往繼續沿著錯誤路徑前進。
QWERTY 鍵盤是最常被引用的例子：它最初是為了讓打字機避免卡鍵而設計的，在現代鍵盤上已無此需求，但幾十年的用戶習慣讓它幾乎無法被更好的鍵盤配置取代。
在軟體開發中，路徑依賴以「技術債」的形式出現：初期為了快速上線做的妥協，成為了後來所有架構決策的邊界條件。重構的成本隨著時間越積越高，到最後高得沒有人願意動它，即使所有人都知道它是錯的。
在決策中，路徑依賴的認知版本是沉沒成本謬誤：「我們已經在這條路上投入了這麼多，不能現在放棄。」這是一個情緒論點，不是數據論點。已經付出的成本是沉沒的，不管你繼續還是停止，那些成本都已經消失了。決策應該只基於未來的成本和收益，不是過去的投入。
認知偏差之所以難以克服，是因為它們在潛意識中運作。了解它們是第一步，但光靠意識是不夠的，大腦在壓力下的速度比理性快。更有效的是在流程上做設計：設立「反對者」角色強迫大家面對反證，建立決策前必須回答的固定問題清單，讓制度代替意志力來對抗大腦天生的自我保護機制。
