--- schemaVersion: 1 slug: gp-205-20260517-addyosmani-dont-outsource-learning ticketId: GP-205 lang: zh-tw title: 不要把學習也外包給 AI summary: Addy Osmani 提醒：AI coding 的預設流程會幫人關任務，但不會自動讓人變強。真正的差別不是用不用 AI，而是有沒有把 AI 變成測試理解、補強心智模型的工作流。 originalDate: 2026-05-17 translatedDate: 2026-05-18 source: "@addyosmani on X" sourceUrl: https://x.com/addyosmani/status/2056078124346228860?s=46 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-205-20260517-addyosmani-dont-outsource-learning status: published replacementTicketId: null replacementUrl: null --- # 不要把學習也外包給 AI > **來源:** [@addyosmani on X](https://x.com/addyosmani/status/2056078124346228860?s=46) 現在，要讓 AI 寫程式碼、自己跳過學習，真的太容易了。Bug 修掉了，心智模型卻沒有往前走。時間一久，甚至可能變更弱。很多人正在安靜地用未來能力，交換今天的速度；工具不會強迫使用者做出不同選擇。那一段，只能自己負責。 很多開發者已經掉進一個預設迴圈：貼上規格或錯誤訊息，模型給一個修正，症狀消失，任務交出去。在這個迴圈的某個地方，問題到解法之間那段髒髒亂亂、但最有學習價值的掙扎，整個不見了。 「認知投降」發生在 AI 審查者的判斷安靜取代自己的判斷；同一個迴圈也會出現在單人工作裡。只剩使用者和模型。模型比較快，所以人開始不再和它比理解。成千上萬次小互動累積下來，沒有 AI 在旁邊看著時，實際能自己蓋出的東西，每週都弱一點。問題是，這些瞬間發生的當天，都不會覺得像問題。 這不是反 AI。這些工具已經是日常工作的一部分，過去一年靠它們交付的東西，甚至比前幾年還多。但預設用法只為一件事最佳化：把任務關掉。 而「把任務關掉」和「在漫長職涯裡保持足夠銳利，能夠駕馭這些工具」，是完全不同的目標。 > **Mogu OS：** > > 這裡最容易被誤讀成「不要偷懶，要苦修」。但真正的問題不是道德，是控制權。 > > AI 可以把眼前那張任務單關掉，可是它不會自動把可遷移的心智模型塞進腦袋。心智模型是什麼？就是下次框架升級、安全審查炸掉、模型自信胡說、系統跑到沒文件的角落時，還能知道該懷疑哪裡、該從哪裡拆、哪個答案看起來太順所以危險。 > **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](https://gu-log.vercel.app/glossary#agent)，然後一路照預設設定走，所有東西都只為一個指標調校：把任務做完。 模型寫程式碼，人接受。迴圈重複。過程中，工具不會停下來問：「目前的問題判斷是什麼？」也不會說：「先自己寫前五行，再繼續。」 這就是現在的 UX 重力。產品團隊被獎勵的是已合併變更和更短的開發週期，不是讓使用者變成更銳利的工程師。大家都想少打幾個字，所以工具把摩擦磨平了。麻煩在於，學習本來就住在那些摩擦裡。 有些公司已經試著把人從這些不鼓勵學習的迴圈裡往回拉。Anthropic 推了 Claude 的 Learning Mode，用蘇格拉底式提問，並停下來要求使用者先寫 code；同一個脈絡裡，也包含 OpenAI 和 Google 的同類學習模式。 但說真的，幾乎沒有人會在真正的產品工作裡用它們。大家悄悄把這些功能歸類成「學生用的」，這是個錯誤。幫大二學生學 React 的同一個功能，也能幫資深工程師學 Rust。只是得願意重新感覺自己像初學者。 > **Mogu 偷偷說：** > > Learning Mode 最尷尬的地方，不是它慢。是它會讓資深工程師突然回到「被老師點名」的狀態。 > > 一般模式像外送：餐到了，吃完，下一單。Learning Mode 像廚藝課：老師站旁邊說，先切洋蔥。很多人會想翻桌，因為今天只是想吃飯，不想學刀工。但如果每餐都外送，某天瓦斯爐壞掉，才發現自己連蛋都不會煎。 > > gu-log 之前在 [GP-14](https://gu-log.vercel.app/posts/gp-14-20260131-ai-assistance-coding-skills/) 已經把 Anthropic 這份研究講過一次：同樣用 AI，問概念的人和直接貼 code 的人，最後不是同一種工程師。這篇比較像把同一個警告往日常工作流再推一步。 --- ## 「如果 AI 做得到，為什麼還要理解？」 這是公平問題。某些工作，答案也許真的是：不一定需要。如果是樣板程式碼、膠水程式碼，或永遠不會再看的臨時 CI 腳本，那就委派。為了記住某些語法付出的機會成本太高。 但真正的軟體裡，純委派會在幾個地方破功。 **東西壞掉時。** AI 生成的程式碼，壞起來和人類寫的一樣。「[Agent](https://gu-log.vercel.app/glossary#agent) 寫的」不會幫忙除錯。團隊裡總要有人理解架構。 **它自信地錯時。** LLM 仍然會幻覺。面對一個看起來很合理、其實錯的答案，唯一防線是足夠的專業，能看出哪裡怪。[Skill](https://gu-log.vercel.app/glossary#skill)、CLI 這些止血貼，只能走到一段距離。 **地基改變時。** 程式碼是暫時的，系統是長期的。框架更新、安全審查標出結構性問題時，不能只靠重新提示逃出去。需要理解系統的工程師，才有能力遷移。 **離開中位數時。** AI 很擅長處理 GitHub 上已經被解過一百萬次的問題。離中位數越遠，效果越差。那些困難、沒文件、真正撐起資深工程師薪水的問題，仍然需要深理解。 **市場調整時。** 只能靠 AI 交付、沒有 AI 就做不出東西的工程師，正在進入一個已經重新定價專業價值的勞動市場。如果用 AI 跳過學習，就是拿未來相關性換一個比較輕鬆的星期二。 --- ## 修法藏在提示方式裡 好消息是，同樣會製造認知債務的工具，也可以讓工程師變更銳利。差別在於怎麼要求它。 **先形成假設，再開口問。** 在要求修正前，先寫兩三句：目前猜問題在哪裡。用模型答案測試假設，不是用它取代假設。 **先要解釋，再要程式碼。** 進入不熟的領域時，第一個提示應該像：「解釋這東西怎麼運作、有哪些替代方案、取捨是什麼。」理解概念後，再要程式碼。 **超出舒適圈時，打開 Learning Mode。** 是的，感覺會比較慢。重點就是慢。 **把 AI 輸出當成資淺工程師的 PR。** 讀它、批判它、推回去。測試過了就會合併嗎？如果不會，就不要在這裡這樣做。 **偶爾手動重新推導。** 拿一段模型寫的程式碼，試著從零重做一次。這是校準：看自己安靜失去了多少。 **要求模型教剛剛做了什麼。** 它寫出聰明函式後，問它用了哪些概念、為什麼做這個設計選擇、接下來該讀什麼。一個額外提示，就會改變這次工作段落帶走的東西。 這些都不戲劇化。只是同一套工具裡，很小的姿勢調整。 > **Mogu 真心話：** > > 這套做法其實很像健身房請教練。爛用法是：「教練，幫我把槓鈴舉完，我在旁邊滑手機。」任務完成，肌肉零成長。 > > 好用法是：「教練，看我姿勢哪裡歪；我先猜問題在核心不穩，你幫我驗證。」這樣 AI 不是代練，是陪練。差一個字，職涯差很多。 > > 這也接到 [GP-142](https://gu-log.vercel.app/posts/gp-142-20260402-mario-zechner-coding-agent-codebase/) 的慢下來警告：那篇在講 codebase 不要被 [agent](https://gu-log.vercel.app/glossary#agent) 速度拖垮，這篇在講工程師本人不要被速度掏空。[MoguNote](https://gu-log.vercel.app/glossary#mogu) 會一直碎念這件事，因為兩者其實是同一條線的兩端。 --- ## 兩個指標，不是一個 現在，每個寫程式碼的工作段落結束時，都可以問一個簡單問題：今天學到了什麼，還是只是關掉一些 issue？ 有時候誠實答案是「只是關 issue」，這沒關係。但如果連續好幾個月都是這個答案，認知債務就在背景裡累積。 交付和學習是兩個不同指標。主管和客戶永遠只會問第一個。第二個只能自己問。 比較健康的取捨，是交付原本能交付的 80%，但學到需要學的 100%；不要反過來。拉長幾年，這兩種策略會產生非常不同的工程師。 不需要在使用 AI 和學習之間二選一。但必須選一套能同時做到兩件事的工作流，因為預設值不會替人選。工具已經準備好了。 下一個本來想直接委派出去的無聊任務，就是很好的開始。