两版 PRD 对比，先按需求编号或同一业务对象对齐，再区分新增、删除、规则改变和仅措辞调整。逐字红绿差异能告诉你哪里改了，却不能直接说明产品行为是否改变。用 AI 辅助时，要求每项差异同时引用新旧原文、说明行为影响并列出未决问题，最后形成一张可评审的变更表。
若还在选择文档起草工具，可先比较PRD生成工具的输入、编辑与导出能力，确保后续版本能够继续修改和对照。
为什么红绿差异还不够
“允许在预约前 24 小时取消”改成“距离预约至少 24 小时可取消”，字面变化很大，行为可能没变；“至少 24 小时”改成“超过 24 小时”，只差几个字，边界却发生变化。PRD 对比应从规则生效条件出发，而不是把修改字符最多的段落当成最重要变更。
| 看到的文字变化 | 先判断什么 | 可能的结果 |
|---|---|---|
| 同一段从第 3 节移到第 5 节 | 是否仍描述同一对象与规则 | 位置调整，不算新增需求 |
| 新增“至少”“仅”“最多”等限定 | 边界或允许范围是否改变 | 可能是实质规则变化 |
| 删除一段说明 | 删除的是功能、重复解释还是过期示例 | 不能一律写成功能下线 |
| 替换按钮名称 | 文案变化是否同时改变动作或承诺 | 可能仅改措辞，也可能改变用户预期 |
| 字段从“选填”变“必填” | 哪些流程会被阻断，旧数据如何处理 | 行为和兼容问题都需要确认 |
本次任务只对两份文档的差异负责。差异确认后，再把变更传给原型、研发与测试；完整协作关系可以参考PRD、原型与代码的一致性方法。不要在一开始就让 AI 同时重写需求、改页面和生成代码，否则很难核对变化来自哪里。
先固定两个版本与比较范围
把基线版和目标版分别保存，不让 AI 边比边覆盖原稿。记录文件名、版本号、确认状态及负责人；若文档中一半是正式规则、一半是讨论草稿，先标记范围。文件“更新得更晚”不代表所有内容都已经批准。
00_context/comparison-scope.md
01_sources/prd-v1.md
01_sources/prd-v2.md
02_working/change-table.md
02_working/questions.md
比较范围：预约取消规则与相关提示。
基线：prd-v1.md，已确认。
目标：prd-v2.md，待评审。
本轮只对比文档，不修改任何源文件，不决定是否接受新规则。
有需求编号则按编号对齐；无编号时按角色、对象、动作与状态匹配。
保留新旧原文证据，无法对应的段落列出候选，不强行合并。Word、PDF 或从协作平台导出的内容，最好先确认正文、表格、批注是否完整。扫描件或复杂表格可能在转换时丢行；AI 没读到某段，不等于目标版删除了它。整理方式可沿用本地项目的来源标记。
一组短 PRD，包含四种变化
下面用预约取消作为练习，两份文本可以直接保存后比较。数字只属于练习规则，不代表任何产品实际政策。
# prd-v1.md
R-01：距离预约开始时间至少 24 小时，用户可以自行取消。
R-02：取消成功后，页面展示“预约已取消”。
R-03：每位用户每天最多创建 3 个预约。
R-04：取消原因必须填写。
# prd-v2.md
R-03：每位用户每天最多创建 3 个预约。
R-01：距离预约开始时间至少 12 小时，用户可以自行取消。
R-02：取消成功后，页面显示“已取消预约”。
R-05：取消后，原预约时段重新开放。注意 R-03 只是移动位置，R-02 调整了文字，而 R-04 在目标版中不再出现。这四个现象需要不同处理，不能一律标成“需求变更”。
| 编号 | 分类 | 新旧证据 | 应写出的影响 |
|---|---|---|---|
| R-01 | 规则改变 | 至少 24 小时 → 至少 12 小时 | 距离开始 12～24 小时之间的预约，从不可自行取消变为可取消；含边界需按“至少”理解并确认时间口径 |
| R-02 | 仅措辞调整 | “预约已取消” → “已取消预约” | 当前文字未改变成功状态或取消动作；同步显示文案即可 |
| R-03 | 位置调整 | 规则内容完全相同，只换顺序 | 不新增实现工作，保留映射 |
| R-04 | 目标版缺失，待确认 | v1 有“取消原因必须填写”，v2 无对应条目 | 不能直接认定变为选填；可能是遗漏、移至别处或取消该要求 |
| R-05 | 新增 | 目标版增加“原预约时段重新开放” | 新增释放时段要求；释放时点与失败处理未说明 |
一条提示词，让差异结果带上证据
请只读取 comparison-scope.md、prd-v1.md、prd-v2.md。
第一步：列出两版的需求编号及对应段落，保留没有匹配到的条目。
第二步：按新增、目标版缺失、规则改变、措辞调整、位置调整分类。
第三步：每项附 v1 原文、v2 原文、行为影响与待确认问题。
不要只比较字数；检查角色、时间、次数、金额、权限、前置条件与异常结果。
“目标版缺失”先写待确认，不自动解释为功能删除。
仅文案和位置调整，不擅自增加实现任务。
没有编号时先给出业务对象匹配表，存在多种可能就列候选。
输出 change-table.md 与 questions.md，不修改源文件。如果 AI 直接给出“大幅提升灵活性”“显著优化体验”等判断，让它回到具体条件：哪些输入原来不允许、现在允许，哪个角色受到影响，哪种状态还没有说明。这些内容才支持评审决定。
用三个边界时间检查规则有没有读反
对 R-01 可以挑三个时间点作人工核对，而不必马上生成整套测试用例。假设其余前置条件相同、时间以同一时区和服务端口径计算：
| 距离开始时间 | v1：至少 24 小时 | v2：至少 12 小时 |
|---|---|---|
| 恰好 24 小时 | 允许 | 允许 |
| 恰好 12 小时 | 不允许 | 允许 |
| 11 小时 59 分 | 不允许 | 不允许 |
这张小表帮助确认差异含义，不替代对权限、预约状态和技术实现的完整检查。若 AI 把“至少 12 小时”写成“超过 12 小时”，恰好 12 小时这一行就能暴露误读。差异通过评审后，再按AI 测试用例方法扩展检查。
没有需求编号，也可以对齐，但要留下不确定项
旧 PRD 常常没有编号。先用“角色＋业务对象＋动作＋状态”组合定位，例如“预约用户／预约／取消／未开始”。标题相似只能作为候选：同一个“取消”可能分别指取消预约、取消支付或关闭弹窗。对齐后再给本轮临时编号，并保留原章节名，方便回到文档核对。
| 情况 | 处理方法 |
|---|---|
| 一段旧规则拆成三段新规则 | 允许一对多映射，逐条判断是否仅拆分表达 |
| 两段合成一段 | 检查限定条件是否完整保留，不能只看主题相同 |
| 同一表格中的必填列消失 | 核对导出是否丢列，再询问业务是否取消要求 |
| 示例与正文冲突 | 把两个证据并列，询问哪一处为准，不自行修成一致 |
| 目标版未写异常处理 | 标记覆盖缺口，不补造客服或退款承诺 |
如果文档采用 Markdown 并使用 Git，可以用Git diff查看两个版本的文字差异作为定位入口。文本对比、业务语义判断和最终评审是三件事：前者提供线索，AI 帮助归类，负责人决定新规则是否成立。
最后交付一张变更表和一份待决清单
# 待确认问题
Q-01 / R-04：取消原因在 v2 缺失，是改为选填、取消收集，还是文档遗漏？
Q-02 / R-05：时段在取消成功后立即释放，还是待其他步骤完成后释放？
Q-03 / R-01：时间按哪个时区与时间源计算？恰好 12 小时是否明确允许？
每项补充：负责人、答复、依据、是否纳入目标版本。
未答复的条目不得在变更表中改为“已确认删除”或“已完成”。能直接拿去评审的成果，应该让人看见“改了什么、根据什么、哪里还不清楚”。墨刀 AI 客户端适合处理本地两版文档并持续更新这张表；你可以下载客户端，先用上述短文档验证一次，再换成团队实际 PRD。
