AI依赖或致编程专业技能崩溃
长期技能养成离不开持续的"摩擦"
"我们设想这样一个未来：智能就像电力或自来水一样成为公共服务，人们按使用量向我们付费，用它做任何想做的事。" ——OpenAI 山姆·奥尔特曼（Sam Altman）
在我的上一篇文章《智能体编码是个陷阱》https://larsfaye.com/articles/agentic-coding-is-a-trap中，我探讨了"熟练协调者悖论"：管理AI编码智能体所需的技能，恰恰会因持续使用这类AI工具而退化。专业经验曾是核心竞争力——开发者经验越丰富，技能退化的可能性就越低，因为多年实践早已让知识固化为深层认知。
如今你会发现，从AI模型中获益最多的群体，绝大多数是拥有数年甚至数十年行业经验的开发者（他们的职业生涯早于AI工具时代）。任何行业老兵都会告诉你：这些知识的根基，来自实打实的亲手实践。
而在大语言模型（LLM）时代入行的开发者，既没有长期积累的优势，又被引导（有时是强制）使用编码助手来提升效率。但这些工具的有效、负责任使用，恰恰需要深厚的专业经验打底。
这让新手陷入了尴尬的困境：要驾驭工具、跟上行业节奏，他们需要具备专家级的能力，可他们偏偏还只是新手。
当前整个行业传递的信号充满矛盾：一方面反复强调，不用AI工具就会被同行"甩在身后"——"AI不会取代你，但用AI的人会"这句话从2023年起就不绝于耳；另一方面又说，要让AI模型发挥最佳效果，必须运用高阶思维："凭感觉编码"行不通，得"向上走"，制定严谨的规格说明，用优秀的设计模式搭建架构，还要始终仔细审核AI输出，绝不能发布自己看不懂的代码。
然而，这些能力并非凭空而来，而是在长期实践中不断经历摩擦与挑战，最终沉淀出的"良好品味"https://www.seangoedecke.com/taste/。
这就引出了另一个情境悖论：如果AI工具要求使用者具备专业能力，而工具本身又会绕过培养专业能力所需的摩擦，那么新手该如何成长为专家，进而有效使用这些工具？
有人寄希望于AI模型能加速学习——初级开发者借助"私人AI导师"，就能拥有和行业老兵一样的底气。语法知识变得不再重要，任何认知空白或模糊地带都能由AI填补。开发者只需站在更高层面，无需深究代码底层逻辑。
"参与者以为AI就像私人导师，但从我们的研究数据来看……他们实际上并没有把生成式AI工具当导师用，情况恰恰相反。"
重度依赖AI辅助的参与者：
- "常常跳过关键的规划阶段，因为他们觉得Copilot已经替自己完成了思考"
- "最终陷入'能力幻觉'，而非真正理解知识"
主动控制AI使用的参与者：
- "成功的原因在于他们培养出了'反向专业能力'——即'识别并忽略AI错误或无用建议的能力'，从而能专注于自己的解决方案，不被AI带偏"
- "能够用AI提升效率，生成自己原本就打算写的代码"
那些毫无限制、对AI充满信心的新手开发者，"跳过了编程解决问题过程中的关键步骤，最终迷失方向"。
或许并不意外，表现最佳的新手开发者，是那些大幅减少甚至完全不用AI编码辅助的人。
由于大语言模型的自主特性，经验越丰富，从中获益越多——你能准确引导、审核和验证AI输出；而知识储备越少，越容易被AI误导。用LLM学习新技能是一种"倒置学习"模式：学生先引导导师，导师给出回应，再由学生继续引导，角色完全反转。
这个过程充满风险：LLM对提示词的表述极为敏感。当你探索新领域时，"不知道自己不知道什么"，而LLM灵活包容的特性，会让你误以为https://futurism.com/future-society/ai-chatbots-dunning-kruger-machines自己懂的比实际更多。
面对哪怕稍有陌生的领域，你往往连该问什么问题才能引导AI给出最佳答案都不知道。这感觉就像一个永远指向"北方"的指南针——而这个"北方"是你自己随口定义的。
AI模型缺乏判断力、共情能力和教学意图，其给出的解决方案并非基于经验，而是来自训练数据中的模式（LLM本质上是极其复杂的模式插值器）。
这个"无限答案机"充满诱惑，甚至会让人上瘾https://archive.is/2pKhN。对于经验不足的开发者来说，情况可能迅速失控：一旦深入AI生成的解决方案，你往往会依赖AI完成后续工作，而这恰恰绕过了构建思维模型所需的问题解决摩擦（公平地说，资深开发者也容易陷入这种困境）。
专业能力的养成，绝非单纯通过观察和对话就能实现，而是需要亲身体验、反复练习和试错——失败是成功的必经之路。就像学烹饪：我可以看大厨做菜，问无数问题，一个月后能头头是道地描述三分熟肋眼牛排的做法，但永远不知道实际烹饪是什么感觉，第一次动手肯定会煎过头。
编程中也有无数这样的时刻：追查没有日志可循的诡异错误，体会不同方法间细微的性能差异，或是在发现现有方案无法扩展时，不得不彻底重写。
正是这些实际的摩擦，直接塑造了"开发者直觉"（或称"品味"）。德语中有个词能精准描述这种状态：Fingerspitzengefühlhttps://architecturenotes.co/p/the-cost-of-ai-in-code-goodbye-fingerspitzengefu（指尖触感）。它是一种肌肉记忆——当开发者看到某段代码时，会本能地觉得："嗯……这可能会出问题。"如果绕过了挣扎的过程，这种直觉就永远无法建立。
宾夕法尼亚大学2025年的大规模研究《无监管的生成式AI会损害学习》https://www.pnas.org/doi/10.1073/pnas.2422633122显示，他们跟踪了1000名用LLM学数学的学生，发现依赖AI的学生最终成绩比只用课本的学生**低17%**（和之前的研究https://dl.acm.org/doi/epdf/10.1145/3632620.3671116一样，这些用AI的学生都觉得自己表现很好）。
但如果把AI用作苏格拉底式的讨论伙伴，而非答案生成器，研究表明https://arxiv.org/abs/2508.05116，"对话式AI系统能有效激发反思、批判性和独立思考"。
在同一项宾大研究中，他们还测试了"导师"模式：学生先向AI求助，再独立解决问题。结果显示，GPT导师组在AI辅助练习中的表现高出127%（不过有意思的是，他们在正式测试中的得分和课本组差不多）。
这种模式之所以有效，是因为AI不再被当作生产工具，而是把认知工作重新交还给了个人。只有当摩擦依然存在时，才能留下持久的印记，最终培养出专业能力。
Anthropic公司2026年的研究https://www.anthropic.com/research/AI-assistance-coding-skills《AI辅助对编码技能养成的影响》也得出了类似结论：
对于软件工程或其他行业的新手而言，我们的研究为"借助AI工具进行有针对性的技能培养"的价值提供了一点佐证。认知投入——甚至是痛苦地卡壳——可能对掌握技能至关重要。
这里存在一种讽刺：用AI编码工具实现最有效学习的方式，恰恰是几乎不用它生成代码。
如果LLM既能写代码又能调试代码，智能体工作流还能从训练数据的海量模式中完成系统设计，那掌握编程知识还有什么意义？未来编程完全可以用自然语言完成，我们无需再接触代码——毕竟模型会不断改进，填补所有认知空白和模糊地带，调试出现的问题，处理自己引入的复杂度。
当前这场万亿美元赌注的核心逻辑是：这些知识无关紧要，因为LLM会接手一切，成为新一代的"开发者"。这散发出一种傲慢的气息，和过去的无代码运动、CEO们的狂热幻想如出一辙，却脱离了现实。
编程/软件开发是逻辑、数学、问题解决、批判性思维、规划、沟通与创造力的独特结合。LLM能以人类无法企及的规模识别模式https://arxiv.org/abs/2307.04721，但模式只能带你走这么远。
性能与错误追踪平台Sentryhttps://sentry.io/welcome/的联合创始人戴维·克莱默（David Cramer）在近期采访https://youtu.be/l8yqPwRQXHI?t=544中一针见血地指出：
我觉得有些人……天真地认为LLM会不断完善，最终能解决所有问题，清理一路上堆积的所有垃圾。但我不这么认为，这更像一场科学实验。
你炫耀自己能用AI生成所有代码，同时推进上百个项目；我就给你看这些代码100%都会出问题。
问题的关键在于，我们是否需要转向更具教育性的AI使用方式。
如果我们继续聚焦并推广以代码生成为核心、而非深度学习的AI工作流，我们就无法培养出下一代专业人才——而他们终将接手今天生成的所有代码。
乔尔·斯波尔斯基（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**终极漏洞抽象**。
如果想成为编程专家，开发者应在很大程度上忽略这些模型的纯代码生成能力，转而将其用作交互式文档、动态教程生成器，以及苏格拉底式练习工具。
当然，这并非万能药：把AI当导师也有风险，它和其他AI交互一样会产生幻觉，因此不能完全依赖它作为学习来源。如果你无法准确审核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完成所有编码任务，无论其经验如何，这些公司终将自食其果。
不过，对于其他想在深度学习（并非双关）和效率之间寻求平衡的人，可以通过以下几个问题来确保AI工具的使用能带来长期益处：
- 如果没有AI工具，我还能完成这项任务吗？
- 我用AI是为了加深理解，还是只想快速得到答案？
- 如果需要审核验证AI的输出，我能充分解释其中的原理吗？
- 如果正在学习新概念，我是否做了充分研究，知道该问哪些正确的问题？
- 我是否通过其他方式（阅读文档、常规搜索、StackOverflow、Reddit）交叉验证了AI给出的方法？
- 这是一项已经重复过100次的机械任务，还是过程中需要自主决策的任务？
即便我已是拥有数十年经验的开发者，日常工作中仍会不断参考这些问题，尤其是在学习新东西时——而这个领域永远有学不完的新内容。
关键要区分认知负债和认知卸载：认知负债是放弃自己的判断和决策，而认知卸载是将机械或繁琐的工作交给工具。
我希望未来能看到一种转变：人们意识到，技能的养成离不开主动参与。你必须直接、持续地投入，经历必不可少的摩擦，才能最终获得专业能力（哪怕这意味着进度会慢一些）。
如果我们一味执着于代码行数和消耗的token，任由专业人才储备逐年枯竭，山姆·奥尔特曼那种"把智能按用量卖给我们"的愿景就可能成为现实。届时，领域知识将变得极为稀缺，一旦开发者没有激活的AI工具订阅，坐下来做开发时就会陷入手足无措的瘫痪状态。
LLM是静态的技能数据库，是插值引擎。而软件工程，是一场关于适应和解决新问题的实践。面对完全独特的系统故障，你无法靠插值来解决。 ——弗朗索瓦·肖莱（François Chollet），ARC-AGI基准测试创始人