name: 用户故事 description: 创建清晰、简洁的用户故事，结合Mike Cohn的用户故事格式和Gherkin风格的接受标准。使用此技能将用户需求转化为可操作的开发工作，专注于成果、确保产品与工程之间的共同理解，并提供可测试的成功标准。 type: component

目的

创建清晰、简洁的用户故事，结合Mike Cohn的用户故事格式和Gherkin风格的接受标准。使用此技能将用户需求转化为可操作的开发工作，专注于成果、确保产品与工程团队之间的共同理解，并提供可测试的成功标准。

这不是功能规格说明书——它是一个对话启动器，捕捉谁受益、他们试图做什么、为什么重要，以及如何知道它有效。

关键概念

Mike Cohn + Gherkin 格式

用户故事结合：

用例（Mike Cohn格式）：

作为 [用户角色/角色]
我想要 [实现成果的动作]
以便 [期望的成果]

接受标准（Gherkin格式）：

场景： [场景的简要描述]
给定： [初始上下文或前提条件]
并且给定： [额外的前提条件]
当： [触发动作的事件]
然后： [预期的成果]

为什么这种结构有效

以用户为中心： 强迫关注谁受益和为什么
以成果为导向： “以便”强调交付的价值，不仅仅是动作
可测试： Gherkin接受标准具体且可验证
对话性： 故事是讨论的开端，不是最终规格
共享语言： 产品、工程和QA都理解格式

反模式（这不是什么）

不是任务： “作为开发者，我想要重构API，以便代码更干净”（这是技术任务，不是用户价值）
不是功能列表： “我想要仪表板、报告和分析”（太大——需要拆分）
不模糊： “我想要更好的体验”（不可测量，没有清晰成果）
不是合同： 故事是对话的占位符，不是锁定的规格

何时使用

将用户需求转化为开发工作
待办事项梳理和冲刺规划
向工程和设计传达价值
确保在开发前存在可测试的接受标准

何时不使用

对于纯技术债务或重构（使用工程任务代替）
当故事太大时（先拆分——参见skills/user-story-splitting/SKILL.md）
在理解用户问题之前（先写问题陈述）

应用

步骤1：收集上下文

在写故事之前，确保有：

用户角色： 这是为谁？（参考skills/proto-persona/SKILL.md）
问题理解： 这解决什么需求？（参考skills/problem-statement/SKILL.md）
期望成果： 成功看起来像什么？
约束： 技术、时间或范围限制

如果缺少上下文： 先进行发现访谈或问题验证工作。

可选辅助脚本（模板生成器）

如果你想从CLI输入生成一致的Markdown存根，可以使用这个脚本。这个脚本是确定性的，不获取数据或写文件。

python3 scripts/user-story-template.py --persona \"试用用户\" --action \"使用Google登录\" --outcome \"无需创建新密码即可访问应用\"

步骤2：写用例

使用template.md获取完整的填充结构。

填充模板：

### 用户故事 [ID]：

- **总结：** [简短、易记的标题，聚焦用户价值]

#### 用例：
- **作为** [如果可用用户姓名，否则角色，否则角色]
- **我想要** [用户采取的动作以达到成果]
- **以便** [期望的成果]

质量检查：

“作为”具体性： 这是特定角色（如“试用用户”）还是通用（“用户”）？
“我想要”清晰性： 这是用户采取的动作，还是你构建的功能？
“以便”成果： 这解释用户的动机吗？还是只是重复动作？

常见错误：

❌ “作为用户，我想要登录按钮，以便我可以登录”（重复动作）
✅ “作为试用用户，我想要使用Google登录，以便无需创建新密码即可访问应用”

步骤3：写接受标准

填充模板：

#### 接受标准：

- **场景：** [简短、人类可读的场景描述价值]
- **给定：** [初始上下文或前提条件]
- **并且给定：** [额外上下文或前提条件]
- **并且给定：** [根据需要额外上下文]
- **并且给定：** [UI聚焦的上下文确保‘当’可以发生]
- **并且给定：** [成果聚焦的上下文确保‘然后’被交付]
- **当：** [触发动作的事件——与‘我想要’对齐]
- **然后：** [预期的成果——与‘以便’对齐]

质量检查：

