原型评审覆盖度可以拆成三个可复算的指标：清单项覆盖率、原型页面覆盖率和问题闭环率。统计前先固定评审范围、清单版本和时间窗，按页面和清单项逐条记录，再按公式计算并核对分母。评估时结合问题密度和返工情况解释结果，覆盖度用于说明评审过程是否完整，评审质量还需要其他证据支撑。
要点总览（TL;DR）
- 原型评审覆盖度拆成三个可复算指标：清单项覆盖率（已评审清单项数÷应评审清单项数）、原型页面覆盖率（已评审页面数÷本期应评审页面数）、问题闭环率（已关闭评审问题数÷已提出评审问题数）。
- 统计前先固定版本号、模块范围、清单版本和时间窗，分母一旦确定不再改动；分母为零时如实说明本期无对应对象，不计算比率。
- 评审记录至少保留页面标识、清单项编号、评审结论、问题描述、责任人、关闭时间六类字段，并维护清单版本与原型版本的对应关系。
- 计算按固定分母、逐条核对、代入公式、交叉核对四步执行，保留分子、分母和结果三个数字便于复算。
- 覆盖率需与问题密度、返工次数联合解读，不设通用达标线，由团队按历史基线确定参考区间；高覆盖率不能单独证明评审质量。
评估目标：覆盖度要回答哪几个问题
覆盖度评估服务于三个具体判断。第一，清单项是否都评到了：评审清单上的检查项，哪些有明确结论，哪些被跳过或遗漏。第二，页面是否都过审：本期需要评审的原型页面，是否都进入了评审流程并留下结论。第三，问题是否闭环：评审中提出的问题，是否都有责任人、处理结果和关闭记录。
这三个问题对应评审过程的不同环节。清单项覆盖率反映检查动作的完整性，页面覆盖率反映评审对象的完整性，问题闭环率反映评审结论的落地情况。三者合起来，才能回答“这次原型评审是否按计划做完、做完的部分是否形成结论”。
本文的范围限定在产品方案沟通与验证阶段的原型评审，评估对象是评审清单、原型页面和评审问题。需求质量评审关注需求描述是否准确、完整、可验证，视觉设计评审关注色彩、排版、交互细节的呈现效果，这两类评审有各自的检查标准和记录方式，不纳入本文的覆盖度计算。覆盖度结果主要用于三个场景：复盘一次评审的执行过程，发现清单或流程中的缺口，判断当前版本的评审是否可以结束。
指标与范围：三个覆盖度指标及统计口径
三个指标共用一套统计前提：统计范围按本期版本和指定模块界定，统计时间窗从评审启动到评审结论确认，统计单位分别为项、页、个。分母必须在计算前固定，不能边算边调整。
| 指标 | 公式 | 分子 | 分母 | 单位 | 时间窗 |
|---|---|---|---|---|---|
| 清单项覆盖率 | 已评审清单项数 ÷ 应评审清单项数 | 有明确评审结论的清单项数量 | 本期适用清单中应评审的清单项总数 | 项 | 评审启动至结论确认 |
| 原型页面覆盖率 | 已评审页面数 ÷ 本期应评审页面数 | 进入评审并留下结论的页面数量 | 本期版本中纳入评审范围的页面总数 | 页 | 评审启动至结论确认 |
| 问题闭环率 | 已关闭评审问题数 ÷ 已提出评审问题数 | 有处理结果和关闭时间的问题数量 | 评审过程中提出的问题总数 | 个 | 评审启动至约定关闭截止时间 |
分母的界定需要写清楚三件事：版本号、模块范围和清单版本。例如“V2.3 版本、订单模块、清单 2024-06 版”，这样不同人复算时能得到同一组数字。清单项覆盖率的分母只计入本期适用的清单项，清单中标注为“本期不适用”的条目应从分母中剔除并单独记录原因。原型页面覆盖率的分母以本期版本的原型文件为准，历史版本页面和已下线页面不计入。问题闭环率的分母是评审过程中正式提出的问题，口头提及但未记录的问题不进入分母，这类情况在记录规范中单独处理。
数据口径与证据：评审记录怎么留才可统计
覆盖度能否算准，取决于评审记录是否按统一字段留存。建议每条评审记录至少包含以下字段：页面标识（页面名称或编号）、清单项编号、评审结论（通过、有问题、跳过、不适用）、问题描述、问题责任人、问题关闭时间。清单项编号与清单版本绑定，页面标识与原型版本绑定，两组版本信息都要出现在记录中。
清单版本与原型版本的对应关系需要单独维护一张对照表。同一页面在 V2.2 和 V2.3 中可能对应不同清单项，混用版本会让分子和分母错位。实际操作中，评审启动时锁定清单版本和原型版本，评审过程中如需更新清单，记录变更时间和影响范围，计算时按锁定版本执行，变更部分单独说明。
缺失记录、跳过项和口头评审按以下规则处理：
- 缺失记录：清单项没有结论也没有跳过说明的，计入分母、不计入分子，并在复盘中列为待补记录。
- 跳过项：明确标注“跳过”并写明原因的，计入分母、不计入分子；标注“本期不适用”的，从分母中剔除。
- 口头评审：评审中口头确认但未留记录的，补录结论和确认人后才计入分子；无法补录的按缺失记录处理。
证据形式包括评审记录表、问题单和评审纪要。评审记录表承载逐项结论，问题单承载问题从提出到关闭的过程，评审纪要记录评审范围、参与人和例外情况。三类证据互相印证，计算时以评审记录表和问题单为主，纪要用来说明口径调整的原因。
当评审记录分散在文档、表格和问题跟踪工具中时，统计工作容易卡在汇总环节。ONES 提供工作项与文档管理能力，可以把清单项结论、评审问题和关闭状态记录在统一的工作项中，按版本和模块筛选后汇总数量，减少手工对表。具体字段配置和统计视图需要结合团队现有的评审流程设置。
计算与评估步骤：从记录到结论的操作顺序
计算按四步执行，每步留下可核对的中间结果。
第一步，固定范围与分母。确认版本号、模块范围、清单版本和时间窗，列出应评审清单项清单、应评审页面清单，分别数出分母。分母确定后写入统计表，后续不再改动。
第二步，逐条核对记录。按页面和清单项逐条检查评审结论，标记通过、有问题、跳过、不适用和缺失五类状态。问题单按提出时间和关闭时间核对状态。
第三步，按公式计算。分别计算三个指标的分子，代入公式得出比率。计算过程保留分子、分母和结果三个数字，便于复算。
第四步，交叉核对。用页面覆盖率乘以平均每页清单项数，与清单项覆盖率的分子做量级比对；用问题单数量与评审记录中“有问题”结论的数量比对，差异较大的要回查记录。
分母为零时需要单独说明。本期没有新增页面时，页面覆盖率不计算比率，写“本期无应评审页面”；清单项全部标注不适用时，同样不计算比率。分母为零不代表覆盖度是 100%，也不代表评审缺失，报告中如实说明对象不存在即可。
评估时把三个指标与问题密度、返工次数放在一起看。问题密度可以用每页问题数或每项清单问题数表示，返工次数指同一页面因评审问题修改后再次评审的次数。覆盖率接近完整但问题密度很低时，需要检查清单项是否过于笼统、评审是否流于形式；覆盖率完整且问题集中在少数清单项时，说明这些检查项需要细化或提前。评估结论建议分档表达，例如“完整覆盖且问题已闭环”“覆盖基本完整、部分问题待关闭”“覆盖存在明显缺口”，分档标准由团队根据历史基线确定，本文不设通用达标线。
例子：一个版本的原型评审覆盖度计算
以下为演示情景，数字用于说明计算过程。某版本订单模块原型评审，锁定清单 2024-06 版，统计时间窗为 6 月 3 日至 6 月 14 日。本期应评审页面 24 页，适用清单项共 180 项，评审中提出问 32 个，截至 6 月 14 日关闭 24 个。
清单项方面，有明确结论的清单项 162 项，其中通过 130 项、有问题 32 项；跳过 12 项，缺失 6 项。清单项覆盖率 = 162 ÷ 180 = 90.0%。
页面方面，进入评审并留下结论的页面 22 页，其中 2 页仅有部分清单项结论。原型页面覆盖率 = 22 ÷ 24 ≈ 91.7%。
问题闭环方面，已关闭问题 24 个，问题闭环率 = 24 ÷ 32 = 75.0%。
结果解读：页面覆盖率 91.7%，未覆盖的 2 页集中在退款流程，属于本期新增页面，评审排期遗漏；清单项覆盖率 90.0%，缺口主要来自 6 项缺失记录和 12 项跳过，跳过项中有 8 项集中在“异常状态提示”类检查项，说明该类清单项与当前原型阶段不匹配，需要在下一版清单中调整适用范围。问题闭环率 75.0%，未关闭的 8 个问题中有 5 个涉及接口字段确认，责任在外部依赖方，需要单独跟踪。
本例暴露的口径问题：最初统计时把 2 页历史版本页面计入了分母，导致页面覆盖率被低估；把口头确认的 4 个清单项直接计入分子，复算时无法找到记录。修正方式是分母只计本期版本页面，口头确认项补录后才计入分子。
解读与限制：覆盖度能说明什么、不能说明什么
覆盖度说明评审动作的执行范围，不能单独证明评审质量。高覆盖率配合较低的问题密度，可能意味着清单项设计得过于宽泛，评审人只需勾选即可通过；也可能意味着原型质量确实较好。区分这两种情况，需要看问题描述的具体程度、返工次数和后续开发中暴露的问题。
清单本身不完整时，覆盖率会虚高。分母只包含清单上列出的检查项，清单遗漏的检查维度不会进入计算。例如清单没有覆盖权限状态和空数据场景，这些维度即使完全没评，覆盖率仍可能显示接近 100%。因此每次复盘时应同步检查清单的完整性，把新发现的问题类型补充进下一版清单。
不同版本、不同模块之间的覆盖率可比性有前提条件：清单版本相同或检查项数量与粒度接近，页面复杂度相当，评审时间窗长度相近。跨版本比较时，应说明清单变更内容；跨模块比较时，应说明模块规模和评审人数差异。条件不一致时，比率差异可能来自口径而非评审执行。
覆盖度是过程指标，用于改进评审流程和清单设计。把它直接用于个人绩效结论会带来误读：覆盖率低可能源于排期紧张或范围界定不清，覆盖率高的评审人也可能只是完成了勾选动作。合理的使用方式是把覆盖度作为团队复盘的事实依据，结合问题闭环情况和返工记录，讨论流程中哪些环节需要调整。
常见问题
评审中途清单加了新检查项，分母要不要跟着改？
建议按评审启动时锁定的清单版本计算，中途新增的检查项不并入本期分母，单独记录变更时间和影响范围，在复盘中说明。这样同一版本内不同人复算能得到同一组数字。如果新增项确实属于本期必须评的内容，可以另起一个补充统计口径，把原清单和新增项分开计算，避免新旧口径混在一个比率里。
口头确认过的清单项，事后还能补进分子吗？
可以补录，但需要留下可核对的记录：补录结论、确认人和补录时间。补录完成后再计入分子。无法补录、找不到确认人的，按缺失记录处理，计入分母但不计入分子。把口头确认直接算作已评审，会让复算时找不到依据，覆盖度数字也就失去了核对基础。
页面覆盖率很高但问题很少，这种情况怎么判断？
先看问题描述的具体程度和返工记录。如果问题描述笼统、返工次数接近零，需要检查清单项是否过于宽泛，评审人是否只需勾选即可通过；如果问题描述具体、后续开发中暴露的问题也少，可能说明原型质量本身较好。两种情况在覆盖率数字上表现相同，区分它们要靠问题单内容和开发阶段的反馈，不能只看比率。
不同模块的覆盖率可以直接横向比较吗？
比较前要确认几个条件接近：清单版本相同或检查项数量与粒度相当、页面复杂度相当、评审时间窗长度相近。条件差异较大时，比率差异可能来自口径而不是评审执行情况。跨模块比较时建议同时说明模块规模、评审人数和清单差异，把比率放在这些背景信息一起看。
覆盖度结果能不能直接用于个人考核？
覆盖度是过程指标，更适合作为团队复盘的事实依据。覆盖率低可能源于排期紧张或范围界定不清，覆盖率高也可能只是完成了勾选动作。把它直接对应到个人绩效容易产生误读。更稳妥的用法是结合问题闭环情况、返工记录和清单改进建议，讨论流程中哪些环节需要调整。
