pm-user-story

用户故事技能

此技能的行为方式（请先阅读）

这是一项生成式技能，而用户故事正是需求悄然变回任务清单的地方。默认做法是把功能重述成一个故事——“添加登录功能”，或空洞的“作为用户，我想要一个按钮，以便提交”——描述要构建什么，而不是谁需要什么以及为什么需要。真正的用户故事是一个小而可测试、立足于真实角色需求的用户价值单元，它让团队对谁、需要什么、为什么需要达成共识——并且要有克制，知道何时不该写故事，因为它并未补充规格中已有的内容。因此，此技能会把关：

1. 确认这是谁的需求、需求是否真实，以及故事将用于何处——没有真实用户作为依据的故事，只是伪装成事实的假设。
2. 落实始终适用的核心原则——从用户价值出发，保持故事简洁，把细节放到验收标准中，使其符合 INVEST 原则且可测试；将故事映射到整个用户旅程，并删掉没有增加清晰度的故事。
3. 明确视情境而定的决策（严格公式还是自由形式、是否要写故事、验收标准的详细程度、是否拆分为故事地图、沟通框架），并说明其中的权衡。

然后，它会移交给 pm-spec-quality-audit（用于标记任务型故事、不可测试的故事和断裂的可追溯性）和**pm-assumption-rigor-audit**（用户需求有证据支持，还是仅为假设？）。

范围：此技能负责用户故事产物。它将角色构建交由 pm-personas-jtbd，将底层问题的定义交由 pm-problem-statement，将完整规格/PRD 和验收标准的详细程度交由 pm-product-spec（由 pm-spec-quality-audit 审核）。敏捷仪式、待办事项梳理和冲刺机制不在范围内。

---

步骤 0 — 编写故事前先明确背景

如果尚不清楚，请先提问；如果在没有答案的情况下继续，请说明所依据的假设：

• 这是谁的需求，需求是否真实？ 故事应从有研究依据的角色和经过验证的需求出发——“作为 Maria，她没有时间配置设置……”胜过“用户更喜欢自动化”。如果角色或需求只是一个假设，请明确说明；缺乏依据的故事会把这个假设带入待办事项列表。（在 pm-personas-jtbd 中构建角色。）
• 需求有多复杂？ 单一且明确的需求适用于“作为一名[角色]，我想要[操作]，以便[收益]”这一公式；涉及多种用户类型或多层收益的功能，可能需要拆分或采用自由形式。
• 故事是否能补充 PRD/规格中没有的清晰信息？ 如果团队已能从其他地方了解完整背景，那么写故事就只是为了文档而写。只有当故事确实有价值时才写。
• 故事将用于何处？ 待办事项列表、规格，还是即将开始的冲刺——这决定了现在需要附上多少验收标准细节。

---

始终适用的核心原则（适用于任何用户故事）

• 从用户价值出发，而不是从任务出发。“作为一名[角色]，我想要[操作]，以便[收益]”表达的是意图和价值，而非技术待办事项。❌“添加登录功能”/“提升仪表板性能”。✅“作为一名回访用户，我想要快速登录，以便访问已保存的数据。”每个故事都是一个待解决的问题，而不是一个待交付的功能。
• **让每个故事都扎根于真实的角色和需求。**从角色出发，再构建故事；对于复杂或早期阶段的问题，先深入了解用户的挫折和困扰，让故事反映真实障碍，而非主观臆测。基于洞察，而非图方便。
• **把这个句式当作起点，而非规则。**如果一个功能涉及多种用户类型、多个操作或层层递进的收益，一句话就无法涵盖；拆分或采用自由形式都可以，只要谁、做什么、为什么清晰明确。
• **让故事保持为一个小型价值单元；把细节留给验收标准。**故事说明需求；筛选类型、边缘情况和交互规则等具体内容，应放在后续的验收标准和规格说明中。不要把故事扩写成迷你规格说明。
• **确保符合 INVEST 原则且可测试。**独立（Independent）、可协商（Negotiable）、有价值（Valuable）、可估算（Estimable）、小型（Small）、可测试（Testable）。验收标准要明确界定“完成”的标准，让设计、工程和 QA 对成功有共同定义（“用户可以添加、查看和移除已保存的目的地”）。
• **在整个用户旅程中串联故事。**故事地图将四个模块连接起来——问题 → 功能 → 用户故事 → 任务——让每项需求都能追溯到真实的用户需求。按故事组织规格说明，可让工作始终以用户为中心；故事地图本身则是在正式记录之前，帮助各方建立共同理解的工具。
• **发现并修正薄弱的故事。**缺少背景、措辞过于技术化，或没有可衡量的目标，都表明它可能是伪装成故事的任务。回到谁、做什么、为什么，并对照用户角色进行检查，从而修正故事。
• **不要写无法增加清晰度的故事。**并非每个功能都需要故事。如果 PRD/规格说明已经向团队提供了背景，故事只会增加噪声，而非价值——始终要问：“它是否增加了其他地方未体现的清晰度？”
• **清晰地传达故事。**用通俗的产品语言突出用户价值和决策，而不是设计或功能用语（“优先呈现最常用的筛选条件，以减少选择过载”，而不是“我们添加了一个筛选组件”）。提炼成一个明确方向，删去噪声，让利益相关者迅速理解意图。

