Appearance
什么是 Vibe Coding
Vibe Coding 这个词是 Andrej Karpathy 在 2025 年初造的。他说的是这样一种状态：你把意图告诉 AI，AI 给你生成代码，你不一定完全读懂，但你能判断它跑不跑、对不对，然后继续往下描述下一个需求。
这不是"代码生成工具"的委婉说法，也不是"低代码平台"的换皮版本。它更接近一种新的工作节奏——你的主要输入是自然语言描述，AI 的主要输出是可运行的代码，而你的角色是判断者和引导者，不是每一行的实现者。
Karpathy 原话是这样说的："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."
当然，"forget that the code even exists"这句话是夸张说法，实际工作中你不可能真的不管代码。但他点出了一件真实的事：在这种工作方式里，代码不再是你的主要输出，你对结果的判断才是。
它和"用 AI 辅助写代码"有什么区别
你可能已经用过 GitHub Copilot、ChatGPT 或 Cursor 来帮你补代码。那种用法通常是：你知道自己要写什么函数，让 AI 帮你补全实现细节，或者帮你查语法。控制权始终在你这边，AI 是个执行工具。
Vibe Coding 的节奏不一样。你描述的是目标，不是实现路径。"帮我做一个支持拖拽排序的任务列表"——你不决定用哪个库、怎么组织组件、数据怎么存。AI 给你一个完整方案，你运行它，看效果，然后继续描述下一个需求或者调整方向。
两种工作方式的对比：
| AI 辅助写代码 | Vibe Coding | |
|---|---|---|
| 你的输入 | 函数签名、TODO 注释、具体问题 | 目标描述、行为期望 |
| AI 的角色 | 填充实现细节 | 设计并实现完整方案 |
| 你的角色 | 主导实现路径 | 判断结果是否符合预期 |
| 适合的任务规模 | 局部修改、小函数 | 完整功能、新项目 |
| 对代码的理解要求 | 较高（你需要能读懂每行） | 较低（能判断行为对不对就行） |
这意味着你会经常在没有完全理解代码细节的情况下做决策。这对很多有经验的开发者来说反而有点不适应，因为过去的习惯是"不理解就不继续"。
它适合什么场景
Vibe Coding 在以下情况下效果比较好：
- 你有一个具体目标，但不熟悉某个技术栈（比如你是后端，但要做一个前端原型）
- 你想快速验证一个想法，不想在基础架构上花时间
- 任务边界清晰，可以一块一块描述
- 你能判断结果对不对，哪怕不知道实现细节
- 项目早期，架构还没定型，改来改去成本低
效果比较差的场景：
- 任务本身你还没想清楚，边描述边发现目标在变
- 项目已经有大量历史代码，AI 对上下文的理解开始出错
- 你对结果的正确性没有判断能力，完全依赖 AI 自检
- 涉及复杂的安全、并发或数据一致性要求，需要对实现细节负责
第二类场景不是说不能用 AI，而是 Vibe Coding 那种"持续描述、持续接收输出"的节奏会失控。你需要先把问题想清楚，再进入这个工作流。
一个实际的判断方法：如果你能在 5 分钟内写清楚"这个功能成功的样子是什么"，Vibe Coding 就可以开始。写不清楚，先把问题拆清楚。
技术背景影响大吗
有基础比没有基础上手更快，但不是必须的。
有前端/后端/全栈基础的开发者，Vibe Coding 能帮你绕过不熟悉的技术栈，同时保留你对架构和质量的判断能力。你不需要学每个框架的细节，但你知道"这个接口设计合不合理""这个错误处理少了什么"。
完全没有编程经验的人也能做出能跑的东西，但通常卡在"能跑"和"真正可用"之间的差距上。AI 不会主动告诉你它生成的权限检查是不是够的、这个 SQL 在大数据量下会不会慢。
所以真正的门槛不是"会不会写代码"，而是"能不能判断代码的结果"。
最容易踩的坑
代码跑起来了，就觉得任务完成了。
"能跑"和"正确"之间有很大的距离，尤其是涉及边界条件、并发、权限或数据一致性的时候。AI 给的代码在 happy path 上通常没问题，但它不会主动说"这个实现在高并发下会出问题"。
你的判断能力是整个工作流里最不能外包出去的部分。
让 AI 一次生成太多。
如果你把一个复杂功能一口气描述清楚，AI 会生成一大块代码。这块代码的问题不是质量差，而是你不知道从哪里开始验证、出了问题怎么定位。更有效的做法是把功能切小，每次只描述一步，跑通了再描述下一步。
出了问题就读代码，而不是先描述现象。
Vibe Coding 里，当 AI 生成的代码出问题时，最快的修复路径通常不是自己去读代码找 bug，而是把错误信息和复现步骤直接给 AI，让它自己定位和修复。自己读代码是个备选方案，不是第一反应。
忽略 diff，直接接受所有修改。
AI 有时候会做超出预期的修改，或者在修复一个问题时引入另一个问题。每次修改后花 30 秒扫一眼 diff，确认改动范围在预期内，这个习惯会帮你省掉很多麻烦。
它对开发者意味着什么
不是"替代程序员"的问题。它改变的是个人开发者的能力上限。
过去，一个人在一个周末能做的事有明确的上限——你的时间、你知道的技术栈、你能手写的代码量。现在这个上限变了。一个后端工程师可以在不懂 React 的情况下做出一个前端原型；一个有产品想法但不会写代码的人可以跑出一个能演示的版本。
这里面有个前提：你得会用这套工具，也得知道它的边界。盲目相信 AI 输出的人会产出一堆能跑但不可维护的代码，而能判断 AI 输出质量的人会快得多、出错少得多。
工程判断能力反而变得更值钱，而不是更不值钱——只是它现在需要和新的工作节奏结合起来。
下一页是第一个 Vibe Coding 项目，用一个具体的 Todo App 跑通从描述到运行的完整流程。