产品原型评审要回答的核心问题是：这份原型是否已经具备进入开发的条件。把“评审通过”建立在可核验的条件和可复算的指标上，比依赖会议印象更可靠。本文给出一套条件清单、充分度指标与三态结论的判定方法，并说明评审记录与意见闭环如何在ONES中承载。
要点总览（TL;DR）
- 准出标准判定的是原型是否达到“可开发”状态，围绕目标与范围、关键流程覆盖、异常分支、交互与状态规则、依赖与约束、意见闭环六类条件逐条核验证据。
- 条件分为阻断项与改进项：阻断项未满足即退回，改进项可带入开发但需登记责任人与关闭时限。
- 评审充分度用流程覆盖率、意见闭环率和高等级遗留问题数衡量，每个指标都要写明公式、分母、统计时间窗与数据来源。
- 结论采用通过、有条件通过、退回三态；覆盖率与闭环率达标但存在高等级遗留问题时，不能判通过。
- 指标反映评审过程是否充分，不保证方案本身正确；准出后新增需求应进入变更管理，必要时触发补充评审。
准出标准要回答什么问题
准出标准判定的是原型本身是否达到“可开发”状态，而不是评审会开得是否热闹。它需要把评审结论从主观印象转为可核验的判断：每一条准出条件都有对应的证据，每一个指标都有明确的分母和统计时间窗，任何人拿到同样的记录都能复算出相同结论。
为了让结论有区分度，条件需要分成两类。阻断项是进入开发前必须满足的条件，例如关键流程缺失、核心状态规则存在歧义、关键外部依赖未确认；任一项未满足，原型就不能直接进入开发。改进项是不影响开发启动、但需要在开发过程中跟踪优化的内容，例如文案细节、次要页面的交互微调、非核心分支的提示语。改进项可以带入开发，但必须登记责任人与计划关闭时间。
准出结论建议采用三种状态，避免“通过/不通过”的二元判断掩盖真实情况：
- 通过：全部阻断项满足，充分度指标达到组织设定要求，无高等级遗留问题。
- 有条件通过：阻断项全部满足，但存在少量改进项或低等级遗留问题；需列明遗留清单、责任人、关闭时限，并在开发启动后的约定节点复核。
- 退回：任一阻断项未满足，或存在未清零的高等级遗留问题；需补充原型或说明后重新评审。
三态结论的价值在于把“差一点”的情况显性化：有条件通过不是放水，而是把遗留内容变成可跟踪的承诺；退回也不是否定，而是明确指出还缺哪一块证据。
准出条件清单与判定口径
准出条件围绕“方案可开发”展开，建议归为六类。每一类都要写明证据形式和判定口径，判定人只需核对证据是否存在、内容是否满足要求，而不必重新讨论方案好坏。
| 条件类别 | 判定内容 | 证据形式 | 等级 |
|---|---|---|---|
| 目标与范围 | 本次原型对应的业务目标、用户角色、功能边界已确认，明确不做什么 | 原型首页的范围说明、需求文档对应章节、评审记录中的确认结论 | 阻断项 |
| 关键流程覆盖 | 应评审的关键流程均有对应原型页面，主路径可完整走通 | 原型页面清单与关键流程清单的对照表 | 阻断项 |
| 异常分支 | 关键流程的主要异常分支（失败、超时、无权限、空数据等）有处理方式 | 原型中的异常状态页面或说明文档中的分支说明 | 阻断项（核心流程）/改进项（次要流程） |
| 交互与状态规则 | 关键操作的前置条件、状态流转、字段校验规则无歧义 | 原型批注、状态流转说明、规则说明文档 | 阻断项 |
| 依赖与约束 | 外部系统依赖、数据来源、权限模型、性能或合规约束已识别并记录 | 依赖清单、接口约定记录、约束说明 | 阻断项 |
| 评审意见闭环 | 评审提出的意见均已处理：关闭、明确采纳计划或明确不采纳并说明理由 | 问题单或意见记录中的状态与处理结论 | 阻断项（高等级意见）/改进项（低等级意见） |
阻断项与改进项的划分规则需要提前约定，而不是评审现场临时决定。一个实用的划分口径是：影响主流程能否走通、影响核心数据正确性、影响外部依赖能否对接的问题，列为阻断项；只影响体验细节、文案表述、非核心分支呈现的问题，列为改进项。等级划分应在评审记录中标注，并由评审主持人在评审结束前确认，避免事后争议。
需要强调的是，六类条件的具体判定内容应结合业务实际裁剪。面向内部工具的原型，权限与合规约束的权重可能较低；面向交易场景的原型，状态规则与异常分支的要求会更严格。标准可以调整，但调整结果要写入评审记录，保证同一项目内口径一致。
评审充分度的量化指标与计算
条件判定回答“缺不缺”，指标回答“评审得够不够充分”。建议至少使用三个指标，并明确公式、分母与统计时间窗。
流程覆盖率 = 已评审关键流程数 ÷ 应评审关键流程数 × 100%。分母来自评审前确定的关键流程清单，分子是本次评审中实际展示并形成结论的流程数。只展示页面但未形成结论的流程，不计入分子。统计时间窗为本次评审对应的原型版本周期。
意见闭环率 = 已关闭意见数 ÷ 提出意见总数 × 100%。分母为本次评审及其后续补充意见的总数，分子为状态为“已关闭”的意见数，包括已修改、已确认不修改并说明理由两类。当分母为零时，闭环率没有定义，应标注为“不适用”，不能记为100%，也不能据此判定评审充分；此时应结合条件逐条判定，并检查是否因评审范围过窄导致没有意见。
高等级遗留问题数 = 统计时点仍处于未关闭状态的高等级问题数量。该指标不取比率，直接计数，要求清零后才能判通过。高等级的定义与阻断项划分规则保持一致。
三个指标的数据来源应统一：关键流程清单来自评审前的范围确认记录，意见数据来自问题单或评审意见记录，原型版本以评审时冻结的页面版本为准。统计时间窗建议截止到准出判定时点，并在结论中注明截止时间，便于后续复算。
指标阈值由组织结合项目风险设定，本文不给出通用达标线。可以采用的设定方式是：核心交易类原型要求流程覆盖率100%、高等级遗留问题为0；内部工具类原型允许流程覆盖率略低，但未覆盖流程需逐条说明原因并登记为改进项。
从记录到结论的评估步骤
把条件与指标落成结论，需要按固定顺序执行，保证每一步都有产物。
- 评审前确定范围与关键流程清单。由产品负责人列出本次原型覆盖的业务目标、角色和关键流程，形成清单并在评审通知中发出。清单是后续计算覆盖率的分母，必须在评审前冻结。
- 评审中记录意见并标注等级与责任人。每条意见记录提出人、对应页面或流程、等级（阻断/改进）、责任人。等级标注在评审现场完成，主持人对分歧做当场裁定。
- 评审后逐条判定条件。对照六类条件表，逐项核对证据是否齐全、内容是否满足判定口径，记录“满足/不满足”及证据位置。不满足的阻断项直接进入退回或补充流程。
- 计算指标。按公式统计流程覆盖率、意见闭环率和高等级遗留问题数，注明统计截止时间与数据来源。
- 汇总形成结论并留痕。阻断项全部满足且指标达到组织要求，判通过；阻断项满足但存在改进项或低等级遗留，判有条件通过并附遗留清单、责任人与关闭时限；任一阻断项不满足或高等级遗留未清零，判退回。结论、条件判定表、指标计算结果一并归档到评审记录中。
这套步骤的关键在于产物可追溯：范围清单、意见记录、条件判定表、指标结果四份材料齐全，结论就能被复核。评审记录与意见状态如果分散在聊天工具和文档里，闭环率统计会变得困难；在ONES中，评审意见可以作为工作项记录状态与责任人，原型说明作为文档与对应版本关联，闭环情况按状态汇总，减少人工核对成本。
一个可复算的判定示例
以下为演示情景，数字仅用于说明计算过程，不代表通用达标线。
某内部审批工具的原型评审，评审前确定应评审关键流程8个，本次评审实际展示并形成结论6个，流程覆盖率为6 ÷ 8 = 75%。评审共提出意见20条，截至判定时点已关闭17条，意见闭环率为17 ÷ 20 = 85%。剩余3条未关闭意见中，1条为高等级问题（审批驳回后的状态回退规则未明确），2条为改进项（提示文案与空状态插图）。
条件判定结果：目标与范围满足；关键流程覆盖不满足，2个流程未评审且未说明原因，属于阻断项未满足；异常分支中核心流程已覆盖，次要流程有1处缺失，列为改进项；交互与状态规则因高等级问题未关闭，判定不满足；依赖与约束满足；意见闭环未完成。
综合结论为退回。理由有两条：关键流程覆盖存在阻断项缺口，高等级遗留问题未清零。即使闭环率85%看起来接近完成，也不能据此判通过。处理方式是补充2个未评审流程的原型并明确驳回状态规则，重新提交评审；2条改进项登记为遗留清单，在下次评审时一并核对。
如果换一种情况：8个流程全部评审，20条意见关闭19条，唯一未关闭的是低等级文案改进项，高等级遗留为0，则结论为有条件通过，遗留项列明责任人与关闭时限，开发可以启动。
结果怎么解读，哪些情况不能直接判通过
指标达标是准出的必要条件，不是充分条件，解读时需要守住几条边界。
覆盖率与闭环率都达标，但存在高等级遗留问题时，不能判通过。高等级问题往往对应主流程走不通或核心规则歧义，这类问题带入开发会在实现阶段放大返工成本。正确做法是先清零高等级遗留，再复核指标。
分母为零或样本过小时，指标不可比。关键流程只有1个、意见只有2条的项目，覆盖率与闭环率的波动会被放大，单看比率容易误判。此时应以条件逐条判定为主，指标仅作参考，并在结论中说明样本规模。
准出标准管的是本次原型版本，不覆盖后续需求变更。通过准出后，业务方新增或调整的需求应进入变更管理流程，重新评估影响范围，必要时触发补充评审。把准出当成一次性放行，会让后续变更绕过评审记录。
最重要的一点：指标反映的是评审过程是否充分，不保证方案本身正确。流程覆盖率达到100%，只说明该看的流程都看了；方案是否解决真实问题，仍取决于目标确认的质量和后续验证。准出标准的作用是把“能不能开始开发”这个判断变得可核验、可复算、可追溯，而不是替代对方案价值的判断。
常见问题
关键流程清单在评审前没冻结，覆盖率还能算吗？
可以算，但要先补一个口径。覆盖率的分母是应评审关键流程数，如果清单在评审后才补，分母就失去了“评审前约定”的意义，算出来的比率容易被质疑。处理方式是在结论中注明清单的形成时间，并说明补入流程的原因；补入的流程如果本次未评审，应计入未覆盖数，而不是从分母中剔除。更稳妥的做法是下次评审前把范围清单随评审通知一起发出并冻结，让分母在评审开始前就确定下来。
意见闭环率的分母要不要包含评审后追加的意见？
建议包含，但要在结论中区分来源。分母取本次评审及其后续补充意见的总数，能反映从评审到判定时点的完整处理情况；如果只统计评审当天的意见，闭环率会偏高，掩盖后续追加意见未处理的事实。操作上可以在意见记录中标注“评审现场提出”和“评审后补充”两类，计算总闭环率的同时给出分类数据，便于判断追加意见是否集中在某类问题上。
有条件通过之后，遗留项应该在什么节点复核？
复核节点建议与开发节奏绑定，而不是定一个固定的自然日。常见做法是放在开发启动后的第一个迭代结束前，或放在遗留项对应的功能模块进入联调之前，确保问题在影响扩大前被发现。复核时要核对遗留项的状态是否按计划关闭，未关闭的说明原因并重新评估等级；如果遗留项升级为阻断项，应暂停相关模块的开发并补充评审。复核结论同样要归档到评审记录中，与最初的准出结论形成完整链条。
不同项目用同一套准出标准，阈值需要统一吗？
条件类别可以统一，阈值不必统一。核心交易类原型对流程覆盖率和状态规则的要求更严，内部工具类原型可以在未覆盖流程上留出说明空间。关键是同一项目内口径一致，并且阈值调整要写入评审记录，说明调整理由和适用范围。跨项目比较指标时，要先确认分母口径、统计时间窗和等级划分规则是否一致，否则比率之间不具备可比性。
评审意见分散在聊天工具里，闭环率怎么统计才可靠？
先把意见收敛到一个可统计的载体，再计算闭环率。可以按“提出人、对应页面或流程、等级、责任人、处理状态”这几个字段建立意见记录，评审结束后由主持人统一整理，聊天记录中的口头意见经确认后补录。统计时以这份记录为准，注明截止时间。在ONES中，评审意见可以作为工作项记录状态与责任人，原型说明作为文档与对应版本关联，闭环情况按状态汇总，减少人工核对成本。
