pm-product-spec

产品需求文档 / PRD 撰写技能

此技能的工作方式（请先阅读）

Claude 默认就能按要求生成一份看似合理的 PRD——问题恰恰在于此。默认行为往往会：在问题尚未明确时就编造需求，写出含糊的目标（“快速”“易于使用”），忽略依赖关系和假设，并把用户故事写成工程任务。文档看起来很完整，但建立在未经验证的问题和无法测试的需求之上，这比没有文档更糟，因为团队会据此开展工作。

因此，此技能会生成内容，但设有门槛，并会强制确保质量，而不只是填充模板：

1. 先把关问题。 在问题陈述清晰且有事实依据之前，不要起草需求。如果用户尚未提供问题陈述，就和他们一起梳理——或指出该规格说明建立在未经验证的假设之上。
2. 撰写正确的文档。 PRD 和规格说明是面向不同受众、适用于不同阶段的不同文档——请审慎选择（见下文）。
3. 确保可衡量。 每项需求都必须可测试；每个用户故事都必须体现价值；每项假设都必须标记为风险。
4. 交付前自查（内置审查环节——见最后一节）。

---

步骤 0 — PRD 还是规格说明？写对文档。

这是两种不同的文档；写错文档（或将两者混为一谈）是常见问题。

	PRD（产品需求文档）	产品规格说明
回答的问题	产品应该做什么，以及为什么	产品将如何设计和构建
受众	广泛——产品经理、高管、营销人员、利益相关者	技术人员——工程师、设计师、QA
适用阶段	早期，发现 / 规划期间	需求达成一致后
灵活性	随着洞察不断出现而调整	开发开始后保持稳定；更改会导致返工
包含内容	愿景、目标、用户画像、用户故事、成功指标	组件、行为、性能目标、依赖关系

经验法则：需求确定优先级（做什么 / 为什么）；规格说明定义依赖关系和行为（如何做）。如果用户仍在决定要构建什么，他们需要 PRD。如果要构建什么已经确定，且需要构建蓝图，他们需要规格说明。撰写前先确认需要哪一种。

---

问题关卡（编写任何需求前都要完成）

无论文笔多好，建立在问题界定不清之上的规格说明都会失败。完整的问题陈述包含三个部分：

• 问题 — 当前状态与期望状态之间的差距（事实，而非假设）。
• 后果 — 对用户或业务造成的负面结果。
• 目标 — 希望实现的改进，而非解决方案。

继续之前，请确保满足以下条件：

• 追溯原因，而非症状。 “留存率低”是症状；“新手引导没有传达核心价值”才是原因。继续追查症状背后的问题。
• 具体，而非宽泛。 “改善用户体验”不是问题——它会产生无穷无尽的任务清单。请缩小范围。
• 依据事实，而非假设。 “流程效率低” / “用户不满意”掩盖了真正原因和可衡量的影响。尽可能结合证据（反馈、数据）。
• 清晰度测试。 设计、工程或领导团队中的成员能否在不需要额外说明的情况下，理解问题是什么、影响哪些人以及它为何重要？如果不能，就继续完善。

如果用户无法提供证据，可以继续，但要明确标记该问题为未经验证、需要测试的假设——不要掩盖这一点。

---

规范 / PRD 结构

按照以下结构编写（根据步骤 0 中的文档类型进行调整）。每个部分都应追溯到问题陈述。

1. 摘要 — 说明它是什么、为何现在需要它、服务于哪些人。
2. 问题陈述 — 来自上面的准入条件。
3. 范围 — 包含与不包含的内容。 明确说明哪些内容不在范围内，而不只是列出包含的内容。未说明的范围往往藏着认知偏差。
4. 角色与用户故事 — 谁需要什么（格式见下文）。
5. 需求 — 产品必须实现什么，每项都应可测试（规则见下文）。
6. 验收标准 — 每项需求的“完成”应是什么样。
7. 依赖项、约束与假设（DCA） — 哪些因素可能导致交付受阻（见下文）。
8. 成功指标 — 以明确、具体的方式衡量结果。

---

需求质量 — 确保每项需求都可测试

将主观描述改为可衡量的目标。这是该技能能带来的最大价值。

• ❌ “应用应快速加载。” → ✅ “在标准移动网络下，仪表板应在 2 秒内加载完成。”
• ❌ “让结账流程更易用。” → ✅ “回访用户无需重新输入已保存的信息，即可在 ≤ 3 步内完成结账。”
• 描述完整的工作流，而不是孤立的功能。
• 如果 QA（或任何人）无需询问你的意图，就能据此编写通过 / 失败检查，那么这项需求就是可测试的。

---

用户故事 — 表达价值，而非任务

使用以下公式：“作为一名[角色]，我想要[执行操作]，以便[获得收益]。” 将每个故事关联到真实角色（结合研究得出的目标与挫折），让待办事项始终围绕真实需求展开。

