如何评估AI需求约束覆盖情况并设定阈值

评估AI整理需求时是否把约束保留下来，可以拆成一套可复算的流程：先建立约束清单并区分硬约束与软约束，再按分层抽样核对AI输出的需求文档，统计遗漏条数与加权覆盖率，最后按硬约束零遗漏、软约束允许少量遗漏的原则设定阈值。本文给出指标定义、抽样与核对记录、计算步骤、一个批次示例和阈值设定方法，适用于理解与整理需求环节的验收与改进。

要点总览（TL;DR）

• 把约束覆盖拆成可复算指标：先建约束清单并区分硬约束与软约束，再按分层抽样核对AI整理后的需求文档，统计遗漏条数与覆盖率。
• 覆盖率＝被保留约束数÷应覆盖约束总数，以“条”为单位；分母是抽样范围内应覆盖的约束条数，不是需求条目数。
• 抽样按需求条目规模、约束类型和处理批次分层，硬约束建议全量核对，核对记录需包含约束编号、原文出处、AI输出位置和判定依据。
• 阈值分层设定：硬约束以零遗漏为默认要求，出现遗漏即触发复核；软约束按需求风险等级设定可接受遗漏率区间，连续多个批次稳定后再固定。
• 覆盖率只反映约束保留程度，受约束清单完整性、判定口径和抽样偏差影响，需与人工评审结论并列使用。

评估目标：要回答哪几个问题

评估对象是AI辅助需求分析与整理后产出的需求文档或需求条目，关注它对原始约束的保留程度。评估不覆盖需求价值判断、优先级排序和方案设计质量，这些仍需人工评审完成。

一次评估至少要回答三个问题：硬约束是否全部保留；软约束的遗漏比例是多少；遗漏集中在哪类约束、哪个处理批次。三个问题对应不同的动作，第一个决定是否触发复核，第二个反映整体保留水平，第三个指向提示词和模板的改进方向。

评估结果的使用边界需要提前说清。覆盖率用于改进提示词、调整核对流程和作为批次验收的参考，不能单独作为需求质量结论，也不能据此推断AI能力的上限。把覆盖率与人工评审结论并列使用，才能形成完整判断。

指标与范围：约束清单、分层与统计口径

约束清单是整套评估的分母来源，应覆盖原始需求文档、会议记录、接口文档与合规要求四类输入。建清单时逐条编号，记录原文出处和所属需求条目，确保每条约束都能回溯到原始材料。

硬约束与软约束按违反后果划分。涉及合规、安全、接口契约、不可回退的业务规则，通常归为硬约束；表述偏好、体验优化、可延后处理的项归为软约束。划分标准应在评估开始前书面固定，避免核对时逐条临时判断造成口径漂移。

约束类型	判定依据	示例	遗漏后果
硬约束	违反会导致合规风险、接口不兼容或业务不可回退	登录必须支持双因素认证；订单金额字段精度为两位小数	需返工或上线受阻
软约束	影响体验或表述完整性，可延后处理	错误提示语需包含操作建议；列表默认每页20条	体验下降，可后续补充

指标定义如下：约束覆盖率＝被保留约束数÷应覆盖约束总数；遗漏率＝遗漏约束数÷应覆盖约束总数。两者以“条”为单位，结果用百分比表示，保留一位小数。分母是抽样范围内应覆盖的约束条数，不是需求条目数，也不是AI输出的段落数。

统计范围分三个口径：按需求条目统计，看单条需求的约束保留情况；按约束类型统计，看硬约束与软约束各自的遗漏分布；按批次统计，看不同提示词版本或不同处理时间的整体表现。三个口径共用同一份核对记录，汇总时分别透视。

数据口径与证据：抽样方案和核对记录

全量核对成本高时采用分层抽样。分层维度包括需求条目规模（如约束条数多少）、约束类型（硬约束与软约束分开）和AI处理批次。各层内随机抽取，硬约束单独成层，避免被软约束数量稀释而漏检。

样本量按评估目的确定。用于批次验收时，样本应覆盖每个硬约束层和主要软约束类型，硬约束建议全量核对；用于趋势观察时，可按固定比例抽取并保持各批次抽样比例一致，保证结果可比。样本量确定后写入评估方案，中途不随意调整。

