用户故事
User Story
中级通用用户故事（User Story）是从使用者视角描述一项需求的简短表达，交代谁想完成什么、为什么。它帮你和团队先对齐用户目标，再讨论怎么做；例如，让店主能快速找到待发货订单，以便及时处理。
你可能会说：「我想让 AI 帮我把这个功能写成用户能完成的事，别一上来就列页面和按钮。」
读之前建议先了解
要点一条用户故事要讲清什么？
- 1
先说清是谁在什么情境下使用
同一个功能，对不同的人可能解决不同问题。比如“查看订单”，店主关心哪些订单还没发货，买家关心包裹到了哪里。你把使用者和情境说清，AI 才不容易把两种需求混在一起。
- 2
写出想完成的事和背后的原因
故事的重点是用户想达成的结果，不是预先指定界面。与其只说“做个红色提醒按钮”，不如说“店主想及时发现超时未发货的订单，以免漏单”。这样我们还能比较通知、筛选等不同做法。
- 3
再用验收条件补足具体边界
用户故事通常刻意写得短，所以它本身不足以让 AI 直接实现。你可以接着说明哪些订单算超时、谁能看到提醒、点开后看到什么。这样既保留用户目标，也有依据判断功能是否做对。
容易混淆的地方
用户故事讲的是某类用户想达成什么结果、为什么；用户用例通常会进一步展开用户与系统如何交互，包括不同路径。它也不是验收标准：故事帮我们确定要解决的问题，验收标准则把“做到什么程度算完成”说清楚。写给 AI Agent 时，两者放在一起更容易落地。
什么时候用
适合用
- 准备给后台增加订单处理功能时，先写店主的用户故事，让团队讨论真正要解决的是漏单还是操作太慢。
- 让 AI Agent 实现新功能前，用用户故事交代使用者和目标，再补充验收条件，减少它自行猜测需求。
- 产品讨论出现多种界面方案时，用用户故事核对：这些方案是否都能帮助同一类用户完成目标。
不适合用
- 只是修复一个已定位的接口报错时，直接提供复现步骤、预期结果和报错信息，比重新写用户故事更有效。
- 只想规定登录接口的字段、状态码和错误响应时，用 API 契约描述更合适；这些技术约定不是用户目标。
- 需要排定未来几个季度的产品方向时，用产品路线图表达阶段目标；单条用户故事承载不了时间与优先级安排。
练一练选一个答案，看看解释
你要请 AI Agent 为店铺后台增加处理退款申请的功能。哪段描述最适合作为用户故事的起点？
让 AI 帮你做复制给 AI Agent 直接用
请先把“店铺后台处理退款申请”整理成 2 至 3 条用户故事，分别写清使用者、想完成的事和原因。列出每条故事还缺哪些业务信息，并提出可验证的验收条件；信息不明时先问我，不要自行决定界面或规则。