AI 编程将阻碍专业能力的形成

TL;DR

这篇文章与我在 6 月写的《从前慢：两种慢，两种命运》指向同一个判断：AI 消除了工作流里的摩擦，却也悄悄跳过了成长路上的必经之路。 当时可能有不少读者看到标题就跳过了。Lars Faye 从编程教育研究和新手使用 AI 的行为出发，为这个判断补上了另一组证据：代码生成得越顺畅，越可能绕过形成判断力所必需的规划、失败和调试。

重点不是反对 AI，也不是把所有摩擦都保留下来，而是分清两种摩擦：系统切换、格式转换和重复搬运应该交给 AI；形成专业能力所必需的思考、试错与受挫，则需要主动保留。第一种摩擦拖慢工作，第二种摩擦构成成长。

以下是 Lars Faye 原文《AI Coding will Prevent Expertise》的译文。

“我们预见的未来是：智能会像电力或自来水一样成为一种公共资源。人们按量向我们购买智能，再把它用于任何想做的事情。”

——OpenAI 的 Sam Altman

在上一篇文章《智能体编程是一个陷阱》中，我讨论了“熟练编排者悖论”：管理 AI 编程智能体所需的那些能力，恰恰也可能因持续使用这些智能体而逐渐退化。

专业经验是其中最主要的区别。开发者的经验越丰富，就越不容易出现能力退化，因为经过多年实践，相关知识已经有机会沉淀下来。

看看现在的情况就会发现，从这些模型中获益最多的，绝大多数都是在这个行业里积累了多年、甚至数十年经验的人——这些经验自然早于 AI 工具出现。任何行业老手都会告诉你同一件事：这些知识的根基，来自亲手做过那些工作。

而在 LLM 兴起前后进入这个行业的开发者，没有长期积累带来的优势，却又被鼓励、有时甚至被强制要求使用编程助手来加速工作。但要想有效且负责任地驾驭这些工具，恰恰需要长期积累的专业能力。

这让他们陷入了一个尴尬的位置：一个新手需要具备专家级能力，才能使用这些工具，并跟上行业节奏。

“专家型新手”

目前，我们正在向整个行业释放非常矛盾的信号。

一方面，我们不断强调：如果不用 AI 工具，就会被那些使用 AI 的同行“甩在后面”。从 2023 年起，“AI 不会取代你，但会使用 AI 的人会取代不会使用 AI 的人”这句话就一直被反复提起。

但与此同时，人们又说，要从这些模型中获得最好的结果，就必须运用高阶思维：“氛围编程”走不远；你需要“上移抽象层级”，编写严谨的规格说明，运用良好的设计模式完成架构，并始终认真审查模型输出，绝不能交付自己无法理解的东西。

然而，这些能力只会在一个人长期经历摩擦和挑战之后形成，最终沉淀为所谓的“好品味”。

这又带来一个悖论：

如果这些工具要求使用者具备专业能力，但同时又能绕过培养专业能力所必需的摩擦，那么一个人究竟应该怎样成为专家，进而有效地使用这些工具？

没有理解支撑的自信

一种乐观设想是：这些模型在生成代码的同时，最终也会加速学习。初级开发者可以在“私人 AI 导师”的帮助下，表现出与行业老手相同的稳重和自信。

语法知识越来越不重要，任何知识缺口和模糊之处都可以由 AI 工具补齐。由于开发者处在更高的抽象层级，代码底层的运行机制可以继续隐藏起来。

开发者工具领域的重要厂商 JetBrains 最近引用了一项名为《不断扩大的差距：生成式 AI 对编程新手的益处与危害》的研究。

这项研究细致分析了参与者在实时编程过程中的具体行为，并测试了他们在不同程度的 AI 辅助下学习编程的能力。研究得出的主要结论既鲜明，又违背直觉：

