AI 编码正在让下一批专家消失：工具要求专家技能，却同时消灭了培养专家的摩擦

原文来源：AI Coding will Prevent Expertise — 依赖 AI 编码工具会跳过培养专业知识所必需的摩擦，下一代开发者可能永远无法成为专家。

先讲一个矛盾，它现在正发生在每一个用 AI 写代码的人身上。

你打开 Cursor 或者 Claude Code，开始描述需求。模型刷刷地生成代码，你 review 一下，觉得差不多，提交。一天下来你"写"了几千行代码，感觉前所未有的高效。但如果你是个入行两三年的开发者，你有没有想过一个问题：这些工具要求你具备的判断力，恰恰是持续使用这些工具会让你永远无法获得的判断力？

Lars Faye 在文章里管这叫"技术型编排者悖论"（skilled orchestrator paradox）：管理 AI agent 需要的技能——拆解问题、写清晰规格、审查输出、判断什么是对的——和持续使用 AI agent 会逐渐萎缩的技能，是同一批技能。你越依赖工具替你干活，越没有机会锻炼这些肌肉。

数据比感觉诚实

文章引用了几个研究，结论都相当扎心。

JetBrains 引用的一项研究叫《The Widening Gap》（不断扩大的鸿沟），专门分析新手程序员在真实编码会话中的行为。参与者普遍觉得"就像有个私人导师"，但研究者从数据里看到的恰恰相反：重度使用 AI 辅助的人，跳过了编程问题解决过程中的关键步骤，然后迷路了。表现最好的新手，是那些大幅限制甚至完全无视 AI 辅助的人。

宾夕法尼亚大学 2025 年的大规模研究（1000 名学生用 LLM 学数学）更直接：用 AI 当拐杖的学生，比只用课本的学生成绩差 17%——而且他们自己以为学得很好。对照组的"导师模式"（学生先自己尝试，卡住了再问 AI）表现好了 127%，但考试分数和课本组差不多。

Anthropic 2026 年的研究《AI 辅助如何影响编码技能的形成》得出类似结论：认知努力——甚至"痛苦地卡住"——对掌握技能很重要。作者由此说出那句讽刺意味拉满的话：

AI 编码工具能产生的最有效的学习，恰恰发生在它不生成任何代码的时候。

反转学习：学生给导师指路

为什么 AI 辅助学习会这么反直觉？作者给了一个很精准的模型：反转学习（inverted learning）。

正常的学习是导师引导学生的知识空白。但 LLM 是自驱动的：你给它什么提示，它就顺着什么方向走。当你在探索陌生领域时，你根本不知道自己不知道什么——于是出现了一个诡异的场景：学生（你）在给导师（模型）指路，而导师非常顺从，你说往哪它就往哪。

结果就是，你会产生一种"我比实际更懂"的错觉。作者有个绝妙的比喻：LLM 就像一支永远指向北方的指南针——不管你把"北方"指在哪里，它都顺从地指向那里。

更麻烦的是，一旦你钻进一个 AI 生成的方案深处，你就被它绑架了：错误是 AI 引入的，你只能继续靠 AI 修。问题解决的摩擦（debug 一个没有日志的诡异错误、感受不同方法的性能差异、意识到方案不可扩展然后重写）——这些摩擦恰恰是构建"开发者直觉"的原材料。德语有个词叫 Fingerspitzengefühl，指尖感觉，就是老程序员看一眼就知道"这玩意儿以后要出事"的那种肌肉记忆。绕开摩擦，直觉就不会长出来。

泄漏的抽象

文章引了 Joel Spolsky 2002 年的"泄漏抽象定律"（Law of Leaky Abstractions），放到今天格外应景：

假装抽象掉什么东西的代码生成工具，和所有抽象一样，会泄漏。而应对泄漏的唯一办法，是学会抽象内部的工作原理……抽象节省我们工作的时间，但不节省我们学习的时间。

换句话说：**别用 Spring Boot 学 Java，别用 React 学 JavaScript，别用 Tailwind 学 CSS。**LLM 是终极的泄漏抽象——它生成的东西看起来全对，直到某个独特的系统故障出现，而模式插值器对"前所未见的问题"无能为力。François Chollet 那句话收尾收得漂亮："LLM 是静态的技能数据库，是插值引擎。而软件工程是在适应和新问题解决中展开的——你没法用插值解决一个完全独特的系统故障。"

认知债 vs 认知外包

那是不是说，别用 AI 了？作者没这么极端，他自己也是每天重度使用 AI 的老兵。他给了一个很实用的区分：

• 认知债（cognitive debt）：把判断和决策都交给 AI——这是危险的。
• 认知外包（cognitive offloading）：把机械、繁琐的部分交给 AI——这没问题。

写正则、补样板代码、查文档、格式化——外包，省时间。但"这个设计对吗""这个方案的权衡是什么""这段代码在真实系统里会不会炸"——这些判断必须自己扛。作者还建议把 AI 当苏格拉底式的陪练而不是答案生成器：用它做交互式文档、动态教程生成器、提问练习，而不是让它替你想。

一个行业级的隐忧

这篇文章最值得咀嚼的，其实是最后那部分行业观察。现在全行业都在喊"不用 AI 就会被淘汰"，公司开始强制开发者只用 AI 写代码——不管你是十年老兵还是刚入行。但现实是：AI 工具的设计者们几乎都在服务资深工程师（Cursor 甚至默认把代码视图藏起来）。新手被夹在中间：公司要求他们用需要专家技能才能驾驭的工具，而工具又在剥夺他们成长为专家的机会。

David Cramer（Sentry 联创）那句评价很毒："你想炫耀你能并行生成几百个东西？我炫耀的是你的代码 100% 是坏的。"

专家的形成需要时间，需要犯错，需要在"没有日志文件的诡异错误"里挣扎一整晚。如果这一代新人都被喂大在"生成→提交"的循环里，等今天这些资深工程师退休，谁来接手这堆被 LLM 堆出来的代码库？这不是反 AI 的立场——这是给"AI 时代怎么培养人"提的一个真问题。答案不在模型那边，在每一个开发者自己的使用习惯里：把摩擦留给学习，把机械交给工具。