【CSDN 编者按】当 AI 已经可以写代码、改 Bug、做重构甚至开始接手系统设计时一个看起来有些“反常识”的问题正在浮现如果未来的程序员越来越少亲手解决问题那么再过十年谁来成为真正能够理解、审查和接管这些系统的专家编译 | 郑丽媛出品 | CSDNIDCSDNnews如今的 AI Coding 浪潮正在把软件开发推向一个令人兴奋的方向● 不会写代码可以用自然语言让 AI 帮你生成应用。● 不熟悉某个框架让 AI 现查现写。● 遇到报错复制日志几十秒得到解决方案。效率提升是真实存在的。但与此同时一个越来越值得讨论的问题也开始浮出水面AI Coding 也许正在提高今天的生产效率却可能也在削弱明天的专家培养能力。最近开发者 Lars Faye 在一篇文章中提出了一个颇具争议的观点AI Coding 可能会阻碍专业能力的形成。他的核心担忧并不是“AI 写的代码不好”也不是要求开发者回到没有 Copilot、Claude Code 或其他 AI 工具的时代而是一个开发者究竟是如何成长为专家的如果这些专业能力来自于长期的实践、试错、排错和失败那当 AI 提前替我们绕过这些过程未来的程序员又该如何获得这些能力这个问题并非纯粹的“反 AI 焦虑”。其实近两年一系列针对 AI 与学习、编程能力的研究也开始得出一些相似甚至令人不安的结论AI 的确可以帮助人们更快完成任务但“完成任务”和“真正学会”之间可能根本不是一回事。一个越来越明显的矛盾新人需要专业能力才能正确使用 AI过去几年软件行业一直在重复一句话“AI 不会取代你但会用 AI 的人会取代你。”这句话几乎已经成为 AI 时代职场竞争的标准口号。于是越来越多开发者开始用 AI 编程工具。公司鼓励多用、IDE 默认集成、Agent 工具不断升级一些企业甚至直接把 AI 使用量与工作流程绑定。但同时行业又在告诉我们另一件事如果想真正用好 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 GapThe Benefits and Harms of Generative AI for Novice Programmers》的研究对初级程序员使用生成式 AI 的情况进行了细致观察。研究人员通过实验观察、访谈和眼动追踪等方式研究了 21 名参与者在编程过程中如何使用生成式 AI。结果非常有意思。从表面上看AI 的效果很好21 名参与者中有 20 人最终完成了编程任务。但研究人员发现这些学生实际上逐渐分成了两类● 一类学生能真正从 AI 中获得加速。他们使用 AI 的方式是让模型帮助完成那些自己原本就知道该怎么做的事情。当 AI 给出错误或没有帮助的建议时他们也有能力识别并忽略。● 另一类学生则陷入了完全不同的状态。他们会跳过原本必要的问题分析和规划过程直接开始询问 AI。由于自己没有真正推导出解决方案最终只能顺着 AI 的建议不断往下走。研究中一个非常关键的结论是这些表现较差的学生会产生一种“能力幻觉”他们觉得自己的表现比实际情况更好。可代码跑起来了并不表示他们真正理解了代码。对此研究人员将这种差异描述为一个正在扩大的鸿沟。对于已经拥有一定基础的人来说AI 可以帮助他们加速但对于原本就缺乏问题解决能力的人来说AI 反而可能进一步放大已有的认知问题甚至引入新的问题。其中还有一个特别的能力被研究人员称为“negative expertise负向专业能力”。它听起来有些奇怪但意思非常简单真正的专业能力有时候体现在你知道什么东西不应该听。比如资深开发者看到 AI 的一段建议时可能会立刻感觉到问题“这个方案虽然能跑但扩展性不行”“这个 API 已经过时了”“测试通过不代表生产环境没有问题”……这种能力不会直接写在官方文档里也很难通过一次 Prompt 学会。它来自大量失败过的项目、踩过的坑以及那些曾经让人卡住几个小时甚至几天的问题。AI 学习正在形成一种“倒置模式”在传统学习中老师通常知道得比学生多。由学生提出问题然后老师进行指导。但 LLM 带来的学习方式有一个特殊之处模型本身非常依赖使用者的引导。如果你问的问题够准确提供的上下文够完整知道应该如何拆分任务那 AI 就能给出相当不错的结果可如果你正在学习一个完全陌生的领域你可能根本不知道自己应该问什么所以通过 LLM 学习可能会形成一种有些倒置的关系。学生首先需要告诉“导师”应该关注什么AI 根据提示回答随后学生再根据回答继续引导 AI——看起来是 AI 在教学生但从某种程度上说学生也在不断决定 AI 应该教什么。这对于专家来说问题不大因为他们有能力判断模型是否跑偏。但对于新人来说他们很可能会把一个错误答案当成正确方向然后继续围绕错误方向提出越来越具体的问题。而 LLM 最大的危险之一恰恰在于它通常不会告诉你“我完全不知道”。它会用非常流畅、合理、甚至极具说服力的语言给你一个错误答案。最终你会产生一种非常危险的错觉“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》中专门研究了一个问题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 所描述的未来可能真的会成为现实“智能会像电力和自来水一样成为一种公共资源人们按量购买、按需使用。”而未来当所有人都习惯于在遇到问题时立刻让 AI 给出答案我们或许会发现真正稀缺的已经不是代码而是那些能在 AI 给不出答案时依然知道下一步该怎么做的人。原文链接https://larsfaye.com/articles/ai-coding-will-prevent-expertise#inverted-learning