什么是 Vibe Coding？通俗解释
Vibe coding 是通过用自然语言向 AI 描述你想要的东西、运行它生成的结果，并根据运行效果而不是代码来引导开发的一种做软件的方式。你评判的是应用本身：按钮能不能用，页面看起来对不对。你不断提出修改，直到它满足你的需要。这个词由 AI 研究员 Andrej Karpathy 于 2025 年 2 月在 X 上的一篇帖子中提出，他在帖子里描述了顺着感觉走、忘记代码存在的状态。
这个词的由来
Karpathy 曾是 OpenAI 的创始成员之一，也担任过特斯拉的 AI 负责人。他用这个说法来形容自己做一些小型周末项目的方式：和 AI 编程工具对话，不看它改动的差异就直接接受，遇到报错就把报错信息贴回去，直到能跑通为止。他明确表示，这种方式适合临时性的项目。
这个说法之所以流行，是因为它命名了许多人已经在做的事情。几个月内，它就被用来指代从个人爱好项目到创业公司原型的各种开发。柯林斯词典还将「vibe coding」选为 2025 年度词汇。如今，它被宽泛地用来指代任何由 AI 写代码、由人用自然语言来指挥的开发方式。
如果你在用 AI 做应用，它为什么重要
对于不写代码的人来说，vibe coding 正是 AI 应用构建工具有用的根本原因。创业者可以在一个下午测试一个想法；小企业主可以做出一个预约表单或库存跟踪工具，而这是他们过去绝不会花钱请外包公司做的；设计师可以把设计稿变成可以点击的原型。
但这个定义本身就包含了一个警告。「忘记代码的存在」在代码只需要为你自己、为当下运行时没有问题。但如果应用要存储客户数据、处理付款，或需要多年稳定运行，这种做法就不太合适了。弄清楚这条界线在哪里，是你在 vibe coding 中能学到的最有用的一课。
一个日常类比
想象你装修厨房时，不自己画图纸，而是直接告诉装修师傅你想要什么。你说「窗户下面一个长台面，开放式置物架，冰箱放在门边」，然后每天晚上走进去看看做得怎么样，再提出需要修改的地方。
这种方式对布局和外观效果很好，因为你站在房间里就能判断。但对于墙后面的东西就不太行：电线、水管、燃气管道是否符合规范，这些光看是看不出来的，问题可能要等到出了故障才会暴露。细心的房主依然会请人来做检查。
Vibe coding 也是如此。界面就是你看得见的房间，安全、数据处理和代码的组织方式，就是墙里面的线路。
实际的 vibe coding 是什么样子
假设你想做一个简单的工具，用来跟踪哪些客户已经付清了发票。
| 步骤 | 你做什么 | AI 做什么 |
|---|---|---|
| 1. 描述 | 「一个客户列表页面，显示发票金额、到期日和已付/未付状态。我可以添加客户，并把发票标记为已付。」 | 编写页面、表单和保存数据的逻辑 |
| 2. 试用 | 添加一个客户，标记为已付，刷新页面 | 在预览中运行应用 |
| 3. 反馈 | 「刷新之后，我的客户都不见了」 | 解释数据只保存在浏览器内存中，并添加数据库 |
| 4. 完善 | 「把逾期发票排到最前面，并标成红色」 | 修改列表 |
| 5. 检查 | 在手机上打开；尝试提交空表单 | 修复你反馈的问题 |
你从头到尾没有打开过任何代码文件。但请注意第 3 步：应用看起来已经完成了，实际上却还没有真正保存任何数据。Vibe coding 奖励那些像用户一样测试、并能精确描述所见内容的人。
优势
- 速度快。 几分钟或几小时就能得到一个可用的初版，而不是几周。
- 尝试想法的成本低。 你可以做出三个版本，然后保留能用的那个。
- 直接掌控。 最了解问题的人亲自塑造产品，不必把需求层层转述给开发人员，信息不会在传递中丢失。
- 边做边学。 很多人只要观察 AI 构建的过程并追问为什么，就能慢慢理解应用各部分如何配合，比如前端与后端、数据库和 API。
真正的风险
这些并不是不该使用 vibe coding 的理由，而是「凭感觉」无法替你检查的东西。
你看不见的安全漏洞
一个应用可能看起来完美无缺，却允许任何已登录用户读取其他所有用户的记录，或者把密钥暴露在运行于访客浏览器中的代码里。这些问题在你以自己的身份随便点点时是不会显现的。常见问题包括：服务器端缺少权限检查、把 API 密钥放在前端代码里，以及表单对任何输入都照单全收。
没人理解的代码
如果没有人读过代码，就没有人知道它是如何组织的。规模小的时候还好。随着应用变大，每次修改都可能破坏某个不相关的功能，而 AI 有时会在「修复」一个 bug 的同时制造另一个 bug。那些数月来从未经过任何审查的 vibe coding 应用，往往比慢慢打造的应用更难修改。
不清楚什么才算「完成」
AI 会很痛快地告诉你某个问题已经修好了。只有测试才能告诉你它是否真的修好了。跳过测试的人，最终得到的功能在演示时能用，一遇到真实数据就出问题：名字很长、字段为空、两个人同时预订同一个时段。
隐藏的依赖与费用
AI 构建的应用常常会接入外部服务，比如邮件服务商、支付处理商和 AI 接口。每一个都有自己的账号、密钥、用量限制和账单。上线前，要先弄清楚你的应用依赖哪些东西。
常见误解
| 误解 | 实际情况 |
|---|---|
| 「vibe coding 就是没有代码。」 | 代码确实存在，只是你没有去读。正因为如此，你之后才能导出它，或者交给开发人员。 |
| 「能运行就说明是对的。」 | 能运行，与正确、安全、可维护，是三回事。 |
| 「这只适合非开发者。」 | 很多专业开发者也会用 vibe coding 做原型，然后在上线前再审查或重写。 |
| 「AI 会主动告诉我哪里有问题。」 | 你问的话它通常会说，但不一定主动提。要直接问。 |
| 「用这种方式做不了认真的东西。」 | 很多真实的应用都是这样起步的。认真的部分，是在真实用户依赖它之前补上测试和审查。 |
如何负责任地进行 vibe coding
以下几个习惯，就能覆盖大部分风险：
- 小步修改。 一次需求，一处改动，然后测试。笼统的大需求只会得到笼统的大结果。
- 使用检查点。 在尝试有风险的操作之前，确保你能回退到上一个可用版本。
- 让 AI 解释。 「这次改动做了什么？可能会破坏哪些地方？」这几句话成本很低，却能发现很多问题。
- 像陌生人一样测试。 用第二个用户账号登录，尝试查看第一个用户的数据。
- 不要把密钥写进代码或聊天里。 API 密钥应放在环境变量或项目 secrets 中。
- 面向真实用户之前先审查。 对于涉及付款或个人数据的应用，请按照安全检查清单逐项核对，或请开发人员帮你看一看。
向你的 AI 构建工具提出的要求
以下提示可以把「凭感觉」变成可以检验的步骤：
- 「在动手构建之前，先告诉我你的计划，以及它会存储哪些数据。」
- 「列出这个应用存储或发送用户数据的每一个位置。」
- 「已登录的用户能否看到或修改其他用户的记录？请检查服务器端代码，而不只是页面。」
- 「有没有 API 密钥暴露在运行于浏览器的代码中？」
- 「如果两个人在同一时刻提交这个表单，会发生什么？」
- 「总结一下最近三次修改改了什么。」
更多方法请参阅如何为 AI 应用构建工具编写提示词；出现问题时，可以参阅如何调试 AI 构建的应用。
在 Mythex 中做 vibe coding
Mythex 是一款为这种工作方式而打造的AI 应用构建工具：你在聊天中描述应用，智能体在实时预览中编写并运行代码，然后你可以将应用发布到公开网址。有几个功能正是针对上述风险设计的：Plan 模式让智能体在修改任何文件之前先列出方案，Ask 模式只回答问题、不做任何编辑，每次成功的操作都会保存一个检查点，你可以随时回退。Pro 用户还可以打开完整的代码编辑器，在需要开发人员审查时导出项目或同步到 GitHub。聊天文档介绍了各种模式和检查点，如果从空白页面开始让你觉得无从下手，可以参考模板作为起点。
常见问题
vibe coding 这个词是谁提出的？
由 AI 研究员、OpenAI 创始成员之一 Andrej Karpathy 在 2025 年 2 月于 X 上的一篇帖子中提出。他描述的是顺着感觉走，忘记代码的存在。这个说法很快就传开了。
vibe coding 和 no-code 是一回事吗？
不完全是。No-code 工具让你在一个隐藏代码的可视化编辑器里搭建应用。而 vibe coding 中，AI 写的是真实存在于文件里的代码；你只是选择不去读它，而是通过描述需求和检查结果来引导开发。
vibe coding 做的真实应用安全吗？
可以安全，但要补上「凭感觉」时会跳过的检查：确认用户之间无法看到彼此的数据，把 API 密钥存放在 secrets 中而不是写在代码里，并审查所有涉及资金或个人数据的部分。对于临时原型，风险较低；对于有真实用户的应用，风险就不低了。
做 vibe coding 需要先学编程吗？
不需要。但了解一些基本概念，比如什么是数据库、API 和身份验证，能让你的需求描述更清楚，也更容易发现问题。理解这些概念不需要你自己写代码。