核对记录是分子分母可追溯的关键，建议包含以下字段：

• 约束编号与所属需求条目
• 约束原文及出处（文档、会议记录、接口文档）
• AI输出中的对应位置（章节、段落或条目编号）
• 是否保留（保留／部分保留／遗漏）
• 判定人与判定依据
• 判定日期与所属批次

缺失值与不可判定项单独标记。约束原文缺失、AI输出中无法定位对应内容、或判定人对标准有分歧的条目，记为“不可判定”，不计入分子也不计入分母，并在汇总表中单列数量。不可判定比例过高时，应先修正约束清单或判定标准，再重新核对。

核对记录与约束清单需要承载在团队日常使用的协作工具中，便于多人分工核对和后续复算。ONES 的工作项与 Wiki 页面可以分别承载约束条目和核对记录，ONES Assistant 能理解项目与 Wiki 上下文，将整理结果保存为工作项或 Wiki 页面，便于把AI输出与核对结论放在同一处对照。

计算与评估步骤：从核对到出数

计算按固定顺序执行，保证不同人复算得到相同结果：

1. 建立约束清单并完成硬软划分，锁定分母。
2. 按分层方案抽样，确定本次核对范围。
3. 逐条核对AI输出，填写核对记录。
4. 按约束类型汇总保留数与遗漏数。
5. 计算覆盖率与遗漏率。
6. 按需求条目和批次分别看遗漏分布。

公式与单位：覆盖率＝保留约束条数÷应覆盖约束条数×100%，遗漏率＝遗漏约束条数÷应覆盖约束条数×100%，结果保留一位小数。部分保留的条目按判定标准归入保留或遗漏，标准需在评估方案中写明，不能逐条灵活处理。

分母为零时标注“不适用”，不记为100%。例如某批次没有硬约束，硬约束覆盖率一栏填“不适用”，避免把空集误读为满分。

重复约束先去重再计入分母。同一约束在需求文档和会议记录中重复出现时，按约束编号合并为一条，保留最完整的原文出处。跨批次合并时按约束编号对齐，同一约束在不同批次被多次处理，只计一次，遗漏判定以最终版本为准。

汇总维度	应覆盖条数	保留条数	遗漏条数	覆盖率	遗漏率
硬约束	—	—	—	—	—
软约束	—	—	—	—	—
合计	—	—	—	—	—

例子：一个需求批次的覆盖率计算

以下为演示情景，数据仅用于说明计算过程。某批次需求整理后，约束清单共登记40条约束，其中硬约束12条、软约束28条。按分层抽样核对全部硬约束和14条软约束，共核对26条，其余软约束本批次未纳入核对范围。

核对结果：硬约束保留11条、遗漏1条；软约束保留12条、遗漏2条。按类型分别计算：

• 硬约束覆盖率＝11÷12×100%≈91.7%，硬约束遗漏率＝1÷12×100%≈8.3%
• 软约束覆盖率＝12÷14×100%≈85.7%，软约束遗漏率＝2÷14×100%≈14.3%
• 合计覆盖率＝23÷26×100%≈88.5%，合计遗漏率＝3÷26×100%≈11.5%

若按约束总量加权，需先把未核对软约束排除在分母外，不能直接用40作为分母，否则会把未核对项误算为遗漏。加权覆盖率用于比较不同批次的整体保留水平时，各批次应采用相同的抽样比例和相同的硬软构成口径。

结果解读：硬约束出现1条遗漏，按后文阈值规则应触发复核，需确认该约束是AI整理时丢失还是原文表述不清。软约束遗漏2条，需查看遗漏集中在哪类约束，例如是否集中在提示语和默认值类约束，据此调整提示词中的约束提取要求。

阈值设定：硬约束与软约束的分层标准

硬约束以零遗漏为默认要求。只要核对范围内出现硬约束遗漏，即触发该需求条目的复核，复核确认后再决定是否放行。这一标准的依据是硬约束遗漏的返工成本和合规风险显著高于核对成本。

软约束按可接受遗漏率设定区间。区间依据来自需求风险等级和返工成本：风险高、返工代价大的需求取更严的区间，风险低、可后续补充的需求可适当放宽。区间应写成明确数值，便于批次验收时直接比对。

