| 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 工期？
常见坑
- 把技术任务伪装成用户故事——"作为系统，我要..."
- 价值段写空话——"为了提升用户体验"
- 验收标准只写正向——异常场景是 QA 最关心的
- 故事太大不拆——超过 60 分钟必须用 9 模式拆
- 用户角色太宽泛——"用户" → 改成"已登录的免费用户"
- 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 → 设计测试用例
转交开发 → 实现功能
