AI 用户故事验收标准：20 个可核对的完整示例

分清用户故事、验收标准、测试和完成定义

用户故事说明某个人需要什么有价值的结果；验收标准定义方案必须满足什么条件；测试用例说明用哪些数据、在什么环境里观察该条件；测试结果记录实际发生了什么。分开管理这些材料，才能在实现变化时保留业务承诺，不把“改了代码”和“改了需求”混为一谈。

这套区别不是生成式 AI 出现以后才需要的。Agile Alliance 将 Ron Jeffries 的 Card、Conversation、Confirmation 模型追溯到 2001 年。对今天的实际意义是：生成一张需求卡片，不等于完成团队讨论，更不等于证实目标已经达成。Agile Alliance：Three Cs。

在 Scrum 中，完成定义描述增量应达到的产品质量状态。一条邀请测试通过，不能免除共同质量要求；技术检查清单完成，也不能替团队决定尚未明确的邀请政策。Scrum Guide：完成定义。

需要解释状态转换时，可以用“假设—当—则”。Cucumber 将初始上下文、事件和可观察结果分开，而可执行场景还需要对应的步骤实现。本文给的是规格示例，不是安装好即可运行的 Cucumber 测试套件。Cucumber Gherkin 参考。

先整理邀请规则，再写具体示例

虚构工作区 W7 的容量为十席。目前有八位正式成员和一条未过期的待接受邀请，合计占用九席。所有者希望将 mina@example.test 以 Member 角色邀请进来。这个地址只是合成测试数据，不应真的向它发信。待接受邀请不等于正式成员身份。

我们把功能分成四个关联故事：INV-01 创建邀请，INV-02 呈现通知投递状态，INV-03 处理过期和撤销，INV-04 确保支持的交互方式与语言可用。这样可以避免把整项功能的验收清单伪装成一个很小、可以直接估算的故事。

这些是为了教学而设定的决定，不是安全标准、邮箱规范或推荐服务等级。真实资料包还应记录政策版本、批准人和生效日期。两份笔记若互相冲突，应保留冲突，直到有权决定的人明确适用规则。

例如，销售笔记中的“可以邀请任何人”不能自动覆盖 P1。“十席”也不是对 OpenMax 商业套餐的描述。如果实际负责人还没有决定待接受邀请是否占席，应该先提出这个问题，再生成容量标准。听起来合理的假设，仍然只是待确认假设。

二十项验收标准：结果明确，也能说出什么算失败

下面是功能层面的覆盖菜单，每条都包含行为与容易漏检的反例。若一条标准涉及紧密关联的多个结果，应分别记录断言结果，不要用一句“部分通过”掩盖到底哪一步出了问题。

1. 创建成功后，收件人仍处于待接受状态

假设 W7 已占九席，操作者目前仍是有权限的所有者；当其以 Member 角色提交有效的新收件人时，授权邀请视图应显示 I77 为 Pending，占用席位变为十席，而成员视图中的正式成员仍是八人。对应 P1–P4、INV-01。只看“成功”提示不够：提示可能掩盖邀请没有保存，或收件人被提前创建为成员的问题。测试需通过有权限的入口检查这两种可观察结果。

2. 邮箱缺失时，保留其他已填内容

假设邮箱为空，但用户已选择 Member 并填写备注；提交后应显示邮箱必填错误，不创建邀请，同时保留角色和备注供用户修改。对应 P2、INV-01。使用表单规范批准的空字符串及纯空格样例，不能让“请填写收件人邮箱”这样的 AI 占位文本被当成有效输入。错误提示出现与其他输入保留，应分别验证。

3. 可选备注保持可选，不自动编内容

假设必填项均有效而备注未设置；邀请创建后，备注仍应处于未设置状态。对应 P2、INV-01。系统不应自动编出问候语、人物关系或邀请理由。检查邀请详情中的明确空值，而不是仅看界面有没有报错。若后续政策要求某种特殊角色必须填写备注，那是新增的条件规则，需要重新讨论，不能暗中改变本例。

4. 格式校验不冒充邮件投递验证

假设输入批准的无效样例 mina.example.test；提交后应显示格式问题，不创建邀请，也不创建通知任务。对应 P2、INV-01。有效样例 mina@example.test 只能证明符合这个产品的输入规则，不能证明邮箱真实存在、归谁所有或一定可送达。真实项目应采用团队批准的邮箱验证规范，不让 AI 临时发明一个所谓通用正则表达式。

5. 邀请角色不能直接授予所有者权限

假设创建邀请只允许 Member 和 Viewer；若请求尝试将角色设置为 Owner，应拒绝且不新增邀请。对应 P2、INV-01。除了检查下拉菜单，还应测试被修改过的请求。界面没有某个选项，不等于服务端已经强制限制该值。所有者转移应是另一个有独立权限约定的故事，不能搭便车进入邀请流程。

