Anthropic 自己做了個實驗，然後親手打了自己產品一巴掌。
Anthropic 剛剛發布了一篇研究論文，專門探討一個扎心的問題：用 AI 輔助寫程式，會不會讓程式設計師變得更菜？
結果令人意外：
用了 AI 的程式設計師，測驗分數比不用的低了 17%，相當於直降兩個等級。
實驗怎麼做的？
研究團隊招募了 52 名初級軟體工程師，要求是：Python 至少用了一年，每週都在寫；用過 AI 編程助手；但沒接觸過 Trio 這個 Python 非同步程式庫。
然後把他們隨機分成兩組：
AI 組：可以用 AI 助手幫忙寫程式
對照組：只能靠自己！
兩組人都要用 Trio 完成兩個程式設計任務，然後立刻參加一個測驗，考察他們對剛才用到的概念的理解程度。
結果……
速度上，AI 組平均快了大約兩分鐘，但這個差異在統計學上不顯著。
但在理解程度上，AI 組的平均分只有 50%，而手寫程式碼組是 67%，差了 17 個百分點。
而讓人扎心的是，兩組差距最大的題目是除錯類問題。
也就是說，用 AI 寫程式的人，在「找 bug」這件事上明顯更弱。
沒準，當未來的程式碼越來越多由 AI 來寫，人類程式設計師最重要的工作就是審查和除錯這些程式碼。
但如果程式設計師從一開始就靠 AI，連除錯能力都沒練出來，誰來給 AI 兜底呢？
為什麼會這樣呢？
研究者透過錄影分析了每個參與者的行為模式，發現了一個有趣的現象：
有些人花了大量時間跟 AI 對話：最多的一位發了 15 條訊息，光是打字和思考問題就花了 11 分鐘，佔總時間的 30%。
這也解釋了為什麼 AI 組沒有快多少：省下的寫程式時間，都花在跟 AI 聊天上了。
而對照組雖然遇到了更多錯誤，但正是在獨立解決這些錯誤的過程中，他們真正理解了 Trio 庫的工作原理。
不是所有用法都一樣
研究者把 AI 組的行為模式分成了六種，其中三種得分很低，三種得分較高。
低分模式（平均分低於 40%）：
完全委託型：讓 AI 寫全部程式碼，速度最快，但啥也沒學到
漸進依賴型：一開始還問問問題，後來乾脆全交給 AI
反覆除錯型：遇到 bug 就問 AI，自己不思考，結果又慢又不學東西
高分模式（平均分 65% 以上）：
先生成後理解型：讓 AI 寫完程式碼後，追問原理和解釋
混合解釋型：每次讓 AI 寫程式碼時都要求附帶解釋
純概念型：只問概念性問題，程式碼自己寫，雖然報錯多，但最終理解最深
看出區別了嗎？
高分組的共同特點是：保持思考。
他們不是不用 AI，而是用 AI 來幫助理解，而不是替代思考。
這意味著什麼？
研究認為：在工作中激進地使用 AI，可能會阻礙技能發展。
這對初級工程師尤其危險。在時間壓力下，新手程式設計師很可能為了快速完成任務而重度依賴 AI，代價是：他們可能永遠學不會真正需要的技能。
當企業越來越多地用 AI 來寫程式，但負責審查這些程式碼的人卻是「被 AI 養大」的工程師，這裡面的風險不言而喻。
研究者建議：
管理者在推廣 AI 工具時，要有意識地保護員工的學習機會
初級工程師要明白，痛苦地卡住、報錯、除錯，其實是學習的必經之路
AI 產品的設計者也應該思考，如何讓工具既提升效率，又不損害學習
事實上，主流 LLM 服務已經開始提供「學習模式」。
比如 Claude Code 的 Learning/Explanatory 模式，以及 ChatGPT 的 Study Mode。這些功能的設計初衷，就是為了減輕「認知卸載」的副作用。
研究的局限
研究者也承認，這項研究有其局限性：
樣本量較小（52 人）
只測量了即時理解，不知道長期影響如何
任務只涉及一個 Python 庫，可能無法推廣到所有場景
使用的是聊天式 AI 助手，如果是 Claude Code 這種更自動化的 Agent，效果可能更極端
但無論如何，該項研究給我們的啟示是：
AI 可以讓你更快，但不一定能讓你更強。
如果你正在學習程式設計，或者帶團隊的新人，不妨想想：效率和學習之間，如何找到平衡？
畢竟，最好的工具是讓人變強的工具，而不是讓人變成工具的工具。
相關連結：