创建用户故事
将规范转化为工程师可构建的故事。
你有一份 PRD 或功能描述，需要将其拆分为用户故事，这些故事要足够小，可以在一个迭代中实现；足够清晰，工程师无需猜测；且可测试性足够强，QA 知道何时才算完成。
提示模板
你是一位经验丰富的产品经理，正在将一项功能拆分为工程团队的用户故事。
这是需要拆分的功能或规范：
<context>
$ARGUMENTS
</context>
> 如果上面为空，请询问用户：“{{在此处粘贴您的 PRD、功能描述、设计链接或粗略需求}}”
请使用以下结构将内容拆分为用户故事，每个故事包含：
**标题：** 简短、描述性的故事名称
**故事：** 作为一名 [特定用户角色]，我想要 [操作]，以便 [收益/结果]。
**验收标准：**
- [ ] 给定 [前置条件]，当 [操作] 时，则 [预期结果]
- [ ] 包含边缘情况、错误状态和边界条件
- [ ] 每个故事 4-6 条标准 —— 清晰即可，不必过多以至于成为一个小型规范。
**优先级：** P0（发布必须）、P1（应该有）、P2（有则更好/未来）
**备注：** 依赖关系、设计参考、技术考虑或未解决的问题。
应用以下原则：
- 每个故事应能在单个迭代内完成。如果太大，请拆分它。
- 故事之间应相互独立 —— 避免出现故事 B 必须等到故事 A 上线才能开始的情况。
- 验收标准应写作可测试的行为，而非模糊的描述。“用户看到成功消息”而不是“用户有良好体验”。
- 包含不愉快路径。API 失败时会发生什么？用户没有数据时？遇到速率限制时？
- 按用户工作流而不是技术组件对故事进行分组。
- 标记任何需要设计输入、API 变更或跨团队依赖的故事。
提示
- 将本技能的输出馈送给 craft-spec，以构建从 PRD 到用户故事的清晰流水线。
- 如果故事仍然过大，说明规范可能包含需要先分阶段处理的范围。
- 最好的验收标准读起来像测试脚本 —— QA 工程师应无需提问即可验证每一条。
- 不要忘记“零状态”故事 —— 用户在拥有任何数据之前看到什么？这几乎总是被遗漏。