什么是 Vibe Coding？

Vibe Coding，直译可以叫“氛围编程”或“感觉编程”。它指的是一种高度依赖 AI 的软件开发方式：人不再从第一行代码开始手写，而是用自然语言描述自己想要的功能、界面、交互或错误现象，让大语言模型和 AI 编程工具生成、修改、运行和解释代码。

这个词由 Andrej Karpathy 在 2025 年提出。它之所以流行，是因为 Cursor、Claude Code、Codex、Replit Agent、Lovable、Bolt 等工具让很多人第一次感受到：只要把想法说清楚，AI 就能把一个原型、脚本、网页或小工具很快做出来。

但 Vibe Coding 不是“完全不会写代码也能放心做生产系统”。更准确地说，它改变了编码时人的位置：人从“逐行写代码的人”，变成了“描述目标、判断结果、设计边界、验收质量的人”。

一句话定义

Vibe Coding 是用自然语言驱动 AI 生成和修改代码，并通过不断运行、观察、反馈来推进软件开发的一种方式。

它的典型过程是：

1. 说出目标：例如“帮我做一个可以上传 Excel 并自动生成图表的网页”。
2. AI 生成初版：给出代码、文件结构、依赖和运行方式。
3. 人运行并观察：看页面是否能打开、功能是否符合预期、报错在哪里。
4. 继续反馈：例如“按钮太靠下了”“导入中文表头会乱码”“移动端布局乱了”。
5. AI 继续修改：直到结果接近可用。

这个过程更像和一个会写代码的助手连续对话，而不是传统意义上的从需求、设计、编码、测试一步步线性推进。

它和“用 AI 辅助编程”有什么区别？

两者很接近，但重点不同。

普通 AI 辅助编程更像“程序员仍然掌控代码”。开发者会让 AI 补全函数、解释报错、写测试、重构局部逻辑，但仍然会认真阅读关键代码，理解架构和数据流。

Vibe Coding 更强调“结果驱动”。使用者可能并不逐行理解 AI 写了什么，而是通过页面表现、命令输出、测试结果和错误信息来驱动下一轮修改。它的口号式体验是：我描述，我运行，我反馈，它修改。

所以，Vibe Coding 的优势是快；风险也是快。它能很快把想法变成东西，也能很快把问题堆进一个你看不懂的代码库里。

为什么它会突然流行？

第一，AI 写代码的能力跨过了可用门槛。过去让 AI 写一个完整项目，经常会卡在依赖、文件结构、运行脚本和上下文缺失上。现在的 AI 编程工具已经能读项目、改多文件、跑命令、看报错，并进行多轮修复。

第二，自然语言变成了新的开发入口。不会 React、Python、SQL、Shell 的人，也可以先用中文或英文表达需求，再让 AI 把需求翻译成代码。

第三，很多软件需求本来就不需要复杂工程。个人脚本、内部工具、一次性数据处理、活动页、演示原型、小型自动化，这些任务以前因为“启动成本太高”被搁置，现在可以很快做出来。

第四，开发者的工作流也在变化。即使是专业程序员，也越来越多地把 AI 当成结对工程师：让它搭骨架、查问题、补测试、迁移 API、写样板代码。

Vibe Coding 适合做什么？

Vibe Coding 最适合低风险、高反馈、边界清晰的任务。

比如：

• 快速验证一个产品想法
• 做一个内部小工具
• 写数据清洗脚本
• 生成网页原型
• 做个人自动化工作流
• 把重复劳动变成命令行工具
• 给已有项目补一个小功能
• 学习一门新技术时快速跑通示例

这些场景的共同点是：就算初版不完美，也能通过运行结果快速发现问题；即使失败，代价也可控。

不适合直接 Vibe Coding 的场景

如果涉及钱、权限、隐私、安全、合规、核心业务，不能只靠“感觉能跑”。

例如：

• 支付、账务、订单结算
• 用户登录和权限系统
• 医疗、金融、法律等高风险业务
• 大规模生产数据库操作
• 安全敏感的后端接口
• 长期维护的核心系统
• 团队多人协作的大型代码库

这些场景需要明确的架构设计、代码审查、测试覆盖、安全检查、可观测性和回滚方案。AI 可以参与，但不能替代工程责任。

真正的能力不只是“会提示词”

很多人以为 Vibe Coding 的核心是 prompt，其实不止。

更关键的能力包括：

• 把模糊想法拆成清楚需求
• 判断 AI 生成的方案是否合理
• 知道什么时候该停下来重构
• 会运行项目并读懂错误信息
• 能识别安全、数据和权限风险
• 能设计测试用例验证结果
• 能把一次性原型整理成可维护代码

也就是说，Vibe Coding 降低了“写出第一版”的门槛，但没有取消“判断好坏”的门槛。甚至在某些时候，判断能力比手写能力更重要。

一个更稳的 Vibe Coding 工作流

如果想把 Vibe Coding 用得更靠谱，可以遵循下面这个流程。

1. 先写清楚目标

不要一上来就说“帮我做一个网站”。更好的说法是：

做一个本地运行的单页网页，用来记录每日阅读。需要添加书名、作者、阅读页数和备注。数据先保存在浏览器 localStorage。界面要适合手机使用。

目标越清楚，AI 越不容易乱发挥。

2. 要求 AI 先给方案

在正式写代码前，可以先让 AI 说明：

