产品原型评审的依据可以归为四类：需求与目标材料、方案材料、约束材料、决策材料。评审前按这四类收集并分发，评审中逐项对照记录结论，评审后把分歧转成带责任人和完成标志的整改项，依据才真正发挥作用。本文给出可直接套用的清单、步骤表、角色分工和完成检查项；评审记录与整改跟踪可放在ONES中承载。
要点总览（TL;DR）
- 原型评审依据分四类：需求与目标材料、方案材料、约束材料、决策材料，评审前按类归集并指定提供人。
- 评审按评审前、评审中、评审后三段推进，每步写明输入、动作、输出和完成标志，避免开完会没有可执行结论。
- 产品、设计、研发、测试与业务各自带来依据、带走交付物，评审通知附角色对照表可减少会上临时找材料。
- 每条结论要能指回具体依据出处，整改项要有责任人和完成标志，待定项单独标记并进入下一轮跟踪。
- 评审记录、整改项与原型版本说明集中留存，后续需求变更时可直接查到当时的判断依据。
原型评审前要准备哪几类依据
评审依据的作用是让讨论有可对照的基准。缺少需求依据，评审容易变成对界面喜好的争论；缺少约束依据，方案可能在评审通过后才被发现无法实现。建议在评审通知发出前，把材料按以下四类归集到一个目录或文档页中，每类指定一名提供人。
第一类：需求与目标依据
- 需求说明：本次原型对应的需求条目、范围边界和明确不做的内容。
- 验收标准：每条需求可验证的通过条件，尽量写成可判断的表述。
- 目标用户与使用场景：谁在什么情况下使用，主要任务路径是什么。
- 业务目标：本次方案要改善的指标或解决的业务问题，作为优先级判断的参照。
第二类：方案依据
- 原型说明：页面清单、版本号、本次评审覆盖的页面范围。
- 交互流程：主流程与关键分支流程，标注入口和出口。
- 信息架构：页面层级、导航关系、字段与内容的归属。
- 关键页面状态：空状态、加载状态、异常与错误提示、权限不足等状态的处理方式。
第三类：约束依据
- 技术可行性说明：依赖的接口、数据来源、性能或终端限制。
- 合规与安全要求：涉及个人信息、权限控制、审计留痕等必须满足的条件。
- 既有系统与接口条件：需要复用的组件、已有接口的能力边界、数据字段口径。
第四类：决策依据
- 评审问题清单：评审前收集的待确认问题，按页面或流程标注。
- 历史遗留项：上次评审未关闭的问题及其当前状态。
- 结论记录模板：结论、依据出处、责任人、完成标志四个字段的空白表格。
四类材料齐全后，形成一份评审依据清单，逐项标注提供人和是否已分发。清单本身就是评审能否开始的前置条件。
按什么步骤组织一次原型评审
评审流程按评审前、评审中、评审后三段组织，每一步都明确输入、动作、输出和完成标志，避免会议开完却没有可执行的结论。
| 阶段 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 评审前 | 四类依据材料、原型版本 | 确定评审范围与不评审内容；提前至少一个工作日分发材料；收集预读问题形成问题清单 | 评审通知、问题清单、材料目录 | 参会人确认已预读，问题清单已归并去重 |
| 评审中 | 问题清单、原型、依据清单 | 按主流程走查，逐页对照需求与验收标准；对每个分歧记录结论和依据出处；未达成一致的标记为待定 | 评审记录：结论、分歧、待定项 | 每个议题都有结论或明确的待定责任人和期限 |
| 评审后 | 评审记录 | 把结论转成整改项，写明责任人、完成标志和截止时间；更新原型版本说明 | 整改项列表、修订后的原型 | 整改项全部有责任人和完成标志，并进入跟踪 |
评审节奏与角色安排
单次评审控制在六十分钟到九十分钟，覆盖的页面范围不宜过大，页面多时按流程分段评审。参与角色至少包括产品负责人、设计与交互、研发代表、测试代表，涉及业务规则时邀请业务方参加。产品负责人主持并拍板结论，指定一人记录，记录人与主讲人分开，保证讨论过程被完整留存。
评审中常见的失控点是逐页讨论视觉细节。处理办法是把问题按“影响流程与规则”“影响实现条件”“仅影响呈现”分类，前两类当场讨论，第三类记录后另行处理。
评审中每个角色提供什么依据、交付什么
角色分工的关键是每个角色既带来依据，也带走交付物。只带问题不带依据，讨论会停留在观点层面；只参会不带交付物，结论就落不到执行。
| 角色 | 提供的依据 | 评审中的职责 | 交付物 |
|---|---|---|---|
| 产品负责人 | 需求说明、验收标准、业务目标、优先级 | 说明方案意图，裁定范围与优先级 | 评审结论、优先级排序、待定项处理意见 |
| 设计与交互 | 原型说明、交互流程、信息架构、页面状态 | 讲解流程与状态设计，回应疑问 | 待修改页面清单、状态补充说明 |
| 研发代表 | 技术可行性说明、接口与数据条件 | 判断实现条件，指出风险与依赖 | 可行性判断、风险项与前置依赖 |
| 测试代表 | 验收视角的场景与边界条件 | 核对验收标准是否可验证 | 待补充的验收条件 |
| 业务方 | 业务规则、实际使用场景与例外情况 | 确认规则与场景覆盖是否完整 | 业务规则确认意见、遗漏场景 |
这张表可以直接作为评审通知的附件，让每位参会人清楚自己要准备什么、会上要给出什么。会后由记录人按角色归集交付物，避免遗漏。
当评审涉及需求、任务、缺陷与测试的关联追溯时，可以把评审结论和整改项登记为工作项，与对应需求建立关联。ONES 的方案覆盖需求、基线、版本、变更、测试与发布，需求发生变化时可沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪记录；评审材料与经验可沉淀在 ONES Wiki 中。具体的工作项类型与状态流转配置需按团队实际情况设置。
一个原型评审依据的填写示例
以下为演示情景，用于说明依据如何对应到结论，不代表真实项目记录。
场景：某电商产品的下单流程原型评审，覆盖购物车、确认订单、支付结果三个页面。
依据与页面的对应
- 需求依据：需求条目写明“支持使用优惠券抵扣，单笔订单限用一张”。对应页面为确认订单页的优惠券选择区域。
- 流程依据：交互流程标注了“优惠券不可用”分支，但原型中该分支只画了提示文案，未说明用户如何更换或放弃优惠券。
- 约束依据：接口条件说明优惠券校验需在下单时实时调用，存在超时可能；合规要求订单金额变更需留痕。
- 决策依据：预读问题清单中有两条，分别是“优惠券失效后金额如何提示”“支付超时后订单状态如何展示”。
结论与整改项的推导
| 议题 | 对照依据 | 结论 | 整改项 | 责任人 | 完成标志 |
|---|---|---|---|---|---|
| 优惠券不可用分支 | 流程依据与需求依据 | 需补充更换与放弃两条路径 | 补充确认订单页优惠券异常状态设计 | 交互设计 | 原型更新并附状态说明 |
| 优惠券校验超时 | 约束依据 | 需定义超时提示与重试方式 | 补充超时提示文案与重试交互 | 产品负责人与研发 | 文案定稿并确认接口超时阈值 |
| 金额变更留痕 | 合规要求 | 需在订单记录中保留变更前后金额 | 补充留痕字段说明 | 研发代表 | 字段说明进入需求文档 |
| 支付超时订单状态 | 问题清单与流程依据 | 本次未达成一致，列为待定 | 与业务方确认后补充 | 产品负责人 | 待定项关闭并更新原型 |
示例中每条结论都能指回具体依据，整改项都有责任人和可判断的完成标志。待定项单独标记，不混入已通过的结论，下一轮评审优先处理。
评审完成后如何检查依据是否用到位
评审结束不等于闭环。用下面这份清单逐项核对，可以判断依据是否真正被使用、结论是否可追溯。
- 四类依据材料是否齐全，并在评审前完成分发，参会人是否确认预读。
- 评审记录中的每条结论是否标注了对应的依据出处，包括需求条目、流程节点或约束说明。
- 未达成一致的议题是否单独列出，并写明待定责任人和关闭期限。
- 每个整改项是否有明确责任人、完成标志和截止时间，是否已进入跟踪。
- 原型版本是否已更新，版本说明中是否记录了本次修改对应的整改项。
- 上次评审的遗留项是否在本轮逐条核对状态，未关闭的是否说明原因。
- 待补充的验收条件是否已回写到验收标准中，测试代表是否确认。
核对中发现结论缺少依据出处的，应回到记录中补齐，无法补齐的结论视为未闭环。整改项进入跟踪后，在下一轮评审开始时先核对完成情况，形成“评审—整改—复核”的循环。评审记录、整改项与原型版本说明集中留存，后续需求变更时可以直接查到当时的判断依据。
常见问题
评审前材料没准备齐，会议还能开吗？
建议先确认缺的是哪一类依据。缺少需求说明或验收标准时，讨论容易变成对界面喜好的争论，这类材料缺失应推迟评审。缺少部分约束说明时，可以先评审流程与页面结构，把涉及技术条件的议题单独列为待定，并指定研发代表在会后补充可行性判断。无论哪种情况，都应在评审记录中写明哪些结论因依据不足而暂缓，避免把未验证的判断当成已通过结论。
原型评审和需求评审的边界怎么划分？
需求评审关注需求本身是否清晰、完整、可验证，原型评审关注方案是否覆盖需求、流程是否走得通、约束条件是否满足。实际操作中两者常有交叉：原型评审发现需求描述含糊时，应把问题回写到需求条目，而不是在评审会上临时改需求口径。把需求质量问题的处理归入需求评审环节，原型评审聚焦方案与依据的对照，两个环节的结论才不会互相覆盖。
评审会上对某个页面争执不下，怎么处理？
先判断分歧属于哪一类：影响流程与规则的、影响实现条件的、仅影响呈现的。前两类当场对照需求依据和约束依据讨论，仍无法达成一致时，由产品负责人明确列为待定项，写清待定责任人、需要补充的依据和关闭期限。仅影响呈现的问题记录后另行处理，不占用评审时间。待定项不混入已通过的结论，下一轮评审优先核对。
整改项进入跟踪后，怎么确认真的改到位了？
整改项应带有可判断的完成标志，例如“原型更新并附状态说明”“文案定稿并确认接口超时阈值”，而不是“已处理”。下一轮评审开始时，先逐条核对上轮整改项的完成情况，未关闭的说明原因。原型版本说明中记录本次修改对应的整改项编号，评审记录、整改项与版本说明集中留存，后续需求变更时可以直接查到当时的判断依据。
评审记录和整改项放在哪里便于追溯？
关键是让结论、依据出处和整改项保持关联，而不是散落在会议纪要和聊天记录里。可以把评审结论和整改项登记为工作项，与对应需求建立关联，需求变化时沿关联关系分析受影响的任务与测试内容。ONES 的方案覆盖需求、基线、版本、变更、测试与发布，可保留过程追踪记录，评审材料与经验也可沉淀在 ONES Wiki 中；具体的工作项类型与状态流转配置需按团队实际情况设置。
