四步流程：复述、PRD、确认、编码
把需求确认环节搬进人机协作，批量修改先列计划，新功能先查重
本页解决的问题
先给结论「四步流程：复述、PRD、确认、编码」要解决的关键问题是什么？
把需求确认环节搬进人机协作，批量修改先列计划，新功能先查重
把品味变成产品可重复的行为。 有用的结果不是一句“我觉得更好”。它应该是一条看得见的规则、一个小例子，以及判断体验何时低于标准的方法。
记录一个前后对比，让别人不用听解释也能看懂质量线。
表面更精致了，却没有减少用户的不确定感。
一个真实需求「帮我加一个导出报表功能」，走一遍完整流程。点击「推进一步」，注意第 4 步：你不点「批准」，AI 就不会写代码。
「请先确认理解后再编码」这句话太模糊。AI 会自己判断「我已经理解了」，然后直接动手。写明「写 PRD、等待许可」这类具体动作，AI 才会真的停下来。实际使用中，简单的一行改动 AI 会自己判断不需要 PRD，这套流程主要拦截多文件变更和新功能开发，也就是返工成本最高的那类任务。
规则原文：「修改超过 3 个文件时，必须先列出修改计划并等待用户确认后再动手。」拖动滑块，改变本次要动的文件数，看断点什么时候触发。
要改哪些文件
完整的文件清单。人先看范围对不对，再看内容。清单本身就能暴露「怎么这个需求要动配置文件」这类异常。
每个文件改什么
逐文件写清楚改动内容。避免 AI 借着一次需求「顺手」做无关的重构和清理。
改动之间的依赖关系
先改哪个、后改哪个、谁依赖谁。防止连续改一串文件后发现思路有误，回滚成本过高。
阈值可以按项目调整：3 个文件是作者项目里的经验值，谨慎的项目可以调成 1，快速原型可以放宽到 5。
问题：AI 不知道项目里已经有轮子
AI 的上下文只有当前对话，它看不到三个月前另一个对话里写的工具函数。不加约束，同一个 formatDate 会被写四遍，每遍行为还略有不同。
规则：先搜索，再动手
- 新增功能前，必须先搜索项目中是否已有类似实现
- 搜索范围：相关目录的函数名、类名、工具方法
- 找到已有实现时，优先复用或扩展
断点要设在动手之前。复述和 PRD 拦截理解偏差，修改计划拦截连锁错改，查重拦截重复造轮子，三道关卡都比事后回滚便宜。
素材来源：对应 rule-opensource.mdc 第二章「需求处理与开发流程」，仓库 itshen/xs_vibe_rules。
从「交互演示一 · 五步流程模拟器」把感觉变成判断
「一个真实需求「帮我加一个导出报表功能」，走一遍完整流程。点击「推进一步」，注意第 4 步：你不点「批准」，AI 就不会写代码」指出，AI 降低了做出“能用”成品的门槛，读者真正需要练的是看出哪里不对，并把感觉说成可以执行的要求。
观察用户的下一步，而不是只看表面
「「请先确认理解后再编码」这句话太模糊。」可以转成几个可观察的问题：用户是否知道现在发生了什么，是否知道下一步做什么，出错或空白时能否恢复，以及信息层级是否让重要内容先被看见。
- 新增功能前，必须先搜索项目中是否已有类似实现
漂亮不等于容易用
把「断点要设在动手之前。」用在第二个页面或流程上，记录一个具体犹豫点和一个改动后的用户动作；能被观察到的变化，才是体验改善。
从「交互演示一 · 五步流程模拟器」走到「为什么必须给具体步骤」
「交互演示一 · 五步流程模拟器」先把问题落在「一个真实需求「帮我加一个导出报表功能」，走一遍完整流程。点击「推进一步」，注意第 4 步：你不点「批准」，AI 就不会写代码」上；到了「为什么必须给具体步骤」，讨论继续推进到「「请先确认理解后再编码」这句话太模糊。 AI 会自己判断「我已经理解了」，然后直接动手。写明「写 PRD、等待许可」这类具体动作，AI 才会真的停下来。实际使用中，简单的一行改动 AI 会自己判断不需要 PRD，这套流程主要拦截多文件变更和新功能开发，也就是返工成本最高的那类任务」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
评估体验时，把抽象的“好看”或“顺手”换成用户动作：他是否看懂状态、找到了下一步、能从错误中恢复，并且愿意继续使用。
- 「交互演示一 · 五步流程模拟器」：一个真实需求「帮我加一个导出报表功能」，走一遍完整流程。点击「推进一步」，注意第 4 步：你不点「批准」，AI 就不会写代码
- 「为什么必须给具体步骤」：「请先确认理解后再编码」这句话太模糊。 AI 会自己判断「我已经理解了」，然后直接动手。写明「写 PRD、等待许可」这类具体动作，AI 才会真的停下来。实际使用中，简单的一行改动 AI 会自己判断不需要 PRD，这套流程主要拦截多文件变更和新功能开发，也就是返工成本最高的那类任务
- 「最后的要点」：新增功能前，必须先搜索项目中是否已有类似实现
最后的「最后的要点」把讨论落到「新增功能前，必须先搜索项目中是否已有类似实现」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。