如今的 AI Coding 浪潮，正在把软件开发推向一个令人兴奋的方向：

●不会写代码？可以用自然语言让 AI 帮你生成应用。

●不熟悉某个框架？让 AI 现查现写。

●遇到报错？复制日志，几十秒得到解决方案。

效率提升是真实存在的。但与此同时，一个越来越值得讨论的问题也开始浮出水面：AI Coding 也许正在提高今天的生产效率，却可能也在削弱明天的专家培养能力。

最近，开发者 Lars Faye 在一篇文章中提出了一个颇具争议的观点： AI Coding 可能会阻碍专业能力的形成。

他的核心担忧并不是“AI 写的代码不好”，也不是要求开发者回到没有 Copilot、Claude Code 或其他 AI 工具的时代，而是：一个开发者究竟是如何成长为专家的？如果这些专业能力来自 于长期的实践、试错、排错和失败，那当 AI 提前替我们绕过这些过程，未来的程序员又该如何获得这些能力？

这个问题并非纯粹的“反 AI 焦虑”。其实近两年，一系列针对 AI 与学习、编程能力的研究，也开始得出一些相似甚至令人不安的结论： AI 的确可以帮助人们更快完成任务，但“完成任务”和“真正学会”之间，可能根本不是一回事。

一个越来越明显的矛盾：新人需要专业能力，才能正确使用 AI

过去几年，软件行业一直在重复一句话：

“ AI 不会取代你，但会用 AI 的人会取代你。”

这句话几乎已经成为 AI 时代职场竞争的标准口号。于是，越来越多开发者开始用 AI 编程工具。公司鼓励多用、IDE 默认集成、Agent 工具不断升级，一些企业甚至直接把 AI 使用量与工作流程绑定。

但同时，行业又在告诉我们另一件事：

如果想真正用好 AI，你不能只是输入一句“帮我做一个 XX”。

你需要：写出清晰的需求→ 制定合理的技术方案→ 判断架构是否正确→ 知道什么时候 AI 的建议有问题→ 审查生成的代码→ 验证测试结果→ 确保最终上线的东西是自己真正理解的。

换句话说： 越想把 AI 用好，你就越需要具备专业能力。

于是， 一个尴尬的矛盾出现了：AI 工具需要经验丰富的人才能驾驭，而新人原本应该通过长期工作积累经验；但 AI 又正在替新人绕过那些原本用于积累经验的过程。

Lars Faye 把这种情况称为“专家型新手”的困境。即一个刚进入行业的人，却被要求拥有接近专家的判断能力，才能安全、高效地使用 AI——这也是为什么现在AI Coding 对资深开发者和初级开发者带来的收益，完全不一样。

今年 6 月，Anthropic对约 40 万个 Claude Code 会话进行分析后发现，在典型的 Agentic Coding 会话中，人类通常还是负责“做什么”的规划决策，而 AI 更多负责“怎么做”的执行决策。并且，使用者的领域经验越多，单次指令能让 AI 完成的工作也越多，其领域专业知识与任务成功率也息息相关。

这代表着一个并不那么符合“AI 人人平等”想象的现实： AI 并没有消除专业能力的重要性，至少目前看来，它反而可能让专业能力的价值进一步放大。

经验丰富的人知道该让 AI 做什么，也知道什么时候应该阻止它继续做下去；而缺乏经验的人，甚至可能不知道自己正在犯错。

AI 让人产生了一种“我已经会了”的错觉

这种担忧也不是只停留在理论层面。

2024 年，一项名为《The Widening Gap：The Benefits and Harms of Generative AI for Novice Programmers》的研究，对初级程序员使用生成式 AI 的情况进行了细致观察。研究人员通过实验观察、访谈和眼动追踪等方式，研究了 21 名参与者在编程过程中如何使用生成式 AI。

结果非常有意思。 从表面上看，AI 的效果很好：21 名参与者中，有 20 人最终完成了编程任务。但研究人员发现，这些学生实际上逐渐分成了两类 ：

●另一类学生则陷入了完全不同的状态。他们会跳过原本必要的问题分析和规划过程，直接开始询问 AI。由于自己没有真正推导出解决方案，最终只能顺着 AI 的建议不断往下走。

研究中一个非常关键的结论是，这些 表现较差的学生会产生一种“能力幻觉”：他们觉得自己的表现比实际情况更好。可代码跑起来了，并不表示他们真正理解了代码。

对此，研究人员将这种差异描述为一个正在扩大的鸿沟。对于已经拥有一定基础的人来说，AI 可以帮助他们加速；但 对于原本就缺乏问题解决能力的人来说，AI 反而可能进一步放大已有的认知问题，甚至引入新的问题。

其中还有一个特别的能力，被研究人员称为“negative expertise（负向专业能力）”。它听起来有些奇怪，但意思非常简单：

真正的专业能力，有时候体现在你知道什么东西不应该听。

