产品原型评审检查清单能否真正判定通过与否，取决于每个检查项是否写清了检查对象、判断依据和通过标准。本文给出一套可直接套用的写法规则、检查项分组框架、角色分工和完成自查表，帮助产品经理或评审组织者把清单从“勾选项”变成“判断依据”。
要点总览（TL;DR）
- 每个检查项写清检查对象、判断依据、通过标准三要素，通过标准优先用“有/无”“一致/不一致”“覆盖/遗漏”等可观察条件。
- 难以二值化的检查项给出分级或阈值，并在评审前区分阻断项与一般项，阻断项未通过则本轮不通过。
- 检查项按方案目标与范围、关键流程与异常分支、页面状态与字段规则、交互权限与数据约束、上下游衔接分组覆盖。
- 清单维护人、评审组织者、方案作者与评审人各有评审前中后的动作和交付物，结论需附证据位置并由负责人确认关闭。
- 控制清单长度、用证据支撑结论、定期回顾修订，评审结束前用完成自查表确认无空白结论、不通过项有责任人和复评安排。
通过标准怎么写：从检查项到可判定条件
一份清单里最容易被忽略的部分，恰恰是“通过标准”。很多清单只写了“检查登录流程是否合理”“确认权限设计是否清晰”，评审时每个人对“合理”“清晰”的理解不同，最后只能凭感觉点头。要让清单具备判定力，每个检查项都应写清三件事：检查对象、判断依据、通过标准。
| 要素 | 回答的问题 | 写法要求 |
|---|---|---|
| 检查对象 | 原型中的哪一处？ | 定位到具体页面、流程节点、状态或字段，避免“整体方案”这类笼统指向 |
| 判断依据 | 对照什么来判断？ | 引用已确认的需求文档、业务规则、设计规范或上下游约定，写明版本或条款位置 |
| 通过标准 | 满足什么条件算合格？ | 写成可观察、可判定的条件，优先使用“有/无”“一致/不一致”“覆盖/遗漏”这类二元判断 |
通过标准的措辞直接决定评审效率。把模糊形容词替换成可核对的判断，是改写清单时最值得投入的动作。下面是一组对照示例：
| 原检查项 | 改写后的检查项与通过标准 |
|---|---|
| 登录流程是否合理 | 检查对象：登录页与登录后跳转；判断依据：需求文档第3.2节登录流程；通过标准：账号密码错误时停留在登录页并提示错误原因，登录成功后跳转到需求指定的默认首页，两条路径在原型中均有可点击的页面或状态说明 |
| 权限设计是否清晰 | 检查对象：角色权限表与各角色可见菜单；判断依据：已确认的角色清单；通过标准：每个角色在原型中标注了可见菜单范围，角色与菜单的对应关系与权限表逐条一致，无未标注角色 |
| 异常情况是否考虑完善 | 检查对象：关键流程的异常分支；判断依据：流程清单；通过标准：流程清单中列出的每个异常分支（如超时、无权限、数据为空）在原型中都有对应页面或状态说明，遗漏数为零 |
有些检查项确实难以二值化，例如信息层级是否易读、操作步骤是否偏多。这类项不要硬套“通过/不通过”，可以给出分级或阈值：按高、中、低三级定义，并写清每一级的判定条件；或者设定数量阈值，例如“完成核心任务的操作步骤不超过5步”。分级和阈值同样要写进清单，评审时按级记录，避免临场发挥。
清单还需要在评审前区分阻断项与一般项。阻断项指不通过就必须修改后重新评审的检查项，通常涉及核心流程缺失、权限规则错误、与已确认需求冲突等；一般项可以在评审结论中记录为待优化，不阻塞本轮通过。阻断项应在评审通知中明确标出，让评审人知道哪些问题必须当场给出结论。
原型评审检查清单的检查项分组
检查项按类别组织，能帮助评审人按顺序覆盖，也方便后续维护时定位增删。以下分组框架可作为搭建清单的起点，实际使用时按项目类型裁剪。
方案目标与范围
- 原型覆盖的页面与流程是否与已确认的需求范围一致，有无超出范围的新增内容未说明。
- 方案要解决的核心问题是否在原型中有对应体现，关键角色和关键任务是否都能走通。
- 本期不做的内容是否在原型或说明中标注，避免评审时误判为遗漏。
关键流程与异常分支
- 主流程的每个节点是否有对应页面或状态，节点之间的跳转关系是否完整。
- 异常分支是否覆盖：输入校验失败、无权限访问、数据为空、操作超时、重复提交等。
- 流程中的回退、取消、中断是否有明确去向，是否会产生未定义状态。
页面、状态与字段规则
- 同一字段在不同页面的名称、格式、必填规则是否一致。
- 列表、详情、编辑等页面之间的状态是否自洽，操作后状态变化是否有说明。
- 字段的计算规则、默认值、长度限制等是否标注，是否与业务规则一致。
交互、权限与数据约束
- 关键交互的操作反馈是否说明，例如提交后的提示、失败后的处理。
- 角色与权限的对应关系是否逐条标注，越权访问的拦截方式是否说明。
- 数据来源、更新时机、依赖的外部系统是否在原型中注明。
上下游衔接
- 原型涉及的接口、数据字段是否与下游开发、上游系统对齐，待确认项是否列出。
- 交付物清单是否明确：原型文件、说明文档、待确认问题列表是否齐全。
- 评审结论需要通知的角色是否已列入分发范围。
评审角色分工与各环节交付物
清单无人维护、评审只勾选不记录，是清单流于形式的两个常见原因。把职责落到具体角色，并为每个环节定义交付物，可以让清单持续可用。
| 角色 | 评审前 | 评审中 | 评审后 |
|---|---|---|---|
| 清单维护人 | 按项目类型裁剪检查项，标注阻断项，更新判断依据的引用版本 | 记录清单本身的问题，如表述歧义、缺项 | 根据评审反馈修订清单，保留变更记录 |
| 评审组织者 | 分发原型、需求文档与清单，约定预审截止时间 | 按清单顺序推进议程，控制阻断项优先讨论 | 汇总结论，分派问题责任人，安排复评 |
| 产品经理（方案作者） | 提交原型与说明，标注待确认问题 | 解释方案依据，当场确认或记录争议点 | 修改原型，逐项回复问题处理结果 |
| 各角色评审人 | 完成预审，在清单中填写初步意见与证据 | 逐项给出通过或不通过的结论，附证据位置 | 确认问题关闭情况，参与复评 |
各环节的交付物同样需要明确：评审前产出的是带预审意见的清单和材料包；评审中产出的是逐项结论、证据引用和问题列表；评审后产出的是问题关闭记录与最终评审结论。评审结论应由组织者汇总、方案负责人确认，阻断项全部关闭后才算本轮通过。
当评审涉及多个角色、多轮修改时，检查项、问题与关闭状态需要有统一的承载位置。可以在文档中维护清单版本，把不通过项转为工作项分派给责任人，并在工作项中记录证据与处理结果，使评审结论与后续修改保持对应。ONES 的文档与工作项可以承担这类记录和流转，具体使用方式按团队现有流程配置。
一个完整示例：登录与权限原型评审
以下为演示情景，用于说明检查项、通过标准和评审记录如何填写，不代表真实项目。
场景：某后台系统的登录与权限模块原型评审，评审范围包括登录页、登录后跳转、角色菜单可见范围三部分。需求文档已确认角色为管理员、运营、访客三类。
| 检查项 | 判断依据 | 通过标准 | 结论与证据 |
|---|---|---|---|
| 登录失败路径 | 需求文档3.2节 | 账号或密码错误时停留登录页并提示原因，原型中有对应状态 | 通过，原型P2标注错误提示文案 |
| 登录成功跳转 | 需求文档3.3节 | 登录后进入需求指定的默认首页，三类角色跳转目标与文档一致 | 不通过，运营角色跳转目标未标注，需补充 |
| 角色菜单可见范围 | 已确认角色清单 | 每个角色标注可见菜单，与权限表逐条一致，无未标注角色 | 不通过，访客角色菜单未标注，权限表第4行与原型不一致 |
| 越权访问处理 | 权限规则说明 | 无权限访问时原型中有拦截提示或跳转说明 | 通过，原型P7有拦截提示 |
本轮评审中，登录失败路径与越权访问处理两项通过；登录成功跳转与角色菜单可见范围两项不通过，且均属于阻断项。组织者将两项转为问题记录，分别指派给产品经理补充跳转标注、与权限表核对后修正菜单标注。两项问题关闭后安排一次简短复评，复评只核对这两项及其关联页面，确认一致后本轮评审结论为通过。
避免清单流于形式的做法与完成检查
清单变长、勾选变快，往往意味着它正在失去判定作用。以下做法可以帮助清单保持有效。
- 控制长度：只保留能影响评审结论的检查项，同一判断不要拆成多条重复项；一般项过多时合并为一条概括性检查。
- 证据支撑：每条结论都要写明证据位置，例如原型页码、需求文档条款；只勾选不说明的项视为未完成评审。
- 定期回顾：每个项目结束后回顾清单，删除长期不触发问题的失效项，补充本轮暴露的遗漏项，并记录修订原因。
- 阻断项前置：评审通知中明确阻断项，评审时优先讨论，避免会议时间被一般项占满。
评审结束前，用下面的自查表确认本轮评审是否完整：
| 自查项 | 完成标志 |
|---|---|
| 所有检查项均有结论 | 清单中无空白结论，未讨论项已注明原因并约定处理方式 |
| 不通过项均有证据与责任人 | 每条不通过项记录了证据位置、责任人和期望完成时间 |
| 阻断项已单独确认 | 阻断项全部通过，或已明确复评安排 |
| 结论已通知相关角色 | 评审结论与问题列表已分发到方案作者、开发及相关上下游角色 |
| 清单修订意见已记录 | 本轮发现的表述歧义、缺项已交由清单维护人处理 |
通过标准写得住、检查项分得清、角色与交付物落得实，清单才能在每轮评审中稳定给出可复核的结论。建议从一个模块的清单开始试运行，经过两三轮评审后再扩展到更多原型范围。
常见问题
检查项写不出可判定的通过标准时，应该怎么处理？
先判断这一项是否真的影响评审结论。如果它只是偏好问题，可以从清单中删除或合并到相关检查项里。如果它确实影响结论但难以二值化，就给出分级或阈值：按高、中、低三级写明每一级的判定条件，或者设定数量阈值，例如“完成核心任务的操作步骤不超过5步”。分级和阈值要写进清单，评审时按级记录，避免临场凭感觉判断。
阻断项和一般项在评审流程上有什么区别？
阻断项不通过时，本轮评审结论为不通过，方案修改后需要复评；一般项不通过可以记录为待优化，不阻塞本轮通过。阻断项通常在评审通知中提前标出，评审时优先讨论，确保会议时间先用于必须当场给出结论的问题。阻断项的范围建议限定在核心流程缺失、权限规则错误、与已确认需求冲突等直接影响方案成立的情况，避免把优化建议都升级为阻断项。
评审会上已经逐项讨论过，还需要记录证据位置吗？
需要。口头讨论的结论在会后容易失真，尤其涉及多轮修改时，没有证据位置的结论无法复核。建议每条结论写明原型页码、需求文档条款或权限表行号，不通过项同时记录责任人和期望完成时间。只勾选不说明的检查项，可以视为未完成评审，由组织者退回补充。
清单用了一段时间后，怎么判断哪些检查项该删、哪些该补？
每个项目结束后做一次回顾：长期没有触发过问题的检查项，评估是否已由其他机制覆盖或不再影响结论，可以删除或合并；本轮评审中暴露的遗漏场景、表述歧义，补充进清单并记录修订原因。修订由清单维护人执行，保留变更记录，避免不同项目使用差异过大的版本而无法横向比较评审结论。
多个角色参与、需要多轮修改时，检查项和问题记录放在哪里比较合适？
关键是让检查项、结论、问题和关闭状态保持对应关系。常见做法是在文档中维护清单版本，把不通过项转为工作项分派给责任人，在工作项中记录证据与处理结果，复评时直接核对工作项状态。ONES 的文档与工作项可以承担这类记录和流转，具体配置按团队现有流程安排。
