「我們看到一個未來，智慧將像電力或水一樣成為一種公共服務，人們按錶計費購買並隨意使用。」– OpenAI 的 Sam Altman

在我上一篇文章〈Agentic Coding is a Trap〉中，我討論了「熟練的協調者悖論」，即管理 AI 程式碼代理所需的技能，與透過持續使用這些 AI 代理而可能減弱的技能是相同的。專業知識曾是主要的區別因素；開發者經驗越豐富，他們經歷技能退化的可能性就越小，因為知識經過多年的經驗沉澱而得以鞏固。

如果你環顧四周，會發現目前從這些模型中獲益最多的人，都是在該領域擁有多年甚至數十年經驗的人（當然，這早於 AI 工具的出現）。任何行業的資深人士都會告訴你同樣的道理：這些知識的基石來自於實際工作。

大約在大型語言模型（LLM）出現時進入該領域的開發者，處於一個沒有長期經驗優勢的位置，但他們卻被引導（有時是被強制）使用需要專業知識歷史才能有效且負責任地運用的程式碼助手來加速他們的努力。

這對這個群體來說是一個尷尬的處境，因為它造成了一個新手需要專家級技能才能利用這些工具並跟上行業步伐的局面。

我們目前向行業內的許多人發出了非常矛盾的信號。我們不斷強調，如果你不使用 AI 工具，你就會被使用這些工具的同行「拋在後面」。「AI 不會取代你，使用 AI 的人會」這句話自 2023 年以來就一直在重複播放。

同時，也說過要從這些模型中獲得最佳結果的方法是應用更高階的思維；「氛圍編碼」是死路一條；你需要「提升到更高的層次」，創建穩健的規格，使用良好的設計模式進行架構設計，並始終仔細審查輸出，這樣你就不會發布你不理解的內容。

然而，做到這一點所需的技能，是那些經歷過時間的摩擦和挑戰，最終形成「良好品味」的人才具備的。

這引出了另一個情境悖論：如果這些工具需要專業知識，但這些工具卻能規避培養專業知識的摩擦，那麼一個人要如何才能成為專家以便有效使用這些工具呢？

一種希望是，這些模型在用於程式碼生成時，最終將加速學習。初級開發者可以像行業資深人士一樣，擁有「個人 AI 導師」的權威和信心。記住語法變得越來越不重要，任何知識或模糊的差距都會被 AI 工具填補。程式碼的深層機制保持抽象，因為開發者處於堆疊的更高層次。

開發者工具的主要參與者 JetBrains 最近引用了一項題為「差距擴大：生成式 AI 對新手程式設計師的益處與危害」的研究，該研究詳細分析了現場程式碼編寫過程中的個人行為，並測試了他們在不同程度 AI 輔助下的學習能力。他們的主要結論是嚴峻且違反直覺的：

「參與者認為這就像擁有一位個人導師。從我們研究的數據來看……我們觀察到他們實際上並沒有像個人導師那樣使用生成式 AI 工具。事實上，情況恰恰相反。」

那些更傾向於使用 AI 輔助的參與者：

與此相反，那些減輕 AI 使用的參與者：

那些在 AI 使用上最不受限制且最自信的新手開發者「跳過了程式設計問題解決過程中的關鍵步驟，現在迷失了方向。」

也許不足為奇的是，表現最好的新手開發者是那些大大減輕或完全忽略 AI 程式碼輔助的開發者。

由於大型語言模型的自我導向性質，經驗越豐富，它們提供的益處就越多，因為你可以準確地引導、審查和驗證輸出。知識越少，它們就越可能誤導你。與大型語言模型互動以學習新技能，呈現出一種「反向學習」模式，一種角色反轉，學生最初引導導師，導師回應，然後學生再次引導導師。

這個過程很危險；大型語言模型對提示的形狀極其敏感。當你探索新領域時，你不知道自己不知道什麼，而大型語言模型靈活且包容的設計可能會讓你認為自己知道得比實際更多。

如果你正在探索即使是有些陌生的領域，你通常甚至不知道需要問哪些問題才能正確引導模型提供最佳答案。它開始感覺像一個總是朝北的指南針，無論你建議北方在哪裡。

