产品原型评审是在投入开发前，把方案讲清楚、验一遍的固定动作。它要确认业务范围、主流程、交互状态、数据字段、异常边界和可行性，并留下带责任人和期限的结论。本文按“准备材料—预审—评审会—结论与整改—复核关闭”五步展开，说明各角色交付物、一个完整示例和通过标准，适合产品经理或项目负责人组织评审时参照。
要点总览（TL;DR）
- 原型评审先定目标清单：确认业务范围与主流程、交互与状态、数据与字段、异常与边界、可行性与工作量粗估，并写明视觉风格和需求文档质量不在本次范围。
- 按原型成熟度调整评审深度：概念草图看范围与主流程，可交互低保真看操作路径与状态，高保真可点击补异常场景与可行性。
- 会前1–2个工作日发出原型、流程图、页面说明和待决策问题清单，收集书面意见，把可书面解决的问题挡在会前。
- 评审会按主流程走查，问题当场归为确认、待改、待定、超出范围四类，结论单写明责任人与期限，原型更新后轻量复核再进入开发。
- 通过标准是主流程无未决分歧、待改项均有责任人与期限、关键异常已覆盖、决策人确认结论，并留存结论单、原型版本号和复核记录。
一次原型评审要回答哪些问题
原型评审容易滑向两种低效：一种是把会议开成漫谈，从视觉风格聊到实现细节；另一种是只做演示，没有人对方案提出可验证的问题。避免这两种情况的办法，是在会前把本次评审要回答的问题写成清单，并明确哪些内容不进入本次评审。
一次完整的原型评审通常验证五类问题：
- 业务范围与主流程：这次方案覆盖哪些用户角色和业务场景，主流程是否完整、有无断点，范围之外的需求是否被明确排除。
- 交互与状态：每个关键页面的操作路径是否顺畅，页面状态（加载、空态、成功、失败、无权限）是否定义清楚，状态之间的跳转是否符合用户预期。
- 数据与字段：页面展示和录入的字段是否齐全，字段来源、必填规则、校验规则和展示格式是否明确。
- 异常与边界：超时、重复提交、并发操作、数据为空、权限不足等场景是否有处理方案，边界条件下的提示和兜底路径是否可接受。
- 可行性与工作量粗估：研发能否判断技术依赖和实现风险，是否需要对方案做简化，大致工作量是否与排期匹配。
与上述问题无关的内容应当明确排除。视觉风格、配色、图标和设计制作细节属于设计走查或视觉评审的范围，放在原型评审里讨论会挤占确认方案的时间。需求文档本身的质量问题（描述是否完整、术语是否统一）属于需求评审的范畴，也不在本次会议中展开。
评审深度应随原型成熟度调整，不必每轮都按同一标准走查：
| 原型成熟度 | 评审重点 | 适合的参会范围 |
|---|---|---|
| 概念草图 | 业务范围、角色划分、主流程走向 | 产品、业务、研发负责人 |
| 可交互低保真 | 操作路径、页面状态、字段与校验 | 产品、设计、研发、测试 |
| 高保真可点击 | 异常场景、边界条件、可行性与工作量 | 全部评审角色，含业务确认 |
本节的可交付物是一份评审目标清单，写明本次要确认的问题、对应的原型版本，以及明确不在范围内的内容。清单在会前发给参会人，会议按清单推进，超出清单的话题记录后另议。
评审前：材料准备与预审怎么做
会上返工大多源于会前输入不足：参会人第一次看到原型，边看边理解，讨论自然发散。把材料提前发出并收集书面意见，可以让会议只处理真正需要当面决策的分歧。
必备输入包括四项：原型链接或文件（注明版本号）、主流程图、关键页面说明（页面目标、主要操作、状态定义）、待决策问题清单（每个问题写明背景、可选方案和产品负责人的倾向）。四项材料缺一项，参会人就容易在会上追问基础信息。
预审按以下步骤执行：
- 提前1–2个工作日发出评审通知包，包含上述材料和会议目标清单。
- 请参会人书面反馈意见，按“必须会上讨论”“可书面答复”“超出范围”三类标注。
- 产品负责人会前处理可书面答复的问题，把答复附在材料中；超出范围的条目记录后移出本次议程。
- 会前确认参会角色与决策人，明确谁对方案有最终确认权。决策人无法出席时，应调整会议时间，避免会后结论被推翻。
完成标志是：评审通知包已发出、书面意见已汇总成预审意见表、待决策问题清单已收敛到会上可讨论的数量。预审意见表按“问题—提出人—处理方式—会上是否讨论”四列记录，会上直接引用，不再重复陈述。
评审会怎么开：五步流程与现场规则
评审会按主流程顺序走查，每一步都产出明确记录，会议结束时结论已经成型，而不是留到会后整理。
- 开场对齐目标：主持人复述本次评审范围和目标清单，确认不在范围内的内容，约定结束时间。
- 按主流程走查：每页先讲用户目标和业务背景，再讲操作路径和状态变化。讲解顺序跟随用户完成任务的过程，不按页面编号跳跃。
- 问题当场归类：每个问题归入“确认”“待改”“待定”“超出范围”四类之一，记录提出人、责任人和期限。归类动作在讨论当下完成，避免会后凭记忆整理。
- 控制节奏与发言顺序：先业务和测试提场景问题，再研发提可行性问题，设计和产品最后回应。实现细节和视觉偏好不在会上展开，记录后由对应角色线下处理。
- 结束前复述结论：主持人逐条复述确认项、待改项、待定项和风险，请参会人确认无遗漏，并明确结论单的发出时间。
现场规则可以提前约定两条：一是每个议题设定讨论时限，超时即转为待定并指定决策人；二是同一问题不重复讨论，已有书面答复的直接引用。会议走查记录按页面顺序记录问题分类，作为结论单的原始输入。
角色分工与各自交付物
评审出现责任悬空，通常是因为角色只被通知参会，没有被要求交付。下表把每个角色在评审中的职责和输出对应起来，会前随通知包发出。
| 角色 | 评审中的职责 | 交付物 |
|---|---|---|
| 产品负责人 | 主讲方案与业务背景，维护待决策问题清单，汇总结论 | 评审结论单、待定项决策跟踪 |
| 交互/设计 | 解释交互逻辑与状态变化，回应操作路径问题 | 更新后的原型版本、状态说明补充 |
| 研发 | 评估技术可行性与外部依赖，标注实现风险 | 风险与依赖清单、工作量粗估意见 |
| 测试 | 提出可测性问题与异常场景，确认验收口径 | 测试关注点清单 |
| 业务/运营 | 确认场景真实性与优先级，判断方案是否满足业务目标 | 场景确认意见、优先级调整建议 |
角色设置可以随团队规模调整。人数较少的团队可能由产品兼任交互说明，或由研发兼任测试视角，此时应在通知包中写明兼任情况，保证每类问题都有明确的人负责回应。决策人通常由产品负责人或业务负责人担任，同一项目内保持稳定，避免每次评审更换确认口径。
评审结论怎么写与如何闭环
结论单是评审的核心产出，写法上要能让没参会的人读懂，也能让整改项被逐条验收。建议按五部分组织：评审范围（含原型版本号）、通过项、待改项、待定项、风险与依赖。
待改项写成可验收的描述，包含三个要素：改什么（页面与具体问题）、改成什么（期望结果）、谁来改和何时完成。例如“退款申请页缺少退款原因必填校验，需补充必填提示与提交拦截，设计更新原型，某月某日前完成”，比“优化退款页校验”更容易跟踪。
待定项要写明决策人、决策时限和所需信息，到期未决策的应升级处理，避免长期悬置影响排期。风险与依赖单独列出，标注影响范围和应对方式，由研发负责跟进。
闭环按三步推进：
- 原型更新后，由产品负责人对照待改项逐条核对，做轻量复核，不重复开完整评审会。
- 复核确认整改项关闭后，在结论单上记录复核结果和新的原型版本号，方案才进入开发。
- 结论单、原型版本号和复核记录一并留存，作为后续需求变更和验收的参照。
当团队把评审结论、待改项和复核记录放在统一的工作项与文档中流转时，整改状态和责任人可以直接在任务列表里查看，减少在聊天记录和表格之间反复核对。ONES 可以承载这类工作项与文档的关联管理，具体配置方式取决于团队现有的工具设置。
一个完整示例：订单退款原型评审
以下为演示情景，用于说明流程如何落地，数据不代表真实项目。
背景与目标：某电商后台计划上线订单退款功能，产品完成可交互低保真原型。本次评审目标是确认退款主流程、退款原因与金额字段规则、审核状态流转，以及异常场景处理；视觉风格和退款报表不在本次范围。
会前材料与预审发现：产品提前两个工作日发出原型链接、退款流程图、关键页面说明和待决策问题清单。预审收到书面意见七条，其中三条可书面答复（字段命名、按钮文案、列表排序），产品会前答复并附入材料；两条超出范围（退款报表、消息通知模板）移出议程；两条需要会上讨论（部分退款是否支持、审核超时如何处理）。
会上走查发现的问题：按“用户提交退款—客服审核—财务打款”顺序走查，当场归类如下：
- 确认：退款主流程与状态流转方案通过；退款原因必填、金额上限校验规则通过。
- 待改：退款申请页缺少金额输入错误的提示状态，设计补充；审核列表缺少批量操作后的结果反馈，产品补充说明。
- 待定：部分退款是否纳入本期，由业务负责人在三个工作日内决策；审核超时自动关闭的时限，由产品与业务确认后补充。
- 超出范围：退款报表需求、通知模板文案，记录后另议。
结论单与复核结果：结论单记录评审范围（原型版本 v0.3）、通过项两项、待改项两项（各附责任人与期限）、待定项两项（附决策人与时限）、风险一项（财务打款依赖外部接口，研发跟进）。原型更新至 v0.4 后，产品对照待改项逐条复核，两项均已关闭；部分退款经业务决策纳入下期，本期结论单标注范围调整。复核记录与结论单一并留存，方案进入开发排期。
完成检查：这次评审算不算通过
是否通过应在会前与参会角色对齐标准，避免会后各执一词。以下检查表可逐项核对：
| 检查项 | 判断标准 | 结果 |
|---|---|---|
| 主流程 | 主流程各环节均已确认，无未决分歧 | 是/否 |
| 待改项 | 每项均有责任人和截止时间，描述可验收 | 是/否 |
| 异常场景 | 关键异常与边界场景已覆盖并有处理方案 | 是/否 |
| 待定项 | 每项均有决策人和决策时限 | 是/否 |
| 风险与依赖 | 已识别并指定跟进人 | 是/否 |
| 决策人出席 | 有最终确认权的决策人全程参与并确认结论 | 是/否 |
| 证据留存 | 结论单、原型版本号、复核记录齐全 | 是/否 |
出现以下情况时，本次评审应判定为未通过，需重新安排：核心流程未确认；关键技术依赖未评估；决策人缺席导致结论无效。判定未通过时，记录已确认的部分和遗留问题，缩小下次评审范围，不必从头重来。
评审通过的标志是：检查表各项均为“是”，结论单已发出，待改项进入整改跟踪，原型更新并复核关闭后方案进入开发。证据留存以结论单、原型版本号和复核记录三项为准，缺一项都会影响后续变更追溯和验收对照。
常见问题
评审会上有人坚持讨论视觉细节，主持人怎么处理？
会前就把视觉风格、配色和设计制作细节写进“不在本次范围”清单，开场时复述一遍。会上出现这类话题时，主持人记录后归入“超出范围”，说明由设计走查或视觉评审另行处理，然后回到当前页面的用户目标和操作路径。如果讨论涉及状态提示是否清楚、错误信息是否可理解，这属于交互与状态问题，可以留在本次评审中讨论。
决策人临时无法参会，评审还能继续吗？
可以继续走查和记录，但结论的有效性会受影响。建议先确认决策人能否在会后短时间内书面确认结论；如果无法确认，把本次评审定位为预评审，已确认的部分照常记录，涉及最终取舍的待定项标注决策人和新的决策时限，再安排一次范围更小的确认会。核心流程未确认或决策人缺席导致结论无效时，不应直接进入开发。
待定项一直没人拍板，怎么避免拖住排期？
待定项在结论单里必须写清三件事：决策人、决策时限、做出决策所需的信息。到期未决策时，由产品负责人升级到上一级负责人，并在结论单上记录升级动作。如果待定项影响主流程或关键依赖，应把它列为本次评审的阻断项，方案暂不进入开发；如果只影响次要分支，可以约定先按默认方案实现，后续变更走需求变更流程。
小团队角色不全，评审怎么分工？
角色可以合并，职责不能空缺。产品可以兼任交互说明，研发可以兼任测试视角，但通知包里要写明兼任情况，保证业务范围、交互状态、可行性、可测性和场景真实性这五类问题都有人负责回应。决策人建议在项目内保持稳定，避免每次评审更换确认口径。团队规模较小时，也可以把预审做扎实，会上只讨论需要当面决策的分歧。
原型改完后需要重新开一次完整评审会吗？
通常不需要。原型更新后由产品负责人对照待改项逐条核对，做轻量复核即可，重点确认整改项是否关闭、是否引入新的状态或字段问题。复核结果和新版本号记录在结论单上，方案即可进入开发。如果整改过程中发现主流程有较大调整，或新增了关键异常场景，再缩小范围安排一次专题评审，不必从头重走全部流程。
