什么是 vibe coding：Karpathy 提出的概念已成为柯林斯年度词汇

最后更新：2026年10月24日 · 作者：Abdullah Zulfiqar，创始人兼主编

什么是 vibe coding？就是用自然语言向 AI 模型描述你想要什么来构建软件，并接受它写出的代码，通常连看都不看。Andrej Karpathy 于 2025 年 2 月创造了这个词，柯林斯词典将其评为 2025 年度词汇。

有一种新的编程方式，我称之为“vibe coding”，在这种方式下，你完全沉浸在感觉中，拥抱指数级增长，甚至忘记代码的存在。这之所以可行，是因为 LLM（例如 Cursor Composer 配合 Sonnet）已经变得太强了。另外，我现在直接用 SuperWhisper 跟 Composer 对话……

你输入一个需求，运行 AI 构建出的东西，说出哪里坏了，然后重复，直到应用能用为止。你通过使用它来判断结果。许多 vibe coder 从不阅读代码。

在不到两年的时间里，vibe coding 从 X 上的一个玩笑，变成了创始人构建首个产品的常规方式。其中一些创始人也在这个过程中泄露了用户数据。本指南解释它如何运作、哪些工具和模型最擅长做这件事，以及你什么时候应该放慢速度。

我认为 vibe coding 对那些对代码一窍不通的人来说是一个很好的起点。但如果你想打造一款好产品，你仍然需要理解事物如何运作、哪个工具适合哪项工作，以及如何保证应用的安全。这正是本指南的目的。

Vibe coding 是一种 AI 辅助编程风格。你用自然语言描述软件，由 Claude、GPT 或 Gemini 这样的大型语言模型（LLM）编写代码，如果代码能用，你就保留它。你不会逐行审查。

vibe coding 的含义来自“vibes”这个词。你顺其自然。你不规划架构，也不阅读 diff（即精确显示 AI 添加、更改或删除了哪些行的视图）。如果应用做到了你要求的事，你就继续往下走。

最后这一点正是 vibe coding 与使用 AI 写代码的区别所在。开发者 Simon Willison 在 2025 年 3 月划出了这条界线：如果你审查 AI 的代码、测试它，并且能解释它如何运作，那你就是在用 AI 助手做正常的软件开发。vibe coding 最简单的定义是：你根据结果来把控方向，跳过代码审查。

这个词如今已成为主流。韦氏词典在 2026 年 9 月的更新中将“vibe coding”收入词典，IBM、Google 和 Microsoft 也都发布了使用该词的指南。

大多数 vibe coding 会话都遵循同样的五个步骤：

大多数人会多次重复步骤 1 到 4，并跳过步骤 5。跳过步骤 5 是大多数 vibe coding 应用失败的原因。

在下面这段对话中，有人没有写任何代码就添加了一个功能：

你：在导航栏右上角添加一个深色模式切换开关。记住用户的选择。 AI：我在导航栏中添加了一个 ThemeToggle 组件，并将用户的选择保存在浏览器的本地存储中。 你：在深色模式下，页面加载时会闪白一秒钟。 AI：这是主题闪烁。页面在读取你已保存主题的代码运行之前就出现了。我在页面 head 中添加了一小段脚本，在显示任何内容之前应用已保存的主题（或系统设置）。

这个人描述了自己想要什么，进行了测试，并用平实的语言报告了一个 bug。AI 处理了代码。

像“给我做一个健身应用”这样模糊的初始提示会得到糟糕的结果。不如给 AI 一份简短的说明：

我想构建：[用一句话描述这个应用] 目标用户：[谁会使用它] 仅版本 1 的功能：

• [功能 1]
• [功能 2]
• [功能 3] 页面/屏幕：[列出它们] 存储的数据：[例如用户、习惯、每日打卡] 登录方式：[邮箱和密码 / Google / 魔法链接] 技术栈：[例如 Next.js + Supabase + Tailwind，或“你来选择并解释原因”] 规则：
• 写代码之前先问我任何问题。
• 一次只构建一个功能。每完成一个，告诉我如何测试它。
• 不要添加我没有要求的功能。
• 只使用知名软件包，安装任何新东西之前先告诉我。
• 每个可用的功能完成后提交到 Git。
• 数据库变更以迁移的形式进行。未经询问绝不删除或重置数据。
• 只有公开密钥（如 Supabase 的 anon 或 publishable key）可以放在前端代码中。密钥保留在服务器上。
• 为每张表开启数据库访问规则（例如 Supabase Row Level Security）。

最后一条规则很可能可以避免下文所述的 Lovable 数据泄露事件。

提示：把规则部分保存为常驻指令，这样你就不必每次都粘贴。在 Claude Code 中，那是 CLAUDE.md 文件；在 Cursor 中，那是 rules 文件；在 Lovable 中，那是项目知识。我们的 Claude Code 模板包含现成的版本，而提示词增强器可以把一个粗略的想法变成更完整的说明。

为了看看这在实践中如何运作，我在 2026 年 10 月 24 日把上面这份说明的一个版本交给了 Lovable，使用的是 Lovable 的免费计划和它内置的 Lovable Cloud 后端。这个应用是：一个习惯追踪器，你可以勾选每日习惯并查看连续打卡记录，包含一个登录页、一个“今天”页面和一个管理习惯的页面。

它在构建之前先提问。由于说明中要求它这样做，Lovable 没有直接开始写代码。它思考了大约 10 秒钟，然后问了三个问题：我是否需要显示名称之类的个人资料信息（不需要，只要邮箱），习惯是否需要颜色（不需要，只要一个名称），以及对于连续打卡来说一天应该在什么时候“结束”。最后一个问题是真正的边界情况。如果没有它，对于在跟服务器不同时区的晚上 11 点勾选习惯的人来说，连续打卡可能会中断。我选择了我的本地时间。

它写了一份我可以批准的计划。接下来它保存了一份计划文件，列出了三个功能、三个页面、两张数据库表（habits 和 check-ins）以及安全规则。两张表都开启了 Row Level Security，这样每个用户只能看到自己的数据，计划中还说明前端代码中不会放入任何密钥。我读完计划后才批准了它。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）