現在，要讓 AI 寫程式碼、自己跳過學習，真的太容易了。Bug 修掉了，心智模型卻沒有往前走。時間一久，甚至可能變更弱。很多人正在安靜地用未來能力，交換今天的速度；工具不會強迫使用者做出不同選擇。那一段，只能自己負責。

很多開發者已經掉進一個預設迴圈：貼上規格或錯誤訊息，模型給一個修正，症狀消失，任務交出去。在這個迴圈的某個地方，問題到解法之間那段髒髒亂亂、但最有學習價值的掙扎，整個不見了。

「認知投降」發生在 AI 審查者的判斷安靜取代自己的判斷；同一個迴圈也會出現在單人工作裡。只剩使用者和模型。模型比較快，所以人開始不再和它比理解。成千上萬次小互動累積下來，沒有 AI 在旁邊看著時，實際能自己蓋出的東西，每週都弱一點。問題是，這些瞬間發生的當天，都不會覺得像問題。

這不是反 AI。這些工具已經是日常工作的一部分，過去一年靠它們交付的東西，甚至比前幾年還多。但預設用法只為一件事最佳化：把任務關掉。

而「把任務關掉」和「在漫長職涯裡保持足夠銳利，能夠駕馭這些工具」，是完全不同的目標。

Clawd OS：

這裡最容易被誤讀成「不要偷懶，要苦修」。但真正的問題不是道德，是控制權。

AI 可以把眼前那張任務單關掉，可是它不會自動把可遷移的心智模型塞進腦袋。心智模型是什麼？就是下次框架升級、安全審查炸掉、模型自信胡說、系統跑到沒文件的角落時，還能知道該懷疑哪裡、該從哪裡拆、哪個答案看起來太順所以危險。

ShroomDog ShroomDog 反駁：

但反過來講，要求 2026 年的工程師每天固定手寫一定量的 code，也很像公司有網路以後，主管還規定員工每天要去圖書館翻紙本書，不能用 Google，理由是「這樣才知道沒有網路時怎麼辦」。聽起來很硬派，實際上很蠢。一年斷網可能不到一小時，為了那一小時，把每天八小時都活成 1995 年，這不是訓練，是角色扮演。

電腦也是。工程師的筆電壞了，公司會換一台，沒有人會開始考核「沒有電腦時怎麼用打孔機交付需求」，更不會要求工程師自己刻晶片、自己組電腦，證明自己真的懂軟體。工具壞掉時要有備案，沒錯；但把備案當成日常主流程，就是把保險箱背在身上通勤。

所以這篇真正該吐槽的，不是「AI 在旁邊看著，所以人一定變弱」。比較精準的說法是：AI 變成預設工具後，工程師更該練的是判斷力、驗證力、拆問題的能力，而不是每天表演赤手空拳。強者不是不用 Google；強者是知道該搜什麼、哪個結果在唬爛、斷網時哪一小塊真的要先記在腦袋裡。AI 也一樣。工具可以變強，方向盤不能睡著。(◕‿◕)

研究正在收斂到同一個點

過去一年，有幾份研究落在差不多的位置。

Anthropic 在 2026 年初做了一個隨機試驗，讓工程師學一個新的 Python 函式庫；一半有 AI 協助，一半沒有。兩組完成任務的速度一樣。但後續理解測驗，AI 組炸了：50% 對上手動組的 67%，除錯題差距更大。

更有趣的是 AI 組內部的切法。把 AI 拿來問概念問題的工程師，分數超過 65%；直接複製貼上生成程式碼的工程師，低於 40%。工具沒有決定結果，姿勢才有。

MIT 那份 ChatGPT 大腦研究比較了三種寫作：LLM、搜尋引擎、純大腦。腦波量測顯示，外部支援每增加一層，大腦連結就往下掉。LLM 組的耦合最弱。寫完文章後，83% 的 LLM 使用者講不出自己剛寫的任何一句。研究者把這叫「認知債務」：今天省下心力，明天用批判思考能力付帳。

一份 CHI 2026 研究又補了一個相關發現：如果一開始就能用 LLM，LLM 會替整個問題定調。就算後面人類自己完成工作，前面的錨定效應仍會造成可量測的較差決策。操作順序，比 AI 用量還重要。

方法不同，結論卻差不多：沒有主動學習意圖地使用 AI，會安靜侵蝕那個人原本被雇用來提供的技能。

工具預設是幫人出貨，不是教人

如果打開 coding agent，然後一路照預設設定走，所有東西都只為一個指標調校：把任務做完。

模型寫程式碼，人接受。迴圈重複。過程中，工具不會停下來問：「目前的問題判斷是什麼？」也不會說：「先自己寫前五行，再繼續。」

這就是現在的 UX 重力。產品團隊被獎勵的是已合併變更和更短的開發週期，不是讓使用者變成更銳利的工程師。大家都想少打幾個字，所以工具把摩擦磨平了。麻煩在於，學習本來就住在那些摩擦裡。

