AI 寫了 90% 的程式碼,工程師還會寫程式嗎?Anthropic 研究揭露的技能形成悖論

引言:一場靜悄悄的技能革命

2026 年 1 月 29 日,AI 安全研究公司 Anthropic 發布了一項讓整個軟體工程界震驚的研究報告:使用 AI 輔助工具學習新程式庫的開發者,在測驗中的得分比手寫程式碼的開發者低了 17%——相當於兩個字母等級的差距。更令人不安的是,這項差距出現在他們剛剛「完成」任務的幾分鐘之後。

這不是理論推測,而是一場涉及 52 名軟體工程師的隨機對照試驗。研究發現,使用 AI 確實能讓任務完成速度稍快,但代價是對程式碼的理解能力顯著下降——特別是在除錯能力上,差距最為明顯。

同一天,獨立追蹤平台 Marginlab.ai 的數據顯示,Claude Code 在過去 30 天的效能下降了約 4%,引發技術社群對 AI 工具穩定性的擔憂。而 Anthropic 內部的數據更令人震撼:27% 的工作已由 AI 完成,某些工程師甚至已經兩個月沒有親手寫過程式碼。

這些數據共同指向一個根本性問題:當 AI 成為我們的程式設計夥伴,我們是在培養更強大的工程師,還是在培養只會「指揮 AI」卻失去底層理解能力的「空心化」工作者?

認知心理學視角:認知卸載的雙刃劍

Piaget 的建構主義警示

瑞士心理學家 Jean Piaget 在 20 世紀中期提出的建構主義學習理論告訴我們:知識不是被動接收的,而是透過主動建構形成的。學習者必須親身經歷「認知失衡」(cognitive disequilibrium) 的過程——當現有知識無法解決問題時,大腦被迫重組思維結構,從而達到更高層次的理解。

Anthropic 的研究恰好驗證了這個理論的反面:當 AI 為開發者消除了所有「認知失衡」時,學習就停止了。

研究將 AI 使用者分為六種互動模式,其中三種低分模式都有一個共同特徵:完全委託給 AI(AI delegation)、漸進式依賴 AI(Progressive AI reliance)、迭代式 AI 除錯(Iterative AI debugging)。這些開發者的測驗平均分數低於 40%。

相反,三種高分模式的開發者雖然也使用 AI,但他們會:先生成程式碼再理解(Generation-then-comprehension)、要求混合式程式碼與解釋(Hybrid code-explanation)、只問概念性問題(Conceptual inquiry)。這些人的平均分數在 65% 以上。

關鍵差異是什麼?認知參與度(cognitive engagement)。

高分組使用 AI「建立理解」,低分組只是「委託生成」。這就像學生時代,真正學會數學的人會用計算機驗證答案,但不會用計算機取代思考;而那些只依賴計算機的人,離開工具就無法解題。

錯誤的價值:被 AI 剝奪的學習機會

研究發現,未使用 AI 的對照組遇到了更多錯誤——包括語法錯誤和概念錯誤——但正是這些錯誤,讓他們在除錯能力測驗中表現更好。

這印證了教育心理學的一個核心發現:從錯誤中學習是技能形成的關鍵路徑。當 AI 消除了所有錯誤,它也消除了最珍貴的學習機會。正如研究報告所言:「認知努力——甚至是痛苦地卡住——對於培養精通能力可能很重要。」

這讓我想起台灣教育現場常見的爭議:計算機該不該進入數學課堂?反對者擔心學生失去心算能力,支持者認為工具能讓學生專注於更高層次的數學思維。但 AI 輔助編程的問題更為複雜:因為程式設計本身就是思維的延伸,當我們外包思維給 AI,我們失去的不只是技能,而是思考本身。

軟體工程文化變遷:從 Craftsman 到 Orchestrator

工程師角色的根本轉變

