Vibe Coding 方法论 · 第 2 节

四步流程：复述、PRD、确认、编码

把软件工程的需求确认环节搬进人机协作：AI 动手之前必须复述需求、写出 PRD、拿到明确许可。再加上批量修改断点和查重规则，把爆炸半径控制在动手之前。

交互演示一 · 五步流程模拟器

一个真实需求「帮我加一个导出报表功能」，走一遍完整流程。点击「推进一步」，注意第 4 步：你不点「批准」，AI 就不会写代码。

STEP 1

思考提问

STEP 2

复述需求

STEP 3

编写 PRD

STEP 4

等待许可

STEP 5

开始开发

点击「推进一步」开始

为什么必须给具体步骤

「请先确认理解后再编码」这句话太模糊。AI 会自己判断「我已经理解了」，然后直接动手。写明「写 PRD、等待许可」这类具体动作，AI 才会真的停下来。实际使用中，简单的一行改动 AI 会自己判断不需要 PRD，这套流程主要拦截多文件变更和新功能开发，也就是返工成本最高的那类任务。

交互演示二 · 批量修改断点

规则原文：「修改超过 3 个文件时，必须先列出修改计划并等待用户确认后再动手。」拖动滑块，改变本次要动的文件数，看断点什么时候触发。

本次要改的文件数

2 个文件

修改计划的三要素

完整的文件清单。人先看范围对不对，再看内容。清单本身就能暴露「怎么这个需求要动配置文件」这类异常。

逐文件写清楚改动内容。避免 AI 借着一次需求「顺手」做无关的重构和清理。

先改哪个、后改哪个、谁依赖谁。防止连续改一串文件后发现思路有误，回滚成本过高。

阈值可以按项目调整：3 个文件是作者项目里的经验值，谨慎的项目可以调成 1，快速原型可以放宽到 5。

新增功能前的查重规则

AI 的上下文只有当前对话，它看不到三个月前另一个对话里写的工具函数。不加约束，同一个 formatDate 会被写四遍，每遍行为还略有不同。

本节要点

断点要设在动手之前。复述和 PRD 拦截理解偏差，修改计划拦截连锁错改，查重拦截重复造轮子，三道关卡都比事后回滚便宜。

素材来源：对应 rule-opensource.mdc 第二章「需求处理与开发流程」，仓库 itshen/xs_vibe_rules。