---
layout: single
title:  "氛围编程 vs 智能体工程"
date:   2026-02-22 10:00:00 +0800
categories: [AI 与大模型, 编程开发]
tags: [Vibe Coding, Agentic Engineering, Andrej Karpathy, 氛围编程 智能体工程]
---

<!-- more -->

## [Andrej Karpathy：氛围编程（vibe coding）](https://x.com/karpathy/status/1886192184808149383)

我称之为“**氛围编程**”（vibe coding）——这是一种全新的编程方式：你完全沉浸在感觉中，拥抱指数级的效率提升，甚至忘掉代码本身的存在。

这之所以成为可能，是因为大语言模型（比如配合 Sonnet 使用的 Cursor Composer）正变得过于强大。而且，我直接通过 SuperWhisper 和 Composer 语音对话，几乎连键盘都不碰。我会提一些极度偷懒的要求，比如“把侧边栏的间距缩减一半”，因为我根本懒得去代码里找位置。我永远点“全部接受”（Accept All），再也不看代码比对（diffs）了。遇到报错信息，我直接原样粘贴回去，一句话都不解释，通常这样就能修好。

代码库的增长速度超出了我以往的理解能力，如果真要搞懂，我得花好长一段时间去通读。有时大模型修不好某个 Bug，我就绕过去，或者要求进行随机改动，直到 Bug 消失。对于那些周末折腾的练手项目来说，这种方式还算凑合，但也确实挺离谱的。

我正在开发一个项目或 Web 应用，但这感觉并不像在编程——我只是观察、动嘴、运行、粘贴，然后它居然大部分时间都能跑通。


## [Andrej Karpathy：智能体工程（agentic engineering）](https://x.com/karpathy/status/2019137879310836075)

很多人转发这条推文，以此纪念“氛围编程”（vibe coding）诞生一周年。简单回顾一下：

我用 Twitter 已经 17 年了（天呐），但我基本上还是完全无法预判推文的互动量。这原本只是一条随手发的“洗澡时的灵光一现”，发完就没管了，但不知为何，它在恰当的时机为一种许多人共同拥有的感受精准定义了一个名字，于是就有了现在的局面：“氛围编程”现在作为我主要的模因（meme）“贡献”被收录进了维基百科，甚至它的词条篇幅比我的还长。哈哈。

我想补充的一点是，在当时，大语言模型（LLM）的能力还比较有限，所以你大多是将“氛围编程”用于一些好玩的练手项目、Demo 和探索。那很有趣，而且效果差强人意。

时至今日（一年后），通过 LLM **智能体**进行编程正日益成为专业人士的默认工作流，只不过增加了更多的监督和审查。我们的目标是利用**智能体**带来的杠杆效应，同时不对手件质量做任何妥协。许多人试图想出一个更好的名字，以便将其与“氛围编程”区分开来，我个人目前最喜欢的是“**智能体工程**”（agentic engineering）：

* **“智能体” (agentic)**：因为新的常态是，你 99% 的时间不再直接编写代码，而是在编排执行任务的**智能体**，并充当监督者的角色。
* **“工程” (engineering)**：为了强调这其中包含艺术、科学与专业技能。这是一门你可以学习并不断精进的学问，拥有另一种维度的深度。

进入 2026 年，我们很可能会看到模型层和新的**智能体**层持续进化。我对这两者结合产出的成果以及又一年的进步感到兴奋。


## [Agentic Engineering](https://addyosmani.com/blog/agentic-engineering/)

一年多前，安德烈·卡帕斯（Andrej Karpathy）创造了 **“氛围编程”**（vibe coding）一词，用来描述一种令人愉悦且不计后果的编程方式：你写提示词，把键盘交给 AI，全盘接受它吐出的所有内容，不看差异对比（diffs），通过把报错信息原样贴回来的方式进行迭代。对于一种客观存在的现象——纯靠 AI “自动驾驶”来快速构建原型或最小可行性产品（MVP）——这是一个非常贴切的标签。

问题在于，“氛围编程”已经变成了一个“筐”，什么都往里装。现在人们用它来描述一切：从周末的随手涂鸦，到人类监督下由**智能体**处理实现的严谨工程工作流。这两者本质上是完全不同的活动，将它们混为一谈正在造成真正的困惑，甚至带来切实的损害。

### 什么是真正的“氛围编程”

氛围编程的核心含义是**顺着感觉走，且不对代码进行审查**。这是其定义性特征。你提问，你接受，你运行，你看看行不行。如果不行，你就把错误贴回去重试。你不停地写提示词。在这模式下，人是“提示词 DJ”，而不是工程师。

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

* **全新的 MVP、原型和黑客松演示**：你需要在周日前弄出一个能跑的东西，代码质量无关紧要。
* **个人脚本和一次性工具**：你是唯一的参与者。如果坏了，重新生成就行。
* **学习与探索**：新手可以做出他们原本做不出的东西，通过 AI 的输出来循序渐进地学习。
* **创意脑暴**：刻意让 AI 过度生成，看看它会建议哪些方案，然后将其丢弃并重新进行正规构建。

如果氛围编程能让数百万原本不会编程的人拥有创建自定义软件的能力，那确实是一项胜利。这种技术在工具箱中占有合法的一席之地。

但其失败模式目前也已证据确凿。模式总是如出一辙：演示时效果惊人，现实落地时一塌糊涂。当你试图修改、扩展或保障其安全性时，你会发现没人理解这些代码到底在干什么。正如一位工程师所言：“这不是工程，这是碰运气。”

### 我们需要一个更专业的术语