需求风险等级	硬约束阈值	软约束可接受遗漏率	触发动作
高（合规、资金、核心接口）	零遗漏	≤5%	超阈值即复核并暂停放行
中（主要业务流程）	零遗漏	≤10%	超阈值触发复核，可带条件放行
低（体验优化、内部工具）	零遗漏	≤20%	记录遗漏并纳入下轮补充

表中区间为方法示例，团队应结合自身返工成本和历史数据校准后使用。阈值验证方式是连续多个批次观察遗漏率的稳定性：若软约束遗漏率在多个批次间波动明显，说明约束清单或判定标准尚不稳定，此时不宜固定阈值，应先统一口径再观察。稳定后再把阈值写入验收规则，并保留调整记录。

解读与限制：结果怎么用、哪里会失真

覆盖率反映的是约束保留程度，不能直接等同于需求质量，也不能作为AI能力的因果结论。覆盖率高的批次仍可能存在约束清单本身不全的问题，覆盖率低的批次也可能因为抽样偏向而失真。

常见失真来源有四类：约束清单不全，导致分母偏小、覆盖率虚高；判定标准不一致，不同核对人对“部分保留”的处理不同；抽样偏差，硬约束未被充分覆盖；硬软约束划分主观，同一约束在不同批次被归入不同类别。评估方案中固定划分标准和判定规则，是控制失真的主要手段。

结果应进入改进闭环：把遗漏按约束类型归类，反馈到提示词的约束提取要求、需求模板的必填项和人工核对环节。例如接口精度类约束反复遗漏，可在提示词中显式要求逐条保留数值精度和单位，并在核对清单中单列该类约束。

复评节奏建议与批次节奏一致，每个批次出一次覆盖率，按季度或提示词版本变更时做版本对比。版本对比时需保证约束清单、抽样比例和判定标准一致，否则前后数据不可比。ONES Assistant 可基于项目与 Wiki 上下文提炼待澄清问题与拆解建议，配合工作项和 Wiki 页面留存核对记录，使遗漏统计与改进动作在同一流程中衔接；具体度量报表能力以团队实际配置为准。

常见问题

硬约束数量很少时，还要单独分层抽样吗？

建议单独成层并优先全量核对。硬约束条数少时，按比例抽样容易抽不到，一旦遗漏又直接触发复核，抽样成本反而更高。若某批次硬约束只有几条，逐条核对更省事，也能避免被软约束的数量稀释。

硬约束确实为零的批次，覆盖率一栏标注“不适用”，不要记为100%。

“部分保留”的约束在统计时算保留还是遗漏？

这属于判定口径问题，需要在评估方案里提前写死，不能核对时逐条灵活处理。常见做法是看约束的关键要素是否齐全：数值、单位、触发条件等要素缺失且会影响实现的，归入遗漏；仅表述位置不同但要素完整的，归入保留。

口径固定后，同一类情形在不同核对人之间应得到相同结论，否则覆盖率会随核对人变化而波动。

软约束遗漏率连续几个批次都超过阈值，应该先调阈值还是先改流程？

先查遗漏分布再决定。如果遗漏集中在某一类约束，例如提示语或默认值类，说明提示词和核对清单有改进空间，优先调整提取要求和模板必填项。如果遗漏分散在各类型且比例稳定，可能是阈值定得过严，可结合返工成本重新校准区间。

调整阈值需保留记录，说明调整依据和生效批次，避免前后数据不可比。

跨批次对比覆盖率时，最容易出现什么问题？

最常见的是口径不一致：约束清单增删、抽样比例变化、硬软划分调整，都会让前后数据失去可比性。做版本对比前，应确认约束清单版本、抽样比例和判定标准保持一致，跨批次合并时按约束编号对齐，同一约束只计一次。

提示词版本变更后首次出数，建议与上一版本用同一批需求做对照核对，再判断覆盖率变化是否真实。

核对记录放在哪里，才能支持多人分工和后续复算？

核对记录需要与约束清单放在同一处可检索的位置，字段固定、可按批次和约束类型筛选。ONES 的工作项与 Wiki 页面可以分别承载约束条目和核对记录，ONES Assistant 能理解项目与 Wiki 上下文，将整理结果保存为工作项或 Wiki 页面，便于把AI输出与核对结论放在同一处对照；具体字段与模板配置以团队实际设置为准。