开场：把软件工程的需求确认环节搬进人机协作
AI 动手之前必须复述需求、写出 PRD、拿到明确许可。 再加上批量修改断点和查重规则，把爆炸半径控制在动手之前。
一句话速览：把需求确认环节搬进人机协作，批量修改先列计划，新功能先查重。
一、五步流程：从思考到编码的完整闸门
一个真实需求「帮我加一个导出报表功能」，走一遍完整流程：
STEP 1 · 思考提问 → STEP 2 · 复述需求 → STEP 3 · 编写 PRD → STEP 4 · 等待许可 → STEP 5 · 开始开发
关键在 STEP 4：拿到明确许可前，禁止编码
用户：帮我加一个「导出报表」功能
AI：收到。动手前我有三个问题：导出格式要 CSV 还是 Excel？数据量最大多少行？要不要带上当前的筛选条件？
用户：Excel，最多 5 万行，带当前筛选条件
AI 复述：「我理解为：在报表页新增导出按钮，按用户当前的筛选条件导出 Excel，上限 5 万行，超出时提示分批导出。这个理解和你的预期一致吗？」
PRD.md · 报表导出功能
目标：按当前筛选条件导出 Excel，上限 5 万行。
改动文件：ReportPage.tsx、exportApi.ts、routes/export.py
流程图：点击导出 → 行数 ≤ 5 万？→ 是：生成 Excel 并下载 / 否：提示分批导出AI：PRD 已生成。得到你的明确许可之前，我不会写任何代码。
许可已给出，才推进到开发阶段。
二、为什么必须给具体步骤
「请先确认理解后再编码」这句话太模糊。AI 会自己判断「我已经理解了」，然后直接动手。写明「写 PRD、等待许可」这类具体动作，AI 才会真的停下来。
实际使用中，简单的一行改动 AI 会自己判断不需要 PRD。这套流程主要拦截多文件变更和新功能开发，也就是返工成本最高的那类任务。
三、批量修改断点：超过 3 个文件，先列计划
规则原文：「修改超过 3 个文件时，必须先列出修改计划并等待用户确认后再动手。」
改动只涉及 2 个文件时未触发断点，直接放行——小范围修改属于可控风险，规矩的目的在于控制风险，简单改动不加仪式。
修改计划的三要素
- 要改哪些文件： 完整的文件清单。人先看范围对不对，再看内容。清单本身就能暴露「怎么这个需求要动配置文件」这类异常。
- 每个文件改什么： 逐文件写清楚改动内容。避免 AI 借着一次需求「顺手」做无关的重构和清理。
- 改动之间的依赖关系： 先改哪个、后改哪个、谁依赖谁。防止连续改一串文件后发现思路有误，回滚成本过高。
阈值可以按项目调整：3 个文件是作者项目里的经验值，谨慎的项目可以调成 1，快速原型可以放宽到 5。
四、新增功能前的查重规则
问题： AI 的上下文只有当前对话，它看不到三个月前另一个对话里写的工具函数。不加约束，同一个 formatDate 会被写四遍，每遍行为还略有不同。
规则：先搜索，再动手。 新增功能前，必须先搜索项目中是否已有类似实现——范围包括相关目录的函数名、类名、工具方法；找到已有实现时，优先复用或扩展。
本节要点
断点要设在动手之前。 复述和 PRD 拦截理解偏差，修改计划拦截连锁错改，查重拦截重复造轮子，三道关卡都比事后回滚便宜。