“参与者认为，这就像拥有了一位私人导师。但从研究数据来看……我们观察到，他们实际上并没有把生成式 AI 工具当作私人导师。事实上，情况恰恰相反。”

那些更多依赖 AI 辅助的参与者：

• “经常跳过关键的规划阶段，因为他们自己并没有通过推理走到这一步，而 Copilot 替他们完成了。”
• 最终形成的是“胜任力错觉”，而不是真正的理解。

与之相反，那些有意识限制 AI 使用的参与者：

• 之所以能够成功，是因为他们形成了“负向专长”，也就是识别并忽略错误或无用的生成式 AI 建议的能力。这使他们可以专注于编写自己的解决方案，而不被模型引向歧途。
• 能够使用生成式 AI 加速工作，但生成的代码原本就在他们的计划之中。

那些使用 AI 最不受限制、也最有信心的新手开发者，“跳过了编程问题解决过程中的关键步骤，最终迷失了方向”。

也许并不令人意外：表现最好的新手开发者，恰恰是那些大幅限制、甚至完全忽略 AI 编程辅助的人。

倒置的学习

由于 LLM 的使用高度依赖使用者主动引导，你的经验越丰富，它带来的收益就越大，因为你能够准确地引导、审查和验证模型输出。你的知识越少，它就越容易误导你。

使用 LLM 学习新技能，呈现出一种“倒置学习”模式：学生首先指导导师，导师作出回应，然后学生再次调整导师的方向。

这个过程非常不稳定。LLM 对提示词的形式极其敏感。当你探索陌生领域时，你并不知道自己不知道什么，而 LLM 灵活、顺从的设计，很容易让你误以为自己懂得比实际更多。

只要进入一个稍微陌生的领域，你往往连应该提出哪些问题都不知道，也就无法正确引导模型给出最好的答案。

它开始像一只永远指向北方的指南针——只不过“北方”在哪里，由你说了算。

在 JetBrains 所引用的同一项研究中，即使准备最充分的学生，也会因为这种学习模式而被 AI 辅助带偏。

有一位参与者原本表现出了良好的基础规划能力和习惯，但随后突然“跳过关键的问题解决规划阶段，直接进入编码，并受到 Copilot 的诱导，迅速生成代码”。最终，他不得不依靠 LLM 修复一开始正是由 LLM 引入的错误。

AI 模型缺乏判断力、同理心和教学意图。它提供的解决方案并不来自经验，而是来自训练数据中的模式——LLM 从根本上说，是极其复杂的模式插值器。

这台可以无限提供答案的机器非常诱人，而且已经被证明可能使人上瘾。

事情很容易迅速失控，尤其是对缺乏经验的开发者而言。一旦深入采用了某个由 AI 生成的解决方案，你往往也只能继续依赖 AI 工具来完成剩余工作，从而绕过形成心智模型所必需的问题解决摩擦。

公平地说，资深开发者同样可能陷入这种局面。

摩擦不是缺陷，而是功能

专业能力和精通程度，并不只是通过观察和对话形成的，而是来自经验、重复以及反复试错。你必须先经历失败，才能取得成功。

假设我想学习烹饪，我可以观看一位顶级厨师工作，并不断向他提问。一个月之后，我也许能够准确描述一块完美的五分熟肋眼牛排，却仍然不知道亲手煎制它是什么感觉，而且第一次尝试时几乎肯定会把它煎过头。

编程中充满类似的时刻：

• 在没有日志帮助的情况下追踪难以理解的错误；
• 亲身感受不同方法之间细微的性能差异；
• 当一种方案显然无法扩展时，不得不推倒重写。

正是这些实际摩擦，构成了“开发者直觉”，也就是所谓的“品味”。

德语中有一个很好的词可以描述它：Fingerspitzengefühl，直译是“指尖直觉”（也就是通过长期实践形成的本能判断）。

它是一种肌肉记忆：开发者看到某个东西时，会本能地想——“嗯……这东西以后大概会出问题。”