• 准备用什么技术
• 会创建哪些文件
• 数据如何保存
• 有哪些边界情况
• 如何运行和测试

这一步能避免 AI 直接生成一堆看似完整但方向错误的代码。

3. 小步修改

不要一次让 AI 做十个功能。更好的方式是一次只改一个明确点：

• 先完成新增记录
• 再完成删除记录
• 再做统计
• 再做导出
• 最后优化样式

小步修改更容易定位问题，也更容易回退。

4. 每次都运行

Vibe Coding 的关键不是“相信 AI”，而是“快速验证”。每次修改后都应该运行、点击、输入、刷新、看控制台、看测试结果。

能跑不代表正确，但不能跑一定不正确。

5. 让 AI 补测试和解释风险

当功能成形后，可以继续问：

请为这段逻辑补充测试，并列出可能的边界情况。

或者：

这段代码如果上线给真实用户使用，安全和数据风险在哪里？

这类问题能把 AI 从“生成模式”拉回“审查模式”。

最大的坑：看不懂的成功

Vibe Coding 最危险的地方，不是 AI 报错，而是 AI 给了一个“看起来能用”的结果。

看起来能用，可能只是因为你还没测到异常情况；看起来修好了，可能只是隐藏了错误；看起来代码很多，可能只是堆了重复逻辑；看起来很高级，可能只是引入了不必要的依赖。

如果一个项目会长期维护，就不能一直用“继续让 AI 改到能跑”为唯一策略。到了某个阶段，需要停下来做几件事：

• 删除无用代码
• 梳理目录结构
• 固定依赖版本
• 补充测试
• 写清楚 README
• 检查安全和权限
• 把关键逻辑重新读一遍

这一步很像从“原型”进入“工程”。

对程序员意味着什么？

Vibe Coding 不会让软件工程消失，但会改变软件工程的分工。

过去，一个想法到产品之间最大的阻力是“谁来写代码”。现在，阻力逐渐变成“谁能定义正确的问题、识别错误的答案、把原型变成可靠系统”。

程序员的价值会更多体现在：

• 建模能力
• 架构判断
• 代码审查
• 调试能力
• 安全意识
• 业务理解
• 系统化测试
• 长期维护能力

简单说，AI 会让更多人能做出软件；但软件越重要，越需要真正懂工程的人兜底。

对非程序员意味着什么？

对非程序员来说，Vibe Coding 的意义很直接：很多过去只能停留在脑子里的小工具，现在可以自己做出第一版。

你不一定要先完整学习一门编程语言，才能开始自动化自己的工作。你可以先从很小的需求开始：

• 把表格自动整理成周报
• 批量重命名文件
• 生成固定格式的文案
• 做一个客户信息查询页
• 把常用计算做成网页工具

但也要记住：如果工具涉及真实用户、公司数据、客户隐私或金钱流转，就要找懂技术的人审查。

结论

Vibe Coding 不是魔法，也不是骗局。它是一种新的软件生产方式：用自然语言把意图传给 AI，再用运行结果和反馈不断逼近目标。

它最适合做原型、小工具、个人项目和低风险自动化。它不适合在缺少审查、测试和责任人的情况下直接承载核心业务。

真正成熟的用法不是“完全跟着感觉走”，而是把 AI 的生成速度和人的工程判断结合起来：让 AI 快速写，让人负责方向、边界和质量。

未来会写代码的人仍然重要，但更重要的是会把问题说清楚、把结果验明白、把系统维护好的人。

参考资料

• Merriam-Webster 对 “vibe coding” 的解释：https://www.merriam-webster.com/slang/vibe-coding
• Wikipedia 对 “vibe coding” 的词源、定义和争议整理：https://en.wikipedia.org/wiki/Vibe_coding
• Advait Sarkar 和 Ian Drosos 的研究论文《Vibe coding: programming through conversation with artificial intelligence》：https://arxiv.org/abs/2506.23253
• Christian Meske 等人的研究论文《Vibe Coding as a Reconfiguration of Intent Mediation in Software Development》：https://arxiv.org/abs/2507.21928

Codex 执行时间

3m 20s

两篇文章对比评价（codex自身评价）

1. Codex 文章的 3 个优点

• 定义更稳，能把 Vibe Coding 讲成一种开发工作流，而不是只讲概念热词。
• 风险边界更清楚，尤其强调安全、权限、生产系统和工程责任。
• 实践建议更具体，有“先写目标、先给方案、小步修改、每次运行、补测试”的完整路径。

2. Codex 文章的 3 个不足

• 开头不够抓人，缺少 Claude 那种适合公众号的标题感和金句。
• 篇幅偏长，信息密度高，但阅读节奏略平。
• 缺少传统编程 vs Vibe Coding 的表格对比，用户扫读成本更高。

3. Claude 文章值得 Codex 借鉴的地方

• 标题、副标题和开场更有传播感。
• 用表格、符号和短句降低阅读压力。
• 工具列表、争议观点和趋势总结更适合普通读者快速理解。

4. Codex 文章是否更适合公众号发布

不完全是。Codex 更适合做深度解释稿，可信度和工程判断更强；Claude 更像公众号成稿，结构更轻、传播性更好。若面向技术读者，Codex 更合适；若面向泛读者，Claude 更容易读完。

5. 一句修改建议

保留 Codex 的工程深度，但把开头、标题、表格对比和段落节奏改得更像 Claude，增强公众号可读性。