核心结论：PRD、原型和代码保持一致，靠的不是评审时多看几遍，而是三件具体的事：给每条需求一个可追溯的编号，把需求写成可验证的界面约束，在变更发生时先做影响面分析再动手。做到这三点，团队才能随时回答“这条规则在原型哪个页面、代码哪个模块、由谁验收”。
本文面向产品经理、设计师和研发负责人，解决的是交付过程中的对齐问题，不讨论需求优先级和排期方法。如果PRD本身还停留在功能罗列，建议先补齐文档结构再进入本节的方法：PRD文档的结构与评审清单已经说明了背景、目标、范围、规则和验收标准的写法。
不一致通常发生在三个位置
先把问题定位清楚，比直接讨论“要不要重新评审”更有效。实际项目里的偏差集中在三处。
第一处是从需求到原型。PRD写“支持批量操作”，原型上画了一个批量按钮，但选中规则、可批量处理的数据范围、部分失败如何处理都没有落位。原型看上去完整，实际只承接了需求里的一个名词。
第二处是从原型到代码。原型是静态画面加跳转，研发必须自己补字段类型、状态机、接口入参和错误码。没有文字说明的部分，研发只能按经验判断，偏差在写代码时就已经产生，评审时看不见。
第三处是变更回流。需求调整后，原型更新了，但PRD条目、接口文档和已提交代码没有同步；或者研发在实现阶段发现了更合理的处理方式，直接改在代码里，没有反查回需求。两种方向都会让文档和实现互相脱节。
先建立需求编号，一致性的前提
可追溯的前提是每条需求有稳定标识。用标题当标识无法追溯，因为标题会在修改中被改写。建议采用“模块缩写-序号”的形式，例如APR-003代表审批模块第三条需求，编号一旦分配不再复用，需求作废时标记为已废弃而不是删除。
每条编号至少要写清六件事，缺一项就说明它还不足以进入原型阶段。
| 字段 | 作用 | 缺失后果 |
|---|---|---|
| 触发条件 | 说明什么情况下这条规则生效 | 研发做出与业务不一致的判断 |
| 角色与权限 | 谁能看到、谁可以操作 | 越权入口在原型和代码里各写一套 |
| 操作动作 | 用户做什么、系统响应什么 | 只画出按钮，没有过程和反馈 |
| 结果与状态 | 成功、失败、处理中分别呈现什么 | 异常路径无人负责 |
| 例外与边界 | 数据缺失、超限、并发时如何处理 | 上线后才暴露规则冲突 |
| 验收标准 | 用什么证据判断完成 | 各方对“做完”的理解不同 |
PRD到原型：把需求写成可验证的界面约束
从PRD到原型的转换，本质是把“业务规则”翻译成“界面可见的约束”。同一条需求，不同写法带来的偏差完全不同。
| 需求写法 | 原型需要呈现 | 验证方式 |
|---|---|---|
| 支持按条件筛选申请 | 筛选项、默认值、无结果状态 | 用一条真实数据走通筛选并命中结果 |
| 超过金额需二次确认 | 阈值提示、确认弹窗、取消后状态 | 分别用低于和高于阈值的数据各走一遍 |
| 附件上传失败可重试 | 失败原因、已填内容保留、重试入口 | 模拟失败后检查是否重新提交成功 |
转换阶段的常见错误，是把原型当成需求的可视化副本：原型上有的内容在PRD里找不到出处，PRD里的规则在原型上没有承接。建议在评审前做一次双向核对，把“原型有、需求无”和“需求有、原型无”的条目分别列出来，AI补充但未确认的内容统一标记为待确认。
如果PRD结构完整但页面、流程和状态还没有拆出来，可以按从PRD提取页面、流程和状态的方法先把结构铺开，再逐条绑定需求编号。原型完成后进入团队验收，结构、交互、状态和业务规则四层要分别确认，可沿用AI原型评审清单里的四层门禁和追踪表结构。
原型到代码：交付前确认字段、状态与接口
原型能表达布局和跳转，但表达不了数据结构和系统行为。交付前需要补齐三份清单，让研发不需要靠猜。
字段清单说明每个字段的名称、类型、来源、是否必填、校验规则和长度限制。状态清单说明页面和组件在默认、加载、空、错误、无权限、处理中和成功条件下分别呈现什么，进入条件和退出条件写清楚。接口清单说明触发时机、入参、返回结构、错误码和失败后的用户可见结果。
这三份清单不需要写成长文档，但必须是明确可核对的表格。原型里表达不了的规则，例如并发提交、超时重试、数据脱敏、批量操作中的部分失败，都应写在说明里；只写“研发自行处理”，等于把业务判断交给了实现方。
如果团队采用设计稿转代码的方式，交付物还要对齐组件命名和样式变量，具体检查项可参照设计稿转代码的完整流程，避免同一按钮在原型和代码里出现两套命名。
变更来了怎么回流
变更不是一致性问题的例外，而是常态。判断变更是否已经回流完成，问四个问题就够：影响了哪几条需求编号、涉及哪些页面和状态、需要改动的代码模块有哪些、已经交付或已测试的内容是否需要回归。
建议给每次变更单独编号，并记录它关联的原需求编号、影响范围、处理动作和回归结论。这样在版本发布前可以按变更编号清点，而不是靠回忆“上次那个改动改完没有”。
多地或多角色协作时，变更讨论容易散在聊天记录里。把每轮变更定位到具体页面和状态，可以让确认过程留下版本记录，这类做法在远程评审的版本与评论方法中有更细的说明。
用三向对照表验证一致性
一致性不是一次性的检查项，而是持续维护的对照关系。三向对照表只保留四列：需求编号、原型证据、代码模块、验收状态。
原型证据写具体页面和状态，例如“审批列表-空状态”，不要写“原型已完成”；代码模块写到可定位的粒度，例如页面、组件或接口名称；验收状态只用三种：通过、缺失、待定。“缺失”表示原型或代码中确实没有这项内容，“待定”表示有内容但规则未确认，两者不能混用，因为前者要补做，后者要先决策。
这张表由谁维护也需要约定。可行做法是产品维护需求编号与验收状态，设计维护原型证据，研发维护代码模块，任何一列变化都在同一次变更里更新，而不是留到版本发布前集中补。
一致性检查清单
- 每条需求是否有稳定编号，且不再复用已废弃编号？
- 需求编号是否写清触发条件、角色权限、操作、状态、例外和验收标准？
- 原型上出现的每个页面和状态，是否都能对应到需求编号？
- PRD里存在但原型未承接的规则，是否已列出并处理？
- 原型未确认的AI补充内容，是否标记为待定并指定负责人？
- 交付前是否补齐字段清单、状态清单和接口清单？
- 变更是否单独编号并写明影响的需求、页面和代码模块？
- 三向对照表中是否还有“缺失”或“待定”未关闭？
- 回归验证是否使用原任务，而不是只看页面是否更整齐？
常见问题
小团队也必须给需求编号吗？
需要，但可以简化。两三个功能的项目用“模块缩写-序号”就足够，关键不是编号格式，而是每次讨论和变更都指向同一个标识。没有标识时，口头约定无法在两周后复查。
原型和代码不一致时，应该以谁为准？
以需求编号对应的确认为准，而不是以某一份产物为准。原型更接近业务意图，代码更接近实际实现，出现冲突时应回到需求条目确认预期行为，再决定改原型还是改代码，并把结论写回对照表。
AI生成原型会让一致性更难还是更容易？
取决于使用方式。AI能在很短时间内产出大量页面，如果没有需求编号约束，偏差会成倍增加；反过来，把确认过的规则作为输入、把生成结果逐条挂到需求编号上，补齐页面和状态的速度会明显提升。判断标准始终是这条页面能否追溯到一条已确认的需求。
一致性的本质是可追溯：需求有编号、原型有证据、代码有归属、变更有着落。把这四件事固定成日常动作，团队就不必在发布前靠人肉比对，也能在需求发生变化时快速判断影响范围。
