我先講一個讓我有點不舒服的數字。

賓夕法尼亞大學的研究員 Shaw 和 Nave 做了一個叫做 Thinking - Fast, Slow, and Artificial 的研究，1,372 位受試者，超過 9,500 個試驗。

設計很簡單：讓受試者做判斷題，一組有 AI 輔助，一組沒有。AI 給的答案裡，有一半是故意錯的。

數字如下：

  • 73.2% 的情況下，受試者接受了 AI 有缺陷的推理
  • 只有 19.7% 的情況下，人們會推翻 AI 的答案
  • 當 AI 明確給出錯誤答案時，人們仍然有 80% 的時候接受了它
  • 使用 AI 的受試者，對自己答案的信心高出 11.7%——即使 AI 答錯了一半

更讓人不安的是信心效應。用一個錯一半的系統，還覺得自己比完全不用 AI 的人更準——這是一個讓人越來越不知道自己不知道什麼的系統。

還有一個發現，我覺得對工程師特別有感：時間壓力讓人少了 12 個百分點抓到 AI 錯誤的機率。反過來，給了明確的金錢激勵和即時反饋，人們多了 19 個百分點去抓錯誤。

這個 time pressure 的發現很重要。很多公司引入 AI 的理由就是「加速交付」，工程師在更快的 deadline 下使用 AI——而這正好是最容易接受錯誤、最難察覺問題的使用條件。

這個研究讓我回想起幾個月前發生在我自己身上的一件事。

那次我沒有想清楚

在帶跨國團隊的時候，有一次碰到一個架構決策：某個 batch job 要跑的東西，到底要用 message queue 還是直接 function call？

我問了 Claude Code，它給了一個很漂亮的分析：延遲容忍度、背壓控制、觀測性……洋洋灑灑，每一點都有邏輯。

我看了大概兩分鐘，然後說：「好，用 queue。」

之後有個工程師問我：「那個 queue 的 consumer 怎麼 scale？」

我愣了一下。

我知道「應該用 queue」，但我完全沒有想過 consumer 的 scale 策略。那個答案是 Claude Code 告訴我的，我只是轉述了它的結論，沒有真的把這個架構消化成自己的理解。

這就是 Cognitive Surrender，認知投降。

Cognitive Surrender vs Cognitive Offloading

Addy Osmani（Google Chrome 技術長）在他的文章裡面做了一個很重要的區分，我覺得值得每個 AI 重度用戶都認真看一遍：

Cognitive Offloading（認知卸載）：把任務交給 AI，但我自己同時在建立理解，保持獨立判斷的能力。

Cognitive Surrender（認知投降）：整包接受 AI 的輸出，不形成自己的理解，用 AI 的信心替代我自己的推理。

差別聽起來很細，但後果差很多。

卸載是工具使用，投降是能力轉移。卸載之後你還在，投降之後……你還在，但你慢慢不知道自己懂什麼了。

工程師最容易投降的四個地方

Osmani 列出了四個在軟體開發裡特別危險的投降點，我一個一個對照了我自己的情況：

1. Code Review

你有沒有看過一個 600 行的 PR，測試都過了，AI 說看起來沒問題，然後你就 approve 了？

我有。而且不只一次。

測試過不代表邏輯對，測試過不代表你看懂了這段程式碼在幹嘛。這是最常見的投降點，因為有一個「通過測試」的假陽性在給你安全感。（延伸閱讀：AI Coding 的驗收流程怎麼做？）

2. Error Debugging

「為什麼這個 null pointer exception 出現在這裡？」

AI 說：「在第 47 行加一個 null check。」

你加了，問題消失了，繼續往前走。

但你知道為什麼 null 出現在那裡嗎？不知道。下次同樣的 bug 出現在別的地方，你還是不知道。每一次這樣修，你就積累了一點「理解缺口」。

3. Architecture Decisions

這是我剛才說的那個故事。最危險的一種，因為架構決策的影響最長遠，但也是 AI 最容易給出聽起來有道理的答案的地方。

問題不是 AI 說的對不對，問題是你自己有沒有消化成「你的理解」。

4. 學習階段

這個是反直覺的。

你在學一個新技術，用 AI 生成程式碼來「看看怎麼寫」——這反而是學習效率最差的方式。研究發現，用 AI 生成模式學習的人，理解分數比用提問模式學習的人低 17%。

讀 AI 給你的答案，跟自己先想然後問 AI 對不對，是完全不同的認知活動。

理解債

我很喜歡 Osmani 用的這個詞：Comprehension Debt，理解債。

技術債大家都懂：今天為了趕時間少做了一些設計，之後要加倍還。

理解債類似，但更難察覺：你的程式碼量在增加，但你對系統的真實理解在萎縮。

MIT 有研究發現，習慣用 AI 的工程師出現了神經連結度下降和記憶重建能力減弱的現象。聽起來很誇張，但你想想：每一次你選擇讓 AI 替你想，你自己的那條神經路徑就少走一次。

而且這個債是複利的。每一次投降，下一次投降就更容易，因為你越來越不確定自己能不能獨立判斷。

怎麼知道自己是不是已經在線上了？

在講怎麼對抗之前，先說怎麼診斷。以下五個訊號，出現任何一個，你很可能已經在認知投降的軌道上：