6. 最后一个席位既不能多占，也不能少给

已占九席时，一个新邀请可以把总占用带到十席；已占十席时，再邀请另一位新人应提示容量不足，且不新增预留。对应 P3、INV-01。两侧都要测：只测试满额拒绝，可能漏掉系统错误拒绝最后一个可用席位的情况。分别记录正式成员数和待接受预留数，才能解释占用数来自哪里，而不是只有一个难以追溯的总数。

7. 换一个请求键，不能绕过收件人去重

假设 I77 对应的同一收件人在 W7 仍处于 Pending；所有者换一个逻辑请求键再次邀请时，应显示已有邀请，而不是再占一席。对应 P3–P4、INV-01。收件人身份和标准化规则必须由实际身份系统负责人确认。本文只使用完全相同的地址，不把这个例子扩展成对别名、大小写或所有邮箱供应商都成立的规范。

8. 已有正式成员，不重复建立邀请

假设目标收件人已经是 W7 的正式成员；所有者请求邀请后，有权限的视图应说明成员已存在，邀请数和席位占用均不增加。对应 P3、INV-01。这和“邀请尚待接受”不是同一状态，需要单独准备数据。也不能为了让提示更详细，顺便暴露该地址在其他租户中的成员关系。

9. 查看者直接调用接口，也不能创建邀请

假设操作者在 W7 的角色为 Viewer；即使直接发送创建请求，也应被拒绝，邀请状态不变。对应 P1、INV-01，本文虚构响应为 403。需要验证的不是 Invite 按钮有没有隐藏。实际权限控制与信息泄露边界应交由安全负责人审查，包括向请求方暴露什么响应，不能把本例当成完整安全设计。

10. 表单打开之后，权限变化仍要生效

假设用户打开表单时是 Owner，但提交前已经变为 Viewer；当提交到达修改状态的边界时，应拒绝操作，不创建预留。对应 P1、INV-01。这个例子专门暴露“打开页面时检查过就够了”的过期权限假设。测试要能控制角色变化，并检查后续结果；“用户之前有权限”不满足当前权限规则。

11. 修改工作区编号，不能跨越租户边界

假设操作者拥有 W7，却没有 W8 权限；请求若改为 W8，应被拒绝，且不透露 W8 的成员、邀请或容量。对应 P1、INV-01。应明确测试未经授权的目标，而不是只在正常工作区操作。实际响应细节服从安全政策；有些系统会故意避免让调用者区分“对象不存在”和“对象存在但禁止访问”。

12. 相同请求重放，仍指向原来的邀请

假设 I77 由 K77 创建；在24小时重放窗口内，同一位当前仍有权限的操作者，在 W7 重复相同内容，应得到 I77，不增加预留。对应 P4、INV-01。范围包括工作区、操作者、键和请求内容。快速双击与响应丢失应分别记录场景。浏览器多发送一次网络请求，并不意味着用户要求再创建一项业务邀请。

13. 同一个键搭配不同内容，应报告冲突

假设 K77 创建的是 Member 邀请；再次使用 K77 却把角色改为 Viewer，应返回冲突并保持 I77 不变。对应 P4、INV-01，本文虚构响应为 409。如果对改过的内容仍返回“成功”，就掩盖了用户要求的角色修改其实没有发生。若产品允许编辑已有邀请，需要另写相应约定与权限，不能从重放规则推断出来。

14. 两个请求同时争最后一席，只能成功一个

在一个重新初始化、已占九席的 W7 测试环境中，两个不同新收件人的请求同时争用最后一席，只能创建一个邀请，另一个收到容量不足结果，最终占用为十而不是十一。对应 P3、INV-01。先后点两次不能证明并发正确。工程需提供可控并发测试，同时保存两个响应和最终有权限访问的容量视图。

15. 响应丢失意味着结果未知，不等于创建失败

假设服务端已创建 I77，但响应在返回途中丢失；客户端在重放窗口内用未变更的 K77 请求核对时，应收到原邀请，不再占一席。对应 P4、INV-01。核对完成前，界面不能肯定宣称创建失败。超过24小时后，应走约定的恢复路径检查现有待接受邀请，而不是继续假设请求键永久保留重放保护。

16. 通知投递失败，不自动抹掉已经保存的邀请

假设 I77 已处于 Pending，通知投递发生暂时故障；本例约定的三次尝试用尽后，应将投递状态标为待人工处理，I77 及其唯一预留仍可识别。对应 P6、INV-02。邮件排队不等于已送达。稳定事件编号可以辅助去重，但本例不保证在外部邮箱的所有故障模式下都恰好只出现一封邮件。

17. 有效期必须落到一个准确时刻

