以下是按产品类型分组的 40 个用户故事：SaaS、电商、移动应用、市场、金融科技、医疗、内部工具和 AI 功能。每个都附有验收标准，因为没有验收标准的故事只完成了一半。之后：从差到好的重写、将史诗分解为故事，以及非功能故事。
2026 年 10 月更新。新用户故事？从 如何编写用户故事开始，然后回到这里获取可调整的材料。
此处使用的格式
每个故事遵循角色-功能-利益模板：
作为一个[用户类型]，我想要[目标或操作]，以便[利益]。
验收标准是简短的编号清单，以便适合表格； 用户故事模板 展示了 Given/When/Then 替代方案。数字（时间限制、阈值）是您自己业务规则的占位符。
SaaS 和 B2B 用户故事示例
B2B 故事围绕账户、角色和计费展开，同时涉及两个用户：执行工作的人和付费的管理员。
| 用户故事 | 验收标准 |
|---|---|
| 1. 作为一个工作区管理员，我想要通过电子邮件邀请团队成员，以便他们可以在我们的账户中工作。 | （1）邀请链接有效期为 7 天。（2）我在发送前选择角色（管理员、成员或查看者）。（3）邀请已是成员的人时，系统会显示错误提示，而不是发送重复邀请。 |
| 2. 作为账户所有者，我希望在应用内升级到付费方案，以便无需联系销售团队即可增加席位。 | （1）我在确认前可以看到价格及变更内容。（2）支付成功后，新限制立即生效。（3）如果银行卡被拒，我仍保留当前方案，并看到拒绝原因。 |
| 3. 作为团队成员，我希望使用公司的 Google 或 Microsoft 账户登录，以便无需设置另一个密码。 | （1）登录提供这两种选项。（2）来自允许的公司域名的首次登录会将我添加到该工作区。（3）来自管理员未允许的域名的账户将被拒绝，并显示清晰的消息。 |
| 4. 作为经理，我希望将活动报告导出为 CSV 格式，以便与财务部门共享。 | （1）导出使用当前应用的筛选条件。（2）文件包含标题行和 ISO 日期（YYYY-MM-DD）。（3）超过 50,000 行的导出通过电子邮件发送下载链接，而不是阻塞页面。 |
| 5. 作为新用户，我希望有一个简短的入门清单，以便无需阅读文档即可获得第一个有用的结果。 | （1）3 到 5 个步骤，完成后自动勾选。（2）我可以关闭它，并从帮助菜单中重新打开。（3）进度在设备间同步。 |
| 6. 作为工作区管理员，我希望有权限变更的审计日志，以便回答客户的安全问卷。 | （1）每条记录记录谁在何时、从哪个 IP 地址更改了什么。（2）任何人，包括管理员，都不能编辑或删除条目。（3）日志可按用户和日期筛选并导出。 |
电子商务用户故事示例
商店故事的成功或失败取决于其异常路径：缺货、银行卡被拒、延迟交付和退货。
| 用户故事 | 验收标准 |
|---|---|
| 7. 作为购物者，我希望按尺寸和颜色筛选产品，以便只看到我可以购买的商品。 | （1）筛选器仅提供有库存的尺寸和颜色。（2）结果无需重新加载即可更新，且 URL 保留筛选条件以便共享视图。（3）“清除全部”重置列表。 |
| 8. 作为访客购物者，我希望在不创建账户的情况下结账，以便快速购买。 | （1）仅需提供电子邮件、地址和支付信息。（2）支付后，我可以一键创建账户。（3）确认邮件在一分钟内到达。 |
| 9. 作为购物者，我希望在付款前看到交付日期，以便知道订单是否会按时到达。 | （1）每个配送选项显示预计交付时间窗口。（2）更改地址时，时间窗口会更新。（3）单独发货的商品显示各自的日期。 |
| 10. 作为购物者，我希望在缺货商品补货时收到通知，以便无需反复检查。 | （1）当库存为零时，“通知我”取代“加入购物车”。（2）商品补货时，我收到一封邮件，然后警报结束。（3）邮件打开商品页面，并预选我的尺寸。 |
| 11. 作为客户，我希望在线发起退货，以便无需联系支持团队。 | （1）仅在退货窗口内的订单显示“退货”按钮。（2）我选择商品和原因，并获得标签或二维码。（3）退款状态显示在我的订单历史中。 |
| 12. 作为商店经理，我希望创建带有效期的折扣码，以便进行周末促销。 | （1）我设置百分比或固定金额、日期和使用限制。（2）结账时，过期的代码显示“此代码已过期”。（3）除非我允许，否则代码不能组合使用。 |
有关配送应用中的结账流程和订单跟踪，请参阅 按需应用的必备元素.
移动应用用户故事示例
移动故事需要网页故事通常可以跳过的标准：无信号、设备权限和生物识别。
| 用户故事 | 验收标准 |
|---|---|
| 13. 作为通勤者，我希望我的车票可以离线使用，以便在无信号的火车上出示。 | （1）车票及其二维码无需连接即可打开。（2）离线横幅显示数据最后同步的时间。（3）需要连接的操作被禁用，并附有说明。 |
| 14. 作为用户，我希望使用 Face ID 或指纹登录，以便无需每次输入密码。 | （1）在我首次密码登录后提供此选项，在我选择启用前保持关闭。（2）在 3 次尝试失败或设备生物识别信息更改后，应用要求输入密码。（3）我可以在设置中关闭此功能。 |
| 15. 作为用户，我希望选择接收哪些推送通知，以便应用不会骚扰我。 | （1）设置列出每个通知类别及其独立开关。（2）更改立即生效。（3）应用在我首次启用某个类别时请求通知权限，而不是在首次启动时。 |
| 16. 作为新用户，我希望在注册前试用应用，以便决定它是否值得使用。 | （1）主要内容无需账户即可浏览。（2）仅在我尝试保存或发布时要求注册。（3）我作为访客保存的任何内容都会转移到我的账户中。 |
| 17. 作为用户，我希望将项目分享到 WhatsApp 或信息，以便发送给朋友。 | （1）分享功能使用手机原生的分享面板。（2）链接若已安装应用则在应用内打开该条目，否则在网站上打开。（3）链接预览显示该条目的标题和图片。 |
市场与按需服务用户故事示例
市场平台至少包含三种角色（买家、服务提供者、运营方），通常只有当每个角色都有对应的用户故事时，某项功能才算完成。
| 用户故事 | 验收标准 |
|---|---|
| 18. 作为客户，我希望能在地图上跟踪我的快递员，以便知道何时该在门口等候。 | （1）取件后，快递员的位置至少每 15 秒更新一次。（2）显示预计到达时间并保持实时更新。（3）送达后停止位置共享。 |
| 19. 作为服务提供者，我希望设置每周可用时间，以便只收到我能接受的请求。 | （1）我可以为每个工作日设置时间段，并屏蔽特定日期。（2）客户无法在这些时间段之外请求服务。（3）更改可用时间不会取消已确认的预约。 |
| 20. 作为客户，我希望在服务完成后对服务提供者进行评分，以便其他客户能做出更好的选择。 | （1）当服务标记为完成时，会弹出评分提示，并保持开放 14 天。（2）我给出 1 到 5 星评分，并可添加可选评论。（3）只有完成过预约的客户才能对该服务提供者进行评价。 |
| 21. 作为卖家，我希望知道每笔款项何时到账，以便规划我的现金流。 | （1）每笔完成的订单显示扣除费用后的款项及预计到账日期。（2）付款历史列出日期、金额和订单。（3）如果付款失败，我会被告知原因及解决方法。 |
| 22. 作为市场运营方，我希望在新卖家的商品上线前进行审核，以确保违禁品不会出现在平台上。 | （1）新卖家的首批商品进入审核队列。（2）审核人员批准或拒绝，并给出卖家可见的理由。（3）批准后，卖家的后续商品将立即发布，除非被标记。 |
金融科技用户故事示例
在受监管的产品中，某些标准由法律设定，例如欧盟和英国的身份验证或支付强客户认证。请将这些作为起点，并与您的合规顾问确认具体规则。
| 用户故事 | 验收标准 |
|---|---|
| 23. 作为新客户，我希望在应用内验证我的身份，以便无需前往网点即可开户。 | （1）我在应用内拍摄身份证件并自拍。（2）我可以看到验证是通过、失败还是需要人工审核，以及下一步该做什么。（3）图像加密存储，且每次员工访问都有日志记录。 |
| 24. 作为持卡人，我希望能立即冻结我的卡片，以便在丢失时无人能使用它。 | （1）冻结在数秒内生效，新的卡片支付将被拒绝。（2）解冻后恢复同一张卡片。（3）界面说明在冻结期间定期支付的处理方式。 |
| 25. 作为用户，我希望交易自动分类，以便每月查看资金流向。 | （1）新交易在出现后一分钟内获得分类。（2）当我更改分类时，来自同一商家的未来交易将遵循我的选择。（3）月度视图显示每个分类的总额。 |
| 26. 作为账户持有人，我希望大额转账需要二次确认，以便在他人得知我密码时保护资金安全。 | （1）超过我设定限额的转账需要在应用内批准或输入一次性验证码。（2）向新收款人的首次支付需要相同步骤。（3）失败的确认会被记录，并通知我。 |
| 27. 作为小企业主，我希望发送带有“立即支付”链接的发票，以便客户可以用卡支付。 | （1）发票邮件包含安全支付链接。（2）支付成功后，发票自动标记为已付。（3）逾期发票会在我选择的日期触发提醒。 |
医疗健康用户故事示例
健康数据受美国 HIPAA 和欧盟 GDPR 等规则约束，因此访问控制和审计日志出现在大多数标准中。请与了解适用于您的规则的人员确认具体细节。
| 用户故事 | 验收标准 |
|---|---|
| 28. 作为患者，我希望在线预约，以便无需致电诊所。 | （1）仅显示所选医生和就诊类型的可用时段。（2）确认通过电子邮件或短信发送，并附带添加到日历的链接。（3）我可以在诊所截止前取消或改期；截止后显示诊所电话号码。 |
| 29. 作为患者，我希望有用药提醒，以免漏服。 | （1）我为每种药物设置提醒时间。（2）除非我允许，否则锁屏通知不显示药物名称。（3）我可以标记每次剂量为已服或未服，并查看历史记录。 |
| 30. 作为医生，我希望在一个屏幕上查看患者最近的化验结果，以便快速为就诊做准备。 | （1）显示最近 12 个月的结果，最新的在前，异常值高亮显示。（2）只有患者的医疗团队可以打开该屏幕。（3）每次查看都记录在访问日志中。 |
| 31. 作为患者，我希望从浏览器加入视频问诊，以便无需安装任何软件。 | （1）链接在桌面和移动端的最新 Chrome、Safari、Edge 和 Firefox 中均可使用。（2）我在候诊室等待医生接入。（3）首先进行摄像头和麦克风检查，若权限被阻止则提供帮助。 |
内部工具和管理员用户故事示例
内部工具往往因为“反正只给我们自己用”而缺乏用户故事，结果最终变成了一堆上百个字段、职责不清的庞然大物。
| 用户故事 | 验收标准 |
|---|---|
| 32. 作为一名客服专员，我希望在一个屏幕上看到客户最近的订单和工单，以便无需切换工具即可快速响应。 | (1) 我可以通过电子邮件、电话号码或订单号进行搜索。(2) 屏幕显示最近 10 笔订单和所有未结工单。(3) 客服专员可以查看但不能编辑支付详情。 |
| 33. 作为一名运营经理，我希望能够通过 CSV 文件批量更新订单状态，以免手动编辑数百条记录。 | (1) 在应用更改前，预览界面会显示哪些行将被修改以及哪些行存在错误。(2) 包含错误的行将被跳过并生成报告。(3) 每次批量更新都会记录操作人。 |
| 34. 作为一名 IT 管理员，我希望在一个地方即可停用离职员工的账户，以便他们立即失去对所有内部工具的访问权限。 | (1) 停用操作会立即终止所有活跃会话。(2) 其未完成任务将重新分配给其主管。(3) 其数据将根据保留策略保留，而非删除。 |
| 35. 作为一名财务主管，我希望超过一定阈值的费用需要审批，以便对大额采购进行核查。 | (1) 超过阈值的费用将提交给指定的审批人。(2) 审批人可以通过电子邮件或应用进行批准或拒绝，并附带评论。(3) 3 个工作日内未处理的请求将被升级。 |
AI 功能用户故事示例
AI 功能需要额外的验收标准：当模型不知道答案时如何处理、数据流向何处，以及如何判断其是否真正有帮助。对于任何发送、发布或支付的操作，必须确保人类始终处于控制地位。
| 用户故事 | 验收标准 |
|---|---|
| 36. 作为一名客服专员，我希望每个工单都有 AI 起草的回复，以便我能更快地回答常见问题。 | (1) 草稿显示在回复框中，并标注为“AI 生成”，仅在我点击“发送”时才会发出。(2) 它会链接所使用的帮助中心文章。(3) 当没有相关文章时，它会明确说明，而不是猜测。 |
| 37. 作为一名用户，我希望用自然语言询问关于我文档的问题，以便无需打开每个文件就能找到答案。 | (1) 答案仅使用我有权限查看的文档。(2) 每个答案都链接到其来源段落。(3) 如果文档中不包含答案，它会明确表示不知道。 |
| 38. 作为一名团队成员，我希望获得长篇会议记录的简短摘要，以便我能在几分钟内快速了解情况。 | (1) 摘要列出决策和行动项及其负责人。(2) 我可以重新生成或编辑摘要。(3) 不会自动进行摘要：只有当有人请求时才会创建摘要。 |
| 39. 作为一名工作区管理员，我希望能够为我团队开启或关闭 AI 功能，以便我们遵守数据政策。 | (1) 一个设置即可控制工作区内的所有 AI 功能。(2) 页面会说明哪个供应商处理数据，以及数据是否用于训练。(3) 更改将在几分钟内应用于所有用户，并记录日志。 |
| 40. 作为一名产品经理，我希望查看用户接受、编辑或拒绝 AI 建议的频率，以便判断该功能是否有帮助。 | (1) 每条建议都会被记录为已接受、已编辑或已拒绝。(2) 仪表板按周显示这些比率。(3) 分析数据仅存储结果，绝不存储提示词或文档内容。 |
坏 vs 好：6 个用户故事的重写
每个重写版本都明确了具体用户，将设计决策排除在目标之外，并提供了实际收益。
| 薄弱的故事 | 失败原因 | 改进版本 |
|---|---|---|
| 系统应支持 PDF 导出。 | 需求语言：没有用户，也没有原因。 | 作为一名会计，我希望每月都能将报表下载为 PDF，以便将其附在我们的记录中。 |
| 作为一名用户，我希望应用易于使用。 | 无法测试，且没有具体目标。 | 作为一名首次使用的用户，我希望从模板开始我的第一个项目，以便在几分钟内了解应用如何运作。 |
| 作为一名开发者，我希望迁移到 PostgreSQL。 | 这是一个技术任务；用户价值被隐藏了。 | 作为一名分析师，我希望月度报告在 3 秒内加载完成，以便我能在会议期间审阅它们。迁移工作成为此故事下的一个任务。 |
| 作为一名客户，我希望进行支付。 | 范围过大：它隐藏了支付方式、失败处理和退款等细节。 | 作为一名客户，我希望在结账时通过银行卡支付，以便我能一步完成订单。Apple Pay、退款和支付失败将作为独立的故事处理。 |
| 作为用户，我希望在右上角有一个蓝色的“保存”按钮。 | 直接规定了设计，没有留下任何讨论空间。 | 作为编辑，我希望我的更改能自动保存，这样即使浏览器关闭也不会丢失工作。 |
| 作为经理，我希望看到报告，以便我能看到报告。 | 收益只是重复了目标。 | 作为销售经理，我希望按阶段查看每位销售代表的销售管道，以便在季度结束前发现停滞的交易。 |
The 用户故事指南 解释了这些重写背后的 INVEST 检查清单。
从史诗到故事：一个分解示例
史诗是一个对于单个冲刺来说太大的结果。以下是 B2B SaaS 产品中“客户可以订阅并支付”这一史诗，分解为可以独立交付的故事：
- 作为新客户，我希望在没有信用卡的情况下开始免费试用，以便我可以在没有承诺的情况下评估产品。
- 作为试用用户，我希望在试用结束前选择套餐并添加我的信用卡，以便保留我的数据和设置。
- 作为账户所有者，我希望下载过去的发票，以便我可以将其归档用于报税。
- 作为账户所有者，我希望在每次年度续订前一周收到电子邮件，以便费用不会让我感到意外。
- 作为账户所有者，我希望在支付失败时有一个宽限期，以便我的团队不会因卡片过期而被锁定。
对于 MVP，故事 1 到 3 足以开始收费；4 和 5 在客户续订时变得重要。 用户故事映射指南 展示了如何划定这条界限。
技术性和非功能性用户故事示例
性能、可访问性和可靠性也可以是故事。指出感受到问题的用户，并使标准可衡量：
- 作为移动购物者，我希望产品页面在中端手机上快速加载，以便我在页面出现之前不会放弃。标准：在指定的测试设备上，通过 4G 网络，主要内容在 2.5 秒内显示；折叠线以下的图像延迟加载。
- 作为屏幕阅读器用户，我希望每个注册字段都有标签并被朗读，以便我可以独立创建账户。标准：表单符合 WCAG 2.2 AA 级；可以仅使用键盘完成；错误会被朗读。
如何将这些示例调整用于您的 MVP
- 将角色替换为您的真实用户。如果您服务的是购买校服的父母，“作为购物者”就变成了“作为购买校服的家长”。
- 用您自己的规则替换每个数字。上述的 7 天邀请、24 小时截止时间和 3 秒目标都是占位符。
- 在首次发布中，仅保留核心旅程上的故事。
- 添加您的客户和支持团队已经在讨论的不愉快路径。
- 与将构建它的人一起完善每个故事。复制的故事仍然需要对话。
如果您在没有技术联合创始人的情况下决定第一版的内容， 非技术创始人如何构建 MVP 涵盖了各种选项。对于一张包含所有字段的空白卡片，请使用 用户故事模板.
有一堆故事但没人构建？我们的团队每个冲刺都将用户故事转化为可用的软件。查看 我们的月度开发计划.
常见问题
什么是好的用户故事示例？
“作为回头客，我希望一键重新订购之前的购买，以便我可以补货而无需再次搜索。”它命名了特定用户、一个没有设计决策的目标和一个真实的收益。添加标准，例如：不再销售的物品在结账前被标记，并使用当前价格而非原始价格。
什么是史诗的示例？
“客户可以订阅并支付”是一个史诗：一个对于冲刺来说太大的结果。它分解为开始免费试用、在试用结束前添加信用卡、下载发票和处理支付失败等故事。
如何编写技术性用户故事？
指出感受到收益的人，即使是队友（“作为值班工程师……”），在 so-that 子句中陈述价值，并给出可衡量的标准。如果完全没有用户可见的价值，它可能是另一个故事下的任务，而不是故事。
用户故事应该有多少验收标准？
通常三到六个。少于这个数量往往意味着遗漏了异常路径；多于这个数量则通常意味着故事太大，应该拆分。