vibe-vibe 教程精读：什么是 Vibe Coding——用对话迭代把模糊想法变成产品-开发者社区

文档
教程
Vibe Coding
示例工程

【免费下载链接】vibe-vibe

The First Systematic Vibe Coding Open-Source Tutorial | From Zero to Full-Stack, Empowering Everyone to Build Products with AI | Live at: www.vibevibe.cn ；首个系统化 Vibe Coding 开源教程 | 零基础到全栈实战，让人人都能用 AI 开发产品 | 在线地址：www.vibevibe.cn

项目地址：https://gitcode.com/datawhalechina/vibe-vibe

点击查看免费下载

导读：本文是 Datawhale 开源教程《vibe-vibe》「1.4 Vibe vs Spec：AI 编程的两种方式」章节的第一课，完整讲解 Vibe Coding 的定义、交互式开发流程、四大核心要素与实用技巧，并结合仓库中的进阶工作流文档与可运行 Demo 测试，说明"生成—反馈—调整"循环在实际项目中如何落地。读完本文，你将能够判断自己的需求是否适合 Vibe Coding，并掌握用多轮对话驱动产品从模糊想法走向可运行版本的完整方法。

一句话定义：Vibe Coding 的本质

在 vibe-vibe 教程体系中，Vibe Coding 被概括为一个非常精炼的公式：

Vibe Coding = 通过对话迭代，将模糊需求逐步变成实际产品。

这一定义的关键，不在于提示词写得有多长、多华丽，而在于需求的明确程度。Vibe Coding 天然适合那些需求模糊、边界不清、需要边走边探索的项目——你心里只有一个大方向，具体要做成什么样，要靠和 AI 的多轮对话才能逐渐看清。

与之相对的是 Spec Coding（规范驱动开发）：需求已经明确时，先写规范文档，再让 AI 按文档执行。两者不是对错关系，而是需求确定性光谱上的两个端点，实际项目中往往混合使用。关于 Spec Coding 的完整介绍，可以参考同章节的 1.4.2 什么是 Spec Coding 与 1.4.3 如何选择和切换。

交互式开发过程：多轮对话而非一次成型

Vibe Coding 与传统的"一次性给全需求"完全不同。它的核心流程是一个循环，而不是一条直线：

这个循环在教程的进阶版中被进一步标准化为「探索 → 规划 → 执行 → 验证 → 提交」五步工作流（见 2.2 VibeCoding 工作流），其中"测试反馈"这一步尤其关键——只有看到实际运行结果，你才知道下一步该往哪里调。

真实对话案例：喝水打卡小工具的五轮演进

原文档给出了一个非常直观的案例——用五轮对话做一个喝水打卡工具，每一轮都对应"初步实现 → 测试反馈 → 调整需求"中的一个节拍：

第1轮 - 初始需求

你：我想做个记录喝水的小工具 AI：我帮你做一个简单的喝水打卡网页...

第2轮 - 基于初版反馈

你：不错，但我想加入提醒功能，每天下午3点提醒 AI：好的，添加定时提醒功能...

第3轮 - 细节完善

你：提醒要能自定义时间，还要显示本周进度 AI：增加时间设置和进度统计...

第4轮 - 功能扩展

你：再做个周报，统计每天喝水量趋势 AI：添加数据可视化和周报生成...

第5轮 - 最终调整

你：界面简化一下，只保留核心功能 AI：优化界面布局，突出核心功能...

注意这五轮对话的两个特点：每一轮都只基于上一轮的产出追加一个明确的小需求；每一轮都先看到实际效果再决定下一步。这正对应教程 1.3 节「三轮微调法」中强调的原则——"一次只改一类问题，改动边界要说清"，避免让修改范围失控（详见 1.3 在平台里生成你的第一个版本）。

从对话到代码：仓库中的可验证落点

Vibe Coding 的"测试反馈"不只是口头描述，而是要在真实代码上验证。在 vibe-vibe 仓库的 demos 目录中，你可以看到这种迭代理念的工程化落地：

demo-01-todo是一个完整的 Next.js Todo 应用，它的 API 测试文件 todos.test.ts 使用 Vitest 覆盖了GET /api/todos、POST /api/todos的成功与失败路径——例如"标题为空时应该返回 400"、"缺少标题字段时应该返回 400"，这就是"测试反馈"环节最直接的证据：每次对话迭代产出的功能，都要靠自动化测试确认行为是否符合预期。
demo-02-todo-auth在 CRUD 之上叠加了 Better Auth 用户系统，体现了"功能稳定后再叠加新层"的迭代节奏。

也就是说，Vibe Coding 的"生成—反馈—调整"循环，在真实工程中表现为：AI 生成代码 → 运行测试/预览 → 依据反馈调整 → 再次验证，直到功能符合需求。仓库中每一个可运行的 demo 都是这条循环的产物。

四个核心要素

原文档将 Vibe Coding 拆解为四个相互支撑的核心要素，这也是理解和用好 Vibe Coding 的框架：

