智能体工程：AI 辅助开发的正确打开方式

2026 年 2 月 4 日

一年前，Andrej Karpathy 创造了"vibe coding"（氛围编程）这个词，用来描述一种"放飞自我"的编程方式：你写个提示词，把键盘交给 AI，不看代码差异，它输出什么你就接受什么，遇到报错就把错误信息粘贴回去让 AI 再试。这个概念精准地捕捉到了一种真实存在的现象——用纯 AI 自动驾驶模式来快速搭建原型或最小可行产品。

问题是，“vibe coding” 已经变成了一个"万能标签"。人们用它来描述从周末小项目到严谨工程流程在内的一切——后者是指在人类监督下，AI 智能体负责具体实现的专业开发模式。这两者有本质区别，把它们混为一谈正在造成真正的混乱和损害。

Vibe coding 到底是什么

Vibe coding 的核心特征是跟着感觉走，不审查代码。你写提示词、接受输出、运行看效果。不行就把错误粘回去再试，一直反复提示。在这种模式下，人扮演的是"提示词 DJ"，而不是工程师。

这种方式在以下场景确实好用：

全新项目的 MVP、原型和黑客马拉松 demo。 你需要周日之前搞出个能跑的东西，代码质量无所谓。个人脚本和一次性工具。 你是唯一的用户，坏了就重新生成。学习和探索。 新手可以借助 AI 做出原本做不出的东西，通过 AI 的输出"照葫芦画瓢"来学习。创意头脑风暴。 故意让 AI 大量生成各种方案，看看它有什么思路，然后丢掉重来、认真构建。

如果 vibe coding 能让数百万原本不会写代码的人拥有开发自定义软件的能力，那这确实是一个了不起的进步。这种技术在工具箱里有它的一席之地。

但它的失败模式已经被充分记录了。套路总是一样的：demo 效果很棒，然后现实就来了。当你想修改、扩展或加固安全性时，就会发现没人真正理解这些代码到底在干什么。正如一位工程师说的：“这不是工程，这是在碰运气。”

我们需要一个更好的术语来描述专业版本

事情是这样的：很多经验丰富的工程师现在正从 AI 中获得巨大的生产力提升——2 倍、5 倍、甚至更多——同时保持着代码质量。但他们的工作方式和 vibe coding 完全不同。他们在写提示词之前会先写需求规格文档，会逐行审查每一个代码差异（diff），会运行测试套件。他们把 AI 当成一个速度很快但不太靠谱的初级开发者，需要持续监督。我个人一直喜欢"AI 辅助工程"（AI-assisted engineering）这个说法，也讨论过它如何描述了人类始终保持参与的那一端。

Simon Willison（我非常欣赏他的工作）提出了"vibe engineering"（氛围工程）——他想保留"vibe"这个词，同时加上"engineering"来传递专业纪律的信号。但在观察了社区围绕这个话题争论数月之后，我觉得"vibe"这个词包袱太重了。它天然传达出随意感。当你告诉 CTO 你在"vibe engineering"公司的支付系统时，你能看到他脸上的担忧。

Andrej Karpathy 本周提出了"agentic engineering"（智能体工程），我觉得这个叫法很不错。

为什么它管用：

它准确描述了正在发生的事情。 你在指挥协调 AI 智能体——那些能执行、测试和改进代码的编程助手——而你担任架构师、审查者和决策者的角色。你可能只亲手写了一小部分代码，其余都由智能体在你的指导下完成。这就是"智能体"（agentic）的含义。而你在整个过程中贯彻工程纪律，这就是"工程"（engineering）的含义。

它在职场语境中更得体。 “智能体工程"听起来就是它本身的意思：一种涉及自主智能体的严肃工程学科。你可以毫不尴尬地对工程副总裁这样说，可以写在招聘描述里，可以围绕它建立团队实践规范。

它划清了界限。 Vibe coding = 随心所欲。智能体工程 = AI 负责实现，人类把控架构、质量和正确性。术语本身就在强化这种区分。

