核心摘要
Vibe Coding（氛围编程）是 Andrej Karpathy 在 2025 年初带火的一种意图中心的软件构建方式。 你用自然语言描述想要什么，让 AI Agent 生成、运行并修复代码。本文讲清这个词到底指什么、它为何在 2025 年变得可行、一个典型循环如何运转，以及同样重要的——它在哪里失效，以及在代码进入生产之前你仍然亏欠它什么。
引言
2025 年初，一个词几乎在一夜之间传遍开发者社区：Vibe Coding（氛围编程）。随着具备编程能力的 LLM 和 Agent 工具走向成熟，很多日常构建工作从"敲代码"转向了"描述意图、审查产出"。这个转变是真实的、值得理解的——但它改变的是你的精力花在哪里，而不是承诺判断力不再重要。
本文看四件事：Vibe Coding 是什么、它为何在 2025 年变得实用、一个典型工作流怎么跑，以及诚实的边界在哪里。如果你的目标是生产级软件，最后那部分最重要。
为什么这很重要？从语法中心到意图中心
几十年来，编程中很大一部分是"翻译"：把人类意图变成计算机接受的语法（C++、Java、Python），并在内存管理、类型检查、API 文档细节上花费大量真实时间。
Vibe Coding 压缩了这个翻译层的很大一块。当具备推理能力的模型在 2024–2025 年跨过多步编程任务的实用性门槛后，它们不再只是自动补全，而开始处理更大的意图单元——搭一个功能的脚手架、把组件接到 API、修一个失败的测试。这让你能少花时间在机械翻译上，多花时间决定要构建什么、以及结果是否真的正确。
"压缩"这个词是刻意的。翻译层变得更小、更便宜，但它没有消失。仍然有人——你——必须确认生成的行为与意图相符，且没有不安全的东西在过程中溜进来。
Vibe Coding 是什么？
起源：Andrej Karpathy 的帖子
2025 年 2 月，Andrej Karpathy——前特斯拉 AI 负责人、OpenAI 联合创始人——在 X 上发帖：
"There's a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." （有一种我称之为"氛围编程"的新型编程方式，你完全沉浸在"氛围"（意图）中，拥抱指数级增长，甚至忘记代码的存在。）
这句话迅速传开。Karpathy 描述的是一种模式：你更少地与具体语法打交道，更像导演指挥演员——描述你想要的软件的行为、交互逻辑和感觉，让 Agent 承担大量机械性的实现工作。
值得把这个说法理解为对一种交互风格的观察，而不是"代码不再重要"的字面主张。代码依然存在、依然运行、依然会以常见的方式失败——Vibe Coding 只是改变了你亲手敲多少。
核心定义：意图驱动开发
本质上，Vibe Coding 是**意图驱动开发（Intent-Driven Development）**的一种强形式，有几个定义性特征：
- 自然语言优先：你的意图（Prompt）是主要输入。
- 端到端自主性：AI 作为 Agent 行动，而不只是补全工具——它能读取文件、运行终端命令、安装依赖，并对自己的产出迭代。
- 行为优先的审查：你常常通过程序如何表现来判断成败，而不是逐行阅读。这是便利，不是保证——对任何触及数据、金钱或认证的东西，"看起来能用"和"确实正确"不是一回事。
底层逻辑：为什么变得可行
Vibe Coding 不是凭空出现的。它随着三项能力共同成熟而变得实用：
- 更大的上下文窗口：模型能一次性在工作记忆里装下更多代码库，于是它是在整个项目的语境中推理某处改动，而不是只看单个文件。
- 具备推理能力的模型：更强的多步推理让模型能预见"改 A 文件会影响 B 文件的逻辑"——尽管它出错的频率仍高到让审查有意义。
- 工具调用（Agentic Workflow）：模型获得了"手"——直接访问文件系统和终端——闭合了"编写 → 运行 → 读报错 → 修复"的循环，无需每一步都有人介入。
这每一项都是一种能力，不是正确性保证。更大的上下文窗口意味着模型能看到更多，不是它总会用对该用的部分；工具调用意味着它能运行并修复代码，不是它的修复就是对的。
核心工作流：DGRR 循环
Vibe Coding 往往以一个快速迭代循环运行——Describe、Generate、Run、Refine：
1. 描述意图 (Describe)
这不止是一行 Prompt。有效的意图通常包含功能需求、视觉参考和约束——约束越明确，模型需要猜的越少。
- 示例："帮我做一个极简的理财应用。用低饱和的莫兰迪色系。点击按钮时加丝滑的弹性动画。数据存储用 Supabase。用户只能看到自己的交易。"
最后那句很关键：像"用户只能看到自己的数据"这样的约束，恰恰是模型不会自行推断的需求。如果一条规则重要，就把它说出来——然后去验证它，因为说出来并不保证模型真的实施了它。
2. AI 生成 (Generate)
Agent 扫描目录，决定是修改现有文件还是创建新组件，安装依赖包，配置环境。
3. 运行 (Run)
Agent 运行应用（例如 npm run dev），你直接在预览里观察行为。
4. 观察与精炼 (Refine)
你不去手改第 45 行，而是描述改动："侧边栏太宽了——让它在移动端自动隐藏。" Agent 定位相关代码并完成修改。对任何正确性关键的东西，"观察"应当包括真正去检查行为——用第二个用户登录、提交非法输入、读一遍查询——而不只是瞥一眼顺畅路径（happy path）。
Vibe Coding 在哪里失效
速度是真的，失效模式也是真的。把这些当作事后再说的东西，正是原型悄悄变成脆弱生产系统的方式。
维护黑洞
没有架构锚点生成的代码，产出快、维护慢。一旦代码库长到超出上下文能舒适容纳的规模，改动就开始引发模型无法预见的回归。缓解办法不是"别用 AI"——而是给工作以结构：清晰的架构、模块边界，以及（对任何非平凡的东西）一份生成必须满足的书面规格。
你没有验证的正确性
行为优先的审查有个盲区：你看到 happy path 能用，就假设其余也没问题。但生产中最要紧的路径——非法输入、并发访问、那个未授权的请求——恰恰是快速目视检查会跳过的。测试能帮上忙，但注意陷阱：Agent 可能写出通过却在断言错误东西的测试。去读断言，尤其是错误路径和权限路径上的断言。
安全不是一种"氛围"
这是"忘记代码存在"最危险的地方。放任不管的话，生成代码会乐于引入未校验的输入、字符串拼接的 SQL、图方便硬编码的密钥，或过于宽松的默认值。无论工具多好，有几条边界不会移动：
- 认证是身份，不是授权。 生成的登录代码证明谁在调用；它不证明他们被允许操作某条特定记录。对象级与租户级检查是你的责任，且必须在每个请求上运行。
- 在边界处校验不可信输入。 模型不会可靠地替你加上这一步。
- 不安全的默认值只给本地开发用。 兜底密钥和放开的 CORS 在你笔记本上没问题，绝不能进入部署环境。
- 把模型输出当草稿，不当权威。 它不设定你的安全策略、访问规则或数据模型——你才设定。
"中间层缺失"
Vibe Coding 在小尺度（一个原型）很强，在大尺度（有重结构、规格驱动的模块）配合下也很强。尴尬地带在两者之间：一个已经长过原型、却还没被赋予大型系统所需架构和规格的真实应用。这通常是从纯"氛围"转向更审慎实践的时机——见 Spec Coding 和 Harness（约束系统）。
优势，放在恰当比例里看
以上这些并不抵消好处——只是把它诚实地框定：
- 原型速度：从想法到可运行原型的时间大幅下降，这改变了什么值得一试。
- 更低的入门门槛：不是全职工程师的人也能构建可用软件，尤其是个人和内部工具。
- 认知余量：有经验的开发者可以同时编排多个部件，把机械工作外包出去，把注意力花在设计和审查上。
三者的共同规律：Vibe Coding 擅长快速产出软件，而在保证软件质量上较弱。你得到的价值，与你把第二部分守得多好成正比。
范式对比：Vibe Coding vs. 传统编码
| 特性 | 传统编码 (Manual) | Vibe Coding (Intent) |
|---|---|---|
| 关注点 | 语法、逻辑、实现细节 (How) | 业务、体验、最终产出 (What) |
| 开发者角色 | 每一行的作者 | 建筑师、导演、意图与产出的审查者 |
| 错误处理 | 手动调试、看堆栈信息 | 粘贴报错、描述预期、审查修复 |
| 学习曲线 | 陡峭（需掌握语言、框架） | 起步更平缓，但生产使用仍需系统思维 |
| 交付单位 | 函数、类、模块 | 完整功能、页面、子系统 |
注意学习曲线那一行：上手容易得多，但要交付可靠的东西，仍需理解架构、安全和测试。Vibe Coding 降低的是入门成本，不是能力上限。
结语：程序员会被取代吗？
Karpathy 的说法是，Vibe Coding 提升的是抽象层级，而不是消灭程序员。真正重要的技能从语法熟练度，转向系统设计、清晰的意图表达，以及——越来越重要的——验证 Agent 产出的判断力。如果说有什么变化，那就是批判性审查 AI 生成代码的能力变得更有价值，而不是更没价值。
要让 Vibe Coding 安全地服务真实工作负载，就给它配上结构：用 Spec Coding 锁定需求，用 Harness（约束系统） 把生成代码约束在重要的边界之内。
相关阅读：