如果避开了亲自挣扎的过程，这种直觉就永远无法形成。

宾夕法尼亚大学在 2025 年进行了一项大规模研究：《缺乏护栏的生成式 AI 可能损害学习》。

研究人员跟踪了 1000 名使用 LLM 学习数学的学生，结果发现学生把 AI 当成了拐杖，最终的成绩比只使用教科书的学生低了 17%。与前一项研究一样，使用 AI 辅助的学生却认为自己表现得非常出色。

但 LLM 并不一定非要用来生成代码

如果把 LLM 当成苏格拉底式的思辨伙伴，而不是答案生成器，研究表明，“对话式 AI 系统能够有效促进反思性、批判性和独立思考”。

宾夕法尼亚大学的同一项研究还测试了一个“导师”版本：学生可以向 AI 求助，但随后必须独立解决问题。

使用 GPT 导师的小组，在 AI 辅助练习阶段的表现提高了惊人的 127%。不过，有意思的是，他们在正式测试中的成绩与只使用教科书的小组大致相同。

这种方法之所以有效，是因为模型不再被作为生产工具使用，认知工作重新回到了个人身上。

只有当摩擦依然存在时，学习才会留下持久的印记，并最终转化为专业能力。

Anthropic 在 2026 年发布的研究《AI 辅助如何影响编程能力的形成》也得出了类似结论：

对软件工程或其他行业的新手而言，我们的研究可以视为一项小规模证据，说明在使用 AI 工具时，有意识地培养能力非常重要。认知投入——甚至是痛苦地卡在某个问题上——很可能是形成精通能力的重要条件。

这里存在某种讽刺意味：

使用 AI 编程工具时，最有效的学习方式，恰恰可能是几乎不让它生成任何代码。

专业能力培养链条的断裂

如果 LLM 既能编写代码，也能调试代码，而智能体工作流又能利用训练数据中丰富的模式完成系统设计，那么学习这些知识还有什么意义？

未来，编程将完全通过自然语言完成。我们不再需要直接接触代码，因为模型会不断进步，填补一切知识和模糊性缺口。它们会调试出现的问题，也会管理由它们自己引入的复杂性。

这场价值万亿美元的赌注是：

这些知识将不再重要。

LLM 会接手剩余工作，实际上成为新一代“开发者”。

这种论调与过去的无代码运动以及 CEO 的狂热设想如出一辙，却脱离了实际开发环境。

编程和软件开发，是逻辑、数学、问题解决、批判性思维、规划、沟通与创造力的独特交汇点。

LLM 能够以人类无法企及的规模识别模式，但模式能够解决的问题终究有限。

性能与错误监控平台 Sentry 的联合创始人 David Cramer 在最近的一次采访中简洁地指出：

我认为有一类人……本能地相信 LLM 最终会变得足够好，能够回来修复这些东西，清理一路堆积起来的所有垃圾。

我不认为这是真的。我认为这是一场科学实验。

你可以炫耀自己能够生成全部代码，同时让几百件事情并行推进；而我可以向你展示，这些代码为什么无一例外都有问题。

专业能力培养链条会断裂，还是只会改变形态？

这取决于我们能否完成必要的转向，以更符合学习规律的方式使用这些系统。

如果继续关注并推广那些把生成代码置于深入理解之上的 AI 编程工作流，我们就无法培养下一代专业人才，而正是他们将要继承今天生成的这些代码。

我的做法：摩擦优先

Joel Spolsky 早在 2002 年就在《抽象漏洞法则》中极具预见性地写道：

那些假装能够把某些东西抽象掉的代码生成工具，与所有抽象一样，都会发生泄漏。而要想妥善处理这些泄漏，唯一的办法就是理解这些抽象究竟如何工作……抽象可以节省我们的工作时间，却无法节省我们的学习时间。

如果开发者想学习 Java，也许不应该从 Spring Boot 开始。