智能体工程在实践中大概长什么样

工作流程并不复杂，但它需要 vibe coding 明确放弃的那种纪律：

从计划开始。 在写任何提示词之前，你先写一份设计文档或需求规格——有时借助 AI 完成。你把工作拆分成边界清晰的任务。你确定架构方案。这正是 vibe coder 跳过的步骤，也恰恰是项目失控的起点。

先指导，再审查。 你从计划中拿出一个范围明确的任务交给 AI 智能体，它生成代码，你用审查人类同事 PR 的同等严格标准来审查这些代码。如果你无法解释某个模块在做什么，那它就不能进入代码库。

狠抓测试。 智能体工程和 vibe coding 之间最大的区别就是测试。有了完善的测试套件，AI 智能体可以在循环中不断迭代直到测试通过，让你对结果高度有信心。没有测试的话，它会开开心心地宣布"搞定了”——然后代码是坏的。测试是你把一个不靠谱的智能体变成靠谱系统的关键手段。

你要掌控代码库。 你维护文档，使用版本控制和 CI，监控生产环境。AI 加速了工作进度，但你要为整个系统负责。

做得好的团队通常报告开发速度更快——这些提速来自于增强一个扎实的流程，而不是抛弃流程。AI 处理模板代码和苦力活，人类专注于架构、正确性、边界情况和长期可维护性。

讽刺的是，AI 辅助开发实际上比传统编码更奖励良好的工程实践。你的需求规格写得越好，AI 的输出质量就越高。你的测试覆盖率越全面，你就越能放心地把任务交给 AI。你的架构越干净，AI 就越少"幻觉"出奇怪的抽象层。正如一篇分析文章指出的：“问题不是 AI 造成的，而是跳过设计思考造成的。”

我们讨论过的技能鸿沟

来自一线的一个不太舒服的真相：智能体工程对资深工程师的助力明显更大。如果你有深厚的基本功——理解系统设计、安全模式、性能权衡——AI 就能成为你的超级放大器。你知道好代码长什么样，所以能高效地审查和纠正 AI 的输出。

但如果你是初级开发者，在打好基本功之前就过度依赖 AI，你面临的是危险的技能退化。你能写出代码但不理解它，你能发布功能但不知道为什么要用某些设计模式。多位工程领导已经将此标记为一场正在形成的危机：一代能写提示词但不会调试、能生成代码但无法推理自己生成了什么的开发者。

这不是在反对 AI 辅助开发，而是在说我们要诚实面对它的要求。智能体工程并不比传统工程更简单——它是另一种难。你用审查时间换取了编码时间，用编排能力替代了实现能力，从"写代码"变成了"读代码和评估代码"。基本功变得更重要了，而不是更不重要。

接下来何去何从

趋势很明确：AI 智能体正在变得越来越强大，智能体工程的工作流正在成为越来越多专业开发者的默认选择。这个趋势还会加速。

我们需要：

诚实的术语。 当你指的是有纪律的、有人类监督的智能体辅助开发时，请叫它智能体工程。当你指的是有趣的、“不管不顾"的、仅适用于原型的版本时，请叫它 vibe coding。不要用同一个词指代两件不同的事。更好的评估框架。 我们需要系统性的方法来衡量 AI 辅助工作流是否真的在产出可靠的软件，而不仅仅是更快的软件。对基本功的投入。 随着 AI 承担越来越多的实现工作，架构思维、安全意识和系统设计的价值只会上升，不会下降。培训体系需要做出相应调整。

AI 编程的兴起并没有取代软件工程的手艺——它提高了门槛。未来能胜出的开发者，不是提示词写得最快的人，而是对"在构建什么、为什么构建"想得最清楚的人，然后利用一切可用工具——包括 AI 智能体——把它做好。

Vibe coding 让我们看到了抛开一切规范后的可能性。

现在是时候把工程纪律带回来了。让我们给它一个配得上的名字。

本文翻译自 Agentic Engineering，仅供学习参考。