原型评审清单是一份按“会前准备—评审中逐项核对—结论与整改”三段使用的检查表。它把每项检查写成可观察的通过标准，并注明证据、负责人和检查时点，同时把影响方案成立的问题标为阻断项。评审对象是产品方案与原型中的流程、信息结构、交互逻辑、状态与异常；视觉设计制作细节和需求本身的优先级、质量评审不在本清单范围内。
要点总览（TL;DR）
- 原型评审清单按“会前准备—评审中逐项核对—结论与整改”三段使用，每项写明检查内容、通过标准、证据和负责人。
- 会前准备解决评审能否开得起来：原型可访问、方案说明齐全、关键角色到场、议题与时长明确、分歧点提前标注。
- 评审中重点核对主流程闭环、分支与异常、信息结构、交互逻辑、角色权限和数据口径，每项给出明确结论。
- 通过标准要写成可观察结果，结论分通过、有条件通过、不通过三档；影响方案成立的问题标为阻断项。
- 阻断项全部关闭或有明确结论、整改项已分配负责人和期限、记录注明对应原型版本，评审才算完成。
谁在什么时点使用这份清单
这份清单服务于原型进入方案评审前后的完整过程，参与角色包括产品经理、交互/UI设计、研发负责人、测试和业务方代表。产品经理负责组织评审并维护清单，交互/UI设计提供原型与方案说明，研发负责人和测试从实现与验证角度核对流程、状态和异常，业务方代表确认场景与业务规则是否符合实际。
使用时点分为三段：原型提交方案评审前，由产品经理和设计完成自检；评审会上，参会角色逐项核对并记录结论；评审结束后，由负责人跟踪整改项和阻断项的关闭情况。前置输入包括可访问的原型文件或可点击链接、方案说明、流程图、关键业务规则与数据口径。缺少其中任何一项，评审很容易停留在观感讨论上。
| 角色 | 主要时点 | 需要准备的输入 |
|---|---|---|
| 产品经理 | 会前自检、会上主持、会后跟踪 | 方案说明、议题清单、评审记录模板 |
| 交互/UI设计 | 会前自检、会上说明 | 原型文件或链接、流程标注、状态说明 |
| 研发负责人 | 会上核对、会后评估整改 | 技术约束说明、对流程与异常的意见 |
| 测试 | 会上核对、会后复检 | 异常场景清单、验收关注点 |
| 业务方代表 | 会上确认、书面意见补充 | 业务规则、数据口径、角色权限要求 |
视觉设计制作细节、需求优先级排序和需求质量评审由其他流程处理，不占用本清单的检查项，避免一次评审承担过多目标。
会前准备检查项：评审能否开得起来
会前准备解决的是评审能否有效进行的问题。以下检查项在会议开始前完成，未通过的项目应先补齐再开会，否则会上只能临时补材料。
| 检查项 | 通过标准 | 负责人 | 检查时点 |
|---|---|---|---|
| 原型可访问性 | 链接在参会者常用环境下可打开，主页面可跳转，标注与说明齐全 | 交互/UI设计 | 会前一个工作日 |
| 方案说明 | 写明目标用户、核心场景、主流程与关键分支，读者不依赖口头补充即可理解 | 产品经理 | 会前一个工作日 |
| 关键角色确认 | 研发、测试、业务方已确认到场，或因故缺席并提交书面意见 | 产品经理 | 会前一日 |
| 议题与时长 | 列出本次需要决策的问题清单，每项对应预计讨论时间，总时长与议程匹配 | 产品经理 | 会前一日 |
| 待决问题预标注 | 已知分歧点逐条列出，注明各方初步立场，会上按顺序讨论 | 产品经理与设计 | 会前一日 |
待决问题预标注常被忽略，却直接影响会议效率。把“某字段是否必填”“某角色能否批量操作”这类分歧提前写出来，会上就能围绕具体问题形成结论，而不是在演示过程中临时发散。
评审中逐项核对：流程、信息结构与交互逻辑
评审会现场按方案内容逐项核对，判断的是方案是否成立。以下检查项覆盖流程、分支异常、信息结构、交互逻辑、角色权限和数据口径，每项都应给出明确结论。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 主流程完整性 | 从入口到结果形成闭环，每个节点都有对应页面或状态说明，无断点 | 流程图与原型页面对照 | 产品经理 |
| 分支与异常 | 失败、空状态、无权限、超时等场景均有处理方案或明确暂缓结论 | 异常场景清单、对应原型页 | 交互/UI设计、测试 |
| 信息结构 | 页面层级清楚，字段归属明确，必填与选填逐项标注 | 页面结构标注、字段说明 | 交互/UI设计 |
| 交互逻辑 | 操作反馈、返回路径、二次确认在原型中可看到，关键动作有结果提示 | 可点击原型或交互说明 | 交互/UI设计 |
| 角色与权限 | 不同角色看到的内容与可执行动作有区分，权限边界写明 | 角色权限表、分角色原型 | 产品经理、业务方代表 |
| 数据口径 | 关键字段的来源、计算规则、展示格式已说明，争议字段有结论 | 数据口径说明、会议记录 | 产品经理、业务方代表 |
核对时建议按主流程顺序推进，每到一个节点同时检查该节点的异常分支和角色差异。这样能发现“主流程通、异常没接住”的常见缺口。测试角色重点核对失败与超时场景，研发负责人重点判断流程在实现层面是否存在明显障碍，业务方代表确认规则与口径是否符合实际业务。
通过标准怎么写才可判断
通过标准要写成可观察、可核验的结果，让不同参会者对同一项检查得出相同判断。写法上包含对象、条件和可观察结果，例如“每个主流程节点都有对应页面或状态说明”“无权限角色进入该页面时看到提示页而非空白页”。
以下对比说明可判断与不可判断的写法差异：
| 不可判断的写法 | 可判断的写法 |
|---|---|
| 体验流畅 | 主流程每个操作后都有反馈提示，返回路径不超过两步 |
| 逻辑清晰 | 每个分支在流程图中标注触发条件，并在原型中有对应页面 |
| 权限合理 | 角色权限表中每个角色对应的可执行动作逐项列出，无空白项 |
| 异常考虑周全 | 失败、空状态、无权限、超时四类场景各有处理方案或书面暂缓结论 |
每项检查的结论分三档：通过，表示该项已达到通过标准；有条件通过，表示主体方案成立，但附有整改项、负责人和期限；不通过，表示该项未达到标准且影响方案判断，需要修改后重新评审。三档结论都要写入评审记录，避免会后对“当时是否通过”产生分歧。
证据与负责人：每项检查落到人和物
评审结论要可追溯，每项检查都需要明确谁提供材料、谁确认结论、证据存放在哪里。建议在检查表中固定以下字段：检查项、通过标准、证据形式、证据位置、负责人、结论、整改期限。
证据形式包括原型页面截图、流程标注、角色权限表、数据口径说明和会议记录中的确认结论。证据位置应指向具体版本，例如原型版本号或文档链接，确保后续查看时能对应到评审当时的状态。评审结论必须注明对应哪一版原型，原型后续修改后，旧结论不再自动适用于新版本。
有条件通过的整改项需要登记负责人、期限和复检方式。复检可以由原评审中的测试或产品经理执行，复检时对照整改项逐条确认，并在记录中更新状态。评审记录、整改项和复检结论如果在文档与工作项中流转，可以使用 ONES 承载：评审记录作为文档留存，整改项作为工作项分配负责人和期限，复检时更新工作项状态，形成从结论到关闭的记录链。
阻断项与完成条件
阻断项是必须解决才能进入下一阶段的问题。典型阻断项包括：主流程不闭环，存在无法到达结果的断点；关键角色权限缺失，导致核心场景无法执行；核心数据口径未定，字段来源或计算规则存在分歧；重大异常场景无处理方案，例如支付失败或超时后状态不明。
非阻断项包括文案措辞、局部样式细节和可后续迭代的次要交互。这类问题可以记录为整改项，但不影响本次评审放行。区分两者的标准是：该问题是否影响方案能否成立、是否影响核心场景走通。把次要问题标为阻断会拖慢进度，把核心缺口放过则会在开发阶段放大返工。
评审完成的判定条件为：阻断项全部关闭，或已有明确结论并指定处理方式；整改项已分配负责人和期限；评审记录已归档并注明对应原型版本。复检由产品经理组织，测试参与确认阻断项关闭情况，复检结论更新到同一份记录中。满足这些条件后，原型方可进入下一阶段。
常见问题
原型评审清单和需求评审清单可以合并使用吗？
可以放在同一场会议里衔接，但检查对象不同。需求评审关注需求是否值得做、优先级是否合理、验收条件是否清楚；原型评审清单关注方案是否成立，即流程是否闭环、异常是否有处理、权限与数据口径是否明确。建议分开成两张表，各自记录结论，避免一张表承担两类判断而让结论含糊。
评审会上业务方代表无法到场怎么办？
会前确认环节就应处理这种情况。缺席方需要提交书面意见，重点覆盖业务规则、数据口径和角色权限三类内容，由产品经理在会上代为说明并记录。涉及核心业务规则且无书面意见的议题，可以列为待决项，不强行在会上形成结论，会后补充确认后再更新评审记录。
原型改动后，之前的评审结论还有效吗？
评审结论对应具体原型版本，原型改动后旧结论不再自动适用。建议在记录中注明版本号，改动涉及主流程、权限或数据口径时重新核对相关检查项；仅涉及文案和局部样式的调整，可按整改项跟踪，不必整场重审。复检时对照整改项逐条确认，并把结论更新到同一份记录。
小团队人手少，清单项可以精简吗？
可以按项目风险调整检查项数量，但会前准备和阻断项判定建议保留。人手少时可由同一人兼任多个角色，例如产品经理同时承担部分测试视角的异常核对，但需要在记录中写明由谁确认，避免结论无人负责。检查项精简后仍应保留通过标准和证据两列，否则会后难以判断当时依据什么放行。
阻断项一时无法关闭，评审还能往下走吗？
可以给出明确结论再推进，例如指定处理方式、负责人和完成时点，并把该项保留为未关闭状态。若阻断项涉及主流程闭环或核心权限缺失，建议先解决再进入开发，否则返工成本会在实现阶段放大。复检由产品经理组织，测试参与确认关闭情况，结论更新到同一份评审记录中。