多个给定可以： 前提条件堆叠（如“给定我登录了”+“给定我购物车有物品”）
只有一个当： 如果需要多个“当”语句，你可能需要多个故事——拆分它们
只有一个然后： 如果需要多个“然后”语句，你可能需要多个故事——拆分它们
对齐： “当”匹配“我想要”吗？“然后”匹配“以便”吗？

红旗：

多个当/然后： 范围蔓延的迹象——拆分故事（参考skills/user-story-splitting/SKILL.md）
模糊的然后： “然后我看到改进的性能”（不可测量——使其具体）

步骤4：添加总结

写一个简短、易记的总结，捕捉故事的价值：

- **总结：** [简短、人类可读的标题]

例子：

✅ “为试用用户启用Google登录以减少注册摩擦”
✅ “批量删除项目以为高级用户节省时间”
❌ “添加删除按钮”（以功能为中心，不是以价值为中心）

步骤5：验证和优化

向团队大声朗读： 每个人都理解谁、什么、为什么吗？
测试接受标准： QA能从这个写测试用例吗？
检查拆分： 如果故事感觉太大，使用skills/user-story-splitting/SKILL.md
确保可测试性： 你能证明“然后”发生了吗？

例子

参见examples/sample.md获取完整例子（好、坏和需要拆分的故事）。

迷你例子摘录：

### 用户故事 042：

- **总结：** 为试用用户启用Google登录以减少注册摩擦

#### 用例：
- **作为** 首次访问应用的试用用户
- **我想要** 使用我的Google账户登录
- **以便** 无需创建和记住新密码即可访问应用

#### 接受标准：
- **场景：** 首次试用用户通过Google OAuth登录
- **给定：** 我在登录页面
- **并且给定：** 我有一个Google账户
- **当：** 我点击“使用Google登录”按钮并授权应用
- **然后：** 我登录到应用并被重定向到入门流程

常见陷阱

陷阱1：技术任务伪装成用户故事

症状： “作为开发者，我想要重构API，以便代码更干净”

后果： 这是工程任务，不是用户故事。没有交付用户价值。

修复： 如果没有用户成果，这不是用户故事——使用工程任务或技术债务票代替。

陷阱2：“作为用户”（太通用）

症状： 每个故事都以“作为用户”开始

后果： 没有角色清晰性。不同用户有不同需求。

修复： 使用特定角色：“作为试用用户”、“作为付费订阅者”、“作为管理员”等。（参考skills/proto-persona/SKILL.md）

陷阱3：“以便”重复“我想要”

症状： “我想要点击保存按钮，以便我可以保存我的工作”

后果： 没有洞察用户为什么关心。只是重复动作。

修复： 深入动机：“以便如果页面崩溃我不会失去我的进度”（真实成果）。

陷阱4：多个当/然后语句

症状： 接受标准有5个“当”语句和5个“然后”语句

后果： 故事太大。可能捆绑了多个功能。

修复： 使用skills/user-story-splitting/SKILL.md拆分故事。每个当/然后对应应该是自己的故事（或至少评估拆分）。

陷阱5：不可测试的接受标准

症状： “然后用户有更好的体验”或“然后它更快”

后果： QA不能验证成功。模糊的“完成”定义。

修复： 使其可测量：“然后页面在2秒内加载”或“然后用户看到成功确认消息”。

参考

可选助手

skills/user-story/scripts/user-story-template.py — 确定性Markdown存根生成器（无网络访问）

外部框架

Mike Cohn, 用户故事应用 (2004) — “作为/我想要/以便”格式的起源
Gherkin (Cucumber) — “给定/当/然后”接受标准格式
INVEST标准（独立、可协商、有价值、可估计、小、可测试）

Dean’s Work

[如果适用，链接到相关Dean Peters的Substack文章]

来源

改编自prompts/user-story-prompt-template.md在https://github.com/deanpeters/product-manager-prompts仓库。

技能类型： 组件 建议文件名： user-story.md 建议放置位置： /skills/components/ 依赖： 参考skills/proto-persona/SKILL.md, skills/problem-statement/SKILL.md 使用方： skills/user-story-splitting/SKILL.md, skills/epic-hypothesis/SKILL.md

用户故事Skill user-story

目的