Anthropic 在 2026 年 1 月發布的《2026 Agentic Coding Trends Report》描繪了一個令人震撼的未來:「工程師正在從『實作者』(implementer) 轉變為『指揮者』(orchestrator)……建構軟體曾經主要意味著撰寫程式碼,儘管軟體工程角色總是涉及許多其他技能。現在,成為軟體工程師越來越意味著指揮撰寫程式碼的 AI agents、評估它們的輸出、提供戰略方向,並確保整個系統正確解決正確的問題。」

這種轉變在台灣軟體業也正在發生。根據比薪水 2025 年的調查,台灣有 63% 的勞工經常使用 AI 工具,其中資訊科技業的 Copilot、Claude 等程式設計輔助工具使用率最高。但真正的問題是:當所有工程師都變成指揮者,誰來培養下一代的實作能力?

Hacker News 上一位資深工程師的評論一針見血:「我注意到初級開發者現在可以快速建構複雜功能,但他們仍然在資深工程師本能做出的架構決策上掙扎。AI 加速了實作,但並不能取代從看過數百個程式碼庫成功和失敗中獲得的模式識別能力。」

Mentorship 文化的崩解

更嚴重的問題是:當資深工程師自己也有兩個月沒寫過程式碼,他們還能有效指導新人嗎?

傳統軟體工程的學習模式高度依賴「學徒制」——初級工程師透過 Code Review、Pair Programming、Technical Discussion 從資深工程師身上學習「工程品味」(engineering taste)。但當 AI 生成了 90% 的程式碼,這些學習機會都消失了。

Anthropic 報告指出,工程師現在只保留「高階設計決策和任何需要組織脈絡或『品味』的事情」給自己。問題是:品味是如何形成的?正是透過大量的實作經驗。

這形成了一個惡性循環:

1. 資深工程師依賴 AI,減少親手寫程式碼
2. 初級工程師失去觀摩學習的機會
3. 新一代工程師缺乏深層技術理解
4. 整個產業的技術債務累積,創新能力下降

台灣的新創圈已經開始感受到這種效應。某位不願具名的技術長告訴我:「現在面試新人,他們的 GitHub 專案看起來都很漂亮,但問到底層實作細節就答不出來。我懷疑很多程式碼都是 AI 寫的,他們自己根本不理解。」

產業經濟學分析:技能貶值與人力市場重構

哪些工程師會被淘汰?

Anthropic 的經濟研究指出,Claude 被用於的任務往往需要比整體經濟更高的技能水平。如果 AI 輔助任務在工作者職責中的占比下降,剩下的將是技能較低的工作。

但這種「任務替代」並不會均勻影響所有白領工作者:

• 對某些職業,它移除了最需要技能的任務
• 對其他職業,它移除了最不需要技能的任務

研究舉了兩個例子:

• 旅行社業務會經歷「去技能化」(deskilling):複雜的行程規劃工作被 AI 取代,剩下例行的機票購買和收款工作
• 物業管理員則會經歷「升技能化」(upskilling):簿記任務被 AI 處理,留下合約談判和利害關係人管理

那麼軟體工程師呢?答案可能介於兩者之間,但更傾向於雙極化:

會被淘汰的工程師:

• 只會呼叫 API、套用框架的「程式碼搬運工」
• 缺乏除錯能力、無法理解 AI 生成的程式碼
• 不願持續學習底層原理的「工具依賴者」

會更有價值的工程師:

• 具備系統設計能力、能做出正確的架構決策
• 理解底層原理、能在 AI 失效時接手
• 懂得如何「正確使用 AI」來建立理解而非取代思考

Hacker News 上一位工程師的自省令人深思:「我已經達到一個穩定狀態,學習的速度與遺忘的速度相當。但在 39 歲(20 年專業經驗)時,我在這個領域忘記的東西比我今天感到舒適的還要多。」

AI 可能會加速這種遺忘。

AI 擴增的不平等問題

