评估AI在需求分析与整理中是否漏掉约束，核心是建立一套可复算的核对方法：先把原始需求素材中的约束逐条列出并区分硬约束与软约束，再对AI整理结果分层抽样、逐条判定保留或遗漏，最后用“已覆盖约束数÷应覆盖约束数”计算覆盖率，并按约束类型分别设定阈值。硬约束按零遗漏核对，软约束按比例阈值管理。本文给出指标口径、抽样留痕方式、六步计算流程和一个带数字的演示，并说明阈值调整与结果解读的边界。
要点总览（TL;DR）
- 约束覆盖率 = 已覆盖约束数 ÷ 应覆盖约束数 × 100%，分母以原始需求素材中可识别的约束条目为准，按需求单或版本批次统计。
- 硬约束（合规、安全、接口上限、性能下限等）按逐条零遗漏核对，出现一条遗漏即判定本批次不通过；软约束（偏好、优先级、体验期望等）按风险等级设比例阈值。
- 抽样按需求类型、约束类型、AI输出长度分层，高风险硬约束层全量核对；语义漂移计为部分覆盖、无法判定的条目单列，均不计入覆盖率分子。
- 覆盖率是过程指标，需与部分覆盖率、不可判定占比、误增率一起解读；阈值随需求类型与风险等级调整，不设通用达标线。
- 评估结果应回到改进闭环：把遗漏集中的约束类型写入提示词、把漂移样本整理成判定示例、把反复出现的不可判定条目转为澄清清单。
评估目标：要回答AI整理后约束有没有丢
评估对象是AI辅助需求分析与整理这一环节的产出：AI整理后的需求文档或需求条目，相对原始需求素材（会议记录、用户反馈、业务方邮件、既有接口文档等）是否保留了其中的约束信息。评估边界止于“约束是否被保留、改写或遗漏”，不延伸到需求价值判断、排期合理性或文档成稿质量。
一次评估需要回答三个问题：
- 漏了哪些：逐条列出被遗漏或被改写的约束，定位到具体需求条目和原文位置。
- 漏在什么类型：遗漏集中在硬约束还是软约束，集中在某类需求（如接口类、合规类）还是某类输出长度，用于判断问题出在提示词、上下文截断还是模型理解。
- 是否可接受：对照按类型设定的阈值，判断本批次结果能否进入下一环节，还是需要补充人工复核。
评估结果有三个直接用途：调整提示词中约束的表述方式与强调顺序；确定人工复核的重点范围（例如硬约束全量复核、软约束抽检）；为AI整理环节设定验收门槛，作为需求进入评审前的检查项。明确这三个用途，可以避免评估滑向“给AI打分”而缺少改进行动。
指标与范围：覆盖率怎么定义、统计哪些约束
主指标是约束覆盖率，公式为：约束覆盖率 = 已覆盖约束数 ÷ 应覆盖约束数 × 100%，单位为百分比。分子是经核对判定为“保留”或“语义等价改写”的约束条数；分母是原始需求素材中可识别的约束条目总数。统计时间窗按需求单或版本批次确定，例如“某版本迭代内提交AI整理的20份需求单”，同一批次内分母口径保持一致，跨批次比较时需说明批次构成差异。
约束的识别口径需要事先约定：一条约束指对系统行为、边界、质量或体验的明确限定，通常表现为数值上限下限、必须满足的规则、禁止事项、依赖条件或明确的优先级要求。模糊表述如“尽量快”“体验要好”若在原始素材中未被量化，应标注为“约束本身模糊”，单独统计，不与明确约束混算。
| 指标名 | 公式 | 分子 | 分母 | 单位 | 时间窗 |
|---|---|---|---|---|---|
| 约束覆盖率 | 已覆盖约束数 ÷ 应覆盖约束数 × 100% | 判定为保留或语义等价改写的约束数 | 原始素材中可识别的约束条目数 | % | 按需求单或版本批次 |
| 硬约束覆盖率 | 已覆盖硬约束数 ÷ 应覆盖硬约束数 × 100% | 保留的合规、安全、接口上限、性能下限等条目 | 原始素材中的硬约束条目数 | % | 同上 |
| 软约束覆盖率 | 已覆盖软约束数 ÷ 应覆盖软约束数 × 100% | 保留的偏好、优先级、体验期望等条目 | 原始素材中的软约束条目数 | % | 同上 |
| 遗漏率 | 遗漏约束数 ÷ 应覆盖约束数 × 100% | 判定为遗漏的约束数 | 同覆盖率分母 | % | 同上 |
| 误增率 | 误增约束数 ÷ AI输出约束总数 × 100% | AI输出中原始素材不存在的约束数 | AI整理稿中识别出的约束总数 | % | 同上 |
硬约束与软约束的划分标准是“是否可协商”。硬约束包括合规与监管要求、安全与权限规则、接口字段与调用上限、性能下限、数据保留期限等，一旦丢失可能造成返工、合规风险或线上故障，按逐条零遗漏核对。软约束包括交互偏好、优先级排序、体验期望、文案风格等，可在评审中协商调整，按比例阈值管理。划分由需求负责人和评审人共同确认，存在争议的条目先按硬约束处理，待澄清后再调整分类。
误增率用于发现另一类问题：AI在整理时补充了原始素材没有的约束，例如自行加上“响应时间不超过200毫秒”。误增不一定都是错误，但必须逐条确认来源，否则会把模型推测当成业务事实带入后续设计。
数据口径与证据：抽样核对怎么留痕
全量核对成本高，通常采用分层抽样。分层维度建议至少覆盖三类：需求类型（如功能需求、接口需求、合规相关需求）、约束类型（硬约束、软约束）、AI输出长度（短、中、长，用于观察长文档是否更容易丢约束）。每层按批次规模确定抽样量，高风险需求（涉及合规、安全、对外接口）的硬约束层建议全量核对，其余层可按比例抽取。样本量过小时，结论只作参考，不用于跨批次比较。
核对证据需要保证他人可以复算，至少保留三类材料：原始需求素材（标注约束所在位置）、AI整理稿（对应版本）、逐条判定记录。判定记录表建议包含以下字段：
- 约束编号、所属需求单、原始素材位置
- 约束原文摘录、约束类型（硬/软）、风险等级
- AI整理稿中的对应表述及位置
- 判定结果：保留 / 语义等价改写 / 部分覆盖（语义漂移）/ 遗漏 / 误增 / 不可判定
- 判定人、判定日期、备注（如漂移的具体差异）
判定规则需要统一：改写后语义等价（如“不超过500毫秒”改为“响应时间上限500ms”）计为覆盖；语义发生漂移（如“仅限内网访问”改为“建议内网访问”）计为部分覆盖并单列，不计入覆盖率分子；原始素材本身表述模糊、无法判断是否被保留的条目计为不可判定，同样单列。部分覆盖和不可判定条目在报告中单独呈现数量与占比，避免被覆盖率数字掩盖。
计算与评估步骤：从抽样到覆盖率的完整流程
以下六步构成一次完整评估，可按批次重复执行。
步骤一：建立约束清单并标注硬/软。由需求负责人从原始素材中逐条摘出约束，编号并标注类型与风险等级，形成本批次的“应覆盖约束清单”。清单需经评审人确认，确认后的分母不再随意变动；后续发现漏列约束，应记录为清单修订并说明对结果的影响。
步骤二：确定抽样量与分层比例。按需求类型、约束类型、输出长度分层，高风险硬约束层全量核对，其余层按批次规模设定抽样比例。抽样时记录随机或系统抽样的方式，保证样本可追溯。
步骤三：逐条核对并记录判定。对照原始素材与AI整理稿，按统一判定规则填写核对记录表。遇到语义漂移或不可判定，写明具体差异，不直接归入通过。
步骤四：计算分层覆盖率与总体覆盖率。先分别计算硬约束覆盖率、软约束覆盖率，再计算总体覆盖率。同时统计遗漏率、误增率、部分覆盖率与不可判定占比。分母为零的层（例如本批次没有合规类约束）标注“不适用”，不参与总体加权，也不写成0%。
步骤五：按类型设定可接受线。硬约束的可接受线为零遗漏，出现任何一条硬约束遗漏即判定本批次不通过，需补充人工复核并修正整理稿。软约束按风险等级设比例阈值，例如高风险需求软约束覆盖率不低于90%，一般需求不低于80%，具体数值由团队结合历史批次表现确定。阈值是验收门槛，不是行业标准。
步骤六：复核异常样本并形成改进项。对遗漏、误增、部分覆盖的样本回溯原因：是提示词未强调、上下文超长被截断、原始素材表述分散，还是模型自行推断。将原因对应到具体改进动作，例如在提示词中单列“硬约束必须原文保留”、对长文档分段整理、对模糊约束先发起澄清。
在团队协作层面，约束清单、核对记录和评估结论需要有稳定的承载位置，才能被复算和追溯。ONES 中可将约束清单与核对记录作为工作项或 Wiki 页面管理，评估结论随需求单流转；ONES Assistant 能基于项目、工作项和 Wiki 上下文回答问题并执行操作，输出过程可追踪、结果可审计，便于把评估中发现的遗漏项转成待澄清问题或复核任务，减少在多个页面之间搬运记录。
例子：一次需求批次的覆盖率计算演示
以下为演示情景，数字用于说明计算过程，不代表任何真实项目结果。
某批次共整理12份需求单，从原始素材中识别出约束80条，其中硬约束20条、软约束60条。按分层抽样核对：硬约束全量核对20条，软约束抽取30条。核对结果如下：硬约束中保留18条、语义等价改写1条、遗漏1条；软约束抽样30条中保留24条、语义等价改写2条、部分覆盖2条、遗漏1条、不可判定1条。
| 层级 | 应覆盖数 | 覆盖数（保留+等价改写） | 部分覆盖 | 遗漏 | 不可判定 | 覆盖率 |
|---|---|---|---|---|---|---|
| 硬约束（全量） | 20 | 19 | 0 | 1 | 0 | 95% |
| 软约束（抽样30条） | 30 | 26 | 2 | 1 | 1 | 86.7% |
计算过程：硬约束覆盖率 = 19 ÷ 20 × 100% = 95%；软约束抽样覆盖率 = 26 ÷ 30 × 100% ≈ 86.7%。软约束全量60条若按抽样比例推算，覆盖约52条，但推算值仅作参考，报告中应同时给出抽样口径和样本量。
阈值判定：硬约束出现1条遗漏，按零遗漏规则判定本批次不通过，需定位该条约束（演示中为“仅允许管理员导出明细数据”被改写为“支持导出明细数据”），修正整理稿并复核同批次其他权限类表述。软约束覆盖率86.7%，若该批次一般需求阈值为80%，则软约束层通过；部分覆盖2条和不可判定1条单列，交由需求负责人确认语义后再决定是否计入。
误增检查：AI整理稿中共识别出约束85条，其中3条在原始素材中找不到来源，误增率 = 3 ÷ 85 × 100% ≈ 3.5%，需逐条确认是否为合理补充，确认无来源的从整理稿中删除。
解读与限制：阈值不是质量保证
覆盖率是过程指标，反映AI整理环节对约束的保留程度，不能等同于需求质量或交付质量。约束被完整保留，需求仍可能因为约束本身不合理、优先级判断错误或业务方向变化而需要调整；覆盖率高的批次也可能存在约束表述不清的问题。解读时应把覆盖率与部分覆盖率、不可判定占比、误增率放在一起看，单看一个数字容易得出片面结论。
几种情况需要特别处理：样本量过小时，覆盖率波动大，结论只作参考，不用于考核；某层分母为零时标注“不适用”，不按0%处理，也不强行并入总体；原始素材中约束本身模糊时，先发起澄清，澄清前的条目计入不可判定，不计入遗漏，避免把素材问题算成AI问题。跨批次比较时需确认需求类型构成、约束密度和抽样比例是否可比，不可比时只做趋势参考。
阈值应随需求类型与风险等级调整，不设通用达标线。涉及合规、安全、对外接口的批次，硬约束零遗漏是底线，软约束阈值可适当提高；内部工具类、探索性需求可放宽软约束比例，把复核资源集中在硬约束上。阈值调整应基于若干批次的实际表现和改进动作的效果，调整时记录依据，避免频繁变动导致结果无法比较。
评估结果最终要回到改进闭环：把遗漏集中的约束类型写入提示词约束、把语义漂移样本整理成判定示例、把反复出现的不可判定条目转为澄清清单，并据此调整人工复核的范围和深度。阈值的作用是触发复核和修正，而不是替代人工判断。
常见问题
硬约束和软约束的边界有争议时怎么处理？
划分标准是“是否可协商”，但实际评审中常遇到介于两者之间的条目，例如“首屏加载不超过2秒”既涉及体验又可能影响转化。处理方式是：由需求负责人和评审人共同确认分类，存在争议的条目先按硬约束处理，按零遗漏核对，待澄清后再调整分类并记录调整依据。这样做的原因是硬约束核对成本更高但漏检代价更大，先严后松比先松后严更安全。分类调整后，本批次的分母与覆盖率需重新计算，并在报告中注明修订。
抽样核对发现遗漏后，是否需要把整批需求重新全量核对？
取决于遗漏的性质。如果遗漏集中在硬约束，或同一类表述在多份需求单中反复出现（例如权限限定被统一改写），建议对同批次相关类型做全量复核，因为这类问题往往来自提示词或上下文处理的系统性原因。如果遗漏是零散的软约束个案，且抽样比例已覆盖主要分层，可先修正样本内条目，再在下一批次观察是否复现。无论哪种情况，都应把遗漏样本回溯到原因，形成改进项后再决定复核范围，避免每次评估都退化为全量人工核对。
分母为零的层怎么处理，会不会影响总体覆盖率？
分母为零表示该批次没有该类约束，例如本批次不涉及合规要求，此时该层标注“不适用”，不参与总体加权，也不写成0%。总体覆盖率按实际有约束的层合并计算分子分母，而不是对各层覆盖率取简单平均，否则会让小样本层获得过高权重。报告中应同时列出各层的应覆盖数与覆盖数，让读者看到总体数字由哪些层构成。跨批次比较时，如果某层从“不适用”变为有约束，需说明构成变化，否则趋势对比会失真。
软约束的阈值定多少合适，能不能直接沿用其他团队的数字？
软约束阈值没有通用标准，直接沿用其他团队的数字风险较大，因为需求类型构成、约束密度和复核资源都不同。可行做法是先跑若干批次，记录软约束覆盖率、部分覆盖率和不可判定占比的实际分布，再结合风险等级设定：高风险需求可设较高比例，内部工具类或探索性需求可适当放宽。阈值设定后应稳定执行一段时间，调整时记录依据和调整前后的批次表现，保证结果可比较。阈值的作用是触发复核和修正，不替代人工判断。
评估结果如何落到日常协作中，避免只停留在报告里？
关键是让约束清单、核对记录和评估结论有稳定的承载位置，并能随需求单流转。可以在项目管理工具中把约束清单和核对记录作为工作项或文档页面管理，评估结论关联到对应需求单；遗漏项转为待澄清问题或复核任务，指派给需求负责人跟进。ONES 中可将约束清单与核对记录作为工作项或 Wiki 页面管理，ONES Assistant 能基于项目、工作项和 Wiki 上下文回答问题并执行操作，输出过程可追踪、结果可审计，便于把评估中发现的遗漏项转成后续任务，减少在多个页面之间搬运记录。这样评估结果才能进入下一轮提示词调整和复核范围设定。