1. 需求探索：快速试错

当想法还不清晰时，Vibe Coding 的价值在于让你用几分钟做出一个基础版本，然后根据实际体验调整方向，而不是在脑内反复推演。试错成本低，探索效率高，这是它相比"先写完整文档再动手"的最大优势。

2. 对话累积：记录即文档

每次对话都建立在前一轮的基础上，AI 会记住之前的实现细节。这意味着对话记录本身就是项目文档——你不需要额外花时间维护需求说明书，历史对话就是需求的演进史。教程进阶版也指出：当需求逐渐清晰后，可以"回顾对话记录，提炼真实核心需求"，把它整理成正式的规范文档（见 1.4.2 什么是 Spec Coding）。

3. 迭代优化：看到效果才知道要什么

"看到实际效果后，才能明确真正的需求"——这是 Vibe Coding 最反直觉也最有效的一点。很多需求是体验之后才被发现的，Vibe Coding 支持快速的"生成-反馈-调整"循环，让需求在迭代中自然浮出水面。进阶工作流文档把这种协作概括为"信任但验证"：默认信任 AI 的产出，通过功能测试、类型检查、关键代码审查来发现问题，再让 AI 修正（见 2.2 VibeCoding 工作流）。

4. Context 管理：让 AI 记住关键决策

随着对话深入，AI 会累积项目上下文信息，关键决策和重要需求会在对话中自然沉淀。但记忆容量有限，超出限制 AI 就会"遗忘"早期内容。教程在 1.4.4 Context 管理技巧中给出了三层管理体系和具体模板，是维持长对话质量的关键手段。

与 Spec Coding 的区别：需求确定性，而非表达长度

Vibe Coding 与 Spec Coding 的关键差异在于需求的确定性，而不是表达的长度：

Vibe Coding：需求模糊，通过对话逐步澄清（动态澄清）
Spec Coding：需求明确，按规范执行（静态描述）

这里有一个常见的误解需要澄清：Vibe Coding 的对话往往比 Spec 文档更长，但它的重点是"动态澄清"而非"静态描述"。区别不在于谁的字数多，而在于需求是从对话中逐步长出来的，还是在一开始就被完整定义的。两者是连续谱上的两个端点，实际项目中经常混合使用——整体架构用 Spec、具体功能用 Vibe，是教程推荐的典型组合模式（见 1.4.3 如何选择和切换）。

适用场景

Vibe Coding 并非万能，它最适合以下几类场景：

产品想法验证：快速做出原型测试用户反应，用最小成本判断方向对不对
个人工具开发：满足自己特定需求的小工具，需求只有你自己清楚，无需对外对齐
学习实验：通过实际项目学习编程概念——在迭代中理解"数据怎么存、页面怎么改、功能怎么加"
创意项目：需求不明确、需要探索创新，边做边找到真正想要的东西

判断一个项目是否适合 Vibe Coding，可以从三个维度快速自检：需求是否模糊（模糊则倾向 Vibe）、复杂度是否较低（简单则倾向 Vibe）、是否是个人或探索性项目（是则倾向 Vibe）。完整判断框架见 1.4.3 如何选择和切换。

使用技巧：让多轮对话高效推进

开始对话

描述核心功能，不要纠结细节：第一轮只交代"要做什么"，把"怎么做"留给 AI 探索
接受第一个版本的不完美：首版的目标是"能跑起来"，不是"惊艳全场"
重点关注核心逻辑是否正确：先确认主干功能对不对，再谈样式和细节

这一点与教程 1.3 节的目标设定完全一致："第一次生成的目标不是惊艳全场，而是先出来一个能看、能点、能聊的版本"（见 1.3 在平台里生成你的第一个版本）。

迭代过程

每次只调整 1-2 个功能点：一次改太多会让修改范围失控，难以定位问题
用具体的例子说明问题：模糊的"这个功能有问题"远不如"点击保存按钮后页面无反应，控制台报错 X"有用
保留重要的决策记录：关键取舍要能追溯，否则后期对话中容易反复横跳

进阶工作流文档提供了更结构化的提示词写法：直接描述任务（不要角色扮演）、给出明确上下文（文件路径 + 具体报错）、提供约束与出口（"如果不确定，请明确说'我不确定'，而不是编造答案"），详见 2.2 VibeCoding 工作流。

Context 维护

定期总结已完成的功能：每隔 10-15 轮对话，把"已完成功能 / 下一步重点"总结一遍
明确当前调整的重点：让 AI 知道这一轮只做什么
必要时重新开始对话避免混淆：功能开发、Bug 修复、架构讨论分开建对话；当对话超过 15-20 轮、AI 开始重复错误理解或任务方向重大变化时，就是开新对话的信号

具体的模板与检查清单可以参考 1.4.4 Context 管理技巧。在命令行型 AI 工具中，还可以用/clear清空上下文、用/compact压缩对话、用检查点快速回退，这些都是在长迭代中保护 Context 质量的工程化手段。