原型评审清单适合用在方案方向待确认、跨角色理解不一致、关键流程和异常分支容易漏看，以及需要留下评审结论和整改记录的场合。它把“看一遍原型提意见”变成按固定问题逐项确认，主要补目标与范围、角色与权限、主流程与异常、状态与反馈、数据与边界、结论与责任人这几类遗漏。原型仍在探索、评审只为收集灵感，或团队对方案尚无基本共识时，清单容易流于形式，应先明确评审目标和参与角色再启用。
要点总览（TL;DR）
- 原型评审清单适合用在方案方向待确认、跨角色理解不一致、关键流程与异常分支容易漏看、需要留下评审结论和整改记录的场合；前提是评审目标明确、原型达到可讨论完成度、参与角色能对方案负责。
- 清单主要补六类遗漏：目标与范围、角色与权限、主流程与异常、状态与反馈、数据与边界、结论与责任人，把隐性检查变成逐项确认。
- 不同评审场景清单重点不同：方案方向评审看目标与范围，交互与流程评审看主流程与异常，跨角色对齐评审看角色、术语与依赖，上线前确认看遗留问题与整改跟踪。
- 原型仍在探索、评审只为收集灵感、方案基本共识尚未形成，或清单项与评审目标不匹配时，应暂缓使用清单，先明确评审目标。
- 可先选一次中等复杂度的真实评审做试点，观察结论是否更明确、遗留问题是否都有责任人和时间，再决定是否推广。
什么情况下值得用原型评审清单
当原型评审需要产出可执行的结论，而不只是交换意见时，清单才值得启用。判断标准可以落在三个条件上：评审有明确对象和范围，参与角色能对方案做出判断，评审结果需要被记录并跟进。三个条件同时成立，清单能把分散的检查动作固定下来；缺少其中任何一个，清单的约束力都会下降。
值得采用的典型场景包括：方案方向评审，需要确认目标用户、核心场景和范围边界；交互与流程评审，需要逐条核对主流程、异常分支和状态反馈；跨角色对齐评审，产品、设计、研发、测试对同一原型的理解需要拉齐；上线前方案确认，需要留下“评审通过什么、遗留什么、由谁整改”的记录。这些场景的共同点是评审结论会影响后续设计和开发动作，遗漏的代价高于评审本身的投入。
启用清单的前置条件也需要说清楚。评审目标应提前写明，例如“确认下单流程的异常处理是否完整”，而不是笼统的“看看原型”；原型应达到可讨论的完成度，关键页面和流程能够走通；参与角色应包含能对方案负责的人，避免只有执行角色到场。清单在评审中的角色是检查工具和记录框架，它替代不了评审人的专业判断，也不负责替团队做决策。
清单解决的是哪几类评审遗漏
原型评审的遗漏通常有规律：大家容易关注页面长什么样，忽略方案为什么这样设计；容易顺着主流程走一遍，跳过异常和边界；容易当场达成口头一致，散会后没人记得结论。清单的价值在于把这些隐性检查变成显性问题，让每个参与者在同一组问题上给出确认或提出异议。
常见的遗漏类型与对应的清单检查项可以这样对应：
| 遗漏类型 | 典型表现 | 清单中的固定问题 |
|---|---|---|
| 目标与范围 | 评审中争论页面细节，没人确认这次方案要解决什么问题 | 目标用户是谁？本次范围包含和不包含什么？成功标准是什么？ |
| 角色与权限 | 只按主角色走通，忽略管理员、访客或异常权限 | 涉及哪些角色？各角色能看到和操作什么？权限不足时如何提示？ |
| 主流程与异常 | 主路径演示顺畅，失败、超时、重复提交没有覆盖 | 主流程的关键节点有哪些？每个节点可能失败的原因和处理方式是什么？ |
| 状态与反馈 | 页面静态展示完整，加载、空态、错误态缺失 | 每个关键操作后系统给出什么反馈？空数据、加载中、失败分别如何呈现？ |
| 数据与边界 | 用理想数据演示，长度、数量、并发等边界未讨论 | 关键字段的取值范围和校验规则是什么？数据为空或超限时如何处理？ |
| 结论与责任人 | 评审结束没有明确通过、修改还是重审 | 本次结论是什么？遗留问题由谁在什么时间前处理？ |
遗漏被补上后，方案沟通会从“我觉得这里不对”转向“这一项我们确认了什么、还缺什么”，讨论更容易收敛。对后续验证也有直接作用：异常分支和状态反馈在评审阶段被确认，设计和开发就不必在实现阶段反复猜测，测试也能据此提前准备用例。清单不保证方案一定正确，它保证的是该检查的问题被摆到桌面上。
按评审场景选择清单重点
同一份清单不必在所有评审中等权使用。评审目的不同，清单应侧重的内容也不同，否则容易出现“每项都勾了、关键问题没谈透”的情况。下面按四类常见场景说明清单重点。
| 评审场景 | 核心问题 | 清单重点 | 可适当简化 |
|---|---|---|---|
| 方案方向评审 | 这个方案是否值得继续投入 | 目标用户、核心场景、范围边界、与现有方案的关系、成功标准 | 具体控件样式、字段校验细节 |
| 交互与流程评审 | 用户能否顺利完成关键任务 | 主流程节点、异常分支、状态反馈、操作前后衔接、权限差异 | 商业目标和范围讨论 |
| 跨角色对齐评审 | 产品、设计、研发、测试是否理解一致 | 角色与权限、术语口径、数据来源、接口依赖、验收标准 | 视觉细节和文案措辞 |
| 上线前方案确认 | 方案是否可以进入开发或发布 | 遗留问题清单、整改责任人、完成时间、回归确认方式 | 探索性讨论和方向争论 |
方案方向评审的重点是确认“做不做、做多大”，清单问题应围绕目标和范围展开，避免过早陷入页面细节。交互与流程评审的重点是“走得通、出错有解”，清单应覆盖主流程、异常和状态。跨角色对齐评审的重点是“大家说的是不是同一件事”，清单应把角色、术语、数据来源和依赖关系逐项确认。上线前方案确认的重点是“还差什么、谁来收口”，清单应转向遗留问题和整改跟踪。
实际操作中，一次评审可能同时带有多个目的。这时可以在清单中标注必答项和选答项：与本次评审目标直接相关的问题必须逐条确认，其余问题记录为待后续评审处理。这样既保留清单的完整性，又不让评审被无关问题拖长。
启用清单需要投入什么
清单的投入主要发生在评审前和评审后，评审本身的时间增加有限。评审前需要准备的材料包括：本次评审的目标和范围说明、可走通关键流程的原型、相关的业务规则或数据说明、上一轮评审的遗留问题。材料不齐时，清单问题会大量停留在“待确认”，评审效果反而下降。
参与角色和分工建议提前明确：
- 评审组织者：确定评审目标和清单版本，提前把材料发给参与者，控制评审节奏。
- 方案负责人：按清单逐项说明设计意图，对确认项和遗留项做出回应。
- 业务或用户代表：确认目标用户、使用场景和业务规则是否符合实际。
- 研发与测试代表：从实现和验证角度提出依赖、边界和验收问题。
- 记录人：记录每项结论、异议和整改责任人，避免会后凭记忆还原。
评审记录与整改跟踪需要有承载方式。可以用文档记录评审结论，用工作项跟踪遗留问题，把“问题描述、责任人、截止时间、当前状态”放在同一处，下次评审前先核对上一轮整改情况。以ONES为例，评审结论可以沉淀在文档中，遗留问题转为工作项分配责任人和时间，状态更新后回到评审记录中关联，形成从评审到整改的闭环。具体采用哪种承载方式，取决于团队已有的协作工具和评审频率；工具的作用是让结论可查、整改可跟，而不是增加一层额外流程。
还需要为清单本身安排维护。业务变化后，部分检查项会失效或需要新增；建议每次评审后花几分钟记录“哪项没用上、哪项漏了关键问题”，定期合并调整。清单长期不维护，会逐渐变成形式化的勾选表。
哪些情况应暂缓使用清单
清单并非越早用越好。原型仍处于探索阶段时，页面和流程会大幅调整，逐项核对清单问题会打断发散讨论，此时更适合用白板、草图或简短走查收集方向性意见。评审目标仅为收集灵感时，清单的确认式提问会限制参与者提出意外想法，可以先开放讨论，再对收敛后的方案使用清单。
方案基本共识尚未形成时也应暂缓。参与角色对目标用户、核心场景或范围边界存在明显分歧，清单会把分歧拆成一个个待确认项，却无法解决分歧本身。更合适的做法是先开一次范围或方向讨论，形成基本共识后再进入清单式评审。
清单项与当前评审目标不匹配时，不要为了“用上清单”而强行逐项过。例如上线前确认评审中仍在讨论目标用户是否准确，说明评审目标发生了偏移，应调整议程或另开评审。判断是否暂缓，可以问三个问题：本次评审要产出什么结论？参与者是否具备做出该结论的信息？清单问题是否指向这个结论？答案不清晰时，先明确评审目标比启用清单更重要。
用一次试点判断清单是否合用
在全面推广前，选一次真实评审做试点，比直接修改团队流程更稳妥。试点范围建议选择中等复杂度的原型评审：流程有一定分支、涉及两到三个角色、结论需要跟进整改，但不至于跨多个团队协调。这样的评审既能暴露清单的检查盲区，也能观察投入是否可接受。
试点中需要记录几类观察点：评审前准备材料花了多少时间，哪些材料缺失导致问题无法确认；清单中哪些问题引发了有效讨论，哪些问题被跳过或回答“后面再说”；评审是否按时结束，超时发生在哪些检查项；评审后遗留问题的数量、责任人和完成情况；参与者是否认为清单帮助他们发现了原本会漏掉的问题。记录方式可以简单到在清单旁标注，不必另建复杂表格。
试点结束后，用以下依据判断是否值得推广：清单是否让评审结论更明确，例如通过、修改后重审或暂缓的比例是否清晰；遗留问题是否都有责任人和时间；是否发现了此前同类评审中容易漏掉的异常分支或权限问题；评审总时长增加是否在团队可接受范围内。如果清单带来的确认项大多停留在“待定”，或参与者普遍认为增加了记录负担却没有改变结论质量，应先精简清单项、调整评审目标，再考虑推广。试点结论应回到清单本身：保留有效问题，删除与当前评审目标无关的条目，形成适合本团队的版本。
常见问题
一次原型评审同时有多个目的，清单怎么用才不拖长会议？
可以在清单中区分必答项和选答项：与本次评审目标直接相关的问题逐条确认，其余问题记录为待后续评审处理。评审开始前把本次目标写清楚，例如“确认下单流程的异常处理是否完整”，清单重点就围绕这个目标展开。多个目的并存时，建议拆成两次评审，或明确本次只解决其中一个，避免每项都浅尝辄止。
团队规模较小、评审参与人不多，还需要原型评审清单吗？
清单的价值取决于评审结论是否需要被记录和跟进，与团队规模没有直接关系。小团队如果评审后马上进入开发、口头结论就能落实，可以只用精简版清单，保留目标与范围、主流程与异常、结论与责任人这几项。如果评审涉及多个角色、遗留问题需要跟踪，清单仍然有用。可以先从五到八个关键问题开始，不必一次铺开完整清单。
清单用了一段时间后大家开始机械勾选，怎么处理？
机械勾选通常说明清单项与当前评审目标脱节，或清单长期没有维护。建议每次评审后记录“哪项没用上、哪项漏了关键问题”，定期合并调整；对反复被跳过的问题，要么删除，要么改成评审前必须准备的材料。也可以把清单问题从“是否确认”改为“请说明结论”，让回答需要具体内容，减少形式化勾选。
评审记录和整改项用什么方式承载比较合适？
关键是让结论可查、整改可跟。常见做法是用文档记录评审结论和异议，用工作项跟踪遗留问题，把问题描述、责任人、截止时间、当前状态放在同一处，下次评审前先核对上一轮整改情况。以ONES为例，评审结论可以沉淀在文档中，遗留问题转为工作项分配责任人和时间，状态更新后回到评审记录中关联。具体选哪种工具取决于团队已有的协作方式和评审频率。
原型完成度不高时，能不能先用清单过一遍？
原型仍处于探索阶段时，页面和流程会大幅调整，逐项核对清单问题容易打断发散讨论。这时更适合用白板、草图或简短走查收集方向性意见。等方案收敛、关键页面和流程能够走通后，再启用清单做确认式评审。判断标准是：本次评审要产出什么结论，参与者是否具备做出该结论的信息，清单问题是否指向这个结论。
