21CTO导读：长期技能形成的过程中需要持续的困难。

我们首先用奥特曼的一句名言来讨论论文的开题。

“我们展望未来，人工智能将像电力或水一样成为一项公共事业，人们可以按表购买，将其用于任何他们尝试的事情。”

——OpenAI创始人 Sam Altman

在之前的文章《智能体编码是一个陷阱》中，我们讨论了“技巧的协调者悖论”，即管理用于编码的人工智能代理所需的技能，因为会持续使用这些人工智能代理而收缩。

经验是关键所在；开发人员的经验越丰富，技能的可能性就越小，因为多年的经验积累已经让他们积累了足够的知识。

如果你现在环顾胜利，你会发现，从这些模型中执行最多的人，几乎都是在这个领域拥有许多甚至填补多年经验的人（当然，这早于人工智能工具的出现）。任何一位行业资深人士都会告诉你同样的话：这些知识的基石等于实践经验。

在大模型时代落后于当今进入该领域的开发人员处于一种不利地位，他们没有长期发展的优势，因此被引导（有时甚至是强制）使用编码助手来加速他们的工作，而有效而明智地使用这些助手需要丰富的专业知识。

对于这个群体来说，这是一个非常尴尬的问题。它造成了一种局面：新手需要具备专家级的技能才能使用工具并跟上行业发展的步伐。

“专家级新手”

我们目前向整个行业传递的信息非常的混乱。

我们反复强调，如果你不使用人工智能工具，你就会被那些使用人工智能工具的同行“甩在后面” 。 “人工智能不会取代你，但使用人工智能的人会取代你”。类似这样的话从2023年就开始反复出现。

同时，也说，要从这些模型中获得最佳结果，就要运用高阶思维；“凭感觉编码”是条死路；你需要“向上追溯”，创建健壮的规范，运用良好的模式进行架构设计，并始终认真有人输出结果，这样你就不会发布自己不理解的东西。

然而具备这种能力的人，需要经历时间的磨练和挑战，才能最终形成“好品味” 。

由此引发了另一个悖论：如果这些工具需要专业知识，但这些工具却能激发规避培养专业知识的难度，那么一个人要如何才能成为专家，从而有效地使用这些工具呢？

缺乏理解的自信

人们希望这些大模型最终能够加速学习，因为它们可以用于代码生成。

初级开发人员也可以像行业资深人士一样，凭借他们的“个人AI导师”以同样自信和严谨的态度开展工作。 知识的重要性急剧降低，任何知识缺口或歧义都将由AI工具完成。

由于开发人员采用了技术栈的更高层，代码的底层机制仍然被抽象化。

开发者工具领域的领军企业JetBrains近期引用了一篇名为《差距扩大：生成式人工智能对新手分析师的利弊》的研究。该研究对程序员在实时编码过程中的行为进行了分析，并测试了他们在不同程度的人工智能辅助下编码学习的能力。其主要结论令人震惊且出乎意料：

“参与者认为这就像拥有一名私人导师。但从我们研究的数据来看……我们观察到，他们实际上并没有像使用私人导师那样使用 GenAI 工具。事实上，情况恰恰相反。”

那些更倾向于使用人工智能辅助的参与者：

• “他们经常跳过关键的计划阶段，发现由于他们没有经过深思熟虑就采取了这种立场，而副驾驶却取代了他们所做的事情。”
• “最终呈现出来的只是‘胜任的假象’，而非真正的理解。 ”

事实上，那些减少人工智能使用量的参与者：

• “他们之所以成功，是因为他们培养了‘刑事专业知识’——即‘忽略不正确或无益的GenAI建议的能力’——使他们能够专注于编写自己的解决方案，而不是被误导。”
• “他们利用 GenAI 加速了开发进程，准备好了他们到底打算编写的代码。 ”

那些对人工智能的使用最无拘无束、最自信的新手开发者“跳过了编程问题解决过程中的关键步骤，现在迷失了方向”。

不出所料，表现最好的新手开发者往往是那些大量减少或完全忽视人工智能编码辅助功能的开发者。

逆向学习

由于学习导师的自主学习特性，你的经验越丰富，他们提供的益处就越多，因为你可以准确地指导、审核和验证学习成果。你的知识越少，他们就越容易误导你。与学习导师互动学习新技能，会形成一种“反向学习”模式，即角色互换：学生最初指导导师，导师做出回应，然后学生再次指导导师。

这个过程充满变数；LLM（学习型硕士）对题目的形式极其敏感。当你探索新领域时，你往往意识不到自己的知识盲区，而LLM灵活多变的设计可能会让你误以为自己懂得比实际更多。

如果你探索的领域哪怕只有一点点陌生，你往往都不知道该问哪些问题才能真正引导模型给出最佳答案。这就像一个指南针，无论你认为北方在哪里，它都永远指向北方。

