深度长文 · 2026年8月 · 约 5000 字 · 深度阅读 ≈ 12 min
📖 参考来源
本文深度引用并评述 Lars Faye 的原创文章：
「AI Coding will Prevent Expertise」— larsfaye.com原文探讨 AI 代码生成工具如何系统性阻断专业能力的形成路径。
最近读到一篇文章，题目叫 「AI Coding will Prevent Expertise」，作者 Lars Faye。读完之后，有种被击中的感觉——不是那种"啊，原来如此"的顿悟，而是一种"我早就感觉到了，但说不出来"的不安被彻底点名了。
我们身边有越来越多这样的人：拿起 Cursor、Claude、Copilot，几天就能交出一个"能跑"的项目，但一旦 AI 给出错误答案，或者遇到一个稍微超出常见模式的问题，就完全卡死。Lars 把这类人称为 专家新手（Expert Novice）——外表像专家（生产速度快、代码量大），内里是新手（没有工程直觉，无法独立调试）。
01 · 上手越快，越难真正入门
Lars 文章的核心论点，可以用一句话概括：从 AI 工具中获益最多的，恰恰是那些本来就不太需要它的资深工程师。
这听起来反直觉，但逻辑非常清晰。有效使用 AI 工具所需要的能力——审查生成代码的质量、判断架构设计的取舍、知道该向 AI 问什么问题——这些本身就是需要多年摸索才能形成的专业技能（Professional Expertise）。而新手，恰恰缺乏这些判断力。
一个初学者用 Claude 写出了 Spring Boot 的 CRUD 接口，代码能跑，但他不知道为什么要这么分层、连接池的参数为什么这样配、事务边界在哪里。他没有学到 Spring Boot，他学到的是"如何向 AI 描述 Spring Boot"——这是两件完全不同的事。
02 · 你感觉学到了，但你只是感觉
Lars 在文章中引用了一项 JetBrains 援引的 ACM 2024 研究，《生成式 AI 对初级程序员的益处与危害（Benefits and Harms of Generative AI for Junior Programmers）》。结论让人无法辩驳：
宾夕法尼亚大学 2025 年的研究更直接：跟踪 1000 名学生发现，使用 LLM 学习数学的学生，比只用教科书的学生 成绩低 17%。更让人哭笑不得的是：这些学生 自认为学得很好。
这句话是整篇文章里击中我最深的。我见过太多这样的情况：工程师用 AI 解决了某个问题，下一次遇到类似问题，大脑的第一反应不再是"我该怎么分析这个问题"，而是"我该怎么向 AI 描述这个问题"。问题解决了，但解决问题的能力没有增长——甚至在退化。
03 · 摩擦力才能形成肌肉记忆
Lars 在文章中引入了一个德语词：Fingerspitzengefühl（指尖感觉）。这是指一个有经验的开发者，扫一眼代码就能感知到哪里可能有问题的那种直觉。这种直觉不是通过阅读文档得来的，也不是观看别人解决问题习得的，它只能来自亲身经历——调试到凌晨两点、在生产环境踩过坑、在某个 bug 上卡了三天然后发现是自己的低级错误。
摩擦力（Friction）才是真正的老师。 当你花三个小时追踪一个内存泄漏，你的大脑在那个过程中建立的神经连接，是 AI 替你找到这个 bug 永远无法给你的。专业能力（Expertise）来自重复的挫败和试错，而不是来自观察或对话。
是的，就连 Anthropic 自己的研究也承认这一点。这句话我觉得是整个 AI 行业最诚实的自我表述之一。你可以高效地使用 AI，但你无法通过使用 AI 来替代那些"应该被你自己痛苦经历的学习过程"。
04 · 下一代专家从哪里来？
Lars 提出了一个更宏观、也更让人不安的问题：如果我们今天用 AI 大规模生产代码，那么谁来维护这些代码？谁来接手今天创建的技术债务？
Sentry 联合创始人 David Cramer 说得很直接：
AI 生成代码的速度是人类的数倍，但理解代码、维护代码、重构代码的人，仍然需要是人类工程师——而且需要是 真正有工程直觉 的工程师，不是"专家新手"。如果今天所有初级工程师都跳过了那些构建直觉的艰难过程，五年后的软件行业将面临一个技术断层：大量能"操作 AI"的人，但极少能"理解系统"的人。
05 · LLM 是终极漏洞抽象
Lars 引用了 Joel Spolsky 2002 年的经典文章《抽象泄漏定律（The Law of Leaky Abstractions）》：
所有抽象层都会泄漏。TCP/IP 在网络拥塞时会暴露底层行为。ORM 在处理复杂查询时会暴露 SQL 的本质。而 LLM——它是 终极漏洞抽象（The Ultimate Leaky Abstraction）。它把几乎所有编程知识都抽象掉了，直到你遇到一个它无法处理的问题。而那一刻，你需要的恰好是那些你从未建立的基础知识。
所以 Lars 的建议是：学 Java 不要从 Spring Boot 开始，学 JavaScript 不要从 React 开始。 先理解抽象背后的东西，再使用抽象。这个顺序，AI 的出现没有改变，反而让它更重要了。
06 · 苏格拉底模式：AI 应该怎么用
一个让我感到希望的数据：宾夕法尼亚大学同一个研究中，使用 苏格拉底式辅导模式（Socratic Tutoring Mode） 的学生，表现提升了 127%。
苏格拉底式意味着：让 AI 向你提问，而不是让 AI 给你答案。"你觉得这个函数的时间复杂度是多少？""你能解释一下为什么这段代码会产生竞态条件吗？"这种模式下，AI 成为了一个苏格拉底式的老师，迫使你自己思考和表述，而不是等待答案。
区分的核心问题只有一个：这件事里，有没有需要你做决策和判断的部分？ 如果有，那是你需要亲自经历的，不该委托给 AI。如果只是机械性执行，委托是完全合理的。
结语 · 我们需要选择哪种工程师文化
Lars 文章的最后，提出了一个有些沉重的警示：如果我们沉迷于代码行数和 Token 消耗，而让专业能力的培育流水线枯竭，那么"按计量销售智能"的愿景可能真的会成为现实——人们将对 AI 工具产生根本性依赖，失去独立解决问题的能力。
我不认为这是一篇反 AI 的文章，Lars 也不是在呼吁我们放弃这些工具。他真正在说的，是一种使用 AI 的心智模式：
François Chollet（ARC-AGI 基准测试创建者）有一句话我一直记得：
AI 工具是插值，工程能力是外推。你需要足够的"已理解"作为基底，才能在遇到全新问题时找到方向。那些基底，只能通过摩擦建立，没有捷径。
这不是一句反对 AI 的话，而是一句关于如何 真正利用好 AI 的话。也许最好的工程师文化，是把 AI 当成一个苛刻的考官，而不是一个随时待命的答案机。
延伸阅读：
- ACM 2024 · 《Benefits and Harms of Generative AI for Junior Programmers》
- Joel Spolsky · 《The Law of Leaky Abstractions》(2002)
- Anthropic Research · 《AI and Expertise Formation》(2026)