從 JetBrains 強調的同一項研究中，即使是最有準備的學生也因為這種學習模式而被 AI 輔助所干擾：一位參與者表現出良好的基本規劃和習慣，但突然「跳過了關鍵的問題解決規劃階段，直接進入編碼，並被 Copilot 誘使快速生成程式碼」，並且不得不依賴大型語言模型來修復由大型語言模型本身引入的錯誤。

AI 模型缺乏判斷力、同理心和教學意圖，提供的解決方案並非植根於經驗，而是植根於訓練數據中的模式（大型語言模型本質上是極其複雜的模式插值器）。

這個無限答案機器誘人且已知會上癮。它可能很快就會瓦解，尤其是對於沒有經驗的開發者。一旦你深入到一個生成的解決方案中，你通常就會被 AI 工具所束縛，無法完成工作，規避了形成心智模型所需的解決問題的摩擦（公平地說，資深開發者也容易出現這種現象）。

專業知識和精通並非純粹透過觀察和對話發生，而是透過經驗、重複以及試錯；你必須失敗才能成功。如果我想學做飯，我可以看一位頂級廚師工作並無休止地提問。一個月後，我將能夠描述完美的五分熟肋眼牛排，但永遠不知道如何烹飪一塊，而且我第一次嘗試時幾乎肯定會把它煮過頭。

程式碼編寫有無限的時刻，需要追蹤沒有日誌文件可幫助的模糊錯誤，體驗某些方法的細微性能差異，或者在明顯無法擴展時重寫方法。

這種應用摩擦直接建立了「開發者直覺」（或「品味」）。德國人有一個很棒的詞來形容這種感覺：Fingerspitzengefühl（指尖感覺）。這是一種肌肉記憶，當開發者看到某樣東西時會觸發，並想：「嗯……這可能會引起問題。」透過避免掙扎的機制，這種直覺永遠不會建立起來。

在賓州大學大規模的 2025 年研究「沒有護欄的生成式 AI 可能會損害學習」中，他們跟蹤了 1,000 名使用大型語言模型學習數學的學生，發現學生將 AI 用作拐杖，表現比僅使用教科書的學生差 17%（與之前的研究一樣，使用 AI 輔助的學生認為他們表現出色）。

如果將其作為蘇格拉底式的辯論夥伴而不是答案生成器來利用，研究表明「對話式 AI 系統可以有意義地激發反思性、批判性和獨立思考」。

在同一項賓州大學的研究中，他們還測試了一個「導師」版本，讓學生提問然後獨立解決問題。GPT 導師組在 AI 輔助練習中表現出驚人的 127% 的提升（儘管有趣的是，他們在測試中的得分與教科書組大致相同）。

這是有效的，因為模型不再被用作生產手段，它將認知工作轉移回個人身上。當摩擦仍然存在時，它會產生持久的印記，從而導致專業知識的形成。

Anthropic 的 2026 年研究「AI 輔助如何影響程式碼技能的形成」得出了類似的結論：

對於軟體工程或任何其他行業的新手來說，我們的研究可以被視為關於有意識地使用 AI 工具進行技能發展價值的少量證據。認知努力——甚至痛苦地卡住——對於培養精通很重要。

這裡有一種諷刺意味：與 AI 程式碼工具進行的最有成效的學習，是當它根本不被用於生成太多程式碼時。

如果大型語言模型可以編寫程式碼和調試程式碼，並且代理工作流程可以從訓練數據中大量的模式中執行系統設計，那麼這些知識的目的是什麼？程式設計將完全以自然語言進行，我們可以擺脫與程式碼互動的需要，因為模型不斷改進並填補任何知識或模糊的差距。它們將調試出現的任何問題並管理它們引入的任何複雜性。

正在進行的這個萬億美元的賭注是：這些知識將無關緊要，因為大型語言模型將填補這個空缺，並有效地成為新一代的「開發者」。這開始給人一種過去無代碼運動所帶來的傲慢和 CEO 的狂熱夢想的感覺，而不是地面的現實。

程式碼編寫/程式設計/軟體是邏輯、數學、問題解決、批判性思維、規劃、溝通和創造力的獨特交匯點。大型語言模型可以以人類無法企及的規模檢測模式，但模式只能讓你走這麼遠。