JetBrains 强调的同一项研究表明，即使是准备最充分的学生也会因为这种学习模式而受到 AI 辅助的影响：一名参与者表现出良好的基本规划和习惯，但突然“跳过了关键的问题解决规划阶段，直接跳到编码，并被 Copilot 诱使快速编写代码”，不得不依靠 LLM 来纠正 LLM 最初引入的错误。

AI 模型缺乏判断力、同理心和教学意图，提供的解决方案并非基于经验，而是基于训练数据中的模式（LLM 本质上便是极其复杂的模式插值器）。

所以，大模型——“无限答案生成器”固然诱人，而且你知道，它会让人上瘾。

它很容易让人沉迷其中，尤其对于经验不足的初阶开发者。一旦你深入研究了生成的解决方案，你往往就不得不依赖人工智能工具来完成余下的工作，从而绕过了构建心智模型所需的解决问题的过程。

坦白地说，懒散的资深开发者也容易陷入这种情况。

摩擦力是一种特性

专业技能和精湛技艺并非仅仅通过观察和交流就能获得，而是需要经验、反复练习和不断试错。

正是应对那句古话：失败是成功之母。

如果我想学做饭，我可以观看一位名厨工作，并不断向他请教。一个月后，我或许能描述出完美的五分熟肋眼牛排是什么样子，但我永远无法体会烹饪它的感觉，而且几乎可以肯定的是，我的第一次尝试就会把它煎过头。

编码的过程中总会遇到各种各样的情况，比如在没有日志文件帮助的情况下追踪晦涩的错误，体验某些方法的细微性能差异，或者当很明显某种方法无法扩展时不得不重写它。

这种实际操作中的摩擦正是培养“开发者直觉”（或“品味”）的关键所在。德语里有个词很贴切地形容了这种感觉：Fingerspitzengefühl（指尖感觉）。它是一种肌肉记忆，当开发者看到某个东西并想到“嗯……这很可能会带来问题”时，这种直觉就会被触发。

如果回避这类挣扎的过程，这种直觉就永远无法建立。

宾夕法尼亚大学在 2025 年开展的大规模研究《没有护栏的生成式人工智能会损害学习》中，研究人员跟踪了 1000 名使用 LLM 学习数学的学生，发现学生们将人工智能当作拐杖，最终成绩比只使用教科书的学生差 17%，而且就像之前的研究一样，使用人工智能辅助的学生认为自己表现出色。

不过，LLM 并不一定非得要生成代码。

研究数据表明，如果将对话式人工智能系统用作苏格拉底式辩论伙伴而不是答案生成器，那么“对话式人工智能系统可以有效地激发人的反思性、批判性和独立思考”。

在同一项宾夕法尼亚大学的研究中，他们还测试了一个“辅导”版本，让学生寻求帮助，然后独立解决问题。GPT辅导组在人工智能辅助练习环节的表现惊人地提高了127%。有趣的是，他们在测试中的得分与教科书组大致相同。

这种方法之所以有效，是因为该模式不再被用作生产手段，而是将认知工作重新转移到个人身上。正是当摩擦依然存在时，才能留下持久的印记，最终造就专业的精湛技能。

Anthropic 于 2026 年发布的研究报告 《人工智能辅助如何影响编程技能的形成》也得出了类似的结论：

对于软件工程或其他行业的初级从业者而言，我们的研究可以被视为利用人工智能工具进行有意识技能提升价值的一个初步证据。认知投入——甚至包括经历痛苦的卡壳——对于培养精湛技能可能至关重要。

这里存在某种讽刺意味：使用 AI 编码工具进行最有成效的学习，反而是当它根本不用来生成任何代码的时候。

输油管道的坍塌

如果大语言模型（LLM）能够编写和调试代码，而智能体工作流能够利用训练数据中丰富的模式进行系统设计，那么这些知识的最初用途是什么？

编程将完全使用自然语言来完成，我们无需再与代码交互，因为模型会不断改进并填补任何知识空白或歧义。它们会调试出现的所有问题，并管理由此产生的任何复杂性。

这场价值万亿美元的豪赌是：这些知识无关紧要，因为大语言模型（LLM）将填补空缺，并有效地成为新一代的“开发者”。

包括马斯克等都说这样类似的话，这种观点开始散发出一种傲慢自大的气息，这种傲慢正是过去无代码运动与CEO们的白日梦的根源，而非对现实之考量。

现实上编码/编程/软件是逻辑、数学、问题解决、批判性思维、规划、沟通和创造力的独特交汇点。LLM 能够以人类无法企及的规模发现模式，但模式只能带你走到这一步。

Sentry（一个性能和错误跟踪平台）的联合创始人David Cramer在最近的一次采访中简洁地表达了以下一点：

我认为有些人天生就相信LLM会不断改进，最终能够修复这些问题，清理掉一路积累下来的所有垃圾代码。我不认为这是真的。

