用 AI 设计验收标准：把“好用、稳定、快速”变成可观察证据
AI 可以发现模糊需求，却不能替团队定义完成。本文讲清如何用场景、正反例、边界、权限和非功能指标建立可验证验收标准。
需求写着“搜索要快、结果要准、操作要简单”。开发做完后说符合要求，产品却觉得不好用；测试不知道输入多少数据才算快，也不知道“准”是不能漏结果，还是排序更相关。所有人都认真工作，只是从一开始就没有共同的完成定义。
AI 可以发现模糊词、扩展场景和生成样例，但验收标准不是模型替团队写几句 Given-When-Then。它要把需求变成在什么条件下，谁执行什么动作，系统产生什么可观察结果，哪些边界和异常也必须成立。
好的验收标准让不同角色依据同一证据判断完成，而不是让句子看起来更正式。
先区分目标、需求和验收标准
| 层次 | 示例 |
|---|---|
| 目标 | 减少客服查订单的时间 |
| 需求 | 支持按手机号搜索订单 |
| 验收标准 | 有权限客服输入完整手机号后，三秒内返回该客户可见范围内订单 |
| 测试用例 | 具体账号、数据、步骤和预期结果 |
验收标准说明规则边界，测试用例用具体数据验证规则。两者相关但不相同，不能用几十条操作步骤掩盖一个仍未定义的业务决定。
先找出所有不可验证的词
快速、友好、智能、及时、尽量、正常、支持和优化都可能隐藏分歧。让 AI 标记这些词并提问：由谁观察、用什么指标、在哪种条件、阈值是多少、失败时看到什么。阈值必须由业务和技术共同确认，不能由模型猜。
从用户场景开始，不要从页面控件开始
“页面有下载按钮”只能证明控件存在，不能证明用户完成任务。更好的标准描述有权限用户选择日期范围后能获得包含规定字段的文件，并对超量、空结果和生成失败给出明确处理。
用 Given-When-Then 但别被格式绑架
Given 写相关前置状态，When 写单一触发动作，Then 写可观察结果。若一句话需要十个 And，可能混入多个规则，应拆分。格式服务于澄清，不是所有非功能要求都适合硬塞进三行模板。
同时写正例、反例和边界
正例说明允许什么，反例说明必须拒绝什么，边界说明规则在哪个点变化。例如最多上传 10 个文件，要确认 0、1、10、11 个，以及总大小、单文件大小、格式和重复文件如何处理。
权限标准要写对象和范围
“管理员可以查看”仍然模糊：哪类管理员、看哪些组织、是否能导出、被停用账号如何处理？验收标准要覆盖角色、资源、操作和范围，并验证无权限用户看不到数据、接口和错误细节。
状态变化要写前后条件
订单取消、审批通过和账号锁定都不是单个按钮结果。写明允许的起始状态、成功后的新状态、关联数据、事件、通知和重复操作。还要规定失败是否保持原状态以及如何重试。
非功能标准也必须可测
| 类型 | 需要说明 |
|---|---|
| 性能 | 负载、数据量、指标、分位数与阈值 |
| 可用性 | 观察窗口、排除项和恢复目标 |
| 安全 | 威胁、角色、资产和验证方法 |
| 可访问性 | 遵循标准、关键流程和辅助技术 |
| 兼容性 | 明确支持的版本、设备和降级行为 |
性能不要只写平均值
“平均响应小于两秒”可能掩盖少量用户等待二十秒。说明测试环境、并发、数据规模、缓存状态、P95 或 P99、错误率与持续时间。生产观察指标也应与验收口径对应。
错误处理是功能的一部分
网络中断、依赖超时、重复提交、数据冲突和权限变化时，用户看到什么、状态是否一致、能否安全重试？只验收成功路径，会把最需要规则的情况留给开发者临场决定。
避免把实现方案写成唯一标准
“使用 Redis 缓存”是方案，不是用户结果，除非架构约束本身需要验收。标准应优先描述行为与质量，给实现保留空间；技术决策另有记录，并通过对应测试验证。
验收标准要能追溯到目标
每条标准关联需求和风险，避免出现大量细节却无法解释价值。若某标准失败，要能判断影响哪个用户结果；若目标改变，也能找到需要修改的规则和测试。
用样例表促进跨角色评审
产品提供业务规则，开发指出实现与依赖，测试寻找边界与可观察性，设计关注交互和无障碍，运营确认异常流程。AI 可以为每个角色生成提问清单，但冲突必须由有决策权的人拍板。
明确未知项而不是偷偷补全
退款到账时间、第三方响应和历史数据质量若未知，应标记待确认、负责人和截止时间。AI 不能用行业常识替组织做承诺。未知未解决前，可设置阻断或显式假设。
定义验收证据和环境
写清在哪个版本、环境、数据集和配置验证，由谁批准，证据保存在哪里。测试环境通过不自动等于生产容量成立；模拟依赖通过也不证明真实第三方行为。
需求变化时同步更新
验收标准不是开工后冻结的合同。新发现应形成版本和决策记录，同步影响设计、代码、测试、文档和上线检查。删除标准也要说明原因，防止团队继续按旧规则执行。
无法稳定测试的依赖怎么办
短信、支付、地图等外部服务经常让验收结果变得偶然。团队应分别定义模拟环境中的业务规则验证，以及真实依赖上的最小连通性验证，并写清超时、限流、重复回调和服务不可用时的可观察结果。若某个条件暂时无法验证，要把它登记为发布风险并指定批准人，不能用一次偶然成功代替标准。风险必须可见。
AI 辅助设计流程
- 输入脱敏的目标、用户、约束和现有规则。
- 让 AI 标记模糊词、冲突、未知和隐含假设。
- 按场景写前置、动作、结果和状态变化。
- 扩展权限、边界、异常与非功能标准。
- 用正反样例让跨角色团队评审。
- 确认阈值、责任和证据后关联测试。
可直接使用的提示词
“你是验收标准澄清助手。只能依据编号目标、需求和约束。先列出不可验证词、冲突、缺失规则和需决策问题，禁止自定阈值。随后按用户角色、前置状态、触发动作、可观察结果、状态变化写标准，并补正例、反例、边界、权限、依赖失败、重复操作和恢复。每条关联目标、风险、验证环境和证据；实现方案与行为标准分开。”
评审检查清单
- 不同角色能否依据同一证据判断通过？
- 模糊形容词是否有条件、指标和阈值？
- 正例、反例、边界和异常是否齐全？
- 权限、状态和副作用是否可观察？
- 非功能标准是否说明负载和环境？
- 未知项是否有负责人而非被 AI 补全？
AI 最适合帮助团队发现没说清的地方，而不是替团队制造确定感。验收标准越早暴露分歧，返工越少；它真正定义的不是“怎么测”，而是所有人共同承认的完成。
本文为读懂 AI 原创内容。处理内部需求、客户资料和系统信息时，请遵守组织的数据权限、隐私、安全与保密制度。