Carnegie Mellon University (CMU) 的研究發現了一個違反直覺的現象:專家在使用 AI 輔助後,反而比不用時慢了 19%。為什麼?因為專家花更多時間驗證、修正 AI 的輸出,而新手更容易盲目接受。

這揭示了 AI 輔助的不平等效應:

• 對新手:短期生產力大幅提升,但長期技能發展受阻
• 對專家:短期效率可能下降,但能保持技能水準
• 結果:技能差距縮小,但整體技能水準下降

對台灣而言,這可能造成另一種不平等:那些能負擔得起「刻意練習」時間的工程師(通常在大公司或有良好導師),會與那些被迫「追求短期生產力」的工程師(新創、外包公司)產生越來越大的能力鴻溝。

初級職位消失後的人才斷層

更嚴重的系統性風險是:如果 AI 能完成所有初級工程師的工作,誰來培養下一代的資深工程師?

這不是科幻小說的情節,而是正在發生的現實。Anthropic 報告指出,某些職業如「資料輸入員」(data entry keyers) 和「資料庫架構師」(database architects),Claude 已經能勝任工作的大部分內容。

如果初級職位大量消失,軟體產業將面臨「人才管線斷層」:

1. 新人失去「做中學」的機會
2. 五到十年後,缺乏有實戰經驗的中階工程師
3. 產業依賴少數資深專家,創新能力衰退
4. 技術債務累積,系統性風險上升

這與日本「失落的一代」問題類似:當企業在經濟衰退時停止招聘新人,十年後就會出現中階人才斷層。AI 可能在軟體業製造類似的危機。

教育啟示:AI 時代的程式教育改革

大學資工系該如何調整?

台灣的大學資工系正面臨兩難:一方面,業界希望畢業生能「立即上手」使用 AI 工具;另一方面,學術界擔心學生失去基礎能力。

Anthropic 研究給出了明確方向:教育重點應該從「如何實作 X」轉向「何時以及為何使用 X」。

具體建議:

1. 強化基礎理論課程:資料結構、演算法、作業系統、編譯器原理——這些「永恆的知識」在 AI 時代更加重要
2. 增加系統設計課程:培養架構決策能力,而非語法記憶
3. 教授「AI 協作技能」:如何提出好問題、如何驗證 AI 輸出、如何在 AI 失效時接手
4. 保留「無 AI 實作」課程:就像數學系仍然教手算微積分一樣,資工系應該保留「純手工」程式設計訓練

台灣大學、清華大學、交通大學等頂尖資工系已經開始調整。台大資工系主任曾在訪談中表示:「我們不是禁止學生使用 AI,而是要求他們必須能解釋 AI 生成的每一行程式碼。理解比實作更重要。」

「刻意練習」在 AI 時代的新意義

心理學家 Anders Ericsson 提出的「刻意練習」(deliberate practice) 理論強調:專業技能的養成需要在適當難度的任務上,持續獲得即時回饋,並進行反思調整。

AI 恰好破壞了這個循環:

• 難度消失:AI 把困難任務變簡單
• 回饋延遲:錯誤被 AI 預先修正,學習者看不到自己的盲點
• 反思缺失:快速完成任務後,缺乏深度思考

因此,AI 時代的「刻意練習」必須重新定義:

1. 設定「無 AI 區間」:每週至少有固定時間純手工寫程式碼
2. 主動製造困難:選擇 AI 不擅長的任務來練習(如系統設計、效能優化)
3. 深度程式碼審查:不只檢查 AI 生成的程式碼,更要問「為什麼這樣寫」
4. 教學相長:教導他人是最有效的學習方式

台灣教育現場的應對策略

台灣的程式教育有其獨特挑戰:技專院校與普通大學的差異、升學主義文化、產學落差等。但也有優勢:紮實的數理基礎、重視考試的文化(適合評量真實理解)、產業聚落完整。

建議策略:

