需求不完整时，测试用例生成的 Gate 应该怎么判？

AI Eval 系列 #11
上一篇：怎么把 AI Eval 接进 CI / Quality Gate？

测试用例生成链路增加校验后，会遇到一个现实问题：需求文档存在缺口，校验反复不通过，最后连供人工评审的草稿都没有生成。

这时需要拆开两个决定：哪些内容已经足以生成草稿，哪些内容已经足以作为正式测试依据。

允许前者，不等于批准后者。规则明确的部分可以继续生成；影响预期结果的未知项，需要显式保留并限制相关用例的状态，不能由模型补成确定事实。

本文延续执行契约与流程偏移的讨论，保留必要校验，同时细化 Gate 所控制的动作。以下规则是设计建议，业务示例和数字均为合成示例，不代表某个项目的实施结果。

一、一个 FAIL 标签解释不了所有问题

用例没有生成，可能来自几种完全不同的原因。

问题层次	示例	优先处理
输入缺口	文档没有说明重复提交时的处理规则	定位缺口，列出待确认问题
执行错误	文档有规则，但读取范围漏掉了对应章节	修正读取或解析，保留失败证据
产物质量	已知规则正确，但操作步骤不足以执行	修改相关用例并复检
校验器问题	语义等价的有效表达被模板匹配拒绝	修复校验器，补正反例回归

这些问题都进入同一个“失败后重新生成”循环，容易让 Agent 重读文档、重写产物，却没有补齐真正缺少的东西。

尤其需要注意：“没有读到”不等于“文档没有写”。 对大文档，需要记录已读取范围、查询结果和引用位置。检索尚未覆盖相关位置时，应写“当前读取范围未找到”，不能直接判定需求缺失。

二、Validator 记录事实，Gate 决定动作

Validator 的职责是说明发现了什么、影响哪里、依据是什么。Gate 根据这些事实，决定当前操作是否允许。

例如，校验器发现某条业务规则未确认：

{
  "check_id": "expected-result-grounding",
  "result": "unknown",
  "affected_requirements": ["REQ-03"],
  "source_scope": "example-spec-v1:section-6.2",
  "reason": "当前读取范围未找到重复提交处理规则"
}

这份结果本身不意味着所有生成工作都要停止。策略可以允许生成不依赖 REQ-03 的草稿，同时阻止 REQ-03 对应的用例进入“可执行”状态。

这里的 unknown 是本文示例中的结果值，不是通用标准。它既不是通过，也不是已确认的业务错误；它表达的是当前证据不足以作出判断。

Gate 的粒度取决于影响范围。某个局部规则缺失，可以隔离相关条目；如果整个权限模型都未确定，多个场景可能共享这一前提，就不能按条目机械放行。依赖范围还不清楚时，应先限制相关工作，查明依赖后再继续。

三、生成草稿和正式交付使用不同条件

“放宽门禁”太笼统。更具体的做法是给每个出口定义条件。

检查项	生成可评审草稿	作为正式测试依据
输入可读取、产物可解析	必须满足	必须满足
用例关联到需求或明确假设	必须保留关系	需求与假设均需完成适用的确认
影响预期结果的业务规则未知	隔离相关条目，继续独立部分	相关条目不得标为可执行
用例名称、步骤和预期不够明确	标记并待修订	修订到人员能够执行与判断
覆盖存在缺口	说明缺口和影响范围	由评审按交付范围处理
人工评审尚未完成	可以输出待评审版本	不标记为已批准

发布、执行或同步到其他系统，都应有各自明确的状态要求。平台支持“待评审草稿”并不意味着上传动作本身能保证质量；如果平台无法保留未知项、来源和评审状态，就不能用一次导入把这些差别抹平。

当前只需要交付草稿时，可以先完成草稿和评审清单。等正式交付条件满足后，再处理后续平台接入，避免把一次生成成功当成质量已经过关。

四、未知项不能靠合理猜测变成预期结果

