智能体工程
作者：Addy Osmani
原文：查看原文
一年前，Andrej Karpathy 用“氛围编程”（vibe coding）这个词，描述了一种非常自由的编程方式：你给出提示，把键盘更多交给 AI，通过不断补充反馈来快速推进原型或 MVP。
这个标签之所以流行，是因为它确实描述了一类真实现象。但问题在于，“氛围编程”后来被越用越宽：从周末项目到严肃的工程流程，人们都在用同一个词。可这两者并不是一回事。前者强调快速试错，后者强调在明确约束下使用 AI 完成实现；混在一起谈，只会让讨论越来越失焦。
氛围编程实际上是什么
氛围编程最鲜明的特点，是顺着感觉快速推进，并且不把代码审查放在优先位置。你给出提示、接受结果、运行看看；如果不对，就继续补反馈再试一次。它更接近一种高速原型流程，而不是完整的工程流程。
这类方式在下面几种场景里确实有价值：
- 从零搭一个 MVP、原型或黑客松演示。目标是先把东西做出来，而不是把长期维护问题一次解决。
- 个人脚本和一次性工具。你是唯一使用者，容错空间更大。
- 学习和探索。新手可以先把系统跑起来，再借这个过程理解实现细节。
- 创意发散。你可以让 AI 一次性生成多个方向，再选一个值得继续打磨的方案。
如果氛围编程让更多原本做不了定制软件的人有机会把想法落地，这当然是好事。它在工具箱里有明确的位置。
但它的局限也同样明显：演示通常很好看，真正进入修改、扩展、加固和维护阶段后，问题才会浮现。你会发现系统虽然能跑，却缺少清晰结构，后续迭代的成本很快上升。正如一位工程师总结的那样：这不是完整的工程交付，更像是在押注“它大概能行”。
我们需要一个更准确的术语来描述专业版本
现实是，很多经验丰富的工程师已经借助 AI 获得了巨大的生产力提升——同时仍然保持代码质量。但他们的工作方式并不像“氛围编程”这个词暗示的那样随意。
他们会先写规范，再给出任务；会逐条审查差异；会跑测试；会把架构、质量和可维护性始终握在自己手里。AI 负责加速实现，人负责定义约束和判断结果。
Simon Willison 曾提出“氛围工程”这个说法，试图在“氛围”之外补上“工程”这一层纪律性。但在我看来，“氛围”这个词的联想已经太强，容易让人误以为这是把严肃系统交给随意流程。
Andrej Karpathy 后来建议改用“智能体工程”（agentic engineering），这个词更准确。
它之所以合适，原因大致有三点：
它描述了真实发生的事。 你在编排能够执行、测试、修改代码的 AI 智能体，而你自己承担架构、审查和决策角色。你也许只亲手写少量代码，但整个过程始终由你施加工程约束。
它在专业语境里更清晰。 “智能体工程”听上去就是一套严肃的工程实践：涉及自主执行能力，也强调工程纪律。它适合写进团队方法论，也适合拿来讨论岗位能力。
它划清了边界。 氛围编程强调快速试错；智能体工程强调 AI 负责实现推进，而人类对架构、质量与正确性负责。两者都可以有价值，但不应该混为一谈。
智能体工程在实践中可能是什么样子
它的工作流并不神秘，但确实要求你把工程纪律重新放回中心位置。
先从计划开始。 在真正动手之前，先写设计文档或规范——哪怕这份文档本身也可以在 AI 协助下完成。把工作拆成边界清晰的任务，先想清楚系统结构，再进入实现。
先指导，再审查。 你把范围明确的任务交给 AI 智能体去执行，它生成代码后，你要像审查团队成员提交的 PR 一样审查它。如果一段实现你自己都无法解释清楚，就不该直接放进代码库。
把测试当成主干，而不是补丁。 智能体工程和氛围编程最大的差别之一，就是有没有稳定的验证闭环。有了可靠测试，AI 才能在明确目标下迭代；没有测试，“完成”就只是一个主观判断。测试不是锦上添花，而是把协作流程变得可靠的关键。
始终由你拥有代码库。 文档要维护，版本控制要清晰，CI 要可靠，生产环境要可观测。AI 可以加速推进，但系统责任不会自动转移。
真正做得好的团队，通常确实会更快。这种速度提升不是来自放弃流程，而是来自让流程本身更高效：AI 处理样板、重复工作和大量实现细节；人类把注意力放在架构、边界条件、正确性和长期维护性上。
某种意义上，AI 时代反而更奖励好的工程实践：规范越清楚，输出越稳定；测试越完整，委托就越放心；架构越干净，结果越容易维持一致。问题往往不是“AI 参与了开发”，而是流程里本来该有的设计和验证没有被明确出来。
我们讨论过的技能差距
一个不太舒服但必须承认的事实是：智能体工程通常更能放大资深工程师的优势。如果你本来就理解系统设计、安全边界和性能权衡，那么 AI 会成为非常强的杠杆，因为你有能力快速判断什么是好实现、什么只是表面可用。
反过来，如果基础能力还没打稳，就把大部分实现完全外包给 AI，风险也很明显：你也许能更快产出功能，但未必真的理解自己交付了什么。长期看，这会削弱对系统本质的掌控力。
这不是在反对 AI 辅助开发，而是在提醒我们：智能体工程并没有让工程本身“更容易”，它只是把难点换了位置。你减少了手工敲代码的时间，但增加了定义任务、组织上下文、审查结果和建立验证机制的责任。基础能力因此不是变得不重要，而是变得更重要。
我们从这里走向何方
趋势已经很清楚：AI 智能体会越来越能干，而智能体工程也会越来越多地成为专业开发者的默认工作方式。
接下来真正重要的，至少有三件事：
- 用更准确的术语。 需要指代严谨、有人类监督的 AI 协作流程时，就叫它智能体工程；需要指代轻量、快速、以原型为目标的流程时，就叫它氛围编程。不要再把两种工作方式混在一个词里。
- 建立更好的评估框架。 我们需要判断的，不只是“它是不是更快”，而是“它是否稳定地产出了可靠的软件”。
- 继续投资基础能力。 AI 接手更多实现工作后，架构思维、安全意识、系统设计和验证能力只会更值钱，不会更不值钱。
AI 编码的兴起并没有削弱软件工程这门手艺，反而提高了标准。真正会脱颖而出的，不是提示词打得最快的人，而是最清楚自己要构建什么、为什么这样构建的人；然后他们再把 AI 智能体纳入这套清晰的方法里，把事情做对。
氛围编程展示了完全放开约束时会发生什么。
而现在，是时候把“工程”重新放回中心了。
我和 O'Reilly 合作写了一本新书 Beyond Vibe Coding，更系统地讨论 AI 辅助工程与智能体工程的实践框架。如果你也在摸索自己的工作流，这本书也许会有帮助。