1. 高中資訊課:引入 AI 工具,但同時要求「無 AI」期末專題,確保基礎能力
2. 大學資工系:推動「AI 使用倫理」課程,討論何時該/不該用 AI
3. 技專院校:強化「AI 除錯」訓練,因為業界需要能修正 AI 錯誤的人才
4. 終身學習:鼓勵在職工程師回流,參加「底層原理」進階課程

實務建議:如何在 AI 時代保持技術深度

正確使用 AI 的三個原則

基於 Anthropic 研究,我整理出三個核心原則:

原則一:用 AI 建立理解,而非取代思考

• ❌ 錯誤:「給我寫一個排序函數」
• ✅ 正確:「解釋快速排序和合併排序的時間複雜度差異,然後協助我實作一個適合小資料集的排序」

原則二:先嘗試自己解決,再請 AI 驗證

• ❌ 錯誤:遇到 bug 立刻問 AI
• ✅ 正確:先自己除錯 15 分鐘,記錄假設,然後請 AI 協助驗證思路

原則三:要求解釋,而非只要程式碼

• ❌ 錯誤:接受 AI 生成的程式碼後直接使用
• ✅ 正確:要求 AI 解釋設計決策、潛在風險、替代方案

Anthropic 研究中的高分組有個共同行為:他們會問 AI「為什麼」,而不只是「怎麼做」。

避免技能空心化的具體做法

個人層面:

1. 建立「技能保鮮機制」:每月至少完成一個「純手工」專案
2. 深度閱讀經典程式碼:Linux kernel、SQLite、Redis 等開源專案
3. 參與技術社群:COSCUP、MOPCON、台灣 AI 實驗室等,與同行交流
4. 寫技術部落格:教學是最好的學習(費曼技巧)

團隊層面:

1. Code Review 文化升級:不只檢查功能,更要討論「為什麼這樣設計」
2. Pair Programming:一人寫程式碼,一人思考架構,AI 作為第三個「顧問」
3. 技術分享會:定期分享「AI 無法解決的問題」
4. 導師制度:資深工程師每週至少花 2 小時與新人「面對面」討論技術細節

公司層面:

1. 設立「學習時間」:Google 的 20% time、台積電的輪調制度都值得借鏡
2. 技能認證機制:不只看產出速度,更要評量技術深度
3. 差異化職涯路徑:技術專家(Individual Contributor) 與管理職同等重要
4. 投資內部訓練:邀請資深工程師開設「底層原理」課程

團隊管理的新挑戰

管理者面臨的最大挑戰是:如何在追求短期生產力與長期技能培養之間取得平衡?

建議做法:

1. 雙軌制績效評估:

   • 短期:專案交付速度、程式碼品質
   • 長期:技術深度成長、導師貢獻

2. 「AI 使用透明化」:

   • 要求工程師標註哪些程式碼由 AI 生成
   • Code Review 時特別關注 AI 生成的部分
   • 追蹤團隊的「AI 依賴度」趨勢

3. 建立「技能安全網」:

   • 確保團隊中至少 30% 成員具備「無 AI」解決問題能力
   • 定期進行「無 AI 演習」(類似消防演習)
   • 建立關鍵技能的備援人才

結論:生產力與能力的辯證

Anthropic 研究揭示了一個深刻的悖論:AI 帶來的生產力提升,可能以犧牲能力發展為代價。這不是 AI 的錯,而是我們使用 AI 的方式出了問題。

正如 Hacker News 上一位工程師所言:「我從未如此快速地學習軟體開發『概念』——但那是因為我已經將實際開發外包給其他人多年了。」這句話既是 AI 的希望,也是警告:概念理解與動手實作必須並重。

台灣軟體業正處於關鍵轉折點。我們可以選擇:

• 路徑一:短視的效率陷阱:追求短期生產力,培養一代「空心化」工程師,最終失去技術競爭力
• 路徑二:永續的能力建構:審慎使用 AI,在提升效率的同時保持技術深度,培養真正的工程專家

