user-story-mapping-workshop

user-story-mapping-workshop 技能概览

user-story-mapping-workshop 技能可以帮助产品管理团队把一个模糊的功能想法，整理成一张结构化的用户故事地图：主干活动、用户任务，以及发布切片。它非常适合需要以更适合工作坊的方式对齐流程、发现缺失步骤，并判断哪些内容应该放进首个版本、哪些可以留到后续切片的人。

不同于那种只会泛泛要求“生成用户故事”的通用 prompt，user-story-mapping-workshop 技能是围绕互动式探索来设计的。这一点在你还没有一份清晰 backlog 的时候尤其重要，因为真正要做的，是先把用户旅程暴露出来，再去写单条故事。

这个技能最适合什么场景

当你需要组织或模拟一次 story mapping 会议时使用它，无论是新产品、功能扩展，还是已经变得支离破碎的 backlog。对于产品管理来说，user-story-mapping-workshop 技能尤其适合用来建立对范围、顺序和优先级的共享视图。

它会输出什么

核心输出是一张二维的故事地图：横向按工作流顺序排列活动，纵向按重要性或发布优先级切分。这个技能也支持生成草稿故事和拆分候选项，帮助把 workshop 的结果顺畅衔接到可交付的计划中。

什么时候它最适合你

如果你想回答的是：“用户到底一步一步在做什么，我们应该先交付什么？” 那就选这个技能。它特别适合产品发现、发布规划或 backlog 重组；如果你已经有了最终版规格说明，它的价值就没那么大了。

如何使用 user-story-mapping-workshop 技能

安装并检查源文件

使用以下命令安装 user-story-mapping-workshop 技能：

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

然后先读 skills/user-story-mapping-workshop/SKILL.md，再读 template.md。这两个文件比通读整个仓库更快地展示工作坊流程和输出形态。

提供合适的起始输入

当你提供问题陈述、目标用户或 persona，以及你已经掌握的任何调研记录或 backlog 片段时，这个技能效果最好。对于 user-story-mapping-workshop usage 来说，弱输入是“梳理登录流程”；更强的输入则是“梳理面向 SMB 管理员的首次 onboarding，他们需要创建账户、邀请队友，并在 10 分钟内完成设置”。

使用工作坊式 prompt

一个好的 user-story-mapping-workshop guide prompt 应该要求输出一张地图，而不是一个列表。请包含结果目标、受众、已知约束，以及你希望被拆分成哪些发布切片。

示例：

• “为一个新的团队 onboarding 功能运行一次 user-story-mapping-workshop。请提出自适应问题，搭建主干活动，识别任务，并建议一个 Walking Skeleton 发布切片。”
• “使用 user-story-mapping-workshop 技能，把这些调研笔记转换成一张 story map，并突出缺失步骤、风险和可拆分候选项。”

阅读会影响输出的模板

如果你想要更高质量的结果，请查看 template.md 以及其中引用的相关模板：skills/user-story/template.md、skills/user-story-splitting/template.md 和 skills/user-story-mapping/template.md。这些文件展示了 workshop 输出如何衔接到 stories 和 splitting，这正是很多纯 prompt 方法最容易失败的地方。

user-story-mapping-workshop 技能常见问题

这个技能只适合产品管理吗？

不完全是，但 user-story-mapping-workshop for Product Management 显然是最直接的场景。产品经理、产品负责人、设计师和交付负责人在需要共享的流程视图、而不是功能列表时，都可以用它。

它和普通的 story prompt 有什么不同？

普通 prompt 往往会把 backlog 条目孤立地生成出来。user-story-mapping-workshop 技能则是为了保留顺序、用户意图和发布顺序而设计的，因此更适合规划和引导工作坊。

使用前必须先有完整 backlog 吗？

不需要。实际上，当 backlog 还不完整、很杂乱时，它最有价值。如果你已经有一份打磨成熟的规格说明，这个技能的增益可能不如直接生成故事或做 refinement 明显。

它适合新手吗？

适合，只要你能描述用户、目标和约束就可以。这个技能比听起来更容易上手，因为它会把对话结构化；但如果你能提供哪怕是比较粗略的调研笔记，或者一个清晰的问题陈述，结果通常会好很多。

如何改进 user-story-mapping-workshop 技能

从你真正要做的决策出发

提升质量最大的办法，是先明确 workshop 必须解决什么：范围、发布切片、缺失步骤，还是 backlog 清理。若你只要求“给我一张 story map”，输出可能会很宽泛；如果你要求“生成一张能帮助决定哪些内容能进入 Release 1 的地图”，user-story-mapping-workshop 技能就能更精准地做优先级判断。

提供足够的产品上下文，避免得到泛化地图

高质量输入应包括 persona、触发事件、核心待办任务（job-to-be-done）、约束条件，以及任何已知边界情况。输入太弱时，技能就只能猜，结果往往会变成很显而易见的通用流程，而不是你真正需要的那张具体地图。

注意常见失败模式

最常见的错误，是把输出当成 backlog 倾倒。另一个常见问题，是跳过 release slicing，这会直接抹掉它最重要的规划价值。如果第一轮结果显得比较平，补上缺失的调研笔记、补清 persona，或者把 workflow 边界说得更明确，再重新运行 user-story-mapping-workshop 技能。

从地图迭代到故事

先用第一轮输出找缺口，然后针对风险最高的切片或最不确定的活动，要求更聚焦的一轮结果。通常第二轮迭代带来的提升，远比把第一轮追求到“完美”更有效，尤其是在真实产品规划中的 user-story-mapping-workshop usage 场景里。