用户用例
Use Case
中级通用用户用例（Use Case）描述某类用户为了达成一个目标，如何与产品交互，以及不同情况下会得到什么结果。它帮你把「做个导出功能」说清楚，让设计和开发知道正常导出、无数据和导出失败时各该发生什么。
你可能会说：「帮我理清用户怎么完成导出，遇到没数据或导出失败时产品该怎么处理。」
动手看看运营导出订单报表
1
运营想拿到本月订单报表，选好日期后点击导出。系统确认他有权限，再检查这个范围里有没有订单。
要点一个用户用例要讲清哪些事？
- 1
先说谁要完成什么目标
比如运营人员想把本月订单导出，目标是拿到可核对的文件，而不是「点击导出按钮」。因为按钮只是操作，目标才决定我们该不该提供日期范围、导出哪些字段。
- 2
再说从哪里开始和怎样结束
你可以写清用户已登录、能查看订单，然后描述他选日期、发起导出、拿到文件的过程。这样 AI Agent 才能判断需要哪些页面状态和接口，而不只是画一个按钮。
- 3
把会改变结果的分支写出来
如果所选日期没有订单，产品可以提示没有可导出的数据；如果生成文件失败，可以告知用户并提供重试。写这些分支，是为了让大家提前讨论结果，而不是等开发完才发现遗漏。
容易混淆的地方
用户故事常用一句话概括「谁想做什么、为什么」，适合提出需求；用户用例会进一步展开交互过程和可能结果。用户流程更偏向展示用户经过哪些页面或操作节点；用例还会交代目标、前提和异常分支。测试用例则是在确定行为后，用具体条件和预期结果检验实现。
什么时候用
适合用
- 让 AI Agent 开发订单导出功能前，先梳理运营人员从选择范围到拿到文件的完整过程。
- 设计后台成员邀请功能时，和团队讨论邀请成功、邮箱已被邀请、权限不足各会发生什么。
- 评审 AI 文档问答功能时，厘清用户提问后得到答案、找不到资料或生成失败的处理方式。
不适合用
- 只是调整现有按钮的颜色和间距，交互目标没有变化时，直接给设计稿或样式要求更省事。
- 线上接口已经报错，需要定位是哪一行代码出问题时，先看报错与调用栈，而不是写用户用例。
- 还不知道目标用户是谁、他们是否需要这个功能时，先做产品发现和访谈，别急着展开交互过程。
练一练选一个答案，看看解释
你让 AI Agent 做一个后台「邀请成员」功能。下面哪段信息最适合作为用户用例的起点？
让 AI 帮你做复制给 AI Agent 直接用
请先为后台「邀请成员」功能整理用户用例：写明使用者、目标、开始前的条件、主要交互和成功结果，再列出邮箱已加入、权限不足、发送失败时用户会看到什么。先标出需要我决定的产品规则，不要直接写代码。