验收标准
Acceptance Criteria
中级通用验收标准（Acceptance Criteria）是团队为一项需求约定的、可检查的完成条件。它解决“做出来了，但不是想要的”这个问题：比如新增导出功能时，先说清谁能导出、导出什么，以及失败时用户会看到什么。
你可能会说：「帮我把这个功能的完成条件写清楚，让我能判断 AI 做出来的东西能不能交付。」
动手看看客户列表导出的验收
切换权限、实际导出范围和失败开关，对照验收约定看结果。管理员按钮可悬停、按住或用 Tab 聚焦；结果由参数模拟，不会真的下载。
这份清单把“谁能导出、导出什么、失败看到什么”变成可检查条件。当前场景通过不等于整项需求通过，还要覆盖其他权限和异常场景。
要点怎样把需求写成能检查的验收标准？
- 1
写用户能观察到的结果
你可以写“用户点击导出后，得到包含当前筛选结果的文件”，而不只是“完成导出接口”。因为前者能从使用结果判断是否完成，也不会过早限定 AI 必须采用哪种实现。
- 2
把关键条件和边界说清
同一个导出按钮，在没有数据、权限不足或请求失败时可能表现不同。我们把这些会影响交付判断的情况写进去，AI 才不容易只实现最顺利的那条路径。
- 3
在动手前对齐检查方式
验收标准可以通过手动操作、自动化测试或查看输出结果来核对，不等于每条都要写成测试代码。先和 AI 对齐怎么检查，完成后你就能逐条核实，而不只听它说“已完成”。
容易混淆的地方
用户故事说的是谁想做什么、为什么；验收标准进一步说明这项需求做到什么程度才算完成。测试用例则把检查过程展开成具体输入、操作和预期结果。一条验收标准可以对应多个测试用例，所以我们先对齐完成条件，再决定怎么测。
什么时候用
适合用
- 让 AI Agent 开发后台导出功能前，约定导出范围、权限限制和失败时的可见结果。
- 准备交付一个注册流程时，和设计、开发一起确认成功、输入错误和重复注册分别怎样表现。
- 接手别人完成的需求时，用约定好的条件逐项检查，而不是只看功能能否打开。
不适合用
- 还在探索用户到底需要什么功能时，先做访谈或原型验证；此时写验收标准会过早固定方案。
- 只是想定位线上某次请求为什么报错时，先查日志和调用栈；这是故障排查，不是定义新需求的完成条件。
- 只是在比较首页的视觉方向时，先做情绪板或可点击原型；等选定要实现的方向，再约定交付条件。
练一练选一个答案，看看解释
你让 AI Agent 给订单后台增加“按当前筛选条件导出”功能。哪组描述最适合作为验收标准？
让 AI 帮你做复制给 AI Agent 直接用
请先为“订单后台按当前筛选条件导出”拟定验收标准，再开始实现。写清适用用户、导出内容、无匹配数据和导出失败时用户能看到的结果；标出需要我确认的地方。完成后逐条说明你如何验证，不要只报告“已完成”。