user-story

name	user-story
description	把功能需求拆解为用户故事和可测试的验收标准时使用。适用于 PRD 第 7 节、Sprint 准备、给 QA 的测试输入。优先使用 INVEST 检查 + Given/When/Then 格式。

用户故事拆解

适用场景

• 把功能模块拆成可独立交付的用户故事
• 为每个功能点定义可测试的验收标准
• 给开发拆任务、给 QA 写测试用例提供输入
• 验证需求是否足够清晰可执行

核心格式

用户故事三段式

作为 <用户角色>
我希望 <完成某个动作>
以便 <获得某个价值>

示例：

✅ 好的：

作为已登录的普通用户
我希望能在订单详情页一键申请退款
以便不用再发邮件给客服等待回复

❌ 差的：

作为系统
我要支持退款功能

（没有用户、没有价值、把技术任务伪装成用户故事）

验收标准 Given/When/Then

Given <前置条件>
When <用户行为>
Then <系统结果>

示例：

Given 用户已登录且订单状态为"已支付"
When 用户在订单详情页点击"申请退款"按钮
Then 系统创建退款申请并显示"已提交，预计 3 个工作日处理"
And 订单状态变为"退款审核中"

每个用户故事至少包含：

• 1 条主路径验收标准
• 至少 1 条异常路径验收标准

INVEST 用户故事检查

每条故事写完后用以下 6 项自检：

I - Independent（独立）
   能否独立交付？是否依赖其他故事必须先完成？

N - Negotiable（可协商）
   是否保留了协作和讨论空间？还是把实现细节写死了？

V - Valuable（有价值）
   是否对用户有明确价值？还是技术内部需要？

E - Estimable（可估算）
   能不能估出工期？信息是否足够？

S - Small（足够小）
   AI 工作流能否 30~60 分钟内完成？超过就要继续拆。

T - Testable（可测试）
   有没有 Given/When/Then 验收标准？能不能验证？

拆分模式（Richard Lawrence 9 模式）

当一个故事太大时，按以下模式拆：

1. 工作流步骤拆分
   注册流程 → 填写信息 / 验证邮箱 / 完善资料

2. 业务规则变体
   订单退款 → 7 天内 / 超过 7 天 / 已发货 / 未发货

3. 操作（CRUD）拆分
   用户管理 → 创建 / 查询 / 修改 / 删除

4. 数据类型变体
   附件上传 → 图片 / 文档 / 视频

5. 数据接口拆分
   导入 → CSV / Excel / API

6. 延迟性能优化
   先实现功能 / 后优化性能

7. 简单/复杂场景拆分
   简单退款（自动） / 复杂退款（人工审核）

8. 主要/次要操作
   主操作 / 撤销 / 历史记录

9. 横切关注点
   先实现功能 / 后加权限 / 再加日志

工作流程

1. 接收功能需求或 PRD 第 6 节内容
   ↓
2. 识别用户角色（每个角色单独考虑）
   ↓
3. 列出每个角色要完成的任务
   ↓
4. 用三段式写故事
   ↓
5. 用 INVEST 检查
   ↓
6. 太大就用拆分模式继续拆
   ↓
7. 每条故事写主路径 + 异常路径验收标准
   ↓
8. 输出故事清单（含优先级）

输出格式

## US-001: 用户申请退款

**故事**：
作为已登录的普通用户
我希望能在订单详情页一键申请退款
以便不用再发邮件给客服等待回复

**优先级**：P0（Must Have）
**预估工期**：30 分钟（AI 节奏）
**依赖**：订单详情页（US-XXX）

**验收标准**：

主路径：
- Given 用户已登录且订单状态为"已支付"
- When 用户点击"申请退款"
- Then 创建退款申请，订单状态变为"退款审核中"

异常路径 1：订单已超过退款期限
- Given 订单已支付超过 30 天
- When 用户点击"申请退款"
- Then 显示"超过退款期限"提示，按钮置灰

异常路径 2：订单状态不允许退款
- Given 订单状态为"已退款"或"已取消"
- When 用户进入订单详情页
- Then 不显示"申请退款"按钮

**INVEST 检查**：
- [x] Independent：不依赖其他故事
- [x] Negotiable：实现方式可讨论
- [x] Valuable：用户价值明确
- [x] Estimable：30 分钟可完成
- [x] Small：足够小
- [x] Testable：有 G/W/T 标准

质量自检

□ 是否用了"作为...我希望...以便..."三段式？
□ 用户角色是否具体？（不能只写"用户"）
□ 价值描述是否真实？（不能只写"为了完成功能"）
□ 是否通过了 INVEST 6 项检查？
□ 是否同时有主路径和异常路径验收标准？
□ Given/When/Then 是否可测试？
□ 是否估算了 AI 工期？

常见坑

1. 把技术任务伪装成用户故事——"作为系统，我要..."
2. 价值段写空话——"为了提升用户体验"
3. 验收标准只写正向——异常场景是 QA 最关心的
4. 故事太大不拆——超过 60 分钟必须用 9 模式拆
5. 用户角色太宽泛——"用户" → 改成"已登录的免费用户"
6. G/W/T 不可测试——"Then 用户感到满意" → 改成具体可观察的系统行为

配套模板

• templates/user-story-template.md — 单条故事模板
• templates/acceptance-criteria-template.md — 故事清单模板（含优先级矩阵）

与其他 skill 的协作

上游：
  prd-writing → 第 6 节功能需求转化为用户故事
  mvp-scoping → 标注每条故事的优先级（Must/Should/Could/Won't）

下游：
  转交项目经理 → 拆排期
  转交 QA → 设计测试用例
  转交开发 → 实现功能