user-story

user-story 技能概览

user-story 技能可以把一个粗略的产品需求，转成一条可直接进入开发的 user story，采用 Mike Cohn 的表述方式，并配套 Gherkin 验收标准。它特别适合产品经理、技术写作者、分析师，以及使用 AI 辅助工作流、需要的是清晰交接产物而不是松散想法或完整规格说明的人。

它真正解决的问题是“清晰”：把用户、动作、价值和可测试结果定义到工程和 QA 都能直接使用的格式里。和通用 prompt 相比，user-story 技能提供了可重复的结构和更收敛的范围；当你想减少歧义 story、减少评审轮次时，这一点尤其重要。

最适合产品到工程交接的 user-story

当你已经知道意图，但需要把它表达得简洁、可测试、易估算时，就用这个 user-story 技能。它尤其适合把 PRD 备注、干系人需求和路线图要点，整理成能支持实施的 story。

user-story 的不同之处

它的核心差异在于：把标准 user-story 格式和明确的验收标准组合在一起。也就是说，输出不只是“好读”，还更容易验证、拆分和讨论。相比自由发挥式 prompt，user-story 技能在需要跨多个条目保持 story 质量一致时，更有价值。

什么时候它最合适

user-story 适合功能开发、流程调整、引导步骤，以及其他范围明确、一个用户动作对应一个可衡量结果的场景。它也很适合支持产品文档的 Technical Writing 团队，因为它能让产品意图和成功标准保持一致。

如何使用 user-story 技能

安装 user-story 技能

使用以下命令安装：

npx skills add deanpeters/Product-Manager-Skills --skill user-story

安装完成后，先阅读 skills/user-story/SKILL.md，再查看 template.md 和 examples/sample.md，了解它预期的结构和质量标准。如果你打算自动生成 story，也建议检查 scripts/user-story-template.py，这样就能知道这个技能需要哪些字段。

提供正确的输入

user-story 技能在你提供具体用户、单一目标动作，以及背后的业务或用户价值时，效果最好。高质量输入通常像这样：

• Persona: trial user, support agent, account owner
• Action: reset my password, export invoices, approve a request
• Outcome: so that I can regain access quickly

像“improve onboarding”这类弱输入，通常会产出比较空泛的结果，因为它没有说明是谁、做什么、为什么。

使用与模板匹配的 prompt

想要获得更好的 user-story usage，最好一次只写一条 story，并且把这个技能本来要填写的字段都带上。一个更好的 prompt 是：

“Write a user-story for a trial user who wants to connect their Google account so that they can sign in faster. Include one summary, the use case, and one scenario with one Given/When/Then set.”

这比直接问“写一个关于登录的 user story”更有效，因为它给出了范围和结果，能提升验收标准的质量。

按这个顺序阅读 repo 文件

要做实用的 user-story guide 工作，建议按顺序查看：

1. SKILL.md：写作规则和概念框架
2. template.md：精确的 Markdown 结构
3. examples/sample.md：好与坏的 story 质量对比
4. scripts/user-story-template.py：如果你想要可重复生成，就看这个

这个顺序能帮助你在起草自己的 story 之前，先看清格式和约束条件。

user-story 技能常见问题

user-story 只适合产品经理吗？

不是。user-story 技能同样适合技术写作者、分析师、设计师和工程师，只要他们需要一个用于规划或实施的共享产物。任何需要把意图转成可测试 story 的人，都能用它。

user-story 和普通 prompt 有什么区别？

普通 prompt 可能生成一段看起来像 story 的文字，但 user-story 技能会推动你使用一致的结构：summary、persona、action、outcome、scenario 和 acceptance criteria。这种一致性在 story 需要评审、估算或拆分时非常重要。

user-story 对新手友好吗？

友好。只要你能描述用户、目标和期望结果，就可以上手。新手最常见的错误，是先写解决方案，而不是先写用户问题。只要你能回答“谁需要这个，为什么需要”，这个技能就很适合你。

什么时候不该用 user-story？

不要把 user-story 用在宏观战略文档、多步骤 epic、架构决策，或者包含很多相互依赖结果的功能规格里。如果你需要多个行为，那么这条 story 很可能太大了，应该先拆分再进入实施。

如何改进 user-story 技能

提供更好的源材料

质量提升最大的来源，是更清晰的输入。要写清楚准确的 persona、触发条件、期望结果，以及任何会影响 story 的约束，比如平台、角色或权限级别。比如，“billing admin on desktop exports invoice history”就比“user downloads data”好得多。

警惕范围膨胀

user-story 输出里常见的失败模式，是把多个结果硬塞进一条 story。如果你的草稿需要多个 When/Then 路径、多个用户动作，或者混合了不同类型的用户，就应该先拆开。repo 里的模板和示例之所以强调每条 story 只保留一个主要行为，是有原因的。

提升验收标准

如果第一版感觉比较虚，就给 Given 状态补充更具体的上下文，并把 Then 的成功条件写得更明确。好的验收标准描述的是评审者能够观察到什么，而不只是系统“应该支持什么”。这一点在 user-story for Technical Writing 场景里尤其重要，因为含糊会让下游文档更难写。

根据评审意见迭代

先把第一版当作草稿，再通过修正 persona、收紧结果描述、删掉任何属于实现猜测的验收标准来优化。如果评审者问“这是给谁的？”或者“怎么测试？”，就把这些问题带回下一轮 prompt 里，让 user-story skill 产出更可用的修订版。