🎵 什么是 vibe coding？——从「让 AI 写代码」到「和 AI 一起做产品」
你已经会用 AI 写代码了：让它生成一个函数、改一个样式、修一个报错，都能跑通。
但你有没有过这种感觉：第一版它做出来了，你看了一眼，说不上哪里不对，但就是不像你想要的东西。 改了一轮，又跑偏了。来回三四次，最后能用了，但你心里清楚，这事儿没学到任何东西。
这一篇就是讲：那问题到底出在哪，以及 vibe coding 到底是个什么东西。
先说结论
| 让 AI 写代码 | vibe coding | |
|---|---|---|
| 你在干什么 | 提需求，验收成品 | 提方向，和它一起把东西磨出来 |
| 一轮的时长 | 一次说清，做完再看 | 几分钟一轮，边做边看 |
| 谁做决策 | 你写清楚，AI 做完 | 你定方向，AI 定实现 |
| 你的核心能力 | 描述能力 | 判断能力 |
一句话：
vibe coding = 你负责「说清楚要什么」和「判断做得对不对」，AI 负责「怎么做」。
你不需要会写代码，但你必须会看结果、敢说不、知道什么时候该停。
为什么你用 AI 写代码会「卡住」？
假设你要做一个「待办事项网页」。
做法一：一次性说清（最容易卡住的方式）
「帮我做一个待办事项网页，要有添加、删除、勾选完成的功能。」
Agent 会一次给你 800 行代码、三个文件。你跑起来——嗯，能用。
但它做出来的东西，一定有 30 处不是你真正想要的：
- 按钮不是你想要的样式
- 删错了没有确认
- 刷新就没了
- 手机上看是一团糟
- 界面上多了一堆你根本没要求的东西
问题出在哪？ 你把「决定权」一次性全交给了 AI。它不知道你喜欢什么风格、不知道你真正在意哪个功能、不知道你其实更想要极简。
而你一次也没看到过程，所以你也没机会在中间纠偏。
做法二：拆小一点
「先只做添加功能，不要删除，不要样式，我只要能加进去。」
这个明显更好。为什么？
因为你缩小了它可能跑偏的空间，而且你立刻能看到结果对不对。
做法三： vibe coding 真正的样子
第 1 轮：「做一个待办页面。先只放一个输入框和一个按钮，我看看。」
→ 出来一个丑但能用的东西。
第 2 轮：「按钮改成圆角、深蓝色，其他别动。」
→ 微调。
第 3 轮：「现在加删除功能，删除前要弹确认。」
→ 增量。
第 4 轮：「数据存到 localStorage，刷新不丢。」
→ 补关键能力。
第 5 轮：「手机上挤成一团了，你看看怎么改。」
→ 截图反馈。看懂区别了吗？ 做法三里，AI 每一步都只做一件小事，你每一步都能看到、能判断、能纠偏。
这就是 vibe coding。
核心机制：为什么「小步快跑」在 AI 编程里格外重要
这是本文最重要的一段，请你慢一点看。
传统编程 vs vibe coding
| 传统编程 | vibe coding | |
|---|---|---|
| 反馈周期 | 写完 → 跑 → 看效果 | 几秒一轮 |
| 一次写多少 | 一个功能写完再测 | 一屏、一小步 |
| 纠错成本 | 写 500 行才发现错了，改起来很痛 | 错 3 行，改 3 行 |
| 谁先看到结果 | 开发者 | 你 |
为什么这对 AI 特别关键
因为 AI 写代码的速度，比你看懂代码的速度快得多。
传统开发里，程序员写完 500 行，会花时间自己读一遍再提交——因为看懂是必修课。而 vibe coding 里，你不需要读懂每一行，你只需要看到效果对不对。
这带来一个反直觉但极其重要的结论：
你越不懂代码，越要把每一轮拆得小。
因为「看懂」这条路对你关闭了，你唯一的反馈通道就是运行结果。轮次越小，这条通道越通畅。
如果你拆得大、一次要 800 行，你拿到手的是 800 行你读不懂的代码 + 一个跑偏的结果。这时候你唯一的动作就是「全盘否定、重新来过」，成本极高。
如果你拆得小、一次要 20 行，你拿到的是 20 行 + 一个立刻能判断对错的结果。判断错了，改那 20 行就行。
💡 这一段是本篇的核心。 记住这句话就够了：
「小步」不是保守，是让不懂代码的你也能拿到方向盘。
三种失控
跑偏了不可怕，可怕的是不知道自己跑偏了。vibe coding 新手最常见的失败，不是做不出来，而是做出来了但没发现已经歪了。
新手常见的三种失控：
| 失控类型 | 表现 | 后果 |
|---|---|---|
| 需求失控 | 一开始说「做个待办」，最后做出来是个多用户协作系统 | 方向完全跑偏，前面的功夫全废 |
| 代码失控 | 功能是能跑，但代码里全是补丁，重复、互相冲突 | 每加一个功能就崩一个，修不动了 |
| 上下文失控 | 聊到第 20 轮，Agent 开始忘事、开始重复做过的事 | 反复返工，越改越乱 |
而防住这三种失控的方法，其实就三句话：
说清边界 → 守住范围
小步迭代 → 守住质量
定期收口 → 守住上下文什么是「AI 可读的」需求
还有一个关键区别，很多人没意识到。
给人看的需求和给 AI 看的需求，是两种东西。
| 给人的需求 | 给 AI 的需求 | |
|---|---|---|
| 例子 | 「做一个简洁的待办应用」 | 「先只做添加功能，界面只留一个输入框和一个按钮」 |
| 特点 | 定方向，允许模糊 | 定边界，可验证 |
| 适合 | 提给设计师、提给老板 | 提给 Agent |
为什么给 AI 的需求必须「可验证」？
因为 AI 不认识你。你说「简洁」，它可能给你极简，也可能给你满屏功能。你说「好看」，它随便挑一套。
而可验证的意思是：你能判断「对不对」。「只有一个输入框和一个按钮」——你一眼就能判断是不是照做了。
💡 你其实已经在用这个方法了： 👉 怎么把需求讲清楚 里的「背景 + 目标 + 范围 + 验收标准」四句话，本质就是在给 AI 写可验证的需求。
下一步
现在你知道 vibe coding 是什么了。接下来四篇，是一条完整的主线：
| 章节 | 你会学到 | |
|---|---|---|
| V1 | ✅ 你在这里 | vibe coding 是什么，为什么小步更重要 |
| V2 | 一轮该做多小？ | 粒度、什么时候该打断、每轮必问的三句话 |
| V3 | 不会写代码，怎么验收？ | 看结果的三个信号、红线信号表、跑偏了怎么拉回来 |
| V4 | 人机分工与长期不失控 | 该你管什么、该它管什么、三条红线、上下文管理 |
如果你只想看一篇，先看 V3 验收与纠偏—— 大多数人翻车都翻在「做完了却没发现不对」。