氛围编程有害论：当 AI 辅助的速度扼杀软件质量

Andrej Karpathy 在 2025 年初创造了"氛围编程"（vibe coding）一词，描述一种编程风格："完全沉浸在氛围中，拥抱指数级增长，忘记代码的存在。"你用自然语言描述需求，AI 生成代码，然后直接发布。这感觉像是一种超能力。然而不到一年，数据开始讲述一个不同的故事。

METR 的一项随机对照试验发现，有经验的开源开发者在使用 AI 编码工具时效率降低了 19%——尽管他们预测自己会快 24%，事后仍然认为自己快了 20%。CodeRabbit 对 470 个 GitHub Pull Request 的分析发现，AI 协作编写的代码包含的重大问题是人工编写代码的 1.7 倍。Anthropic 对 52 名工程师的研究显示，AI 辅助的开发者在自己代码库的理解测试中得分低了 17%。

即时代码生成的多巴胺循环正在创造一种新的技术债务类别，它不会出现在你的迭代回顾中。以下是它为何重要，以及应对之策。

理解债务：不会自我宣告的债务

技术债务大家都熟悉。你走了捷径，你知道走了捷径，最终它会拖慢你的速度。理解债务不同——它是系统中代码量与任何人真正理解的代码量之间日益扩大的差距。

Addy Osmani 将此描述为 AI 生成代码的隐性成本：代码库表面看起来健康，而理解力却在悄然退化。一个学生团队在项目第七周发现，没有人能解释为什么做出了任何设计决策，或者系统的不同部分应该如何协同工作。表面的代码质量掩盖了系统性的误解。

机制很直接。AI 生成代码的速度快于人类评估代码的速度，颠覆了传统的审查动态。一个初级工程师现在可以生成代码的速度快于高级工程师批判性审计的速度。这移除了曾经使审查有意义的质量门控。

数据支持这一点。主要使用 AI 进行代码委托的开发者——"帮我写这个"——在理解测试中得分低于 40%。而使用 AI 进行概念探究的开发者——"解释这是怎么工作的"——得分超过 65%。相同的工具，截然不同的结果，完全取决于开发者如何对待生成的代码。

没人想听的生产力悖论

METR 的研究值得仔细关注，因为它与 AI 编码工具的主流叙事相矛盾。十六位经验丰富的开发者，每位都有多年对大型开源项目的贡献经验（平均 22,000+ 星标，100 万+ 行代码），完成了 246 个随机分配为允许或不允许使用 AI 工具的任务。

当允许使用 AI 时，开发者花在主动编码和阅读代码上的时间减少了。取而代之的是，他们花时间提示、等待 AI 输出和审查建议——接受率不到 AI 生成内容的 44%。75% 的人报告阅读了 AI 输出的每一行，56% 的人进行了重大修改以清理代码。

研究者谨慎地指出，这种效率降低特定于有经验的开发者在他们已经熟悉的成熟代码库中工作。对于绿地项目或不熟悉的代码库，情况可能不同。但这个注意事项恰恰说明了问题：AI 编码工具的生产力提升是真实的，但比营销宣传的要窄，而且它们最有帮助的场景——不熟悉的代码、样板代码、脚手架——也是理解债务积累最快的场景。

安全定时炸弹

除了生产力之外，氛围编程还引入了随时间复合的具体安全风险。

研究人员发现，1,645 个 Lovable 生成的应用程序中有 170 个——10.3%——在其 Supabase 配置中存在关键的行级安全缺陷。AI 生成的代码安全漏洞率是人工编写代码的 2.74 倍，配置错误率高 75%。

Django 联合创始人 Simon Willison 以 1986 年挑战者号灾难作为类比：一场等待发生的灾难性故障，"某个由 AI 编写的核心组件没有被正确理解或检查。"Arcjet CEO David Mytton 划出了明确的界限——AI 应该实现经过实战验证的安全库，而不是从零发明安全机制。

问题不在于 AI 编写了不安全的代码。问题在于氛围编程的工作流程专门阻碍了那种能捕获安全问题的仔细审查。当你处于"描述、生成、发布"的流程中时，激励结构主动对抗你停下来对屏幕上刚出现的内容进行威胁建模。

技能侵蚀螺旋