Sentry（一個性能和錯誤追蹤平台）的聯合創始人大衛·克萊默（David Cramer）在最近的一次採訪中簡潔地說：

我認為有一類人……他們內心深處相信 LLM 會變得足夠好，以至於他們會回去修復這些東西，它將能夠清理掉一路堆積的所有垃圾。我不認為這是真的。我認為這是一個科學實驗。你想炫耀你能生成你所有的程式碼並讓數百件事情同時進行，我將炫耀並 100% 證明你的程式碼有多麼破碎。

這真的取決於我們是否進行了必要的轉變，以更具教學意義的方式使用這些系統。

透過繼續專注於和推廣優先於深入理解的程式碼生成 AI 工作流程，我們並沒有培養下一代將繼承今天所創建程式碼的專業人才。

Joel Spolsky 在 2002 年就預見性地在他的「洩漏性抽象定律」中寫道：

程式碼生成工具，它們假裝抽象出某些東西，就像所有抽象一樣，會洩漏。處理這些洩漏的唯一方法是學習抽象是如何工作的……抽象節省了我們工作時間，但它們並沒有節省我們學習時間。

如果開發者想學習 Java，他們可能不應該從 Spring Boot 開始。如果他們想學習 JavaScript 的基礎知識，他們不應該從 React 開始。如果他們想精通 CSS，他們不應該從 Tailwind 開始。大型語言模型可以被認為是終極的洩漏性抽象。

如果開發者想成為程式設計專家，他們應該在很大程度上忽略這些模型的純程式碼生成能力，而是將它們用於互動式文檔、動態教程生成器和蘇格拉底式練習。

當然，這並非萬靈丹：將 AI 工具用作導師本身也存在風險，因為它容易出現與任何其他互動相同的幻覺，並且不能僅僅依賴它作為學習來源。如果你無法正確審查生成的程式碼的準確性，那麼你就無法審查生成的概念的準確性。如果你將 AI 用作導師，你仍然必須根據官方文檔、人類同行和實際的試錯來驗證其輸出。

「程式碼編寫實際上是鞏固理解的好方法。你編寫的程式碼越多，你對你正在工作的領域的理解就越深。」—— Kent Beck，測試驅動開發的創始人

選擇這條更慢、更謹慎的道路是培養專業知識的最佳方式，但我意識到當周圍的生態系統積極地與之對抗時，這有多麼困難。公司正在（經常魯莽地）強制使用 AI，並且它已嵌入到大多數軟體開發工具和 IDE 中，因為它們主要迎合資深工程師（即使是一些像 Cursor 這樣的工具，除非用戶特別尋找，否則會隱藏程式碼視圖）。一些公司甚至強迫開發者僅使用 AI 進行所有程式碼任務，無論經驗水平如何，這些公司將不得不吸取自己的教訓。

然而，對於那些希望在深度學習（無雙關語）和生產力之間取得平衡的其他人來說，有一些限定性問題可以問，以確保你對這些工具的使用能帶來長期的好處。

即使作為一名擁有數十年經驗的開發者，我仍然在日常工作中不斷參考它們，尤其是在我嘗試學習新東西時（在這個領域，這永無止境）。

關鍵在於區分認知債務和認知卸載：認知債務是放棄你的判斷和決策，而認知卸載是委派機械或繁瑣的任務。

正如 Anthropic 的研究提到的，「痛苦地卡住」是一件好事。這需要紀律和努力才能不回歸到僅僅生成可能甚至不準確的答案。大型語言模型並沒有突然改寫我們學習的基本原理，但它們確實為我們提供了一種新的學習方式。

我希望看到多年來出現的重新調整是，人們理解技能不會在沒有積極參與的情況下發展。你必須直接且持續地參與，才能體驗到最終形成專業知識的必要摩擦（即使這意味著移動得更慢）。

大型語言模型是技能的靜態數據庫。它們是插值引擎。然而，軟體工程是適應性和新穎問題解決的練習。你無法透過插值來解決一個完全獨特的系統故障。—— François Chollet，ARC-AGI Benchmark 的創始人