比如，资深开发者看到 AI 的一段建议时，可能会立刻感觉到问题：“这个方案虽然能跑，但扩展性不行”，“这个 API 已经过时了”，“测试通过不代表生产环境没有问题”……

这种能力不会直接写在官方文档里，也很难通过一次 Prompt 学会。 它来自大量失败过的项目、踩过的坑，以及那些曾经让人卡住几个小时甚至几天的问题。

AI 学习，正在形成一种“倒置模式”

在传统学习中，老师通常知道得比学生多。由学生提出问题，然后老师进行指导。

但 LLM 带来的学习方式有一个特殊之处：模型本身非常依赖使用者的引导。如果你问的问题够准确，提供的上下文够完整，知道应该如何拆分任务，那 AI 就能给出相当不错的结果；可如果你正在学习一个完全陌生的领域，你可能根本不知道自己应该问什么

所以，通过 LLM 学习可能会形成一种有些倒置的关系。

学生首先需要告诉“导师”应该关注什么，AI 根据提示回答，随后学生再根据回答继续引导 AI——看起来是 AI 在教学生，但从某种程度上说，学生也在不断决定 AI 应该教什么。

这对于专家来说，问题不大，因为他们有能力判断模型是否跑偏。但对于新人来说，他们很可能会把一个错误答案当成正确方向，然后继续围绕错误方向提出越来越具体的问题。

而 LLM 最大的危险之一恰恰在于：它通常不会告诉你“我完全不知道”。它会用非常流畅、合理、甚至极具说服力的语言，给你一个错误答案。最终，你会产生一种非常危险的错觉：

“ AI 一直都在回答我的问题，所以我应该已经理解了。”

可事实上，你可能只是获得了一条非常顺畅的错误路径。

“摩擦”可能才是培养专业能力的关键

真正成为一名开发者的过程，其实包含大量看似没有效率的事情。

●一个诡异的 Bug，没有日志，也没有人知道原因。

●一个功能写完后，发现性能差得离谱。

●一个架构刚开始看起来很优雅，用户量一上来就彻底失效。

●一个程序改了十几次，最终发现最初的设计方向就是错的，只能推倒重来。

这些经历 从效率角度看，似乎都是“浪费时间”。但问题是：它们可能正是专家能力形成的过程。

Lars Faye 在文中提到了一个德国词汇：Fingerspitzengefühl，大致可以理解为一种“指尖上的感觉”。对于开发者来说，它更接近我们常说的“技术直觉”或者“工程品味”。

当一个经验丰富的工程师看到某段代码时，他 可能暂时说不出具体哪里有问题，但会产生一种直觉：“这个东西以后大概率要出事。”这种能力不是 AI 自动生成代码时能直接传递给人的，它来自一次又一次的实践。

如果一个开发者从第一天开始，就把排错、设计、重构、性能分析、代码实现都交给 AI，他也许能比过去更快完成项目，但 与此同时，他也失去了形成这种工程直觉的机会。

毕竟，让 AI 生成一个排序算法，与理解为什么它能够工作，是两回事；让 AI 修复一个并发 Bug，与理解这个 Bug 为什么会发生，是两回事；让 AI 帮你设计系统，与理解为什么这个架构能够承受未来的流量，同样是两回事。所以，AI 免去的可能不只是重复劳动，还包括一部分培养专业能力所必需的“摩擦”。

Anthropic 发现：使用 AI 后，开发者掌握程度下降了 17%

到了 2026 年，这种担忧获得了更直接的实证支持。Anthropic 在今年 1 月发布的研究《How AI assistanceimpacts the formation of coding skills》中，专门研究了一个问题：

AI 是否会在提高工作效率的同时，影响技能的形成？

研究采用随机对照实验，让软件开发者学习一个新的 Python 库，并比较使用 AI 和不使用 AI 的情况下，开发者的学习与理解情况。结果：使用 AI 辅助的参与者，在完成任务后不久进行的相关知识测试中， 成绩平均比手写代码的参与者低 17%。

甚至，AI 也没有带来明显的速度优势：AI 组完成任务的速度确实略快，但差异并不大。也就是说： 就算开发者牺牲了一部分学习效果，也不一定换来了显著的效率提升。

不过，Anthropic 的研究也并非简单地得出“AI 有害学习”的结论，关键区别仍在于：你究竟如何使用 AI。那些掌握程度更高的参与者，并没有把 AI 单纯当作代码生成器。他们会追问原因，要求解释概念，在独立编码的过程中利用 AI 验证理解。

基于以上，Anthropic 的结论是，对于初学者来说，有意识地进行技能培养非常重要：“认知上的努力，甚至‘痛苦地卡在一个问题上’，这些过程很可能正是形成真正熟练度的重要条件。”

不一定非要 AI 帮你写代码