Anthropic 的研究給我們最重要的啟示是:AI 不應該是「自動駕駛」,而應該是「輔助駕駛」。駕駛者(工程師)必須保持警覺、理解路況、隨時準備接手。當我們把方向盤完全交給 AI,我們就失去了駕駛能力——而當 AI 失效時(它必然會失效),我們將無力應對。

工程師的核心價值從來不是「寫程式碼的速度」,而是「解決問題的智慧」。AI 可以成為我們的工具,但永遠不應成為我們的替代品。

真正的問題不是「AI 會不會取代工程師」,而是「我們會不會讓 AI 掏空我們的能力」。

答案取決於我們今天做出的選擇。

參考資料與延伸閱讀

核心研究論文

1. Anthropic (2026) - "How AI assistance impacts the formation of coding skills"
   https://www.anthropic.com/research/AI-assistance-coding-skills
   arXiv 論文

2. Anthropic (2026) - "2026 Agentic Coding Trends Report: How coding agents are reshaping software development"
   https://resources.anthropic.com/hubfs/2026 Agentic Coding Trends Report.pdf

3. Anthropic (2026) - "Anthropic Economic Index: new building blocks for understanding AI use"
   https://www.anthropic.com/research/economic-index-primitives

Hacker News 討論串

4. Hacker News - "How AI assistance impacts the formation of coding skills"
   https://news.ycombinator.com/item?id=46820924

5. Hacker News - "Claude Code daily benchmarks for degradation tracking"
   https://news.ycombinator.com/item?id=46810282

6. Hacker News - "Ask HN: Did AI make you a worse programmer?"
   https://news.ycombinator.com/item?id=42614392

效能追蹤與產業分析

7. Marginlab.ai - "Claude Code Opus 4.5 Performance Tracker"
   https://marginlab.ai/trackers/claude-code/

8. WinBuzzer (2026) - "Independent Tracker Confirms Claude Code Performance Drops"
   https://winbuzzer.com/2026/01/29/claude-code-performance-drops-independent-tracker-xcxwbn/

9. 比薪水 (2025) - "AI 技能已成職場共識!63% 勞工經常使用 AI"
   https://blog.salary.tw/article/2025-taiwan-ai-work

認知心理學與教育研究

10. NCBI (2025) - "Children Show More Selective Cognitive Offloading After First Being Compelled to Offload Indiscriminately"
    https://pmc.ncbi.nlm.nih.gov/articles/PMC12323294/

11. Nature (2025) - "AI assistance reduces engagement with work"
    https://www.nature.com/articles/s41598-025-98385-2

12. Microsoft Research (2025) - "AI and Critical Thinking Survey"
    https://www.microsoft.com/en-us/research/wp-content/uploads/2025/01/lee_2025_ai_critical_thinking_survey.pdf

CMU 與其他學術研究

13. Carnegie Mellon University (2025) - "Simulated Company Shows Most AI Agents Flunk the Job"
    https://www.cs.cmu.edu/news/2025/agent-company

14. IEEE (相關) - "Research in computer science education: assessment of coding skills"
    https://ieeexplore.ieee.org/document/9962584

台灣在地資源

15. COSCUP - 台灣開源人年會
    https://coscup.org/

16. MOPCON - 行動科技年會
    https://mopcon.org/

17. 台灣人工智慧實驗室 (Taiwan AI Labs)
    https://ailabs.tw/

作者後記:本文撰寫過程中參考了大量第一手研究資料和技術社群討論,力求呈現平衡、具建設性的觀點。AI 是工具,不是敵人;關鍵在於我們如何使用它,以及如何在追求效率與培養能力之間找到平衡。歡迎讀者在評論區分享你的實務經驗與觀察。

關鍵字: AI 輔助編程、技能形成、認知卸載、Anthropic、Claude Code、軟體工程教育、程式設計、台灣科技業、工程師職涯發展

版權聲明: 本文採用 CC BY-NC-SA 4.0 授權,歡迎註明出處後轉載分享。