聊聊 AI 時代的認知投降與認知卸載

前言

在這個月的團隊例行 Retrospective 會議上，考量到組織近期可能迎來變動，我提議聊點不一樣的話題。

以往的 Retrospective 主要專注於「如何優化下個 Sprint」，但面對未來的未知，我認為更值得探討的是：

在 AI 時代，工程師該培養什麼技能，才能讓職涯保持競爭力？

於是，我挑選了三篇文章作為討論基底：

Cognitive Surrender 認知投降

Cognitive Surrender 這篇文章是引述自賓州大學華頓商學院的研究，主要提到兩個重要的概念「認知投降與認知卸載」。

1. 認知卸載（Cognitive Offloading）

定義：你將「如何做」委託給 AI，但依然牢牢掌控「要做什麼」。

特徵：

你會主動評估工具給出的結果是否合理。
一旦發現異常或錯誤，你會介入並修正。

2. 認知投降（Cognitive Surrender）

定義：你完全停止自己去建構答案，悄悄地將 AI 的輸出直接當成你自己的產出。

特徵：

因為你從頭到尾都沒有建立自己的獨立觀點，所以根本無從比較、也覺得沒什麼好檢查的。
容易盲目借用 AI 的高自信度，誤以為自己也懂了。

人們容易選擇認知投降

在橫跨三項實驗、共 1,372 名參與者的研究中，研究發現光是「有 AI 可用」這件事，就足以讓人們選擇認知投降。

在 AI 給出錯誤答案的測試中，參與者高達 73% 的時間都直接接受了這個錯誤答案。

更糟糕的是：當有 AI 可用時，人們的自信心反而上升了——即使其中有一半的答案是故意出錯的。他們借用了模型的高自信（AI 的自信心通常都很高），並誤以為那是自己的把握。

解法 1：建立防線

AI 現在最強的是「如何做 How」，但對於「要做什麼 What」，AI 有時候的判斷能力還沒有辦法勝過人類，因為有些既有的知識是 AI 不知道的。

因為目前的 LLM 說到底就是一個在預測下一個 token 可能會出現什麼的模型，所以當 context 不太夠的時候，可能導致生出來的下一段 code 會不如自己想做的。

之前我也有兩篇文章，正在探討 AI 的極限與邊界：從四篇 2025–2026 論文洞察 AI 的極限與邊界、AI 時代的工程師，該往哪裡走？。從四篇論文裡面就會發現，AI 目前最重大的缺陷就是判斷力。

建立防線的實際案例

最近我碰上一個很深刻的實例。當時我正在修改某個微服務（Microservice）的 API，打算擴充資料庫中一個 JSONB 格式的 summary 欄位：

DataModule {
  summary: jsonb
}
 
summary {
  // 舊格式
  summaryA: string
  // 新需求：追加
  summaryB: string
}

原本我以為只要確保這個新欄位的 CRUD 流程正常運作即可。直到與維運該服務的資深同事討論後，才發現背後隱藏了許多未知的業務邏輯：

該欄位需要同步寫入訂單快照。
該欄位會被另一個團隊（B Team）更新，若直接覆寫 summary，會導致 summaryB 遭到覆蓋。
此模組會被送往另一個系統進行 AI 翻譯，但 summaryB 依需求必須排除在翻譯之外。

如果只看正向流程，滿足 CRUD 的基本要求並不難。然而，因為缺乏這些既有的背景知識，我當時正處於「不知道自己不知道」的盲區，完全喪失了判斷力。這時若一味依賴 AI 下 Prompt 產出程式碼，就會徹底陷入「認知投降」。

在這個案例中，最好的「防線」就是與相關團隊充分交流，補足資訊落差，避免盲目信任 AI 的正向輸出。

解法 2：像審查新人的程式碼一樣嚴格

我們常聽人說「AI 寫 Code 比人類更強」。

但以我的實際體感，AI 目前的思考模式更像是一位實作能力極強、但缺乏全局觀的 Mid-level 工程師。它無法像 Senior 工程師一樣通盤考量各種邊界條件（Edge Cases），甚至在脈絡（Context）不足或記憶體快滿時，會開始偷懶或編造答案。

你必須一直不斷地逼問他、補充更多的細節，不然他甚至有時候會欺騙，或是因為 memory 快滿的時候開始嘗試偷懶。

所以，我們不能因為是 AI 寫的就輕易放行，而是要想像這是一個剛進團隊的工程師寫的 PR，要謹慎地使用相同的標準在 AI 身上。

Code Review 的實際案例

近期有越來越多來自不同團隊（包含工程師與非技術的同事）的成員開始向我們提交 PR。在審核這些外部貢獻時，我傾向採取比內部成員更嚴格的標準。

主因在於，這些程式碼極可能正處於上述的「認知投降」狀態，潛藏著盲點。

我們在實際審查中也發現，即便 PR author 表明「已經自行測試、確認無誤」，但從整體架構面來看，往往還是遺漏了許多細節。而這些細節，正是我們必須為團隊設立防線、嚴格把關的關鍵。

解法 3：留意疲勞狀態

在文章裡面其實就有提到，我們人很容易會因為看太多東西感到疲勞，但是 AI 不會。

所以，我們必須要時刻注意自己的疲勞狀態。例如一天可能看到第五個 PR 時，優秀的工程師應該要有自知之明，當大腦太累、已經失去評估能力時，就先停止讓 AI 產生內容。

留意疲勞狀態的實際案例

在跟同事聊這題時，他說在 AI 剛爆發時，其實是處於「認知卸載」的狀態，會試著掌控更多 AI 到底想做什麼。

但隨著時間慢慢推進，最後開始往「認知投降」的部分前進。因為產出的東西實在太多了，讓我們慢慢變得有點超出認知負荷。

最近，我們除了日常工作，還需要 review 來自 Data Team、PM 或 UI/UX 團隊等跨領域的 PR。運氣好時能迅速 Review 並 Merge，但狀況不佳時，光是一條 PR 就能來回拖上很久。

當 PR 的 Comment 數量暴增、大腦陷入疲勞，我們就會慢慢往「認知投降」靠攏。

這背後其實存在一個「認知投降的惡性循環」：當外部提交的 PR 本身就帶著盲目的認知投降，而負責 Review 的人又因為量大、疲勞而防線崩潰時，審查者最終也會跟著走向認知投降。

目前雖然還沒有完美的解法，但「意識到自己正處於疲勞狀態」，就是守住這條防線的第一步。

小結

「認知卸載」與「認知投降」的本質，其實就是「知道自己不知道」與「不知道自己不知道」的界線。

身處 AI 浪潮第一線的工程師，如何時刻保持警覺、將主導權留給自己（認知卸載），而不是將思考權讓渡給工具（認知投降），將是決定未來競爭力的關鍵。

文章先跟大家分享「認知投降」跟「認知卸載」，之後再整理對於另外兩篇的討論以及一些想法。