编程专业技能将因AI依赖而衰退

# AI 编程将阻碍专业技能发展 | Lars Faye 来源：https://larsfaye.com/articles/ai-coding-will-prevent-expertise > "我们预见这样一个未来：智能将像电力或自来水一样成为一种公共事业，人们按需购买，用于任何他们想要的地方" \- **OpenAI 的 Sam Altman** 在我之前的文章《智能体编码是一个陷阱》(https://larsfaye.com/articles/agentic-coding-is-a-trap)中，我讨论了“技能型编排者悖论”：管理AI编码智能体所需的技能，恰恰可能因为持续使用这些AI智能体而被削弱。专业技能曾是主要的差异化因素；经验越丰富的开发者，其技能*更不可能*发生萎缩，因为这些知识经过多年的积累已经固化。 环顾当下，你会看到*绝大多数*从这些模型中获得*最大*收益的人，都是拥有多年甚至数十年行业经验的人（当然，他们的经验早于AI工具时代）。任何行业老手都会告诉你：这些知识的基石来自实践本身。 那些在大语言模型（LLM）兴起时期入行的开发者，身处一个缺乏长期经验积累的境地，但他们正被引导（有时甚至被要求）使用编程助手来加速工作——而这些助手需要深厚的专业知识才能有效且*负责任*地驾驭。 对于这一人群来说，处境相当尴尬，因为这导致了一种局面：*新手*需要具备*专家级*技能才能利用这些工具并在行业中保持竞争力。 ## "专家新手" (https://larsfaye.com/articles/ai-coding-will-prevent-expertise#the-expert-novice) 我们目前正向整个行业的人们传递着非常矛盾的信息。我们不断强调，如果你不使用AI工具，就会被那些*正在*使用它们的同行"甩在身后"。自2023年起，"AI不会取代你，使用AI的人会取代你" (https://hbr.org/2023/08/ai-wont-replace-humans-but-humans-with-ai-will-replace-humans-without-ai) 这句话就一直不绝于耳。 然而同时，人们又说，要从这些模型中获得**最佳结果**，需要*运用高阶思维*；"氛围编程" (vibe coding) 是条死胡同；你需要"向上层发展"，创建稳健的规范，采用良好的设计模式进行架构设计，并且*务必*仔细审查输出结果，以确保你*绝不会*交付自己不理解的东西。 然而，做到这些所需的技能，是一个人在长期经历摩擦和挑战后，逐渐形成"良好品味" (https://www.seangoedecke.com/taste/) 的产物。 这就引出了另一个情境悖论：如果这些工具*需要专业知识*，但工具本身却能*主动规避*那些*培养专业知识*的摩擦过程，那么一个人如何*成为专家*，以便能够有效使用这些工具呢？ ## 盲目的自信 (https://larsfaye.com/articles/ai-coding-will-prevent-expertise#confidence-without-comprehension) 一种希望是，随着这些模型被用于代码生成，它们最终会*加速学习*。初级开发者可以借助他们的"个人AI导师"，像行业资深人士一样自信从容地工作。理解语法的重要性日益降低，任何知识或模糊之处都可以由AI工具填补。代码的底层机制被抽象化，因为开发者处于更高的抽象层级。 JetBrains (https://www.jetbrains.com/) 是开发工具领域的重要参与者，他们最近完成了一项研究 (https://dl.acm.org/doi/epdf/10.1145/3632620.3671116)，通过仔细分析初级和新手开发者在实时编码会话中的行为，并测试他们在不同程度AI辅助下学习编程的能力。他们的主要结论清晰且反直觉： > "参与者认为这就像有一个私人导师。从我们研究的数据来看...我们观察到，他们实际上并没有像使用私人导师那样使用生成式AI工具。事实上，情况恰恰相反。" **那些更倾向于重度AI辅助的参与者：** - "*经常跳过关键的规划阶段*，发现因为他们没有自己推理出这一步，所以Copilot替他们做了。" - 最终获得的是一种"能力错觉"*而非真正的理解*。 **相反，那些限制AI使用的参与者：** - "之所以成功，是因为他们发展出了'负面专业能力'——即'能够*忽略不正确或无用的生成式AI建议*'的能力'——使他们能够专注于编写自己的解决方案，而不是被引入歧途。" - "能够使用生成式AI来加速，创建他们*本来就要写的代码*。" 那些在AI使用上最无约束且最自信的新手开发者，*"跳过了编程问题解决过程中的关键步骤，结果迷失了方向。"* 也许并不令人意外的是，表现最好的新手开发者是那些*极大地限制*或*完全忽略*AI编程辅助的人。 ## 逆向学习 (https://larsfaye.com/articles/ai-coding-will-prevent-expertise#inverted-learning) 由于大语言模型（LLM）的自导向特性，*你经验越丰富，它们提供的帮助就越大*，因为你可以准确地引导、审查和验证输出。知识越少，它们就越可能*误导你*。通过与LLM交互学习新技能，形成了一种"逆向学习"模式：角色互换，最初是*学生*在引导*导师*，导师回应，然后学生再次引导导师。 这个过程充满风险；LLM对提示词的结构极为敏感。当你在探索新领域时，*你不知道自己不知道什么*，而LLM那种灵活且顺从的设计，可能会让你相信自己知道的比实际更多 (https://futurism.com/future-society/ai-chatbots-dunning-kruger-machines)。 如果你探索的领域即使稍显陌生，你常常甚至不知道该问哪些问题才能正确地引导模型给出最佳答案。这感觉就像一个指南针，无论你*暗示*北方*可能*在哪里，它都指向那里。 从同一项JetBrains研究 (https://dl.acm.org/doi/epdf/10.1145/3632620.3671116) 来看，即使是准备最充分的学生，也因这种学习模式而被AI辅助带偏：一位参与者展示了良好的基本规划和习惯，但突然*"跳过了关键的问题解决规划阶段，直接开始编码，并被Copilot吸引而快速生成代码"*，并且**不得不依赖LLM来修复LLM最初引入的错误**。 AI模型缺乏判断力、同理心和教学意图，其提供的解决方案并非基于*经验*，而是基于训练数据中的模式*（LLM的核心，本质上是极其复杂的模式插值器）*。 这台无限的问答机器极具诱惑力，而且已知具有成瘾性 (https://archive.is/2pKhN)。情况可能迅速失控，尤其是对经验不足的开发者。一旦你深入到一个生成的解决方案中，你常常就受制于AI工具来完成剩余工作，从而绕过了形成心智模型所必需的解决问题的摩擦过程*（公平地说，资深开发者也容易受此影响）*。 ## 摩擦是特性 (https://larsfaye.com/articles/ai-coding-will-prevent-expertise#the-friction-is-a-feature) 专业技能和精通并非纯粹通过观察和对话获得，而是通过经验、重复和试错；必须经历失败才能成功。如果我想学做饭，我可以观看一位大厨工作并提出无尽的问题。一个月后，我也许能描述出完美的半熟肋眼牛排是什么样子，但永远不会知道烹饪它的实际感觉，而且第一次尝试几乎肯定会煮过头。 编程充满了这样的时刻：追踪晦涩难懂的错误却找不到日志文件帮忙，体验某些方法带来的细微性能差异，或者在明确知道方案无法扩展时不得不重写。 这种应用的摩擦力直接构建了"开发者直觉"（或"品味"）。德国有个很棒的词来形容这个：Fingerspitzengefühl (https://architecturenotes.co/p/the-cost-of-a-in-code-goodbye-fingerspitzengefu)（指尖感觉）。它是当开发者看到某样东西时触发的肌肉记忆，心想，*"嗯...这很可能会出问题。"* 如果回避了挣扎的过程，这种直觉就永远不会形成。 在宾夕法尼亚大学（UPenn）2025年的大规模研究《不受约束的生成式AI可能损害学习》(https://www.pnas.org/doi/10.1073/pnas.2422633122)中，他们跟踪了1000名使用LLM学习数学的学生，发现学生将AI当作拐杖，最终表现*比仅使用教科书的学生差17%*（并且与JetBrains研究 (https://dl.acm.org/doi/epdf/10.1145/3632620.3671116) 一样，使用AI辅助的学生*自认为表现优异*）。 ### 然而，LLM不必只是生成代码 (https://larsfaye.com/articles/ai-coding-will-prevent-expertise#llms-dont-just-have-to-generate-code-though) 如果被当作苏格拉底式的辩论伙伴而非答案生成器来利用，研究表明 (https://arxiv.org/abs/2508.05116)，*"对话式AI系统能够有意义地激发反思性、批判性和独立思考"*。 在同样来自宾夕法尼亚大学的研究中，他们还测试了一个"导师"版本，让学生请求帮助，然后*独立解决问题*。GPT导师组在AI辅助练习环节中表现惊人，*高出127%*（尽管有趣的是，他们在测试中的得分与教科书组大致相同）。 这之所以有效，是因为模型*不再被当作生产手段*，认知工作被转移回个体身上。正是在摩擦仍然存在的情况下，它才能产生持久印记，从而形成专业知识。 Anthropic 2026年的研究 (https://www.anthropic.com/research/AI-assistance-coding-skills)《AI辅助如何影响编程技能的形成》得出了类似的结论： > 对于软件工程或任何其他行业的新手从业者而言，我们的研究可以视为支持AI工具下有意识技能培养价值的一小块证据。认知努力——甚至陷入痛苦的困境——可能对于培养精通至关重要。 这里存在某种讽刺意味：使用AI编程工具能够发生的最高效学习，恰恰是**当它不被用来生成太多代码的时候**。 ## 人才管道崩溃 (https://larsfaye.com/articles/ai-coding-will-prevent-expertise#pipeline-collapse) 如果LLM可以编写代码*和调试*代码，并且智能体工作流能够利用训练数据中丰富的模式执行系统设计，那么这些知识最初存在的目的是什么？编程将完全用自然语言完成，我们可以不再需要接触代码本身，因为模型在不断改进并填补任何知识或模糊性的空白。它们将调试出现的任何问题，并管理它们引入的复杂性。 正在进行的万亿美元赌注是：**这些知识将不再重要**，因为LLM将填补空缺，并有效地成为新一代的"开发者"。这开始散发出一种傲慢的气息，这气息曾驱动过过去的低代码运动和CEO们的狂热幻想，而非立足于现实。 编程/程序/软件是逻辑、数学、问题解决、批判性思维、规划、沟通和创造力的独特交汇点。LLM可以检测到人类永远无法企及的模式 (https://arxiv.org/abs/2307.04721)，但模式只能让你走到一定程度。 Sentry (https://sentry.io/welcome/)（一个性能和错误跟踪平台）的联合创始人David Cramer在最近的一次采访 (https://youtu.be/l8yqPwRQXHI?t=544) 中简洁地表达了这一点： > 我认为有一种人...内心深处相信LLM会变得足够好，以至于它们会回来修复这些东西，能够清理沿途堆积的所有垃圾。我不认为这是真的。我认为这是一个科学实验。你想炫耀你能生成所有代码并且有上百个任务并行运行，我会炫耀给你看代码100%是broken的状态。 ### 管道会崩溃，还是仅仅改变？ (https://larsfaye.com/articles/ai-coding-will-prevent-expertise#will-the-pipeline-collapse-or-just-change) 这真的取决于我们是否做出了必要的转变，以更具教学意义的方式使用这些系统。 如果我们继续关注并推广那些将代码生成置于深刻理解之上的AI编程工作流，*我们就是在培养将继承今天所创建代码的下一代专业人士*吗？ ## 我的方法：摩擦优先 (https://larsfaye.com/articles/ai-coding-will-prevent-expertise#my-approach-friction-first) Joel Spolsky 预见性地写道*（早在2002年）*，在他的《抽象泄漏定律》中： > 像所有抽象一样，代码生成工具假装抽象掉了某些东西，但它们会泄漏。处理泄漏的唯一正确方法是学习抽象的工作原理...抽象节省了我们工作的时间，但并没有节省我们学习的时间。 如果一个开发者想学习Java，他们可能不应该从Spring Boot开始。如果想学习JavaScript基础，不应该从React开始。如果想精通CSS，不应该从Tailwind开始。LLM可以被视为终极的抽象泄漏 (https://www.jonathanbeard.io/blog/2026/06/20/ai-the-ultimate-leaky-abstraction.html)。 ### 我在此的建议与我之前的处方非常相似 (https://larsfaye.com/articles/ai-coding-will-prevent-expertise#my-advice-here-is-very-similar-to-my-previous-prescription) 如果一个开发者想成为编程专家，**他们应该在很大程度上忽略这些模型的纯代码生成能力**，而是将其用于*交互式文档、动态教程生成器*以及*苏格拉底式练习*。 当然，这并非万灵药：将AI工具用作导师也有其风险，因为它和其他交互一样容易产生幻觉，并且不能**仅仅**依赖它作为学习来源。如果你无法准确审计生成代码的正确性，你就无法审计生成概念的正确性。如果你使用AI作为导师，你**必须**仍然将其输出与*官方文档*、*人类同行*以及*实际的试错*进行核对。 > *"编程实际上是巩固理解的绝佳方式。你编程越多，就越理解你所从事的领域。"* — Kent Beck，测试驱动开发的创造者 选择这条更慢、更审慎的道路是培养专业技能的最佳方式，但我意识到当周围生态系统积极反其道而行时，这有多困难。AI正在被各公司强制推行（常常是鲁莽地），并且被整合到大多数软件开发工具和IDE中，这些工具主要迎合资深工程师的需求*（即使像Cursor这样的工具，除非用户特别寻找，否则也会隐藏代码视图）*。一些公司甚至强迫开发者 (https://www.wsj.com/tech/ai/tech-firms-arent-just-encouraging-their-workers-to-use-ai-theyre-enforcing-it-d43ebf84) *仅*使用AI完成*所有*编码任务，无论经验水平如何，这些公司将不得不自己吸取教训。 然而，对于其他所有试图在深度学习（双关）与生产力之间寻求平衡的人来说，