如何撰写用户故事（含示例与验收标准）

用户故事是从用户视角对某项功能的简短描述：“作为[某类用户]，我希望[目标]，以便[原因]。”在它下面，你要写下验收标准，即若干具体条件，只有全部满足，该故事才算完成。每个故事都应小到能一次完成构建和测试，并且写得让任何人都能进行检查。

用户故事是由敏捷软件团队推广开来的，但当你借助 AI 应用构建工具独自开发时，它同样有用。好的故事就是好的提示词。

格式

一个用户故事包含三个部分：

作为 [谁]，我希望 [什么]，以便 [为什么]。

• 谁是某一类具体的用户：初次访问的游客、付费会员、诊所前台、管理员。不要只写“用户”。
• 什么是他们想做的事情，用他们自己的话来说。不是界面如何运作。
• 为什么是他们所关心的结果。这一部分最容易被跳过，却能防止你做出错误的东西。

示例：

作为健身会员，我希望用手机取消课程预约，以便候补名单上的人可以顶替我的名额，而且我不会被收取爽约费。

“为什么”告诉你“做什么”没有说明的两件事：它必须能在手机上使用，并且涉及候补名单和费用规则。

验收标准

故事说明想要什么，验收标准说明何时算完成。它们应当足够具体，使两个人对每一条是否通过都能达成一致。

常见的写法是 Given / When / Then：

• **Given（给定）**某个起始情境
• **When（当）**用户执行某个操作
• **Then（则）**出现这个结果

以健身预约的故事为例：

1. 给定我有一个在 12 小时之后的预约，当我点击取消并确认，则该预约被删除，我看到“预约已取消”。
2. 给定我取消了一个预约，且该课程有候补名单，当取消保存后，则候补名单上的第一位会获得名额并收到邮件。
3. 给定一个在 12 小时之内的预约，当我点击取消，则在我确认之前，会看到将收取晚取消费用的提示。
4. 给定我在手机宽度的屏幕上，则取消按钮无需左右滚动即可看到。

普通的检查清单也可以，只要每一项都可以测试。“取消很方便”无法测试，“从预约列表最多点两次即可取消”则可以。

分步骤：写出好的故事

第一步：从真实的用户和真实的问题出发

选定一类用户，以及他们今天正在为之苦恼的事情。如果你做过客户访谈，就使用他们的原话。“我总是忘记取消，结果被扣费”比“添加取消功能”是更好的起点。

第二步：写出一行的故事

填入模板。如果你写不出令人信服的“以便”，就先问问这项功能是否真的需要。

第三步：添加三到六条验收标准

先覆盖主要的成功情况，再覆盖重要的变体：不同的角色、空状态、限制条件、错误。如果你写了六条以上，这个故事可能太大了。

第四步：注明超出范围的内容

一行字就能省去很多反复沟通：“超出范围：付费课程的退款；管理员代会员取消。”这样可以防止故事在你构建的过程中不断膨胀。

第五步：对照 INVEST 检查

INVEST 是衡量好故事的常用检查清单。一个好的故事应当是：

你不必给每个故事都打分。当一个故事感觉不对，而你想知道原因时，这个方法最有用。

好与坏的示例

如何拆分过大的故事

大型故事是项目停滞的地方。常见的拆分方式有：

• **按用户角色。**会员取消自己的预约；员工可以取消任何人的预约。
• **按流程中的步骤。**浏览课程；预约课程；收到提醒。
• **先做简单情况。**现在先实现免费课程的取消；费用和退款留给之后的故事处理。
• **按数据变化。**先支持一个门店，之后再支持多个门店。
• **先做正常流程，再做错误处理。**先让它正常工作，再添加课程已满、通行证过期等情况的处理。

拆分出的每一部分仍应是用户可以使用并能察觉到的东西。

把用户故事用作提示词

带有验收标准的用户故事，非常接近 AI 应用构建工具的好提示词。它为 AI 提供了谁、什么、为什么以及“完成”的定义。每条消息发送一个故事：

作为健身会员，我希望用手机取消课程预约，以便候补名单上的人可以顶替我的名额。 验收标准：

1. 在“我的预约”中，每个预约都有取消按钮，并包含确认步骤。
2. 在课程开始前超过 12 小时取消，只需删除该预约。
3. 在开始前不足 12 小时，确认前显示“将收取 5 美元的晚取消费用”，并将该费用记录在预约上。
4. 如果课程有候补名单，第一位候补者获得名额并收到邮件。
5. 在手机宽度的屏幕上可以正常使用。 超出范围：退款，员工代会员取消。 请先构建这部分，然后在预览中逐条检查验收标准，并告诉我哪些通过了。

你也可以让 AI 根据粗略的想法起草故事，然后由你自己修改：

这是我的应用想法：[两三句话]。请为第一版写出用户故事，按用户类型分组，每个故事附上 3 到 5 条 Given/When/Then 形式的验收标准。标出哪些是上线必需的，哪些可以稍后再做。

务必阅读并修改结果。AI 不了解你的用户，而你了解。

验收标准同时也是你的测试计划。当故事构建完成后，请自己逐条核对每条标准。我们关于上线前测试应用的指南就是在此基础上展开的。

用户故事与其他文档的关系

• 产品需求文档描述整个产品：问题、用户、范围。用户故事是其中的具体细节。参见如何用 AI 撰写 PRD。
• 缺陷报告描述的是已经构建完成的某个故事中出现的故障。参见如何撰写好的缺陷报告。
• MVP 是能够交付核心价值的最小故事集合。参见什么是 MVP。

常见错误

• **“作为用户……”**太笼统。请写出具体的用户类型。
• **省略“以便”。**没有原因，就无法做出合理的取舍。
• 写的是解决方案而不是需求。“我希望有一个下拉菜单”，在没有人考虑设计之前就把设计锁定了。
• 无法测试的标准。“简单”“快速”“直观”是愿望，而不是标准。
• 实际上是史诗（Epic）的故事。“管理我的账户”其实是十个故事。
• **一次性写完所有故事。**详细地写出接下来的几个故事；其余的保留为一行的概要，等到需要时再展开。

Mythex 中的用户故事

在 Mythex 中，Plan（计划） 模式非常适合把想法转化为故事：智能体会在修改任何内容之前先讨论方案。当某个故事准备就绪后，切换到 Build（构建） 并粘贴进去，每条消息一个故事。每完成一个故事后，可以使用 /test 在预览中点击操作并检查流程；如果某条回复的方向错了，也可以用 Revert to this point（恢复到此处） 将其回滚。参见文档中的有效提示词，以及我们关于为 AI 应用构建工具撰写提示词的指南。

用户故事检查清单

• 写明了具体的用户类型
• 描述的是需求，而不是设计
• 包含真实的“以便”原因
• 有三到六条可测试的验收标准
• 至少覆盖一种边界情况或错误
• 说明了超出范围的内容
• 足够小，能在一次工作中完成构建和测试
• 构建完成后已逐条检查验收标准

常见问题