I77 创建于 2026-01-05T10:00:00Z，过期时刻为 2026-01-07T10:00:00Z。若其他条件满足，严格早于该时刻的接受操作可以继续；恰好到达该时刻则不行。对应 P5、INV-03。测试应控制时钟。过期只释放一次预留，并保留可解释的状态；接受成功具体怎样建立成员，应由独立接受故事定义，不能默认“有链接就自动入组”。

18. 重复撤销，不能重复释放席位

假设授权所有者撤销一条 Pending 邀请；再次执行撤销后，状态仍是 Revoked，而且预留只释放一次。对应 P1、P5、INV-03。从占用十席开始，第一次变为九席，第二次仍是九席。如果接受和撤销同时发生，需要另加明确的冲突规则。这个顺序执行的例子，不能代替并发决定，AI 写得再流畅也不例外。

19. 键盘用户能找到邮箱错误并完成修正

在受支持的键盘与屏幕阅读器组合中，发生邮箱必填错误后，用户应能识别字段和错误，无需指针即可到达修改控件，并在其他输入不丢失的情况下重新提交。对应 P7、INV-04。记录浏览器、辅助技术、焦点行为及播报证据。仅用 Tab 键走一遍，不等于完整无障碍评估，也不能据此声称符合 WCAG。

20. 不同语言和时区显示的是同一个截止点

对 I77 的同一 UTC 过期时刻，东京、上海和 UTC 上下文应分别显示1月7日19:00、18:00和10:00，采用批准文案并明确时区。对应 P7、INV-04。存储的截止时间与邀请编号不变。应检查真实窄屏排版和缺译回退；翻译了字符串，却没在界面中检查，并不算完成本地化验证。

用五步把 AI 草稿变成团队可执行的约定

1. 固定最小有效资料包。 包括用户故事、P1–P7 或真实对应规则、批准样例、范围排除和未决问题。去掉真实邀请令牌与个人邮箱。AI 无法访问某份来源时，应报告缺失，不能声称读过该政策。
2. 同时要求候选标准与反对理由。 每条都返回规则编号、起始状态、动作、结果、禁止副作用和反例，并说明缺少哪些决定。没有批准来源的规则，即使像行业惯例，也只能是建议。
3. 让产品、工程和测试用例子讨论。 例如，待接受邀请到底占不占席？Example Mapping 区分规则、例子和无法当场回答的问题；问题要保持可见，而不是在文字润色时被删除。Cucumber Example Mapping。
4. 先确认范围，再挂接测试。 创建、投递和生命周期若无法构成一个连贯的小故事，就拆开。给标准稳定编号和版本，明确业务决定者与技术可行性判断者。生成的测试代码仍需独立审核断言，不能因为自动执行就认定期待结果正确。
5. 收集结果，不为了通过而改期待值。 保存构建版本、环境和对应批准版本的证据，区分失败、阻塞和未运行。政策变化后保留旧结果，再评估哪些测试需重跑；不能看见运行结果后偷偷调整预期来制造绿色状态。

上游还有未决发布风险时，可以参考AI 项目风险登记模板。交付后若要检查流程问题，可用迭代回顾分析指南。回顾会议不能替代某项功能所需的验收证据。

对照错误草稿，正确解释不完整的测试证据

下列是编辑编写的常见 AI 式弱草稿，不是某个已测试模型的输出记录。每项都给出可核对的修订原因，重点不在于“改得更专业”，而是消除错误业务含义。

下载材料中的十二条示例记录为：T01–T04 通过，T05 权限执行失败，T06 通过，T07 并发未运行，T08–T10 通过，T11 键盘与错误提示失败，T12 日文排版未运行。合计八项通过、两项失败、两项未运行。十二项计划检查中执行了十项；执行的十项中八项通过；全部十二项中有八项具备通过证据。

这些分母回答不同问题，不是可以互换的“质量分”。这十二项选定检查也没有覆盖全部二十项标准。即使已执行项通过率达到80%，权限失败仍会阻止相关行为验收。并发未运行，就没有并发通过证据。正确决定是修复、执行缺失检查并补看覆盖范围，而不是把功能标为完成。

这只是一个虚构的证据阅读练习。没有实际运行邀请后端、邮件供应商或 OpenMax 流程来生成这些结果。读者可以从材料复算数量和比例，但复算只证明对十二条教学记录的解释，不证明某个系统真的通过测试。

按不确定性选择最简单的需求细化方法

故事很小、责任人随时能讨论时，一次简短人工讨论配手动维护的共享文档可能就够了。准备成本低，分歧能当面说清；缺点是无人记录时，决定容易丢失。在加入更多自动化前，先把工作表做成有版本的约定。

待办工具的原生模板可以让每个故事都填写规则、示例和证据，但它不能判断语义正确性。同一个必填文本框，既能装批准政策，也能装编出来的要求。自动语法检查适合发现编号缺失或格式错误，不能证明业务规则本身正确。