如果想学习 JavaScript 基础，就不应该从 React 开始。

如果想真正精通 CSS，就不应该从 Tailwind 开始。

LLM 可以被视为终极的有漏洞抽象。

我的建议与上一篇文章中的主张非常相似

如果开发者想成为编程专家，就应该在很大程度上忽略这些模型单纯生成代码的能力，转而把它们用于：

• 交互式文档；
• 动态教程生成；
• 苏格拉底式练习。

当然，这并不是万能解法。

把 AI 工具当作导师也存在风险，因为它同样会产生幻觉，不能被当作唯一的学习来源。

如果你无法正确审查生成代码的准确性，同样也无法审查 AI 生成概念的准确性。

如果把 AI 当作导师，仍然必须通过以下方式验证其输出：

• 官方文档；
• 人类同行；
• 实际试错。

“编程其实是巩固理解的绝佳方式。你编写的程序越多，对自己所处领域的理解就越深入。”

——测试驱动开发的创造者 Kent Beck

选择这种更慢、更审慎的路径，是培养专业能力的最佳方式。但我也明白，当周围的生态系统都在与这个方向对抗时，这件事有多么困难。

企业正在强制推广 AI，而且往往相当鲁莽。AI 已经被内置到大多数软件开发工具和 IDE 中，而这些产品主要面向资深工程师设计。有些工具，例如 Cursor，甚至会默认隐藏代码视图，除非用户主动寻找。

部分公司甚至强制开发者在所有编程任务中只能使用 AI，完全不考虑经验水平。这些公司最终只能自己吸取教训。

不过，对于其他希望在深入学习与生产效率之间取得平衡的人来说，可以用下面这些问题自检，确保自己使用这些工具时仍能获得长期收益。

我的 AI 辅助检查清单

• 如果没有 AI 工具，我还能完成这项任务吗？
• 我使用模型，是为了加深理解，还是为了更快获得答案？
• 如果必须审查和验证生成结果，我能否充分解释其中发生了什么？
• 如果正在学习一个新概念，我是否已经做过足够的研究，知道应该提出哪些问题？
• 我是否通过其他方式交叉检查并验证了这个方案，例如阅读文档、使用传统搜索工具、查询 Stack Overflow 或 Reddit？
• 这真的是一项已经重复过上百次的机械性任务，还是过程中包含需要主动判断和决策的环节？

即使我已经拥有数十年的开发经验，在日常工作中仍然会不断参考这些问题，尤其是在学习新事物时——而在这个行业里，需要学习的新事物永远不会断绝。

关键在于识别认知债务与认知卸载之间的区别：

• 认知债务，是放弃自己的判断和决策；
• 认知卸载，是把机械或繁琐的工作委托出去。

正如 Anthropic 的研究所说，“痛苦地卡住”是一件好事。

想让自己不再滑回到直接生成答案的状态，需要自律和努力——更何况，生成的答案一开始就未必准确。

LLM 并没有突然改写人类学习的基本规律，但确实为我们提供了一种新的学习方式。

智能不是一种商品

我希望未来几年能够发生的转变，是人们重新理解：如果没有主动参与，能力就不会形成。

你必须直接且持续地投入其中，亲身经历最终形成专业能力所必需的关键摩擦——即使这意味着前进得更慢。

如果我们继续执着于代码行数和消耗的 token，而专业能力培养链条却在多年间逐渐断裂，那么 Sam Altman 所设想的、按量把智能卖回给我们的未来，可能真的会成为现实。

领域知识可能变得极其稀缺。到了那时，一个人只要坐下来准备做任何开发工作，如果身边没有处于有效期内的 AI 工具订阅，就会立刻感到一阵无所适从。

LLM 是静态的技能数据库，是插值引擎。

然而，软件工程是一种适应与解决全新问题的实践。面对一个完全独特的系统故障，你不可能仅靠插值找到出路。

——ARC-AGI 基准测试的创造者 François Chollet