传统学习包括遇到问题、与之斗争，并从斗争中建立直觉。氛围编程用"遇到问题、扔给 AI、得到可用的解决方案、发布、明天带着同样的理解差距重复"来替代这个循环。

这对初级开发者的打击最大。他们缺乏通过手动犯错获得的直觉，而这种直觉对于检测 LLM 何时偏向不正确的逻辑至关重要。但它也影响有经验的开发者——Anthropic 的研究显示，工程师成为全栈开发者的速度更快，同时对更深层技能集退化的担忧也在增加。

结果是一类新的脆弱开发者，他们能生成代码但不能理解、调试或维护代码。当 AI 生成的代码出错时——它必然会出错——这些开发者无能为力。代码变动数据证实了这一点：代码变动率上升了 41%，代码重复增加了四倍，仔细的重构从 2021 年变更行的 25% 下降到 2024 年的不到 10%。

Forrester 预测到 2026 年，75% 的企业将面临直接归因于 AI 驱动快速开发的中度至严重技术债务。这不是关于遥远未来的预测。就是现在。

重构危机

当没有人能解释代码为什么能工作时，重构变得不可能。重构需要系统的心智模型——不仅理解每个部分做什么，还要理解它为什么存在、它维护什么不变量、改变它会破坏什么。

氛围编码的系统以手动编写的遗留代码不具有的方式抵抗重构。对于遗留代码，曾经有人理解过它——有注释、提交信息、设计文档，或者至少有一个记得约束条件的开发者。对于氛围编码的系统，理解从未存在过。代码是从高级描述生成的，意图和实现之间的映射从未在任何人类大脑中保持过。

这创造了一个悖论：代码表面上通常比遗留代码更干净，但更难安全地更改。它通过了 linter 检查，遵循命名约定，看起来很地道。但它是一座纸牌屋，因为结构性决策是由一个优化合理性的模型做出的，而不是由一个推理领域的工程师做出的。

团队在需要让系统适应新需求时发现了这一点。修改看起来很直接。但每次更改都会触发意外的失败，因为 AI 的实现选择看起来合理但实际上是任意的——没有底层设计原理来指导修改。

AI 时代的刻意练习模式

答案不是停止使用 AI 编码工具。答案是停止将它们作为理解的替代品。以下是有效的模式。

将理解作为交付物，而非代码。 在接受任何 AI 生成的代码之前，你应该能够向同事解释每一个结构性决策。如果你不能，你还没有完成任务——你只是创造了理解债务。

使用 AI 进行探索，而非委托。 数据很清楚：问"解释这是怎么工作的"的开发者优于说"帮我写这个"的开发者。使用 AI 探索解决方案空间、理解权衡、学习不熟悉的 API。然后在所学的基础上自己编写代码。

强制审查不对称性。 初级工程师不应该单独审查 AI 生成的代码。速度反转——生成超过审查——意味着你需要高级工程师参与，正是因为 AI 使生成步骤变得微不足道地快。

维护设计原理日志。 对于每个重要的 AI 生成组件，记录为什么选择这种方法、考虑了哪些替代方案、它满足了哪些约束。这是氛围编程摧毁的上下文，你需要刻意地重建它。

设置理解检查点。 定期选择一个随机模块，让负责的开发者从记忆中解释它。不是"大声读代码"——解释设计意图、不变量、失败模式。如果他们不能，这是理解债务正在积累的信号。

限制影响范围。 David Mytton 的框架很实用：氛围编程可接受用于围绕验证组件的脚手架、小的可审查更改和一次性原型。不可接受用于新的安全实现、整个生产代码库和开发者无法独立验证的任何内容。

即将到来的清算

41% 的新代码现在是 AI 生成的。Stack Overflow 的 2026 年开发者调查发现，76% 使用 AI 编码工具的开发者报告至少有时会生成他们不完全理解的代码。代码库中未解决的技术债务总量从 2025 年初的几百个问题攀升到 2026 年 2 月的超过 110,000 个。

爆发还没有发生。但条件已经具备：越来越多的生产代码没有人完全理解，由调试技能正在退化的开发者维护，在衡量"发布的代码行数"而非"理解的系统"的组织中。

能够度过这场风暴的团队是那些认识到一个基本事实的团队：**理解工作就是工作本身。**代码只是产物。AI 可以比以往更快地生成产物。但如果没有人理解产物，速度只是创造你无法解决的问题的更高效方式。