要用 AI 编写用户故事和验收标准，应从已验证的用户证据出发，写明角色和目标，将工作拆成可复核的结果，再写出获授权人员能够观察和判断的标准。AI 应揭示缺失假设和边界情形，而不能虚构用户需求、选择实现细节或批准需求。

关键要点

每个故事都应追溯到已验证的需求、问题、政策或运营约束。

围绕用户目标写故事，而不是围绕指定功能或界面。

覆盖正常、边界、失败、权限、无障碍、隐私和安全结果。

区分验收标准、实现任务、测试用例和完成定义。

通用 AI 工作流提供来源、复核和审批控制。更广泛的顺序和责任归属可参阅用 AI 制订项目计划；用户故事不是缩小版项目计划。

用户故事之前需要哪些证据？

收集能够解释用户、问题、预期结果、约束和待解问题的证据。来源可以是获批研究发现、支持服务模式、分析数据、政策要求、无障碍发现、事件报告或责任明确的业务规则。

建立证据包：

证据 ID	来源	已观察需求或约束	人群/情境	置信度	负责人
E-014	主持式研究发现	用户不知道提交是否成功	首次申请者	中	研究负责人

把证据和方案分开。“用户需要确认提交已收到”描述结果；“显示五秒绿色提示”只是一个实现构想，不应默认成为用户需求。

不要向 AI 服务提供机密录音、个人数据、安全细节或不受限的内部文档。只使用已批准的最小片段和稳定证据 ID。

如何编写目标导向的用户故事？

GOV.UK 指出，用户故事应说明角色、用户需要什么及目标，常用“作为……我需要/想要/期望……从而……”格式，并强调目标是最重要的部分。［1］

生成文字前先填写故事画布：

字段	问题
角色	谁真正经历该需求，而不是虚构人物？
情境	需求在何时何地出现？
需要	用户必须达成什么结果？
目标	该结果为何重要？
证据	哪些 ID 支持故事？
约束	有哪些政策、无障碍、隐私、安全或运营边界？
假设	什么尚未验证？
批准人	谁拥有产品决定权？

然后让 AI 提供备选方案：

从这份证据包起草三个用户故事候选。每个候选都必须说明角色、需要和目标，引用支持证据 ID，避免界面和实现选择，列出无证据支持的假设，并说明何时应拆分或拒绝故事。不要虚构用户研究，也不要把利益相关方偏好当成用户证据。

复核角色是否真实相关、目标是否以结果为中心，以及团队能否在不预先指定方案的情况下讨论故事。

如何拆分 epic 或过大的故事？

GOV.UK 把需要数周以上的大型故事称为 epic，并建议尽可能拆成可在一个迭代内完成的小故事。［1］不要只按数据库、API 和界面等技术层拆分，否则每个故事可能都没有独立用户价值。

有用的拆分维度包括：

不同的用户目标或旅程阶段；
正常路径与可恢复的异常路径；
读取、创建与修改三类结果；
权限或角色类型；
先处理简单情况，再处理复杂变化；
支持的渠道或政策辖区；
先人工复核，再安全地自动化。

每个受影响故事都要保留横切约束。工作被拆分后，隐私、无障碍或授权要求不能随之消失。

什么样的验收标准可观察？

验收标准描述获授权用户、客户或其他主体接受工作前必须满足的条件或结果。NASA 软件工程指南强调定义和记录验收标准及条件；适用时可包括范围、性能、可靠性、兼容性、数据等约定指标。［2］

从外向内编写标准。优先描述可观察结果、消息、状态转换、导出记录或可量化容差，不要写内部类、数据库行或选用库。

先使用普通清单：

标准 ID	情形	可观察结果	证据来源	负责人
AC-01	有效提交	用户获得唯一编号和明确下一步	E-014	产品负责人
AC-02	重复提交	用户收到警告且已填数据不丢失	E-021	产品负责人
AC-03	处理服务不可用	用户获得可恢复失败路径	运营政策 P-03	服务负责人

“构建端点”“使用模态框”或“编写单元测试”都不是合适的验收标准；它们是实现或交付任务，不是用户可观察的验收结果。

验收标准应覆盖哪些边界情形？

让 AI 按明确类别挑战正常路径：

边界： 空、最小、最大、过期、重复或罕见但有效的输入。
失败： 依赖不可用、超时、请求被拒、部分完成或重试。
权限： 未登录、角色错误、所有权变化或访问已撤销。
无障碍： 键盘操作、焦点、状态播报、错误恢复和非视觉理解。
隐私： 数据最小化、可见范围、保留、导出和删除边界。
安全： 未授权操作、不安全输入、重放、速率限制及必要审计。
运营： 监控、支持交接、回滚和服务降级时的行为。

并非每个故事都需要每一类，但每类都应明确判定“已覆盖”或“不适用”。团队无权决定的领域应由相关负责人复核。

NIST 的生成式 AI 风险框架提醒模型可能自信地生成错误内容，并强调评估、来源核验、人工监督和安全处理错误。［5］在责任团队验证证据和可行性前，AI 生成的标准只是候选。

