智能体工程
一年前，Andrej Karpathy 创造了"氛围编程"（vibe coding）这个词来描述一种欢快而鲁莽的编程方式：你提示，把键盘交给AI，接受它吐出的一切，不看差异，通过粘贴错误消息来迭代。这是一个很好的标签，用来描述一件真实的事情——在纯AI自动驾驶模式下构建快速原型或MVP。
问题在于，"氛围编程"已经成为一个包罗万象的术语。人们现在用它来描述从周末黑客到严谨的工程工作流程的一切，在后者中，AI代理在人类监督下处理实现。这些是根本不同的活动，混淆它们正在造成真正的困惑——以及真正的损害。
氛围编程实际上是什么
氛围编程意味着跟着感觉走和不审查代码。这是其定义特征。你提示，你接受，你运行它，你看看它是否有效。如果无效，你粘贴错误并重试。你不断提示。人类是一个提示DJ，而不是工程师。
这对以下情况确实有用：
- 绿地MVP、原型和黑客马拉松演示。 你需要在周日之前完成某些工作。代码质量无关紧要。
- 个人脚本和一次性工具。 你是唯一的用户。如果它坏了，你重新生成它。
- 学习和探索。 新手可以构建他们原本无法构建的东西，从AI的输出中学习。
- 创意头脑风暴。 故意过度生成以查看AI建议的方法，然后扔掉它并正确构建。
如果氛围编程让数百万原本无法创建自定义软件的人获得了这种能力，那是真正的胜利。这种技术在工具箱中有其合法地位。
但此时失败模式已经得到充分记录。模式总是相同的：演示很棒，然后现实来临。你尝试修改它、扩展它或保护它，然后你发现没有人理解代码实际在做什么。正如一位工程师所说，"这不是工程，这是希望。"
我们需要一个更好的术语来描述专业版本
事情是这样的：许多经验丰富的工程师现在从AI中获得了巨大的生产力提升——2倍、5倍，有时更多——同时保持代码质量。但他们的工作方式看起来完全不像氛围编程。他们在提示之前编写规范。他们审查每个差异。他们运行测试套件。他们将AI视为一个快速但不可靠的初级开发人员，需要持续监督。我个人喜欢"AI辅助工程"，并谈到这如何描述人类保持在循环中的那一端。
Simon Willison（我崇拜他的工作）为此提出了"氛围工程"——它重新定义了"氛围"，同时添加了"工程"来表示纪律。但在观察社区辩论这个问题几个月后，我认为"氛围"这个词承载了太多包袱。它暗示随意性。当你告诉CTO你正在"氛围工程"他们的支付系统时，你可以看到他们脸上的担忧。
Andrej Karpathy 本周建议使用"智能体工程"（agentic engineering），我认为我喜欢它。
以下是它可能有效的原因：
它描述了实际发生的事情。 你正在编排AI代理——可以执行、测试和改进代码的编码助手——而你充当架构师、审查者和决策者。你可能只手动编写一小部分代码。其余部分来自在你指导下工作的代理。这就是代理性的。而你在整个过程中应用工程纪律。这就是工程。
它在专业上是清晰的。 "智能体工程"听起来就像它本身：一个涉及自主代理的严肃工程学科。你可以毫不尴尬地对你的工程副总裁说这个词。你可以把它放在职位描述中。你可以围绕它建立团队实践。
它划出了一条清晰的界限。 氛围编程 = YOLO。智能体工程 = AI做实现，人类拥有架构、质量和正确性。术语本身强制执行了这种区分。
智能体工程在实践中可能是什么样子
工作流程并不复杂，但它需要氛围编程明确放弃的纪律：
你从计划开始。 在提示任何东西之前，你编写设计文档或规范——有时在AI的帮助下。你将工作分解为定义明确的任务。你决定架构。这是氛围编码者跳过的部分，而这正是项目脱轨的地方。
你指导，然后审查。 你从计划中给AI代理一个范围明确的任务。它生成代码。你以审查人类队友PR的同样严格程度审查该代码。如果你无法解释模块的作用，它就不会进入。
你无情地测试。 智能体工程和氛围编程之间最大的区别是测试。有了可靠的测试套件，AI代理可以在循环中迭代直到测试通过，让你对结果有很高的信心。没有测试，它会愉快地在损坏的代码上宣布"完成"。测试是你将不可靠的代理转变为可靠系统的方式。
你拥有代码库。 你维护文档。你使用版本控制和CI。你监控生产。AI加速工作，但你对系统负责。
做得好的团队通常报告更快的开发速度——这些收益来自增强可靠的流程，而不是放弃流程。AI处理样板和繁重的工作。人类专注于架构、正确性、边缘情况和长期可维护性。
讽刺的是，AI辅助开发实际上比传统编码更能奖励良好的工程实践。你的规范越好，AI的输出就越好。你的测试越全面，你就越有信心委派。你的架构越干净，AI产生奇怪抽象的可能性就越小。正如一项分析所指出的，"AI没有造成问题；跳过设计思考才是问题所在。"
我们讨论过的技能差距
这是来自一线的一个令人不舒服的真相：智能体工程不成比例地使高级工程师受益。如果你有深厚的基础——你理解系统设计、安全模式、性能权衡——你可以将AI作为巨大的力量倍增器。你知道好代码是什么样子，所以你可以有效地审查和纠正AI输出。
但如果你是初级的，并且在建立这些基础之前就依赖AI，你就会面临危险的技能萎缩风险。你可以在不理解的情况下生成代码。你可以在不学习某些模式存在原因的情况下交付功能。几位工程领导者已经将此标记为一个新兴危机：一代可以提示但不能调试、可以生成但不能推理他们生成的内容的开发人员。
这不是反对AI辅助开发的论点。这是一个关于诚实面对它所要求的内容的论点。智能体工程并不比传统工程更容易——它是一种不同类型的困难。你正在用审查时间交换打字时间，用编排技能交换实现努力，用阅读和评估代码交换编写代码。基础知识更重要，而不是更不重要。
我们从这里走向何方
轨迹很清楚：AI代理正在变得更有能力，智能体工程工作流程正在成为越来越多专业开发人员的默认选择。这将加速。
我们需要：
- 诚实的术语。 当你指的是有人类监督的严谨的、代理辅助的开发时，称之为智能体工程。当你指的是有趣的、鲁莽的、仅用于原型的版本时，称之为氛围编程。停止对两者使用一个术语。
- 更好的评估框架。 我们需要系统的方法来衡量AI辅助工作流程是否真正产生可靠的软件，而不仅仅是更快的软件。
- 对基础知识的投资。 随着AI处理更多实现，对架构思维、安全意识和系统设计的溢价上升，而不是下降。培训计划需要适应。
AI编码的兴起并没有取代软件工程的工艺——它提高了标准。将要蓬勃发展的开发人员不是提示最快的人。他们是对他们正在构建什么以及为什么思考最清晰的人，然后使用所有可用的工具——包括AI代理——来很好地构建它。
氛围编程向我们展示了当你放弃所有惯例时可能发生什么。
现在是时候把工程带回来了。让我们称之为它本来的样子。
我与O'Reilly合作写了一本新书，Beyond Vibe Coding，更深入地探讨了AI辅助（和代理）工程的实用框架。如果你一直在自己的工作流程中摸索这个问题，我很想听听什么有效。