AI需求约束覆盖率按“被正确保留并可追溯的约束条目数 ÷ 抽样需求中应存在的约束条目总数”统计，分母以人工核对的基准约束清单为准，分子只计在AI整理结果中明确出现、语义未变且能定位到具体位置的条目。统计时先区分硬约束与软约束，再分别计算覆盖率与遗漏率。这套口径适合评估AI在需求理解与整理环节的约束保留情况，阈值需要团队结合业务风险和试点基线自行设定。
要点总览（TL;DR）
- 覆盖率按条目数统计：被正确保留且可追溯的约束条数 ÷ 抽样需求中应存在的约束总条数；遗漏率 = 1 − 覆盖率，两者不重复计算。
- 分母以人工建立的基准约束清单为准，每条约束记录来源位置、原文、硬软类型和是否可验证；只有出现、语义一致、可定位三条同时满足才计入分子。
- 硬约束与软约束分层统计：硬约束遗漏按条计为高风险并逐条说明原因，软约束遗漏按条记录并观察分布趋势。
- 抽样按需求类型或风险分层，先定时间窗与纳入排除规则再定样本量；分母为零或样本不足的分层单独标注，不并入百分比。
- 阈值没有通用达标线，以试点基线数据校准并按风险分层设定，硬约束要求更严；跨批次比较时保持抽样口径与类型划分稳定。
评估目标：要回答AI漏了哪些约束
这项评估的对象是同一批需求在AI整理前后的约束保留差异：原始需求、会议记录和附件中已经明确的约束，在AI输出的需求文档或结构化条目中还剩下多少、漏掉了哪些。评估结果用于三个具体用途：发现AI容易遗漏哪类约束，判断某批整理结果能否进入评审或开发环节，以及在多轮试点之间跟踪覆盖率的变化趋势。
评估边界需要提前说清。本文只统计约束条目的覆盖情况，不评价文档结构、表达风格、排版等成稿质量，也不替代常规的需求澄清过程。约束本身的合理性、需求价值判断属于需求分析工作，不在覆盖率指标的范围内。把边界写进评估说明，可以避免后续把覆盖率高低直接等同于需求质量好坏。
指标与范围：覆盖率、遗漏率与分层口径
覆盖率采用条目数口径，单位为“条”，不使用百分比之外的加权分数。核心公式为：覆盖率 = 被正确保留并可追溯的约束条目数 ÷ 抽样需求中应存在的约束条目总数 × 100%。遗漏率 = 1 − 覆盖率，两者互为补数，同一批数据只计算一次，避免把“未覆盖”和“遗漏”重复计入两个指标。
| 指标 | 分子 | 分母 | 用途 |
|---|---|---|---|
| 总体覆盖率 | AI结果中正确保留且可定位的约束条数 | 基准清单中的约束总条数 | 看整体保留水平 |
| 硬约束覆盖率 | 正确保留的硬约束条数 | 基准清单中的硬约束条数 | 判断是否可进入下一环节 |
| 软约束覆盖率 | 正确保留的软约束条数 | 基准清单中的软约束条数 | 观察趋势与改进空间 |
| 遗漏条数 | 基准清单中未在AI结果中正确出现的条数 | — | 按类型归类分析遗漏模式 |
硬约束指违反即不可交付的强制条件，例如合规要求、安全限制、性能下限、必须支持的接口或平台；软约束指可以权衡的偏好条件，例如交互方式偏好、非关键的体验要求、可选的兼容范围。划分标准应在评估开始前由需求负责人和评审人共同确认并写入清单，同一批统计中不中途调整。硬约束遗漏按条计为高风险，需要逐条说明原因；软约束遗漏按条记录，重点观察分布和趋势。
统计范围要固定下来：明确纳入的需求批次、时间窗和排除规则。例如统计某迭代周期内进入需求评审的全部需求，排除重复提交和被撤回的条目。范围一旦确定，分子分母都从同一范围内取数，跨批次比较时保持口径一致。
数据口径与证据：约束清单怎么来
分母的可靠性取决于基准约束清单的质量。清单由人工从原始需求文档、评审会议记录、相关附件中逐条提取，每条约束记录以下字段：约束编号、所属需求、来源位置（文档章节或会议记录时间点）、原文摘录、约束类型（硬/软）、是否可验证、备注。来源位置和原文摘录是后续复核的关键，缺少原文的条目不能进入分母。
判定“已覆盖”需要同时满足三个条件：该约束在AI整理结果中有明确对应的表述；表述语义与原文一致，范围、数值、条件没有被放宽或收窄；能够定位到AI结果中的具体段落或条目。只有意思相近但条件发生变化的表述，例如把“响应时间不超过200毫秒”写成“响应较快”，不计入分子，按语义漂移单独记录。
缺失值和争议条目单独处理：原文本身模糊、无法判断是否构成约束的条目，标记为“待确认”，暂不进入分母；两位核对人对是否覆盖意见不一致的条目，记录双方理由，由第三人裁定后再计入。所有标记和裁定理由保留在清单中，保证结果可以复算。
计算与评估步骤：抽样、核对、汇总
第一步确定抽样方案。按需求类型或风险等级分层，例如按核心交易类、支撑类、体验类分层，每层按比例抽取，风险高的层可以适当提高抽样比例。先确定时间窗和纳入排除规则，再确定样本量；样本量过小时结论只作参考，不用于跨批次比较。
第二步建立基准清单。对抽中的每条需求，由需求负责人或熟悉背景的成员提取约束条目，填写来源位置、原文和类型，形成该批次的基准清单。
第三步逐条核对AI结果。核对人对照基准清单，在AI整理结果中查找对应表述，判断是否满足出现、语义一致、可定位三个条件，并在清单中记录覆盖状态和定位位置。建议采用双人复核：一人初核，另一人抽查或全量复核，争议条目按前述规则裁定。
第四步汇总计算。分别统计硬约束、软约束的应存在条数和已覆盖条数，计算分层覆盖率和总体覆盖率，再按遗漏类型归类，例如数值条件丢失、范围条件放宽、前置条件缺失、约束被合并后语义变化等。遗漏分布往往比总覆盖率更能说明问题出在哪个环节。
第五步处理特殊情况。某条需求基准清单中约束数为零时，该需求不进入覆盖率计算，单独标注为“无约束样本”；某分层样本不足或分母过小时，只报告条数和遗漏明细，不强行给出百分比结论。汇总时保留原始条数，便于不同批次之间按条对比。
在核对记录的管理上，基准清单、覆盖状态和争议裁定可以落到统一的工作项或文档中：ONES Assistant 能理解项目、工作项和 Wiki 页面等上下文，并可把自然语言指令转化为可追踪的工作项或 Wiki 页面内容，适合把核对任务分派给评审人、把裁定理由沉淀在文档里；其输出过程可追踪、结果可审计，便于后续复算。是否用工具承载这套流程，取决于团队已有的协作方式，清单字段和判定规则本身不依赖特定工具。
例子：一批需求的覆盖率怎么算
以下为演示情景，数字用于说明计算过程，非真实项目数据。假设某批次抽样20条需求，人工核对后基准约束共100条，其中硬约束40条、软约束60条。AI整理结果经双人核对，正确保留硬约束36条、软约束48条，另有3条表述相近但条件发生变化，按语义漂移不计入分子。
| 分层 | 应存在条数 | 正确保留条数 | 覆盖率 | 遗漏条数 |
|---|---|---|---|---|
| 硬约束 | 40 | 36 | 90% | 4 |
| 软约束 | 60 | 48 | 80% | 12 |
| 合计 | 100 | 84 | 84% | 16 |
计算过程：硬约束覆盖率 = 36 ÷ 40 = 90%；软约束覆盖率 = 48 ÷ 60 = 80%；总体覆盖率 = 84 ÷ 100 = 84%，遗漏率 = 16 ÷ 100 = 16%。遗漏的4条硬约束逐条记录原因，例如2条为性能下限数值丢失、1条为合规前置条件缺失、1条为接口范围收窄；遗漏的12条软约束按类型归类，观察是否集中在某类表述上。
结果解读示例：该批次硬约束覆盖率90%，仍有4条高风险遗漏，说明这批结果不能直接进入开发，需要针对遗漏条目补充后再评审；软约束覆盖率80%，遗漏集中在体验类偏好表述，可作为下一轮提示词或核对重点的改进方向。如果下一批次在相同抽样口径下硬约束覆盖率上升、硬约束遗漏条数下降，可以认为改进有效；单看总体覆盖率上升不足以得出这个结论。
阈值设定与结果解读的限制
可接受阈值没有通用标准，应由团队在试点批次的基线数据上设定，并按风险分层区别对待。硬约束通常要求更严，例如试点阶段可以先以“硬约束遗漏为零或经逐条确认可接受”作为进入下一环节的条件；软约束可以设定一个观察区间，重点看趋势而非单批次绝对值。阈值写进评估说明时，同时注明适用的需求类型、批次范围和样本量，避免把一次试点的阈值直接套到其他团队或业务上。
解读结果时注意几个限制。覆盖率只反映约束条目的保留情况，不保证需求整体质量，需要结合遗漏类型分布和人工评审综合判断。抽样若偏向某类需求，结果不能直接外推到全部需求；语义一致性判定带有主观成分，双人复核和争议记录可以降低偏差，但无法完全消除。分母为零的样本、样本量过小的分层，都应单独说明，不并入总体百分比。跨批次比较时保持抽样口径、约束类型划分和核对人相对稳定，否则覆盖率变化可能来自口径变化而非AI表现变化。
常见问题
AI整理结果里约束表述意思相近但条件变了，算覆盖还是算遗漏？
按遗漏处理，并单独标记为“语义漂移”。判定已覆盖要求语义与原文一致，范围、数值、条件没有被放宽或收窄。例如原文写“响应时间不超过200毫秒”，AI结果写成“响应较快”，条件已经丢失，不能计入分子。这类条目在清单中记录原表述、AI表述和差异点，汇总时与完全未出现的遗漏分开统计，便于判断问题出在提取环节还是改写环节。
一条需求里约束特别多，或者几条约束被AI合并成一句，怎么计数？
计数以基准清单的条目为单位，不以句子为单位。几条约束被合并表述时，逐条核对每条约束的条件是否都还在：全部保留且可定位，则每条都计入分子；其中一条的条件丢失，只把丢失的那条计为遗漏。反过来，一条约束在AI结果中被拆成多处表述，只要语义一致且能定位，仍按一条计入，不重复计数。评估开始前把合并与拆分的处理规则写进说明，避免不同核对人算法不一。
样本量多少才够用，小批量试点能不能算覆盖率？
没有统一的最小样本量，取决于需求类型分布和约束密度。实践中的做法是先按风险分层抽样，每层保证有足够条数支撑分层结论；某层分母过小时，只报告应存在条数、遗漏条数和遗漏明细，不强行给出百分比。小批量试点可以算覆盖率，但结论限定在该批次和该口径内，用于发现遗漏模式和校准阈值，不直接外推到全部需求。跨批次比较时保持抽样比例和分层方式一致。
硬约束遗漏为零是不是就可以直接进入开发？
硬约束遗漏为零是进入下一环节的必要条件之一，还需要看软约束遗漏的分布和人工评审结论。覆盖率只反映约束条目的保留情况，不评价需求本身的合理性和完整性。如果软约束遗漏集中在某类体验要求上，可能影响后续设计决策，需要在评审中补充确认。把“硬约束遗漏逐条确认可接受”和“软约束遗漏已归类并评估影响”同时作为放行条件，比单看一个百分比更稳妥。
核对记录和裁定理由放在哪里，后续怎么复算？
基准清单、覆盖状态、定位位置和争议裁定需要保存在同一处可追溯的位置，字段固定、版本可查，复算时才能按同一口径重跑。可以落在文档或工作项中统一管理：ONES Assistant 能理解项目、工作项和 Wiki 页面等上下文，并可将自然语言指令转化为可追踪的工作项或 Wiki 页面内容，适合把核对任务分派给评审人、把裁定理由沉淀在文档里，其输出过程可追踪、结果可审计。清单字段和判定规则本身不依赖特定工具，团队按现有协作方式承载即可。