事实是：许多经验丰富的工程师现在正通过 AI 获得巨大的生产力提升——2 倍、5 倍甚至更多——同时还能维持代码质量。但他们的工作方式与氛围编程完全不同。他们在写提示词之前先写规格说明（Specs）；他们审查每一个 diff；他们运行测试套件；他们把 AI 看作一个速度极快但不可靠、需要持续监督的初级开发人员。我个人很喜欢“AI 辅助工程”，并讨论过这如何描述人类保持参与的工作状态。

西蒙·威利森（Simon Willison，我非常钦佩他的工作）为此提出了“氛围工程”（vibe engineering）——它找回了“氛围”一词，同时加入了“工程”以显示纪律性。但在观察了社区几个月的辩论后，我认为“氛围”这个词带有太多的负面包袱。它传递出一种随意感。当你告诉一位首席技术官（CTO）你正在对他们的支付系统进行“氛围工程”时，你能看到他脸上的担忧。

安德烈·卡帕斯本周建议使用**“智能体工程”**（agentic engineering），我想我挺喜欢这个词。

以下是它奏效的原因：

* **它描述了事实情况**：你正在编排 **AI 智能体**（能够执行、测试和优化代码的编程助手），而你担任架构师、审查员和决策者。你亲手写的代码可能只占很小比例，其余部分由**智能体**在你的指导下完成。这就是 **“智能体化”**。同时，你在整个过程中应用了工程纪律。这就是 **“工程”**。
* **具备职业辨识度**：**“智能体工程”**听起来名副其实：这是一门涉及自主**智能体**的严肃工程学科。你可以毫无顾虑地对你的工程副总裁提起它，可以把它写进职位描述，也可以围绕它建立团队实践。
* **划清了界限**：氛围编程 = 尽兴就好（YOLO）。**智能体工程** = AI 负责实现，人类负责架构、质量和正确性。术语本身就强化了这种区分。

### 智能体工程在实践中可能是这样的

其工作流并不复杂，但需要氛围编程所明确抛弃的那种纪律：

1. **从计划开始**：在写任何提示词之前，你先撰写设计文档或规格说明（有时也借助 AI 协助）。你将工作分解为定义明确的任务，确定架构。这是氛围编程者会跳过的步骤，也正是项目脱轨的地方。
2. **指导，然后审查**：你从计划中分配一个范围明确的任务给 **AI 智能体**。它生成代码。你以审查人类队友 PR 的严谨态度来审查这些代码。如果你解释不清一个模块的作用，它就不能进入代码库。
3. **坚持不懈地测试**：**智能体工程**与氛围编程之间最大的区别在于测试。有了可靠的测试套件，**智能体**可以在循环中迭代直到通过测试，从而给你极高的信心。如果没有测试，它会对着错误的代码愉快地宣布“完成”。测试是你将不可靠的**智能体**转化为可靠系统的手段。
4. **掌控代码库**：你维护文档，使用版本控制和持续集成（CI），监控生产环境。AI 加速了工作，但你对系统负责。

做得好的团队通常报告开发速度变快了——这种增长源于对稳健流程的增强，而非抛弃流程。AI 处理样板代码和枯燥的体力活，人类专注于架构、正确性、边缘情况和长期可维护性。

讽刺的是，AI 辅助开发实际上比传统编程更奖励良好的工程实践。你的规格说明越好，AI 的输出就越好；你的测试越全面，你就越能放心地授权；你的架构越清晰，AI 就越不容易幻觉出怪异的抽象。正如一份分析所指出的：“AI 没有制造问题，跳过设计思考才是问题所在。”

### 我们讨论过的技能差距

这是一个来自一线、让人有些不安的事实：**智能体工程**让资深工程师获益更多。如果你有深厚的基础——理解系统设计、安全模式、性能权衡——你可以利用 AI 作为巨大的力量倍增器。你知道好的代码长什么样，因此可以高效地审查和纠正 AI 的输出。

但如果你是新手，在建立这些基础之前就依赖 AI，你将面临危险的技能萎缩。你可以产出代码却不理解它；你可以上线功能却不学习某些模式为何存在。几位工程负责人已指出这是一个隐现的危机：一代开发者只会写提示词却不会调试，只会生成内容却无法对其进行推理。

这并不是反对 AI 辅助开发，而是主张诚实面对它所提出的要求。**智能体工程**并不比传统工程容易——它是一种不同维度的难。你用打字时间换取了审查时间，用实现精力换取了编排技能，用编写代码换取了阅读和评估代码。基础知识变得更加重要，而非变得无足轻重。

### 我们该走向何方

趋势已非常明确：**AI 智能体**正变得越来越强大，**智能体工程**工作流正成为越来越多专业开发者的默认选择。这一进程将会加速。

我们需要：

1. **诚实的术语**：当你指的是有纪律、由人类监督的**智能体**辅助开发时，称之为**智能体工程**。当你指的是那种好玩、随性、仅限原型的版本时，称之为氛围编程。不要再用同一个词涵盖两者。
2. **更好的评估框架**：我们需要系统的方法来衡量 AI 辅助工作流是否真的产出了可靠的软件，而不仅仅是更快的软件。
3. **对基础知识的投入**：随着 AI 处理更多的实现工作，架构思维、安全意识和系统设计的重要性只会不降反升。培训项目需要做出调整。

AI 编程的兴起并没有取代软件工程这门手艺——它反而提高了门槛。未来能脱颖而出的开发者，不是那些写提示词最快的人，而是那些对“构建什么”以及“为何构建”思考最清晰，并能动用包括 **AI 智能体**在内的一切工具来把事情做好的人。

氛围编程向我们展示了放下所有陈规后的可能性。
现在，是时候把“工程”带回来了。让我们名副其实地称呼它。