遵循 INVEST 原则 — 独立、可协商、有价值、可估算、足够小、可测试。

标记薄弱的故事 — 这类描述的是任务，而非用户价值，应当重写：

• ❌ “添加登录功能” / “提升仪表板性能”（只有任务，没有说明对象和原因）
• ✅ “作为一名回访用户，我想快速登录，以便访问已保存的数据。”

---

依赖项、约束与假设（DCA）

这是默认情况下最常被遗漏的部分，也是交付真正容易出问题的地方。

• 依赖项 — 一个步骤为下一步提供前提。区分内部依赖项（团队内部，可通过规划管理）和外部依赖项（法律审批、第三方供应商、其他团队，风险更高）。梳理依赖链，明确单项延迟会带来的后续影响。
• 约束 — 各类边界：预算、截止日期、遗留技术、法律 / 合规要求。尽早说明，避免制定不切实际的计划。
• 假设 — 团队认为属实但尚未确认的事项。将每项假设都转化为由负责人落实的可衡量检查。未验证的假设若一直搁置，就会成为隐藏风险；应将其揭示出来并视为风险。

审查现有规范时应指出的早期预警信号：关键依赖项的负责人不明确、各团队的时间表不一致、假设经过多个冲刺周期后仍未验证。

交付前自审（内置审查环节）

在提交文档前，请先自行进行以下质量检查——这正是这项技能与套用模板的区别所在：

• 每项要求都可衡量／可测试（没有未定义的“快速”“直观”“用户友好”等表述）。
• 每条用户故事都体现了价值（包含谁 + 为什么），符合 INVEST 原则，且不是伪装成用户故事的任务。
• 范围明确列出哪些内容不在范围内，而不只是列出范围内的内容。
• 每项要求都能追溯到问题陈述。
• 假设已标记为风险，并说明如何测试；依赖项注明是内部还是外部。
• 成功标准以具体、可衡量的方式定义。

然后将文档交给审查视角进行审查。这些是候选视角——按 docs/orchestration-policy.md 中的方针决定采用方式，或将整个产物交由 pm-product-review 审查。此处，assumption-rigor 始终适用（自动运行）；其他视角则根据产物的实际内容提供选择。如果用户调用这项技能是为了处理某个特定事项，请遵守该范围。

在完整的从构想到计划的构建流程中，这份规格说明是 pm-idea-to-plan 的最后一阶——它应在问题界定、发现证据和最具风险的假设经过测试后再交付，并与这些基础相称。在走完前述各阶之前就产出规格说明，只会得到一份精美的 PRD，却押注于未经验证的假设；这正是那个入口流程旨在避免的问题。

交接时，请使用各视角对应、可安装的技能 name。只有在该技能已安装时才调用；如果未安装，本技能上方的自审清单已涵盖这些规则——继续操作即可，不要因此受阻。

• pm-assumption-rigor-audit（自动运行）——当规格说明基于重要但未经验证的假设时，检查风险最高的假设是否正在接受测试，测试方法的保真度是否合适、成功标准是否预先设定，而不是让假设继续伪装成事实。
• pm-spec-quality-audit（提供选择——适用于编写规格说明的情况）——审查整份文档：每项要求的可测试性、流程是否完整而非仅覆盖理想路径、范围排除项、DCA 的完整性、验证证据、不同层次是否混杂，以及是否适合目标受众。
• pm-okr-metric-validity-audit（提供选择——适用于列出成功指标的情况）——专门审查成功指标：虚荣指标、不可证伪的目标、伪装成结果的产出，以及缺少护栏、容易被操纵的指标。

请报告任何无法满足的内容（例如：“要求 3 的成功指标未定义——需要设定目标”），不要悄悄用听起来合理的文字补上。请注意，规格说明是持续更新的文档：每次冲刺评审和发布后，都应重新验证各项要求。

---

常见的正反做法

❌ 不要	✅ 应该
在问题尚未明确前起草要求	先通过问题陈述（问题 + 后果 + 目标）设定门槛
描述表象（“留存率低”）	明确根本原因
“改善用户体验”	聚焦于具体且有证据支持的问题
“页面应该很快”	“在标准移动网络下，页面应在 2 秒内加载完成”
“添加登录功能”	“作为一名回访用户，我希望快速登录，以便访问已保存的数据”
只列出范围内的内容	也明确说明哪些内容不在范围内
省略依赖项和假设	加入 DCA 部分；将假设转化为有负责人承担的可测试检查
混淆 PRD 与规格说明	根据当前阶段／受众决定需要哪种文档
提交精美却含糊的文档	进行自审；标出未定义的目标，不要凭空编造
把规格说明当作最终定稿	将其视为持续更新的文档——在评审和发布后重新验证

课程来源（Uxcel）

• 了解产品规格说明
• 产品规格说明与产品需求文档
• 为有效的规格说明定义问题
• 依赖项、约束和假设
• 审查和验证规格说明
• 了解用户并撰写用户故事