因为 AI，编程专业要崩溃了

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

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

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

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

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

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

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

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

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

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

Tip

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

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

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

Tip

如果想真正用好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。由于自己没有真正推导出解决方案，最终只能顺着AI的建议不断往下走。

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

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

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

Tip

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

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

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

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

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

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

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

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

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

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

Tip

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tip

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所描述的未来可能真的会成为现实：

Tip

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

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