何时使用 Given、When、Then？

具体示例有助于形成共同理解时，可使用 Given/When/Then。Cucumber 将 Given 定义为初始情境，When 为事件或操作，Then 为预期的可观察结果，并建议结果应对用户或外部系统可见，而不是埋在系统内部的实现细节。［3］

示例：

Given 已登录申请人完成所有必填字段 When 申请人提交一次 Then 服务显示唯一编号和预期下一步

重复提交、断网、授权变化和无效数据应各用独立示例，不要把许多分支塞进一个长场景。场景是标准的例子，不自动代表整套验收标准。

验收标准与任务、测试和完成定义有何区别？

产物	主要问题	范围	负责人
用户故事	用户要达成什么、为什么？	一个连贯需求	产品团队
验收标准	哪些可观察条件使故事可接受？	故事特定	产品及相关方
实现任务	团队如何构建？	技术工作	交付团队
测试用例	如何执行并比较具体行为？	验证覆盖	QA 和工程
完成定义	哪种共享质量状态适用于增量？	产品或团队级	Scrum 团队/组织

Scrum 指南把完成定义定义为增量达到产品质量措施时的正式状态。［4］它比故事特定的验收标准更广且更可复用。故事即使满足功能标准，也可能因为文档、安全复核、集成或另一项共享质量要求未完成而不符合完成定义。

验收测试也不同于验收标准：标准说明什么必须为真，测试和复核活动则生成证明它为真的证据。NASA 将验收测试描述为用于判断系统是否满足验收标准的正式测试。［2］

标准获批后，可用AI 测试生成工作流设计具体测试；需要可重复运营指引时，使用用 AI 创建 SOP 清单。

如何用 AI 编写用户故事和验收标准并保留追溯？

建立需求追溯表：

故事/标准	证据 ID	约束 ID	测试或复核证据	决定负责人	状态
US-07 / AC-01	E-014	P-03	AT-114	产品负责人	已批准

每项标准都应有来源或明确的负责人决定，每项高影响约束都应映射到一个或多个标准。标准之后应映射到测试或复核证据，但起草时不能虚构尚不存在的证据。

视情况与产品、设计、工程、QA、研究、无障碍、安全、隐私、法律或运营负责人共同复核。提出以下问题：

用户和目标是否有证据支持？
是否有标准其实是实现指令？
正常、边界和失败结果是否可观察？
权限、无障碍、隐私和安全决定是否明确？
容差和例外是否可量化？
每一项是否都有负责批准的人？

最终决定使用保留人工审批的 AI 工作流。AI 可以准备复核包，不能批准自己生成的需求。

总结

从已验证证据、约束、假设和负责人开始。
围绕角色的需要和目标写故事，而不是指定界面。
尽可能沿独立有价值的结果拆分 epic。
定义可观察的正常、边界、失败、权限、无障碍、隐私和安全结果。
Given/When/Then 是可选示例，不能代替思考。
把标准追溯到证据，并把人工审批与生成分开。

常见问题

AI 能从会议记录编写用户故事吗？

它可以起草候选，但会议发言不会自动成为已验证用户需求。起草前要区分证据、利益相关方要求、假设和决定。

一个故事应有多少条验收标准？

应足以定义有意义的正常、边界和失败结果，又不把故事变成规格堆砌。列表过长或混合多个目标时应拆分故事。

用户故事必须使用“作为、我想、从而”格式吗？

不必。格式很有用，但核心是角色、需要和目标。选择团队能一致复核的格式。

必须用 Given/When/Then 写标准吗？

不必。许多故事用清晰清单更合适。具体场景能澄清情境、事件和预期结果时再使用。

验收标准和测试用例一样吗？

不一样。标准定义接受前必须为真的条件；测试用例说明用于获取证据的输入、操作、环境和比较。

完成定义是每个故事的一部分吗？

共享完成定义适用于增量或产品质量状态，验收标准则针对具体故事。工作完成前可能两者都须满足。

所有标准都可量化时，AI 能批准需求吗？

不能。可量化不等于具有用户价值、政策权限、可行性、安全性或组织批准，仍须由负责人员决定。

免责声明：AI 生成的故事和标准只是草稿，不能取代获授权的产品、工程、无障碍、安全、隐私、法律或运营审批。

来源：

GOV.UK Service Manual — Writing user stories — https://www.gov.uk/service-manual/agile-delivery/writing-user-stories
NASA Software Engineering Handbook — SWE-034 Acceptance Criteria — https://swehb.nasa.gov/spaces/7150/pages/16450634/SWE-034%2B-%2BAcceptance%2BCriteria
Cucumber — Gherkin Reference — https://cucumber.io/docs/gherkin/reference/
Scrum Guides — The Scrum Guide — https://scrumguides.org/scrum-guide.html
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

Sources checked 2026 年 8 月 30 日。

延伸阅读：

如何用 AI 编写用户故事和验收标准：覆盖边界情形并保留追溯