什么是 Vibe Coding

Vibe Coding 这个词是 Andrej Karpathy 在 2025 年初造的。他说的是这样一种状态：你把意图告诉 AI，AI 给你生成代码，你不一定完全读懂，但你能判断它跑不跑、对不对，然后继续往下描述下一个需求。

这不是"代码生成工具"的委婉说法，也不是"低代码平台"的换皮版本。它更接近一种新的工作节奏——你的主要输入是自然语言描述，AI 的主要输出是可运行的代码，而你的角色是判断者和引导者，不是每一行的实现者。

它和"用 AI 辅助写代码"有什么区别

你可能已经用过 GitHub Copilot、ChatGPT 或 Cursor 来帮你补代码。那种用法通常是：你知道自己要写什么函数，让 AI 帮你补全实现细节，或者帮你查语法。控制权始终在你这边。

Vibe Coding 的节奏不一样。你描述的是目标，不是实现路径。"帮我做一个支持拖拽排序的任务列表"——你不决定用哪个库、怎么组织组件、数据怎么存。AI 给你一个完整方案，你运行它，看效果，然后继续描述下一个需求或者调整方向。

这意味着你会经常在没有完全理解代码细节的情况下做决策。这对很多有经验的开发者来说反而有点不适应，因为过去的习惯是"不理解就不继续"。

它适合什么场景

Vibe Coding 在以下情况下效果比较好：

• 你有一个具体目标，但不熟悉某个技术栈（比如你是后端，但要做一个前端原型）
• 你想快速验证一个想法，不想在基础架构上花时间
• 任务边界清晰，可以一块一块描述
• 你能判断结果对不对，哪怕不知道实现细节

效果比较差的场景：

• 任务本身你还没想清楚，边描述边发现目标在变
• 项目已经有大量历史代码，AI 对上下文的理解开始出错
• 你对结果的正确性没有判断能力，完全依赖 AI 自检

第二类场景不是说不能用 AI，而是 Vibe Coding 那种"持续描述、持续接收输出"的节奏会失控。你需要先把问题想清楚，再进入这个工作流。

最容易踩的坑

当 AI 生成的代码跑起来了，就觉得任务完成了。

这是 Vibe Coding 最常见的陷阱。"能跑"和"正确"之间有很大的距离，尤其是在涉及边界条件、并发、权限或数据一致性的时候。AI 给的代码在 happy path 上通常没问题，但它不会主动告诉你"这个实现在高并发下会出问题"。

你的判断能力是整个工作流里最不能外包出去的部分。

让 AI 一次生成太多。

如果你把一个复杂功能一口气描述清楚，AI 会生成一大块代码。这块代码的问题不是质量差，而是你不知道从哪里开始验证、出了问题怎么定位。更有效的做法是把功能切小，每次只描述一步，跑通了再描述下一步。

开发者为什么值得认真对待这件事

不是因为它能"替代程序员"——这个说法没什么意义。而是因为它改变了个人开发者的能力上限。一个人在一个周末能做到的事情变了。过去需要一个团队的项目，现在可以一个人在几天内跑出原型。

这里面有个前提：你得会用这套工具，也得知道它的边界。盲目相信 AI 输出的人会产出一堆能跑但不可维护的代码，而能判断 AI 输出质量的人会快得多、出错少得多。

这本质上是一个工程判断能力的问题，不只是工具使用的问题。

---

下一页是第一个 Vibe Coding 项目，用一个具体的 Todo App 跑通从描述到运行的完整流程。