当然，AI 并不是不能帮助学习，只是我们大多数人都把 AI 当成了一个“答案机器”。要是 换一种使用方式，它的价值可能完全不同：

●不直接要求 AI 写答案，而是让它解释思路；

●不让它直接修复 Bug，而是让它给出排查方向；

●让它模拟面试官，连续追问你的设计；

●让它针对代码提出问题，而不是直接重构；

●让它解释多个方案之间的权衡；

●先自己完成，再让 AI Review。

简而言之，就是把 AI 从“代替你思考的工具”，变成“推动你思考的工具”。

一些研究已经发现，把AI 用作讨论伙伴，而不是单纯的答案生成器，更能促进反思、批判性和独立思考。宾夕法尼亚大学的相关实验也测试了带有“导师模式”的 AI。在这种模式下，AI 不会直接代替学生完成问题，而是提供帮助，让学生独立完成任务。

于是，AI Coding 出现了一个非常有意思的“悖论”： 对于想真正提升能力的开发者来说，最有价值的 AI Coding 工具，可能不是那个一次生成 1000 行代码的工具；而是那个在你卡住时，不立刻告诉你答案，并反问“你觉得这里为什么会出错”的 AI。

如果新人不再成长为专家，软件行业会发生什么？

这个问题进一步延伸，便会涉及到整个行业的人才培养机制。

过去，软件行业存在一条相对清晰的成长路径：新人从简单任务开始，写功能、修 Bug、读别人的代码、踩坑；随着经验增加，他们开始负责更复杂的模块；再往后，他们逐渐理解架构、性能、系统设计和工程管理——这个过程中，初级开发者不断积累经验，最终成为高级工程师。

但 AI 正在改变这条路径：如果简单的代码任务越来越多地交给 AI，那新人会失去大量传统意义上的“练级任务”。更进一步，如果 AI 连 Debug、重构和系统设计都逐渐接管，那么新人究竟在哪里获得经验？

而这，就是 Lars Faye 所担忧的“人才管道”问题。

如今的资深工程师能很好地使用 AI，是因为他们已经拥有几十年积累的知识；但十年之后，新人在成长过程中始终依赖 AI，那么谁来成为下一代资深工程师？

如果 AI 让整个行业越来越依赖少数真正理解系统的人，那么所谓的“人人都是开发者”，最终可能反而意味着： 真正的开发能力越来越集中在少数人身上。其他人能让 AI 写代码，却越来越难在没有 AI 的情况下理解、维护和修复这些系统。

“以后 AI 会修好它”？这可能是一场危险赌注

目前，许多支持完全自动化 AI Coding 的一个常见观点是：“现在生成的代码不完美也没关系， 反正未来 LLM 会更强，可以回过头来修复所有这些问题，清理一路堆积起来的各种垃圾。”

但正如 Sentry 联合创始人 David Cramer 最近在一次采访中所说： “这更像是一场科学实验，而不是已经被证明的工程事实。”

ARC-AGI Benchmark 创建者 François Chollet 也指出，LLM 本质上可以被看作一种基于已有模式进行插值的系统，而软件工程却经常要求面对从未出现过的问题进行适应和创新——面对真正独特的系统故障，你无法仅仅依靠“增加插值”来解决问题。

未来稀缺的不是代码，而是专家

最后，Lars Faye 强调他的这篇文章并不是要呼吁开发者拒绝 AI。AI Coding 已经成为越来越重要的生产工具，所以问题不是“要不要用 AI”，而是“在什么地方用、怎么用”。

对于正在学习编程或者进入新领域的开发者来说，Lars Faye 建议可以经常问自己几个问题：

●如果没有 AI，我还能完成这项任务吗？

●我是在理解问题，还是只是在更快获得答案？

●如果让我审查 AI 的代码，我能解释它在做什么吗？

●如果 AI 的答案是错的，我有能力发现吗？

●我是否查阅了官方文档和其他资料？

●这是一个重复性任务，还是一个需要我自己做关键判断的问题？

这些问题没有标准答案，但它们至少能够帮助我们区分：我是在用 AI 提高效率，还是正在逐渐失去专业能力。

Lars Faye 希望，未来几年整个行业能够逐渐重新认识一件事： 技能不会凭空形成。你必须持续、直接地参与实践，经历那些必要的摩擦，最终才能形成真正的专业能力 ——即使这意味着：你可能会走得更慢。

如果我们继续只关注生成了多少行代码、消耗了多少 Token，而忽视专业能力培养的“人才管道”正在逐渐干涸，那么 Sam Altman 所描述的未来可能真的会成为现实：

“智能会像电力和自来水一样成为一种公共资源，人们按量购买、按需使用。”

而未来，当所有人都习惯于在遇到问题时立刻让 AI 给出答案，我们或许会发现， 真正稀缺的已经不是代码，而是：那些能在 AI 给不出答案时，依然知道下一步该怎么做的人。