当用户故事/史诗太大无法估算、排进一个 sprint…

把过大、过复杂、含多个流程/规则/数据/验收条件的用户故事或史诗，系统化拆成更小、可独立开发测试和交付的故事。

适用场景

解决思路

1. 从需要拆分的故事、史诗或特性开始；确保它使用用户故事格式书写（可参考 skills/user-story/SKILL.md 或 skills/epic-hypothesis/SKILL.md）。
2. 如果调用时已经提供故事文本、上下文转储或附加的 ARGUMENTS: 行，把它视为已回答的输入，直接使用并跳过它已覆盖的问题，不要重复询问。
3. 如果没有提供输入，先询问要拆分的故事文本，然后拿这些拆分模式逐一分析它。
4. 使用 template.md 的完整填写结构与输出格式。
5. 按顺序套用 8 个拆分模式，找到第一个适用的模式后停止。
6. Pattern 1 工作流步骤（Workflow steps）：询问该故事是否包含多个顺序步骤；若包含，按用户旅程中的连续步骤拆分。例：把“注册、验证邮箱、完成 onboarding”拆成“用邮箱/密码注册”“通过确认链接验证邮箱”“回答 3 个资料问题完成 onboarding”。
7. Pattern 2 业务规则变体（Business rule variations）：询问该故事是否对不同场景有不同规则；若有，按规则场景拆分，例如权限、计算等。例：把“会员 10%、VIP 20%、首次购买 5% 折扣”拆成会员折扣、VIP 折扣、首次购买折扣三个故事。
8. Pattern 3 数据变体（Data variations）：询问该故事是否处理不同数据类型或输入；若有，按数据类型或输入拆分。例：把“上传图片、PDF、视频”拆成上传 JPG/PNG 图片、上传 PDF 文档、上传 MP4/MOV 视频三个故事。
9. Pattern 4 验收条件复杂度（Acceptance criteria complexity）：询问该故事是否有多个 When 或 Then 语句；若有，沿这些边界拆分。例：把“管理购物车”拆成添加商品、移除商品、更新数量三个故事。注意：这是故事需要拆分的最常见信号；看到多组 When/Then 就按这些边界拆。
10. Pattern 5 重大工作量（Major effort）：询问该故事是否需要显著技术工作且可增量交付；若是，按技术里程碑或实现阶段拆分。例：把“文档实时协作”拆成查看谁在阅读文档的只读在线状态、查看其他编辑者的实时光标位置、实时看到其他用户的编辑三个故事。
11. Pattern 6 外部依赖（External dependencies）：询问该故事是否依赖多个外部系统或 API；若是，按依赖边界拆分。例：把“用 Google、Facebook 或 Twitter 登录”拆成 Google OAuth 登录、Facebook OAuth 登录、Twitter OAuth 登录三个故事。
12. Pattern 7 DevOps 步骤（DevOps steps）：询问该故事是否需要复杂部署、基础设施或运维工作；若是，按部署或基础设施需求拆分。例：把“上传大文件到云存储”拆成上传小文件（<10MB）、上传大文件（10MB-1GB）并显示进度、恢复中断上传三个故事。
13. Pattern 8 小型探索行动（Tiny Acts of Discovery, TADs）：如果以上模式都不适用，询问是否存在需要解开的未知或假设；若有，用小实验拆解未知。TADs 不是故事，是实验；用于在写故事前降低风险和澄清。例：AI 推荐场景可拆成原型 3 种推荐算法并用 10 个用户测试、定义成功标准（点击率、用户满意度）、构建最简单推荐引擎（协同过滤）、测量并迭代。
14. 对每个拆分结果，写出完整用户故事，格式来自 skills/user-story/SKILL.md：User Story [ID]、Summary、Use Case（As a/I want to/so that）、Acceptance Criteria（Scenario/Given/When/Then）。
15. 验证拆分 1：每个拆分是否交付用户价值，而不是只完成“前端做完了”。
16. 验证拆分 2：每个拆分是否可以独立开发，没有硬依赖。
17. 验证拆分 3：每个拆分是否可以独立测试，并且验收条件清晰。
18. 验证拆分 4：每个拆分是否足够小，适合一个 sprint，约 1-5 天工作量。
19. 验证拆分 5：拆分合并后是否等于原始故事，没有丢失内容。
20. 如果任一验证答案为“否”，修订拆分。
21. 避免水平切片：不要拆成“Story 1：构建 API；Story 2：构建 UI”；应垂直拆分，每个故事都包含前端 + 后端工作，以交付完整用户能力。
22. 避免过度拆分：只在故事太大时才拆；一个 2 天的故事不需要拆分。
23. 避免无意义拆分：不要“Story 1：功能前半部分；Story 2：功能后半部分”；应使用 8 个拆分模式之一，让每个拆分都有明确理由。
24. 避免制造硬依赖：不要拆成“Story 2 必须等 Story 1 100% 完成、测试并部署后才能开始”；应拆成允许独立开发；若依赖不可避免，优先做 Story 1。
25. 避免忽略“so that”：如果拆分后的故事有相同的 so that，说明只拆了动作没拆结果，可能是任务分解而不是故事拆分；确保每个拆分有不同用户结果，否则重新考虑拆分模式。

适用边界 · 注意事项

• 故事已经足够小且范围明确时不要用，避免过度拆分；例如 2 天的故事不需要拆。
• 拆分会产生拖慢交付的硬依赖时不要这样拆；若依赖不可避免，优先交付被依赖的第一个故事。
• 对象是技术任务而不是用户故事时不要用本技能，改用工程任务拆解。