Vibe Coding 通常指用自然语言与 AI 交互、迭代生成软件的开发方式。这个词的使用范围并不统一：有人用它描述以运行结果为主、不逐行理解生成代码的尝试，也有人用它泛指 AI 辅助开发。
本文采用较宽的语境，介绍一种适合小型原型的做法：由人确定需求、检查改动并验收结果。下面是流程概览，不是一份包含环境配置、数据库和部署命令的完整上线教程。
先分清概念与做法
自然语言输入是这种方式的特点；版本控制、权限检查和验收则是本文建议加入的工程措施，不能把它们当作这个词唯一的定义。
工具可以帮助查找文件、修改代码和运行命令，但能读多少上下文、能执行哪些操作，取决于具体产品、模式、项目和权限。生成成功不代表逻辑正确，也不代表适合部署到生产。
开始前先判断：你能否识别任务的主要错误，能否检查相关改动，能否在失败时恢复？如果不能，先缩小原型范围，或找能审查这部分代码的人协助。
阶段一：需求收敛，写到能说出「不做什么」
典型失败点：需求里全是形容词——好看、流畅、高级、有质感。模型接不住形容词，只能自己补，补出来的通常不是你要的那个。
对策是换成可观察的描述。「做一个好看的作品列表」改成「每行显示标题、作者、状态标签；一行不超过三行文本；列表为空时显示一句引导语」。
再加一句边界：这一版不做搜索、不做筛选。写在需求里，比事后删代码省事。
阶段二：先写验收标准
这是整条流程里最常被跳过的一步，也是真正决定成败的一步。
验收标准就是 3 到 6 条你能当场验证的句子：
- 上传一张图片后，列表里能看到它
- 删除后刷新页面，它不会回来
- 未登录点击发布，跳到登录页，而不是报错
每条都对应一个动作和一个预期结果。写不出来，说明需求还没收敛，先回去做阶段一。
这几条还有第二个用途：直接贴进提示词。这样可以让目标更明确，也方便发现遗漏或超出范围的改动；仍需检查实际输出。
工具会影响操作方式，但需求不明确时，换工具无法代替验收标准。
阶段三：拆成能单独验证的小任务
一个任务，一次改动，一个可验证的结果。
反例很典型：一次让 AI 把登录、数据库、页面一起加上。它会给出一大段看起来对的代码，你改了三处，然后不知道哪一处导致页面白屏。
对策是把任务切到「做完就能跑」的粒度，哪怕功能不全，项目也要保持在能启动的状态。这样每次出错，可疑范围只有一块。
举个例子。「加登录」拆成四步：有登录页且能提交；提交后校验账号；校验通过进入首页；未登录访问首页跳回登录页。四步都能单独跑，也都能单独撤销。
阶段四：生成与局部替换
给模型明确的任务范围，例如“修复这个组件的提交状态，保持现有接口合同”。如果修改需要联动调用方、测试或样式，应先说明原因和文件清单，避免把必要修改限制在错误的边界内。
典型失败点：它顺手重写了整个文件，把不相关的部分也改了。你以为是新 bug，其实是旧代码被覆盖。
对策很土但有效：文件小一点；要求输出完整函数而不是片段，方便整段替换；每次替换前先提交一次。
至于这一轮该在编辑器里改，还是交给终端代理跑一遍，判断依据是任务形态不是功能表——AI 编程工具怎么选这篇拆过一遍。
阶段五：验证与回滚
验证不是「看起来没问题」，是把阶段二那几条逐条走一遍，写下结果：通过、不通过、没测到。
回滚靠提交点。为可独立验证的改动保留提交或备份。恢复前检查是否还有其他未保存的工作；涉及数据库或文件写入时，代码回退不能代替数据恢复。
一种值得避免的情况是：连续改十轮之后，才发现第一轮就错了，而那时已经没有干净版本可退。
「没测到」这一类要单独写下来，不要混进「通过」。下次打开项目，你会先看到它，而不是重新猜一遍哪里没试。
每一步留下什么
- 需求：可观察的目标与本次范围。
- 验收：关键动作及预期结果。
- 任务：可独立检查的修改单元。
- 实现：改动差异、相关调用方和恢复点。
- 验证：通过、失败和未测试项，以及对应证据。
什么项目不适合这么做
- 强合规场景：金融、医疗、涉及资质与责任主体的功能，需要审计链路和明确的人。AI 生成的代码没有这个属性。
- 强性能要求：瓶颈在哪要靠 profiling 和你的真实数据，模型看不到你的数据。
- 需求本身没有验收标准：连你都说不清「对」是什么，AI 只会把它放大。
- 多人长期维护的核心系统：风格、边界、异常处理要人兜底，生成速度换不来维护成本。
一次性原型、内部小工具、验证想法的 Demo，是最适合的场地。做成之后要不要重写，是另一个决定，别在这一步纠结。
把过程留下来，才有下一次
流程跑完，除了代码，还值得保留你为什么这么选、哪句提示词起了作用、哪一步真的验证过。这三样，正好对应构建记录模板里最容易被跳过的部分，照着填就行。
造个啥的广场可以查找公开记录；是否跑通应核对具体证据，四段式则是一种便于整理信息的建议。也可以去方法与工具翻同类记录。
本文建议的起点是：先把验收要求定义清楚，再让 AI 动手。下次开工前，先把这次流程写成一条构建记录，少走一遍比多写一篇总结有用。
进一步核对
概念背景可参考 Google Cloud 对 Vibe Coding 的介绍；拆小任务、提供上下文与审查输出的建议可参考 GitHub Copilot 最佳实践。本文示例是方法说明，没有作为已上线项目的实测结果。
社区讨论 0 条观点