1. 600 行 PR，掃了一遍就 approve 「測試是通過的」不等於 review。你如果說不出這個 PR 改了什麼、為什麼這樣改，你沒有在 review，你在蓋章。

2. Bug 修了，但不知道為什麼修的 你加了那行 null check，問題消失了，繼續往前走。但兩週後，同樣的問題會以新的形式回來找你。

3. 為某個決策辯護，重建不出 why 開會時有人問你為什麼選這個方案，你說的是「當時看起來合理」或「agent 說這樣比較好」——你借用了 AI 的信心，但那個 why 從來不是你的。

4. 沒有 agent 時，不太敢動鍵盤了 你獨自寫程式的能力，是你真實水位的體溫計。如果這個能力在萎縮，你知道發生了什麼。

5. 系統壞了，第一反應是「再讓 agent 修」 不再有「從第一性原理出發，這個問題應該怎麼解決」這個步驟。投降已經變成預設反應，不是主動選擇。

出現紅色訊號的時候，立刻做一件事：關掉 agent，拿紙或開新文件，手動重建你跳過的那段 why。 不是懲罰自己，是把你的理解補回來。

五條護身術

我不是說不要用 AI，我現在每天都大量使用 Claude Code（三個月 63 萬行的反思在這裡）。

但在某幾個場景，我現在會刻意加一道防線：

① 先寫預期

看 AI 輸出之前，心裡先有個答案。哪怕只是「我覺得這邊應該回傳 null」，或者「這個 query 大概會跑三行還是五十行」。有了預期，當 AI 說別的東西的時候，你就自動進入「為什麼不同」的模式，而不是接受模式。不一致的那一刻，才是真正的判斷時刻。

② 當不是 AI 寫的來讀

看到一個 PR，先假設這是實習生提的。「測試通過」你就直接 merge 嗎？「看起來沒問題」算 review 嗎？用同樣的標準對 AI 生成的程式碼，不要因為它是機器寫的就降低你的驗收門檻。

③ 讓模型反駁它自己

「給我一個相反的、同樣有說服力的論點。」

這句話很便宜，但能擊穿借來的信心。每次你分不清楚要用哪個方案的時候，其實是你已經快要投降的訊號——這個時候就請 AI 反駁它自己，強迫你去評估兩邊，而不是被動接受最先聽到的那個。

④ 注意疲勞

認知投降是疲勞現象。早上第一個 PR 你認真看，第五個你一眼掃過。累到無法評估的時候，你不是在用 AI 加速，你是在讓 AI 替你決定。

疲勞的時候不要讓 agent 繼續生成，要去休息。

⑤ 看自信從哪裡來

開會為某個決策辯護的時候，你能重建 why 嗎？還是只記得「agent 這樣說，聽起來合理」？

如果說不出來，那個信心是借來的。把 agent 關掉，回去把 why 自己重建出來。

核心自檢，一句話：我是在獨立形成觀點，還是在原封不動接受 agent 的視角？

個人意志不夠，還需要結構：Harness Engineering

上面五條護身術是個人層面的東西。但有一個殘酷的現實：個人意志在組織規模下會失效。

亞馬遜試圖用禁令解決這個問題：「初級和中級工程師，不得在沒有資深工程師簽字的情況下提交 AI 生成的程式碼。」方向對，但方法錯。

為什麼？因為資深工程師很快就變成了瓶頸。他們一天要審大量 AI 生成的 PR，第一個認真看，第五個快速掃過，第十個基本上只是蓋章。

這就是 Wharton 研究裡 time pressure 效應的組織版本：你用禁令製造了一個必然產生認知投降的流水線。 把問題從初級工程師轉移到資深工程師身上，但沒有解決。

Harness Engineering 走的是完全不同的路。它的核心哲學是：

Humans steer. Agents execute.

不是靠「誰來盯」，而是靠「系統設計讓 AI 做不了某些事」。

具體來說，Harness Engineering 的重點不是阻止 AI 寫程式，而是建立結構性護欄——分級審查機制、不可逆操作的強制確認、變更範圍的硬性限制。它讓認知投降的「代價」在系統層面被攔住，不依賴每個人每次都保持高度警覺。

這跟認知投降的關係很直接：

  • 個人層面：五條護身術，讓你習慣保持判斷
  • 組織層面：Harness Engineering，讓系統不依賴個人意志

只有個人習慣，沒有組織護欄，疲勞和時間壓力遲早會讓人投降。只有組織護欄，沒有個人習慣，工程師照樣會慢慢失去獨立判斷的能力——只是失敗不會炸生產環境而已。

兩個層面都需要。

AI 應該讓你用完更強，不是更弱

我覺得最好的 AI 使用狀態，Osmani 說的很精確：Mutual Amplification，互相放大。

每一次的 AI 協作，結束之後你的心智模型應該要比開始之前更清晰，不是更模糊。你不只完成了任務，你也理解了這個任務。

如果每次用完 AI，你對自己在做什麼越來越不確定，那你不是在用工具，你是在把自己的理解轉移給工具。

「如果你的程式碼在 shipping，但你對系統的理解在萎縮，你是在用認知債支付進度。」

這句話我之後每次 code review 之前都打算想一次。

有沒有想到你最近有沒有在某個地方投降過？

我覺得誠實回答這個問題，比任何工具選擇都更重要。

延伸閱讀