---

依赖上下文的决策（呈现出来，不要自动应用）

对每项决策，说明权衡，并给出与 Step 0 相关的建议；让用户选择。把每个工单机械地套进“作为一名用户……”模板，就是失败的做法。

决策	适用情况	应避免／调整的情况	默认建议
严格套用公式还是自由表述	对离散、单一用户角色的需求使用公式	将多用户／分层功能强行压缩成一句话	默认使用公式；如果“谁／做什么／为什么”无法用一行表达，就拆分或改用自由表述
是否要写用户故事	当它能补充规格中缺少的共同“谁／做什么／为什么”时	将每个工单都例行写成用户故事	只有在能补充其他地方尚未记录的明确信息时才写
现在需要多详细的验收标准	为当前阶段明确“完成”的定义；进入冲刺／规格时再补充完整的验收标准	在早期梳理阶段就预先撰写穷尽的验收标准，或提交完全没有验收标准的用户故事	添加用于定义完成状态的验收标准；可测试性深度和结构留给 pm-product-spec／spec-quality 处理
写单个用户故事还是拆分成映射	用户故事涵盖多个操作／用户角色，或过大而无法在一个冲刺内完成时拆分（INVEST：小）	把一个巨型 Epic 当作用户故事，或过度拆分成技术任务故事	按用户价值拆分；建立问题 → 功能 → 用户故事 → 任务的映射
沟通表述方式	向利益相关者介绍时，先说明决策和用户价值	使用设计语言或功能清单来表述，把决策埋在其中	先说明用户价值，按便于浏览的方式组织内容，并删去无关信息

---

验证结果（编排）

交接时使用各审查视角对应的可安装技能 name。只有在该技能已安装时才调用；如果未安装，此技能自身的核心内容已涵盖这些规则，直接继续即可，不要因此阻塞。

完成撰写或修订后，应交由审查视角检查，而不是直接宣布完成。这些是候选审查视角——请遵循 docs/orchestration-policy.md 中的处理方式，或将整个产物交由 pm-product-review 审查。这里的 assumption-rigor 是始终相关的审查视角（自动运行）；其他审查视角则是可选的，应根据产物的实际内容决定是否采用。如果用户调用此技能是为了处理某个特定事项，请尊重这一范围。

• pm-assumption-rigor-audit （自动运行）——每个用户故事所依据的用户角色和需求是否有证据支撑，还是基于假设？标记建立在未经验证的用户身份或需求判断上的用户故事。
• pm-spec-quality-audit （可选——如果编写的用户故事会用于制定规格）——这里的核心规格检查：标记任务故事（将功能改写成用户故事，却没有用户价值）、缺少验收标准且无法测试的用户故事，以及需求与用户需求之间断裂的可追溯性。它还负责检查验收标准的深度，以及用户故事留待后续处理的完整流程覆盖情况。

组合关系（依据 docs/orchestration-policy.md §9）：用户故事由上游工作提供输入，而不是对其进行审查——用户角色（pm-personas-jtbd）和问题（pm-problem-statement）是上游输入。如果审查发现某个用户故事实际上是任务，或依据的是假定的用户，应回归其目的进行修正：**用户故事的存在，是为了确保团队为真实的人解决真实的需求——如果没有说明谁会受益以及原因，那它就是披着用户故事外衣的任务。**对于从创意到计划的完整构建，pm-idea-to-plan 是组合流程的入口，会按顺序串联这一步骤和后续流程，并确保在制定规格前提供证据。

常见的正确与错误做法

❌ 不要	✅ 应该
“添加登录功能”／“提升仪表板性能”	“作为一名回访用户，我希望快速登录，以便访问已保存的数据”
“作为一名用户，我希望有一个按钮，这样我就可以提交”	明确真实的用户角色、实际行动，以及背后的价值
臆造用户故事所服务的用户	以基于研究的用户角色和经过验证的需求为依据
强行把每项功能都写成一句“作为一名……”	将此公式作为默认写法；遇到复杂需求时，可拆分或采用自由形式
在用户故事中塞入筛选器类型和边缘情况	保持用户故事简洁；将具体内容放入验收标准
让用户故事无法测试	遵循 INVEST 原则；验收标准明确设计、工程和 QA 的“完成”定义
只列出互不相关的用户故事的待办列表	按照“问题 → 功能 → 用户故事 → 任务”进行映射，让每项内容都能追溯到需求
习惯性地为每个工单编写用户故事	如果规格说明已提供完整背景，则跳过用户故事
使用设计／功能语言描述解决方案	以用户价值和决策为主线，采用通俗的产品语言
未经检查就交付用户故事	按照规格质量和假设严谨性要求移交

---

来源课程（Uxcel）

• 了解用户并构建用户故事
• 清晰地传达解决方案