我认为这就像一个科学实验。你想炫耀自己能够生成所有的，还能让数百个程序代码完全运行，那我也炫耀，同时你展示了代码的缺陷。

一条输油管道会坍塌，还是会发生改变？

这实际上取决于我们是否需要进行必要的改造，将这些系统更多地用于教学目的。

如果我们继续专注于推广以代码生成，而不是深度理解为优先的AI编码工作流程，我们一定无法培养出能够继承今天所创建代码的下一代专业人才。

我的方法：难度先行

乔尔·斯波尔斯基（Joel Spolsky）早在2002年就远远见地在其著作《抽象概念灯光法案》（Law of Leaky Abstractions）中这样写道：

那些尝试 Abstract 出某些东西的代码生成工具，就像所有 Abstract 一样，都会造成代码泄漏。而有效解决这些泄漏的唯一方法就是学习 Abstract 的工作原理。Abstract 可以节省我们的工作时间，但并不能节省我们的学习时间。

如果开发者想学习 Java，他们可能不应该从 Spring Boot 入手。如果他们想学习 JavaScript 基础，他们也不应该从 React 入手。如果他们想精通 CSS，他们不应该从 Tailwind 入手。

而LLM（基础架构）可以被视为抽象层遮挡的最大限度体现。我的建议与前面的处方非常相似。

如果开发者想成为编程专家，他们应该忽略这些模型的纯粹代码生成功能，而应该将它们用于交互式文档、动态教程生成器和“苏格拉底式练习”。

当然，这并非万能之策：使用人工智能工具作为指导者也存在风险，因为它和其他任何交互一样，都可能出现各种错觉，因此不能将其作为学习资源。如果无法正确审核生成代码的准确性，就无法审核生成概念的准确性。即使将人工智能工具作为指导者，也必须对照官方文档、人类同行以及实际的试错过程来验证其输出结果。

“编程实际上是巩固理解的完美方式。你编程越多，就越能理解你内在的领域。” ——肯特·贝克，测试驱动开发（TDD）的创始人

选择一条更慢、更审慎的道路是提升专业技能的最佳路径，但我深知，当周围的生态系统都在面临对抗时，这条路走的会有多么艰难。

人工智能正被各大公司强力反击（往往是鲁莽的不由分说），并被集成到大多数软件开发工具和集成开发环境（IDE）中，因为它们服务于资深工程师（一些主要工具，例如光标，会隐藏代码视图，无需用户主动查看）。

还有公司甚至强制开发人员在所有编码任务中都必须使用人工智能，无论其经验的一些水平如何，这些公司最终都会被深刻的教训。

然而，对于其他所有希望在深度学习（没有双关语）和生产力之间取得平衡的人来说，你可以提出一些资格问题，以确保你使用这些工具能够带来长期的好处。

以下是我的AI助手检查清单：

• 如果没有人工智能工具，我还能完成这项任务吗？
• 我使用该模型是为了加深理解，还是为了加快找到答案？
• 如果我需要审核和验证生成的成果，我能否充分解释发生了什么？
• 如果我正在学习一个新概念，我是否做了充分的研究，知道应该问哪些正确的问题？
• 我是否通过其他方法（阅读文档、标准工具搜索、StackOverflow、Reddit）交叉验证了该方法？
• 这是一个已经完成100次的机械性任务，还是一个需要高层决策才能完成的任务？

即使作为一名拥有一批多年经验的开发人员，我仍然在日常工作中不断参考它们，尤其是在我尝试学习新事物的时候。

在这个领域，学习永远有乐趣，且永无止境。

关键在于我们要区分认知债务和卸载认知：认知债务是放弃你的判断和决策，而认知负债是机械的或乏味的工作委托出去。

正如人类学研究中所提到的，“陷入困境”其实是件好事。它需要自律和努力，才能避免成为纯粹的生成答案，而这些答案本身可能不太准确。大语言模型并没有彻底改写我们学习的基本原理，但它确实为我们提供了一种新的学习方式。

信息并非商品

我希望未来几年看到的转变是，人们逐渐认识技能的学习并积极参与。

你必须直接而持续地投入其中，才能体验到最终实现专业技能所必需的困难，甚至这意味着进步会更加缓慢。

如果我们只关注代码行数和代币（Token）消耗，而忽视了专业知识渠道的逐年枯竭，那么 Sam Altman 提出的按量出售智能的设想可能会真正成为现实。

，领域知识将变得极为稀缺，当人们着手进行任何类型的开发工作时，如果没有有效的AI工具订阅，就会感到束手无策，动弹不得。

大语言模型（LLM）是一个类似的静态的技能数据库，它们是一种值引擎。然而，软件工程却是一门可插拔和创新性问题解决的艺术。你无法通过插值来解决一个完全独特的系统故障。

——弗朗索瓦·肖莱，ARC-AGI基准测试的创造者

作者： 一件音乐的鱼