直接回答：让 PRD 和原型保持一致，关键不是把两份文件写成一样，而是建立一条可追溯链：每条需求有唯一编号，每个页面、交互和状态都有明确来源，每次变更都记录影响范围，并在同一版本中完成复核。实际执行可以按“统一词典 → 需求编号 → 页面矩阵 → 状态表 → 双向追踪 → 变更闸门 → 回归评审”七步完成。
这套方法适合产品经理、交互设计师、研发和测试一起推进迭代，也适合用 AI 起草 PRD 或原型的团队。它解决的是持续同步、变更可控和评审可验证，不会替代接口协议、数据口径、性能和安全等仍需文字确认的工程要求。
一个容易被忽略的判断：原型不是 PRD 的插图，PRD 也不是原型的注释。两者应当是同一组产品假设的两种证据：PRD 负责说明规则和验收，原型负责展示路径和状态，评审负责确认它们指向同一个版本。
PRD 和原型保持一致，究竟要一致什么
“一致”不是页面文字和文档逐字相同，而是任何人都能回答三个问题：这条需求从哪里来？它在原型中怎样发生？发生变化后谁确认过？建议把一致性拆成三层，评审时分别打勾。
| 一致性层 | 检查对象 | 合格证据 |
|---|---|---|
| 语义一致 | 术语、字段、角色、需求编号、状态名称 | 业务词典和状态表中只有一个口径，例如“审核中”不会在页面上变成“处理中” |
| 行为一致 | 入口、触发条件、校验、权限、成功与异常反馈 | 原型中的按钮和页面状态能回指 PRD 规则，PRD 的每个分支都有页面或交互证据 |
| 证据一致 | 版本、变更原因、评审结论、负责人和验收结果 | 需求追踪矩阵与变更账本能说明这一版为何这样做、由谁确认 |
如果只检查视觉稿是否“像 PRD”，很容易漏掉权限、空状态、失败重试和不可逆操作。真正的同步目标，是让需求、流程、页面、状态和验收证据形成闭环。
为什么 PRD 和原型会逐渐不同步
不同步通常不是某个人粗心，而是协作链缺少“变化经过哪里”的约定。以下四类问题最常见：
- 词汇漂移：PRD 写“审核中”，流程图写“处理中”，原型写“等待结果”，团队不知道它们是否代表同一状态。
- 单向更新：产品改了规则却没有通知设计，或者设计新增了页面但没有回写需求范围。
- 只画主路径：原型展示成功流程，PRD 中的权限、超时、失败、撤销和重复提交没有落到页面。
- 版本没有基准：评论散落在多个链接和群聊里，评审结论没有绑定到具体 PRD 与原型版本。
解决办法不是要求大家“记得同步”，而是让同步变成可检查的产物：编号、矩阵、状态表和变更记录。
七步建立 PRD—原型一致性闭环
第 1 步：冻结本轮范围和唯一基准版本
在开始画页面前，先写清本轮要验证什么、暂不验证什么，以及评审使用的 PRD 和原型版本。范围至少包含目标用户、核心任务、端（Web、App 或后台）、评审对象和截止时间。
建议在 PRD 顶部保留一行版本信息：版本号｜更新时间｜负责人｜本轮变更｜关联原型链接。如果需求仍在讨论，标记为“草案”，不要让草案原型直接进入开发评审。
第 2 步：先统一业务词典和状态表
把容易产生歧义的词集中定义。业务词典写清字段含义、单位、可见角色和取值；状态表写清进入条件、允许操作和退出条件。状态表不是附录，而是原型交互的约束。
| 状态 | 进入条件 | 允许操作 | 退出条件与页面反馈 |
|---|---|---|---|
| 待提交 | 用户填写信息但尚未确认 | 编辑、删除、提交 | 提交成功进入“审核中”；缺少必填项时保留当前页并提示 |
| 审核中 | 系统已创建申请并等待处理 | 查看进度、撤回（若规则允许） | 审核通过或驳回；页面显示时间和当前处理节点 |
| 驳回 | 审核不满足规则 | 查看原因、修改后重新提交 | 重新提交后回到“审核中”，旧结论保留在记录中 |
状态命名一旦确定，PRD、流程图、原型文案和测试用例都使用同一套词。不要让设计师通过改文案来“修复”未确认的业务定义。
第 3 步：给需求、规则和验收条件加唯一编号
编号可以很简单，例如 REFUND-01、REFUND-02。关键是编号要稳定、可引用，并且能区分功能需求、业务规则和验收条件。评审时说“REFUND-03 的上传失败状态缺失”，比说“这里好像少了点东西”更容易行动。
推荐的编号写法是“模块-序号-类型”，例如 REFUND-03-R 表示退款模块的第 3 条规则，REFUND-03-A 表示对应验收条件。不要在每次改文案时重新编号；若需求废弃，保留编号并标记状态，避免历史评论失去上下文。
第 4 步：用页面矩阵把需求映射到原型
页面不应按 PRD 章节数量机械生成，而应按用户任务和状态拆解。一个任务可以包含页面、弹层和结果页；当角色、权限、操作对象或状态明显变化时，再拆出独立页面。
| 需求编号 | 用户任务 | 页面/弹层 | 关键组件与操作 | 异常或权限 |
|---|---|---|---|---|
| REFUND-01 | 查看订单是否可退款 | 订单详情 | 退款入口、可退款金额、时效提示 | 订单已超过期限时隐藏入口并说明原因 |
| REFUND-02 | 提交退款申请 | 退款申请页 | 原因选择、金额校验、凭证上传、确认提交 | 金额超限、必填缺失、上传失败 |
| REFUND-03 | 跟踪处理结果 | 退款进度页 | 节点时间、当前状态、处理说明 | 审核驳回、超时、重复提交 |
页面矩阵的作用是把“需求范围”变成“可点开的清单”。它还能发现两种反向问题：有规则却没有页面证据，或原型里出现了没有 PRD 来源的页面。后者应标为“范围外待确认”，不能默认为需求。
第 5 步：把流程、交互和状态做双向追踪
很多团队只做“PRD → 原型”的单向映射，却忽略“原型 → PRD”的反查。双向追踪至少要覆盖：用户动作、系统响应、页面跳转、权限判断、异常反馈和状态变化。
检查时沿两条路径走一遍：
- 从 PRD 出发：逐条读取需求编号，找到对应页面、组件、触发动作和状态；找不到就标记“原型缺口”。
- 从原型出发：逐页点击入口和按钮，回指需求编号与规则；找不到来源就标记“新增待确认”。
这一步能识别“页面看起来完整，但关键规则没有落地”的假完整，也能阻止 AI 或设计稿擅自扩展业务范围。
第 6 步：设置变更闸门，先分析影响再改两份材料
需求变化是常态，真正危险的是变化没有经过同一个闸门。每次变更先回答四个问题：改了什么？为什么改？影响哪些页面/状态/角色？怎样验收？
| 变更等级 | 典型例子 | 必须同步的内容 | 评审方式 |
|---|---|---|---|
| 高风险 | 权限、金额、数据状态、不可逆操作变化 | PRD规则、流程图、原型页面与异常状态、测试条件 | 产品、设计、研发、测试共同确认 |
| 中风险 | 新增分支、调整页面顺序或角色任务 | 页面矩阵、原型跳转、状态表和验收条件 | 产品与设计先走查，再通知研发 |
| 低风险 | 文案、间距、图标或展示顺序调整 | 原型和受影响的文案/验收描述 | 负责人确认并留下记录 |
可以复制下面的变更账本作为团队约定：
| 变更编号 | 原因 | PRD位置 | 受影响页面/状态 | 负责人 | 验收结论 |
|---|---|---|---|---|---|
| CHG-001 | 退款期限由 7 天调整为 3 天 | 退款规则-02 | 订单详情、申请页、超时状态 | 产品/设计 | 待回归 |
| CHG-002 | 驳回后允许补充材料 | 处理结果-03 | 驳回页、上传弹层、重新提交路径 | 产品/研发 | 已确认 |
只有当账本中的受影响范围、版本和验收结论都补齐，变更才算关闭。这样可以把“改了一个字段”对多个页面的连锁影响显式化。
第 7 步：发布前做一次差异回归，而不是从头重读
回归评审只看本轮变更和它的影响面，效率更高，也更容易发现遗漏。建议由产品主持，设计、研发和测试分别从自己的证据出发检查：
- 产品：需求编号、业务规则和验收条件是否是同一版本。
- 设计：页面、交互、状态、文案和权限是否覆盖矩阵。
- 研发：接口依赖、数据口径、异常反馈和不可实现项是否已标注。
- 测试：成功、失败、空、加载、无权限、重复提交和边界值是否都有可验证条件。
可复制的需求追踪矩阵
下面的列足以支撑一轮中小型迭代；复杂项目可以继续增加接口、埋点和测试用例列。
| 需求ID | 角色/场景 | 规则与验收 | PRD锚点 | 原型页面/状态 | 版本 | 负责人 | 结论 |
|---|---|---|---|---|---|---|---|
| REFUND-02-R | 会员提交退款 | 超过期限不可提交并说明原因 | 退款规则-02 | 订单详情-超时、申请页-提交按钮 | v1.3 | 产品/设计 | 通过/待补/阻塞 |
| REFUND-03-A | 审核驳回后补交材料 | 补交成功后回到审核中 | 处理结果-03 | 驳回页-上传弹层-审核中 | v1.3 | 产品/研发 | 待回归 |
“通过”表示需求覆盖、规则一致且结果可验证；“待补”表示规则已明确但原型缺证据；“阻塞”表示规则本身尚未确认。把三种结论分开，才能避免设计替产品决策，也避免研发带着未确认的规则开工。
示例：用退款申请验证一次同步
假设 PRD 规定：“已付款且未超过 7 天的会员订单可申请退款；用户选择原因并确认金额后提交；金额超过实付金额时不可提交；申请进入审核中后展示处理节点；驳回时必须展示原因并允许按规则补交材料。”
先为这段需求拆出 REFUND-01 到 REFUND-04，再检查原型是否同时出现：
- 订单详情页的可申请/不可申请入口与时效说明；
- 申请页的原因、金额、凭证和提交校验；
- 审核中的进度节点和等待反馈；
- 驳回原因、补交材料和重新提交后的状态回退。
如果原型只画了“填写表单—提交成功”，它并没有完成这条需求。问题不是页面数量少，而是行为证据不足。反过来，如果原型新增“极速退款”按钮，却没有 PRD 规则和验收条件，也应先放入待确认清单，不能直接交付。
如何用 AI 做一致性审计
AI 适合做逐条比对和整理缺口，不适合在 PRD 与原型冲突时自行决定业务规则。把 PRD、原型页面清单或截图作为输入，要求它只输出“缺失、冲突、过期、待确认”，并标明证据位置。
请对照这份 PRD 与原型页面清单，建立“需求ID—页面—交互—状态—验收证据”追踪表。逐条列出：1）原型缺失的需求；2）原型新增但 PRD 没有来源的页面或规则；3）PRD 与原型冲突的术语、权限、条件和结果；4）可能已过期的版本。每项注明证据位置、影响范围、负责人和复核条件。不得自行新增或选择业务规则，无法判断时标记为“待产品确认”。
AI 输出仍要回到矩阵和变更账本中，由产品负责人确认。不要把“模型没有发现冲突”当成一致性证明，也不要把未经人工确认的生成内容直接交给研发。
在墨刀里如何把这套方法落到协作流程
可以先把需求、页面矩阵和状态表整理成结构化输入，再用墨刀 AI 生成可编辑原型起稿；随后在画布中补齐页面状态、交互说明和异常分支，使用预览和分享链接让产品、设计、研发共同走查。
如果需求本身还不完整，可先参考AI 生成 PRD补齐角色、规则、流程和验收，再回到追踪矩阵。需要逐条检查需求质量时，可以结合AI 需求评审列出矛盾和缺口；产品原型评审的方法可参考产品原型评审流程。
墨刀的在线编辑、预览、分享、评论和版本协作可以帮助团队把讨论留在同一条原型链路中，但它们不会自动替团队确认规则。同步的责任仍然属于需求负责人和评审参与者。
发布前 10 分钟一致性清单
- 本轮 PRD、原型和评审链接是否指向同一版本。
- 每条核心需求是否有唯一编号。
- 业务词典和状态表是否已冻结。
- 页面矩阵是否覆盖入口、核心页面、弹层和结果页。
- 每个按钮是否能说明触发条件、系统响应和下一状态。
- 权限、金额、时间、数据口径等高风险规则是否有证据。
- 空、错、加载、失败、无权限、重复提交是否有处理方式。
- 原型中的新增页面或规则是否已在变更账本中得到确认。
- 本轮变更是否完成影响分析，并同步到 PRD、流程、状态和验收条件。
- 评审结论是否写明通过、待补或阻塞，以及负责人和下一步。
常见问题
PRD 和原型谁应该先做
先明确目标、角色、任务和规则，再用原型验证路径与状态。两者可以迭代，但每轮都要有一个明确的基准版本，不能让“先画了再补文档”成为长期协作方式。
视觉稿和 PRD 看起来一致，就算同步了吗
不算。视觉一致只说明展示层接近，还要检查权限、校验、异常、状态和验收条件。一个好看的页面如果没有表达失败和边界，仍可能与 PRD 不一致。
需求临时变化，怎样避免全部返工
先用变更闸门判断影响面，区分高、中、低风险；只回归受影响的页面、状态和验收条件。保留需求编号和变更账本后，不需要每次从头重读整份 PRD。
没有流程图，能不能保持 PRD 和原型一致
可以，但至少要写清页面顺序、判断条件、成功结果和失败结果。若规则本身存在冲突，应先标记待确认，再开始画页面。
AI 能不能自动把 PRD 和原型同步
AI 可以帮助抽取需求、建立追踪表和发现疑似冲突，但不能替团队确认业务规则，也不能保证所有隐含约束都被识别。把 AI 当作审计助手，最终以负责人签署的版本和验收结论为准。
让 PRD 和原型保持一致，靠的不是增加文档数量，而是把需求编号、页面、交互、状态、变更和验收串成一条证据链。先统一词典，再做双向追踪；发生变化时走变更闸门，发布前做差异回归，团队就能在需求持续迭代的情况下保持同一套产品理解。