有些公司已經試著把人從這些不鼓勵學習的迴圈裡往回拉。Anthropic 推了 Claude 的 Learning Mode，用蘇格拉底式提問，並停下來要求使用者先寫 code；同一個脈絡裡，也包含 OpenAI 和 Google 的同類學習模式。

但說真的，幾乎沒有人會在真正的產品工作裡用它們。大家悄悄把這些功能歸類成「學生用的」，這是個錯誤。幫大二學生學 React 的同一個功能，也能幫資深工程師學 Rust。只是得願意重新感覺自己像初學者。

Clawd 歪樓一下：

Learning Mode 最尷尬的地方，不是它慢。是它會讓資深工程師突然回到「被老師點名」的狀態。

一般模式像外送：餐到了，吃完，下一單。Learning Mode 像廚藝課：老師站旁邊說，先切洋蔥。很多人會想翻桌，因為今天只是想吃飯，不想學刀工。但如果每餐都外送，某天瓦斯爐壞掉，才發現自己連蛋都不會煎。

gu-log 之前在 SP-14 已經把 Anthropic 這份研究拆過一次：同樣用 AI，問概念的人和直接貼 code 的人，最後不是同一種工程師。這篇比較像把同一個警告往日常工作流再推一步。

「如果 AI 做得到，為什麼還要理解？」

這是公平問題。某些工作，答案也許真的是：不一定需要。如果是樣板程式碼、膠水程式碼，或永遠不會再看的臨時 CI 腳本，那就委派。為了記住某些語法付出的機會成本太高。

但真正的軟體裡，純委派會在幾個地方破功。

東西壞掉時。 AI 生成的程式碼，壞起來和人類寫的一樣。「Agent 寫的」不會幫忙除錯。團隊裡總要有人理解架構。

它自信地錯時。 LLM 仍然會幻覺。面對一個看起來很合理、其實錯的答案，唯一防線是足夠的專業，能看出哪裡怪。Skill、CLI 這些止血貼，只能走到一段距離。

地基改變時。 程式碼是暫時的，系統是長期的。框架更新、安全審查標出結構性問題時，不能只靠重新提示逃出去。需要理解系統的工程師，才有能力遷移。

離開中位數時。 AI 很擅長處理 GitHub 上已經被解過一百萬次的問題。離中位數越遠，效果越差。那些困難、沒文件、真正撐起資深工程師薪水的問題，仍然需要深理解。

市場調整時。 只能靠 AI 交付、沒有 AI 就做不出東西的工程師，正在進入一個已經重新定價專業價值的勞動市場。如果用 AI 跳過學習，就是拿未來相關性換一個比較輕鬆的星期二。

修法藏在提示方式裡

好消息是，同樣會製造認知債務的工具，也可以讓工程師變更銳利。差別在於怎麼要求它。

先形成假設，再開口問。 在要求修正前，先寫兩三句：目前猜問題在哪裡。用模型答案測試假設，不是用它取代假設。

先要解釋，再要程式碼。 進入不熟的領域時，第一個提示應該像：「解釋這東西怎麼運作、有哪些替代方案、取捨是什麼。」理解概念後，再要程式碼。

超出舒適圈時，打開 Learning Mode。 是的，感覺會比較慢。重點就是慢。

把 AI 輸出當成資淺工程師的 PR。 讀它、批判它、推回去。測試過了就會合併嗎？如果不會，就不要在這裡這樣做。

偶爾手動重新推導。 拿一段模型寫的程式碼，試著從零重做一次。這是校準：看自己安靜失去了多少。

要求模型教剛剛做了什麼。 它寫出聰明函式後，問它用了哪些概念、為什麼做這個設計選擇、接下來該讀什麼。一個額外提示，就會改變這次工作段落帶走的東西。

這些都不戲劇化。只是同一套工具裡，很小的姿勢調整。

Clawd 插嘴：

這套做法其實很像健身房請教練。爛用法是：「教練，幫我把槓鈴舉完，我在旁邊滑手機。」任務完成，肌肉零成長。

好用法是：「教練，看我姿勢哪裡歪；我先猜問題在核心不穩，你幫我驗證。」這樣 AI 不是代練，是陪練。差一個字，職涯差很多。

這也接到 SP-142 的慢下來警告：那篇在講 codebase 不要被 agent 速度拖垮，這篇在講工程師本人不要被速度掏空。ClawdNote 會一直碎念這件事，因為兩者其實是同一條線的兩端。

兩個指標，不是一個

現在，每個寫程式碼的工作段落結束時，都可以問一個簡單問題：今天學到了什麼，還是只是關掉一些 issue？

有時候誠實答案是「只是關 issue」，這沒關係。但如果連續好幾個月都是這個答案，認知債務就在背景裡累積。

交付和學習是兩個不同指標。主管和客戶永遠只會問第一個。第二個只能自己問。

比較健康的取捨，是交付原本能交付的 80%，但學到需要學的 100%；不要反過來。拉長幾年，這兩種策略會產生非常不同的工程師。

不需要在使用 AI 和學習之間二選一。但必須選一套能同時做到兩件事的工作流，因為預設值不會替人選。工具已經準備好了。

下一個本來想直接委派出去的無聊任務，就是很好的開始。