验收标准评审：找出歧义、缺失与不可验证的验收条件
需求写清楚了，并不代表团队对“做到什么程度才算完成”已经达成一致。实际项目中，一条看起来完整的验收标准，到了开发和测试阶段，仍然可能出现不同的理解：什么条件下触发、预期结果是什么、异常情况怎么处理、边界在哪里，以及最终应该如何验证。
这些问题如果没有在需求阶段暴露出来，通常会继续传递到开发、测试设计和验收阶段。测试人员不仅需要补充测试场景，还要反复回到需求中确认规则、追问细节，甚至重新对齐开发和产品对验收结果的理解。很多返工，并不是实现出了问题，而是团队一开始就没有把“如何判断需求完成”定义清楚。
验收标准评审（Acceptance Criteria Review）Skill 希望把这部分工作提前。它通过 AI 对需求背景、业务规则和 Acceptance Criteria 进行结构化分析，检查验收条件是否完整、预期结果是否明确、边界和异常场景是否覆盖，以及每一项标准是否真正可验证，并将发现的问题整理成可以直接进入需求讨论的评审结果。
它并不是替团队决定验收标准，而是帮助测试人员更快找到需要确认什么、哪里存在歧义、哪些条件还没有定义、哪些标准目前无法验证，让问题尽可能在编码和测试开始之前被发现。
本文将具体介绍这个 Skill 适合在什么时候使用、需要提供哪些输入、会检查哪些问题、最终产出什么，以及如何把评审结果带回真实的需求协作流程中。
验收标准评审 Skill 用来做什么
验收标准评审 面向需要把测试判断讲清楚、交接出去的工作。它把项目材料、判断依据和下一步动作放在同一条线上——读者可以先知道该检查什么，再决定怎么执行与复核。本文用一个具体场景展开，并保留需要人工确认的边界。
先回到源 Skill
这个 Skill 的完整执行规则在 验收标准评审 提示词。源目录还包含 3 个评测用例，用于验证输出是否遵守契约。
它要求特别注意：
- 不要替产品方决定缺失的业务规则
- 每条标准写成可观察结果
- 把阻塞开发或测试的歧义单独升级
用一份项目材料开始
先把当前拿得到的材料摆上来。缺口可以保留，状态必须说实话。
| 材料 | 这次填什么 | 缺失时的处理 |
|---|---|---|
| 目标与范围 | 审阅会员升级验收标准，找出歧义、缺失状态、不可验证的描述和业务规则冲突 | 标出不在本轮判断内的链路 |
| 版本与环境 | 需求版本、构建号、环境和时间窗口 | 降级为设计或分析，不写执行结论 |
| 证据 | 需求、接口、日志、指标、trace 或历史缺陷 | 区分事实、假设和待确认项 |
| 决策边界 | 谁确认风险，哪些动作未经授权不能执行 | 列出 Owner 和下一步 |
可以这样调用：
请使用 acceptance-criteria-review Skill。
任务：审阅会员升级验收标准，找出歧义、缺失状态、不可验证的描述和业务规则冲突
输入材料：[版本、链接、日志或报告路径]
范围：[本次包含和排除的对象]
限制：[时间、数据、权限、合规要求]
先审计输入，再按风险和证据强度排序。材料没有证明的内容标为假设，并列出验证方法。产物要能被下一位同事接住
| 输出字段 | 作用 | 示例状态 |
|---|---|---|
| 发现或判断 | 说明观察到的行为、差异或风险 | 已确认 / 假设 / 待确认 |
| 依据 | 指向版本、日志、trace、测试或需求 | source_id 或链接 |
| 影响 | 说明受影响的用户、链路或发布判断 | P0、P1 或接受的残余风险 |
| 下一步 | 指定验证动作和负责人 | Owner、截止时间、预期证据 |
没有运行记录、查询结果或原始材料时，不写“已通过”。静态分析和实际执行是两件事。
在项目里跑一轮
先用一个边界清楚的小回合启动——审阅会员升级验收标准，找出歧义、缺失状态、不可验证的描述和业务规则冲突。别急着把结果写成报告。先把输入版本、时间窗口和负责人贴到同一处；然后把每个判断连回具体材料；最后只安排一项能改变结论的验证动作。
用例应能从验收标准直接追溯，遇到不可验证的表述先回到需求负责人。这一轮交付应当包含：可复查的证据索引、仍然成立的假设、以及下一位同事可以直接执行的动作。这样做很朴素，也很有效。
在项目里跑一轮
先用一个边界清楚的小回合启动——审阅会员升级验收标准，找出歧义、缺失状态、不可验证的描述和业务规则冲突。别急着把结果写成报告。先把输入版本、时间窗口和负责人贴到同一处；然后把每个判断连回具体材料；最后只安排一项能改变结论的验证动作。
用例应能从验收标准直接追溯，遇到不可验证的表述先回到需求负责人。这一轮交付应当包含：可复查的证据索引、仍然成立的假设、以及下一位同事可以直接执行的动作。这样做很朴素，也很有效。
进阶使用：把一次分析变成持续机制
用例应能从验收标准直接追溯，遇到不可验证的表述先回到需求负责人。
每次输出都保存输入版本和 source_id。下一次发生需求、代码、环境或数据变化时，只重算受影响的判断，并将结果标记为 changed、unchanged 或 needs-review。这样不会把旧结论当成新证据。
三段式 Skill 链
requirements-analysis → acceptance-criteria-review → test-case-writing
| 交接 | 传递内容 | 接收方要检查什么 |
|---|---|---|
| 上游到 acceptance-criteria-review | 来源版本、范围、风险、未决项 | 输入是否过期，冲突是否标记 |
| acceptance-criteria-review 到下游 | 判断、证据索引、残余风险、待办 | 产物是否可执行，Owner 是否明确 |
| 下游回写 acceptance-criteria-review | 执行结果、缺陷、事实变化 | 是否更新基线与回归范围 |
交接时传摘要、证据索引和原始材料的位置。信息量足够，结论出了问题也能回到来源。
团队门禁
| 门禁 | 检查内容 | 未满足时 |
|---|---|---|
| acceptance-criteria-review 输入门禁 | 版本、环境、证据来源和 Owner | 停止生成，列出缺口 |
| acceptance-criteria-review 产物门禁 | 关键结论带依据、状态和影响 | 退回补证据 |
| acceptance-criteria-review 执行门禁 | 命令、查询或验证路径可复现 | 标记基础设施或测试问题 |
| acceptance-criteria-review 决策门禁 | 残余风险有接受人与日期 | 不进入下一阶段 |
容易踩的坑
- 只写检查点，不写输入条件、预期结果或证据。
- 把所有发现都标高优先级，团队无法取舍。
- 材料缺失时拒绝产出，或者反过来把猜测当成事实。
- 用一次成功或一次异常代表长期行为，忽略重复试验与版本差异。
两个实际问题
输入还不完整，能开始吗？
能。先交付受限初版：列出已知事实、假设、缺口和最小验证动作。环境、数据或权限缺失时，不写执行结论。
什么时候需要人工确认？
范围取舍、风险接受、生产操作、数据权限和发布决定必须由对应负责人确认。Skill 负责整理证据与选项，不替团队做授权决定。
先用一份真实材料跑通 验收标准评审，把输入、产物、人工修改和验证证据留在同一个工作链里。下一次变化发生时，才有东西可以复用。