假设需求只写了：“用户可以提交申请。”没有说明重复点击提交会发生什么。

下面两种输出，质量并不相同：

直接生成确定断言： 连续点击两次提交，系统提示“请勿重复提交”，且只生成一条记录。
保留待确认问题： 重复提交的处理规则待确认；候选测试点包括重复记录、重复请求反馈和幂等行为，确认规则后再形成预期结果。

第一种可能符合常见设计，但提示文案、记录数和处理方式都不是已给出的事实。第二种仍然推进了测试分析，同时保留了业务决策的位置。

可以让未知项关联来源范围、影响用例、需要回答的问题和后续处理状态。没有指定负责人时就留待分配，不由 Agent 编造一个人名。

人工确认规则后，还需要更新关联用例并重新验证。评审过一次文档，并不自动意味着后续新生成的全部产物也已评审。

五、覆盖报告必须展示分母和未知项

只对已解析条目计算覆盖率，很容易隐藏问题。

假设已识别 20 个需求条目，其中 15 个规则明确，5 个尚待确认。15 个明确条目都关联了用例，并不能据此声称“整体覆盖率 100%”。

更透明的报告可以是：

指标	合成示例
当前已识别的需求条目	20
规则明确的条目	15
规则明确且已关联用例的条目	15
未知或待确认条目	5
明确条目关联率	15 / 15
全部已识别条目中，规则明确且已关联用例的比例	15 / 20

这两个比例都只描述追溯关系，不能证明用例有效、已通过评审，也不能证明整份文档已经完整解析。 是否遗漏需求、是否覆盖关键风险、是否具备可执行步骤，需要另行检查。

如果需求总量尚未可靠建立，报告就说明分母仅是“当前已识别条目”。不要用一个精确百分比掩盖输入范围的不确定性。

六、门禁卡住时，先拿失败样本检查规则

发现 Gate 连续失败后，既不应直接删除所有检查，也不应默认校验器永远正确。

可以围绕同一检查建立四类小样本：

规则明确、用例正确：应该通过相应检查。
规则明确、用例遗漏：应该被识别为产物问题。
规则没有确认：应该保留未知状态，不生成确定断言。
文档有规则但解析漏读：应该暴露读取缺口，不能冒充输入本身缺失。

还应加入“无关条目可继续”和“共享前提缺失须阻塞相关范围”的对照，检查 Gate 是否误伤独立工作，或遗漏真实依赖。

Anthropic 关于 Agent Eval 的工程文章指出，模糊任务和评分器缺陷都可能造成失败，阅读执行记录有助于区分 Agent 的错误与评分器误判。对应到这里，门禁治理也需要检查输入、产物、证据和判定规则，不能只统计通过率。

修改规则后，应同时保留原本正确被拦截的样本和误拦截样本。让后者通过的同时，确认前者仍会被拦截，才能知道这次调整修复了什么。

七、下一次运行应该交付什么

一次有用的生成结果，至少包含三样东西：可评审的用例草稿、能够追溯到需求的关系、尚未解决的问题及影响范围。

运行报告再说明哪些范围已读取、哪些检查已执行、哪些条目可继续、哪些需要人工决定。遇到阻塞时，允许保留局部成果，但不能把局部完成改写成整项完成。

这样，必要的执行契约仍然有效：Agent 无权自行绕过失败检查；系统则可以依据事先明确的策略，允许独立部分推进。下一步该修读取、修用例、修校验器，还是请人确认业务规则，也就有了可核对的依据。

参考与继续阅读

Anthropic：Demystifying evals for AI agents：任务歧义、评分器校准与执行记录检查。
Agent 会跳步骤：从测试用例生成失败到 Execution Contract Drift：为什么必要阶段不能只靠 Prompt 约束。
怎样构造一套真正有用的业务 Eval Dataset？：把正常、边界和失败样本纳入评测。
让 Agent 下班后继续跑：有界自主运行怎么设计？：任务遇到未知项后如何停止、保存和恢复。