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