行为已经商定、系统可实际运行时，可执行测试才有价值。它提供可重复观察，但也可能很忠实地执行错误期待。因此要分别审查业务规则和测试断言。上下文很长或反复出现时，可让 AI 辅助整理候选；与此同时，要承担其可能补出貌似合理却没有依据细节的风险。先做一个范围很小的审核试点，再决定是否扩大，并保持版本控制与明确写入权限。

OpenMax 可以参与哪一步，不能替代哪一步

OpenMax 的 AI 产品经理官方材料包含 PRD 生成提示，要求整理用户故事、验收标准、范围排除和未决问题。它支持的是需求起草使用场景，不证明已有现成邀请引擎，也不证明已经接通你的测试系统。OpenMax AI 产品经理使用场景。

合适的交接是：提供脱敏需求包，由助手整理候选标准，再交团队审核。已批准待办与测试证据仍保存在你们认可的记录系统里。在开启写入或集成之前，应在自己的环境里确认连接器是否可用、授权范围、审核机制和出错恢复方式。本文没有实测这些能力。

可以使用下面这段原创提示作为起点：

仅依据附带的已批准规则，为 INV-01 起草验收标准候选。每条返回规则编号、操作者、起始状态、动作、可观察结果、禁止副作用、反例和未决问题。把 Pending、成员身份和投递状态分开。不编造政策、性能目标或测试结果；没有依据的决定明确写成问题。不修改待办，不发送邀请。

如果核心政策还存在分歧，OpenMax 不能提供缺失的业务决定权。先找负责人明确，再查看 OpenMax 产品信息，使用工作表对一个非生产故事试做。只有审核者能解释哪些候选被保留、修改或拒绝及其原因时，才值得扩大范围。

边界：这些示例不是整个功能的合格证

真实安全与隐私行为需要结合架构和实际义务，由合格负责人审核。本文虚构的租户与角色规则不是授权设计，也不是法律意见。不要把生产令牌、客户邮箱或敏感需求附件粘贴进未经批准的工具。

性能、恢复与无障碍需要各自的证据。“快”应具体到操作、负载、环境、百分位计算方法、样本窗口和错误规则，不要从模板里随手抄一个800毫秒。“可恢复”应定义恢复点、恢复时间与数据一致性检查，不能只说回到上一部署版本。某条表单路径可访问，也不等于整个站点符合无障碍要求。

如果功能本身使用 AI 模型，还要建立单独的评估约定：数据集版本、评价尺度、评审方式、不可接受结果和回退行为。“用 AI 写标准”与“给 AI 系统设标准”是两个问题。确定性的邀请测试不能证明模型质量；不错的模型平均分也不能为越权修改开脱。

结束故事前，先问一个最小而关键的问题：出现什么观察结果，我们会拒绝这个实现？ 如果团队无法回答，应先改规则或例子，而不是继续让 AI 增加字数。对本文案例，先处理权限和键盘缺陷，比美化通过率标题更有价值。

常见问题

AI 生成的验收标准可以直接采用吗？

在责任团队核对来源规则、范围和可测试性之前，它只是候选。文字获得批准，与实际系统行为获得验证，是两个不同阶段。

每个用户故事都要包含二十个示例吗？

不需要。选择相关风险，并将无关行为拆成独立故事。本文二十个示例跨越同一邀请功能的创建、投递、生命周期和使用体验。

写成“假设—当—则”就可测试了吗？

不是。还需要明确起始状态、业务规则、可观察结果和具体边界。自动执行还需实现步骤、准备环境并取得真实结果。

测试通过率80%就能验收吗？

不能只看比例。虚构材料中，十项已执行检查有八项通过，但两项失败，另外两项未运行。权限失败仍是阻断问题，示例也没有覆盖全部标准。

OpenMax 能自动批准故事完成吗？

本文只核实了官方需求起草使用场景，没有验证自动审批、待办集成或测试执行。验收决定仍由团队授权的责任人作出。

来源与编辑方法

OpenMax 内容团队，2026年9月4日修订。本文是 OpenMax 自有品牌教育内容，不是独立产品评测。邀请规则、示例、提示、工作表和结果记录均为本指南编写，不是客户案例、基准测试或第一手产品实测。真实安全、隐私和无障碍要求仍需相关专业人员审核。

• Cucumber：Gherkin 参考——上下文、事件、可观察结果，以及文字与可执行步骤的区别。
• Cucumber：Example Mapping——细化时分开记录规则、示例和问题。
• Agile Alliance：Three Cs——讨论和确认的历史背景。
• Scrum Guide——增量质量的共同完成定义。
• OpenMax：AI 产品经理——已公开的需求起草提示；本文未使用其中的营销效果数字。