用户故事核心三要素：角色、功能、价值
用户故事是敏捷需求描述的核心容器，它把零散的客户诉求转化为可讨论、可验证的结构化表达。三要素（角色、功能、价值）分别回答“谁要”、“做什么”和“为什么”。只要任意一个要素缺失，故事就会失去可执行性。
用户故事标准模板： 作为<角色>，我希望<功能>，以便<价值>
1.1 三要素详解
| 要素 | 含义 | 常见错误 | 正确示例（局部） |
|---|---|---|---|
| 角色（Who） | 发起交互或受影响的用户类型、系统角色 | “用户”过于宽泛；遗漏系统角色 | “作为已登录的普通用户” |
| 功能（What） | 系统提供的具体行为或可观测结果 | 描述实现细节而非行为；包含“点击按钮”等UI层术语 | “我希望系统自动保存草稿” |
| 价值（Why） | 该功能带来的业务收益或用户目标达成 | 只写“为了提高效率”而不量化；与角色利益脱节 | “以便我在网络中断时不丢失已编写内容” |
检查清单： 写完后用三要素逐一核验。如果某个要素可以删掉而不影响理解，说明它写错了或冗余。
1.2 从业务问题到三要素的提炼路径
用户故事不是凭空编出来的。它来自对业务痛点的抽象、用户访谈的归纳以及场景的切片。典型路径如下：
- 采集原始诉求：通过用户访谈、故障工单、竞品分析收集“我想要 X”。
- 剥离技术和UI：把“点一个蓝色按钮”还原为“触发一个状态变更”。
- 定位真实角色：区分提出者（买方）、执行者（操作人）、受益者（结果方）。
- 追问“为什么直到最后一步”：连续问5次以便提炼深层价值。
- 写出一句话故事：按模板压缩成一行，删除所有冗余副词。
避坑提醒： 请不要把用户故事写成功能清单：“作为管理员，我希望有导出按钮”。这是UI需求，不是故事。正确的写法：“作为报表负责人，我希望一键导出当月流水，以便离线审计。”（功能抽象为“导出”，价值明确为“离线审计”）
1.3 三要素如何衔接验收条件
验收条件本质上是三要素的可测化展开。角色决定了前置权限和上下文；功能分解为具体步骤或边界；价值转化为通过/失败的判断指标。没有三要素，验收条件就会变成无根的技术清单。
1.4 用户故事三要素到验收条件流程
实战建议： 在PRD中，每个用户故事都应附带一个类似的溯源图——哪怕不画SVG，也要在文字中注明“本故事脱胎于某次用户访谈中XX角色抱怨XX痛点”。这样能大幅减少需求评审时的返工。