job-stories

job-stories 技能概览

job-stories 技能可以帮助你把粗略的产品想法转化为 JTBD 风格的 job story，格式是：“当[情境]时，我想要[动机]，这样我就能[结果]。” 当你需要更清晰的待办项、更好的需求规划，或者在进入方案设计前，先用一套共同语言描述用户上下文时，它尤其有用。

job-stories 技能最适合什么场景

当你已经知道功能大方向，但还需要把背后的用户问题打磨得更清楚时，适合使用 job-stories 技能。它很适合产品经理、设计师、分析师，以及需要根据设计链接、功能提示或干系人笔记来起草需求的 AI agent。

它为什么不同于通用提示词

它的核心价值在于结构化：它会推动模型先从情境和动机出发，再补上与可观察结果绑定的验收标准。相比笼统的“写用户故事”提示词，job-stories 在团队更关注上下文、意图和可测试结果时，会更实用。

什么时候它特别合适

这个技能很适合 job-stories for Requirements Planning、前期探索前的 backlog 成形，以及把功能概念翻译成以用户为中心的故事。如果你只需要几句不带验收标准的灵感列表，或者你们团队完全使用另一种需求格式，那它就没那么合适。

如何使用 job-stories 技能

正确安装并触发它

对于 job-stories install，请使用目录默认的技能加载器：npx skills add phuryn/pm-skills --skill job-stories。然后在调用技能时，提供足够的信息，让模型能推断用户情境、产品领域和目标结果。只给一个功能名，通常信息量是不够的。

给它正确的输入形状

这个技能在提示词里同时包含产品、功能、用户上下文和任何设计参考时效果最好。一个好的起始提示会像这样：“基于这些用户情境：[context]，为 [product] 的 [feature] 功能创建 job stories。使用设计链接 [design]，重点写结果，不要写角色。” 这比“为 checkout 写 job stories”要好得多。

先看这些文件

先从 SKILL.md 开始，因为它包含工作流、故事模板和必需参数。如果你的本地副本里还有相邻文档，接着阅读 README.md、AGENTS.md 和 metadata.json，以及任何 rules/、resources/、references/ 或 scripts/ 文件夹。在这个 repo 里，SKILL.md 是主要事实来源，所以需要扫描的额外内容并不多。

能明显提升输出的工作流建议

建议分两轮使用这个技能：第一轮先生成原始 job stories，第二轮再结合真实约束进行润色。如果第一版太空泛，就补充具体情境、决策点和设计链接。如果故事还是偏角色化，就要求改写为以触发条件和期望进展为中心，而不是以 persona 为中心。

job-stories 技能常见问题

job-stories 适合 Requirements Planning 吗？

适合。job-stories 就是为 requirements planning 设计的，尤其适合你想要的是以用户为中心的 backlog 条目，而不是从功能出发的 ticket。它可以把范围转成情境、动机和结果，方便设计和工程一起讨论。

使用它一定要有设计文件吗？

不一定，但提供设计文件时，job-stories 技能会更强。Figma 或 Miro 链接能帮助模型把验收标准锚定到可见行为上，而不是自己猜测。

它和普通 user story 有什么区别？

普通提示词往往会生成以角色开头的模板，或者很浅的验收标准。job-stories 技能更适合那些关键判断在于“用户为什么要这样做”以及“用户需要什么结果”，而不只是系统应该做什么的场景。

这个技能适合新手吗？

适合，只要你能用简单语言描述一个功能。主要限制在于输入质量：新手如果能提供一两个真实的用户情境，而不是宽泛的功能主题，通常会得到更好的结果。

如何改进 job-stories 技能

提供更丰富的情境，不要只给功能名

提升质量最大的办法，是补足具体上下文。不要只写“notifications”，而要写成“当用户在旅行中错过付款提醒时”这样的情境，这样 job-stories 技能才能生成有意义的情境、动机和结果链条。

加上约束和成功信号

如果你在意可访问性、时机、设备限制或审批流程，就要提前写出来。只有当提示词说明什么算成功、什么必须可观察、什么会让故事失败时，验收标准才会更扎实。

按失败模式要求修改

如果第一版太泛，就要求减少角色引用，增加情境细节。如果它太偏方案，就要求改写成避免实现语言的 job story。如果范围太大，就把功能收窄到一次只聚焦一个用户目标。

把第一版当作规划草稿

把第一轮输出当成探索工具，而不是最终需求。最好的 job-stories 用法，是不断迭代，直到这些故事与你的路线图、设计和工程约束对齐，然后删掉任何对 Requirements Planning 或交付没有帮助的内容。