在软件开发这行，需求文档里、Sprint Planning 会上、架构评审中，你都会碰到这两个词。Use Case vs User Story 这个区分之所以重要，是因为它们服务不同的目的——在错误的地方用错工具，要么导致功能规格不足、上线就崩，要么导致过度文档化、没人会读。
我两种都写过，两种都教过新同事，也见过团队试图强迫一种格式去做另一种格式的工作时有多痛苦。以下是它们各自到底是什么意思、什么时候用、以及怎么搭配。
一眼对比
| User Story | Use Case | |
|---|---|---|
| 格式 | 索引卡上的一句话 | 多页结构化文档 |
| 模板 | "作为[用户]，我想要[功能]，以便[目的]" | 标题、参与者、前置条件、主流程、备选流程、后置条件 |
| 细节程度 | 刻意留白，靠对话补充 | 完备——覆盖所有路径和异常 |
| 谁来写 | PO 或团队协作 | 业务分析师或系统架构师 |
| 最适合 | 敏捷 Sprint、迭代开发 | 复杂系统、受监管行业、系统集成 |
| 生命周期 | 临时的——讨论、开发、归档 | 持久的——作为参考文档长期维护 |
| 思考方向 | 由外向内：用户需要什么 | 由内向外：系统如何响应 |
User Story：敏捷的方式
User Story 由 Kent Beck 发明，Mike Cohn 推广，是一个刻意不完整的工件。不完整不是 bug——是设计意图。三段式模板迫使你回答三个问题：
- 作为[具体用户] —— 这是为谁做的？不是「作为用户」，而是「作为一个还没注册过账号的首次访客」。
- 我想要[具体动作] —— 他们需要做什么？不是「我想要更好的体验」，而是「我想在不联系客服的情况下重置密码」。
- 以便[具体目的] —— 为什么需要？不是「以便产品更好」，而是「以便我忘记密码后能立刻登录，不用等 24 小时的邮件回复」。
User Story 里刻意留下的空白，靠对话来填补——PO、开发者、测试在 Sprint Planning 期间讨论 Story，完善共识。这就是为什么 User Story 在敏捷团队里有效：团队在一起（物理或虚拟）、每天交流、误解的成本低，因为他们小批量交付，快速纠偏。
一个好的 User Story 示例：
作为一个用着手持扫描枪的仓库拣货员，我想要 App 显示出我拣货清单里下一个商品所在的具体货架位置，这样我能一把抓过去，而不是在货架通道里找来找去。
注意什么是没有的——没有提到界面布局、没有错误处理、没有写扫描枪没电了怎么办。这些细节会在对话中浮现。Story 的职责是用足够的上下文启动对话，让所有人都知道这是为谁做的、什么算成功。
验收标准（Acceptance Criteria）经常附在 User Story 后面，为"做完"设一个具体标准：
- 给定一个包含 5 件商品的拣货清单，当我扫描第一件商品时，扫描枪显示"Aisle 3, Shelf B, Bin 12"
- 给定商品分布在不同通道，当我完成一件时，下一件的位置在 1 秒内显示
- 给定一个拣货清单，当扫描枪断连时，当前商品的位置保持显示，并出现"重连中"提示
Use Case：结构化的规格
Use Case 由 Ivar Jacobson 在 80 年代提出，在 90 年代到 21 世纪初成为记录软件需求的标准方式。User Story 能写的便利贴上，Use Case 是一份有固定结构的文档。
一个完整的 Use Case 通常包含：
- 标题和编号 —— 唯一标识这个用例
- 主要参与者（Primary Actor） —— 发起交互的人或系统
- 干系人（Stakeholders） —— 任何对结果有利害关系的人
- 前置条件（Preconditions） —— 用例开始前必须为真的事
- 主成功场景（Main Success Scenario） —— 正常路径，逐步描述
- 扩展/备选流程（Extensions） —— 每一个偏离正常路径的变体
- 后置条件（Postconditions） —— 用例结束后必须为真的事
- 特殊需求（Special Requirements） —— 非功能性约束（性能、安全、合规）
同样的场景，写成 Use Case：
UC-014：拣货清单商品位置展示
主要参与者： 仓库拣货员（已认证，手持扫描枪） 前置条件： 拣货清单已分配给该拣货员，仓库地图已加载到设备，扫描枪有连接。
主成功场景：
- 拣货员扫描拣货清单中下一件商品的条码。
- 系统查询库存数据库获取该商品的货架位置。
- 系统在扫描枪屏幕上显示"Aisle X, Shelf Y, Bin Z"。
- 系统在仓库地图上高亮该位置。
- 拣货员走到该位置并取出商品。
扩展：
- 2a. 商品条码在数据库中未找到 → 显示"商品不在系统中——请退回主管"并记录未识别的条码。
- 2b. 库存数据库查询超时（>2 秒）→ 重试一次，然后显示"系统响应较慢——请等待"并显示加载动画。
- 3a. 商品在多仓位位置 → 按距离拣货员当前位置排序显示所有可选仓位。
- 5a. 拣货员在货位扫描了错误商品 → 扫描枪震动，闪红光，显示"商品错误——应为[商品名]"。
Use Case 不留任何死角。每一个失败模式、每一个边界情况、每一个系统响应都被记录。对支付系统或医疗设备来说，这种细节程度不是过度——是法律要求。
团队最常见的混淆
错误一：把 User Story 写成伪装的 Use Case。 症状：一个 User Story 带 14 条验收标准、一个关联的 Confluence 页面，还有"参见附图"。这不是 User Story——这是一个被人强行压缩进 Jira 工单里的 Use Case，因为团队流程规定"所有东西都必须是 User Story"。如果一个功能需要对备选流程做完备记录，那就写 Use Case，然后从一个轻量的 User Story 引用它。
错误二：对敏捷团队里的简单功能使用 Use Case。 Web 应用里的"重置密码"流程不需要 6 页的 Use Case 文档。两个 User Story 加一次团队对话，15 分钟就能覆盖。Use Case 的价值跟交互的复杂度成正比，不是跟文档的长度成正比。
错误三：写 Use Case 不写扩展流程。 主成功场景是容易的部分。扩展流程才是真正的工作量所在——也是那些跳过了 Use Case 的团队在上线后踩到的坑。如果你在写 Use Case，但扩展部分空着，说明你还没有想得足够深。
两者怎么搭配
在实践中，很多高效的团队两个都用。一个 User Story 放在 Sprint 看板上："作为一个客户，我想用银行转账付款，这样可以避免信用卡手续费。"这个 Story 关联一份 Use Case 文档，覆盖银行转账流程的每条路径——14 种失败方式、合规要求、超时和重试逻辑。
User Story 让团队在站会时有一个能指着说的东西。Use Case 让他们确信有人已经在写代码之前想过了边界情况。当 Story 做完、Sprint 结束，Story 归档了。Use Case 作为动态文档保留。
你的团队该不该用 Use Case
对你正在构建的功能，问自己三个问题：
- 这个交互有超过 5 种不同的出错方式吗？ 如果有，Use Case 的扩展部分会在代码写出来之前就帮你发现 Bug。
- 这个交互的失败会有监管、财务或安全后果吗？ 如果有，Use Case 的结构化文档是值得花时间的。
- 构建这个功能的团队分布在多个时区，实时对话的机会有限吗？ 如果有，Use Case 的细节能填补原本靠走廊聊天解决的信息缺口。
如果三个问题都回答"不"，User Story 大概率就够了。
总结
User Story 是轻量的、对话驱动的，为能通过日常交流澄清细节的敏捷团队而设计。用于 Sprint 级别规划和简单功能。
Use Case 是完整的、结构化的，为遗漏边界情况会有真实后果的场景而设计。用于复杂交互、受监管系统和系统间集成。
一种不比另一种更好——它们解决不同的问题。知道什么时候该拿哪一个的团队，构建的软件在生产环境里能用，不只是演示的时候好看。
