prd-template

name: prd-templatelanguage: zhdescription: "按经过验证的产品经理模板结构撰写产品需求文档（PRD）。当被要求写 PRD、产品规格、功能说明或新功能、新产品的需求文档时使用。产出完整的 PRD：问题陈述、用户故事、功能需求、技术考量和成功指标。"

prd-template 的简体中文翻译，英文版本为规范版本。

PRD 模板

这个技能帮助按行业最佳实践撰写专业的产品需求文档。

它在流程中的位置：主线的中间

产品决策主线的第二步：/assumption-mapper → prd-template → /rice-prioritisation → /roadmap-narrative。它从 /assumption-mapper 接收风险最大的假设（如果那一步运行过，读它的图谱，而不是重新猜风险），并把 PRD 的成功指标交给 /rice-prioritisation：那个有基线的数字会成为 RICE 的 Impact。共享术语（问题陈述、假设、成功指标、来源标注）统一定义在 docs/craft/product-decisions.md；请严格使用。

循环

PRD 由外而内撰写：永远先问题、后方案，分四个阶段。第一阶段是承重墙：建立在模糊问题上的 PRD，从头到尾再精致也是错的。

1. 锁定问题陈述。 一句话：谁、在什么时候、有什么问题，以及放任不管的代价。不出现任何方案用语。下面的一切都必须向它归结。 完成标准： 问题陈述独立成立，没有提到任何功能，陌生人也能看出"解决了"是什么意思。
2. 给成功指标定基线。 证明问题已解决的那一个数字，附当前基线和算作成功的变化幅度。把上游 /assumption-mapper 的风险作为待定问题带到这里，而不是默默押注。 完成标准： 指标有基线（或明确标注为没有基线），并且它衡量的是问题，而不是活动。
3. 起草各部分，每一部分向上追溯。 填写下面的模板，让每条需求和故事都追溯到问题陈述；追溯不到的删掉。给事实标注来源：猜的数字是 [hunch]，要标出来。 完成标准： 每条需求都追溯到问题陈述，每个声称的事实都带有 [data] / [hunch] / [assumption]。
4. 交接。 写明成功指标和计划项，让 /rice-prioritisation 能用这个指标给 Impact 打分，而不是重新发明一个。 完成标准： PRD 写明了 /rice-prioritisation 打分所需的指标和范围，无需再问。

所需输入

如未提供，请向用户询问：

• 功能或产品名称
• 要解决的问题（从用户的角度）
• 目标用户（角色、场景、想完成什么）
• 成功指标（你怎么知道它奏效了？）
• 范围（MVP 还是完整愿景：什么在范围内，什么不在）
• 关键干系人（谁需要审阅和批准）

从大脑读取 / 写入大脑

如果存在 professional-brain（brain/），用它，而不是询问你已经有的背景：

• 先读： context.md（产品、指标定义、语气）、knowledge/strategy.md（产品方向）、相关的 hypotheses/ 和对应的 entities/ 功能文件。运行 python3 ../professional-brain/scripts/brain_query.py ./brain "<feature>" 获取有依据的事实，并把它们的来源标注带进 PRD（不要把 [hunch] 当作确定的需求）。
• 之后写： 把功能保存为或写入 entities/<feature>.md，把范围决策记入 decisions/，把新的假设加入 hypotheses/。每条都标注来源。

延伸材料

这个技能附带两份支持文件，可用时请使用：

• templates/prd-skeleton.md：可填写的 PRD 骨架，每个部分都有"好的样子"提示。当用户想自己完成文档而不是生成草稿时，从它开始。
• references/success-metrics-guide.md：成功指标部分的校准：四项指标测试、标准的采用 / 结果 / 业务 / 护栏指标组合，以及常见陷阱。撰写或审阅指标表时参考。

模板结构

每份 PRD 都应按顺序包含以下部分：

1. 概述

• 问题陈述：我们在解决什么问题？（2 到 3 句）
• 方案概要：我们要做什么的高层描述（2 到 3 句）
• 成功指标：如何衡量成功（3 到 5 个关键指标）

2. 背景

• 为什么是现在：为什么现在是合适的时机？
• 战略对齐：它如何与公司目标对齐？
• 用户研究摘要：研究的关键洞察（如适用）

3. 用户故事与使用场景

格式："作为 [用户类型]，我想要 [行动]，以便 [好处]"

• 包含 3 到 7 个主要用户故事
• 每个故事都加上验收标准

4. 需求

功能需求：

• 必须有（P0）
• 应该有（P1）
• 最好有（P2）

非功能需求：

• 性能预期
• 安全考量
• 无障碍要求

5. 设计与用户体验

• 设计稿或线框图链接
• 关键用户流程
• 边界情况和错误状态

6. 技术考量

• 架构影响
• 对其他系统的依赖
• 技术风险及应对

7. 实施计划

• 第一阶段（MVP）：第一版包含什么
• 第二阶段：接下来做什么
• 第三阶段：未来的增强

8. 待定问题

• 仍需做出的决定
• 需要咨询的干系人
• 需要的研究

9. 附录

• 研究链接
• 相关文档
• 竞品分析

写作指南

语气：清晰、简洁、可执行 读者：工程师、设计师、干系人 长度：功能 3 到 6 页，产品 8 到 12 页

最佳实践：

• 用具体例子，而不是抽象描述
• 写"为什么"，而不只是"是什么"
• 让需求可测试
• 链接到支持材料
• 随决策更新

好 PRD 的标准

✅ 要：

• 从用户的角度写
• 包含具体的成功指标
• 处理边界情况
• 链接到研究和数据
• 明确写出取舍

❌ 不要：

• 写实现细节（那是技术规格）
• 假设每个人都有背景
• 让需求含糊不清
• 跳过"为什么"
• 忘记无障碍

评分量表（0 到 40）

交付前给这个技能的任何产出打分；32 分以上才算可以交付。

质量检查

• 问题陈述从用户的角度写（而不是公司的）
• 成功指标具体、可衡量
• 用户故事包含验收标准
• 需求可测试（不含糊）
• 明确列出待定问题
• 实施计划区分了 MVP 和后续阶段

反模式

• 不要从公司的角度写需求：每条需求都必须追溯到用户需要
• 不要写"系统应该很快"这样含糊的需求：每条需求都必须可测试
• 不要把 MVP 和后续阶段混为一谈：明确第一版包含什么、不包含什么
• 不要让成功指标只是没有基线的百分比：写明当前状态和目标
• 不要跳过待定问题：未解决的假设就是风险；把它们摆出来是产品经理的工作

PRD 开头示例

# PRD：多渠道客服工作台

## 概述

**问题陈述**：客服团队目前用三个独立的工具处理来自邮件、在线聊天和社交媒体的客户咨询，导致回复延迟、重复劳动和客户体验不一致。平均每位客服每天要浪费 2.3 小时在工具之间切换、手动追踪对话记录。

**方案概要**：建设一个统一工作台，把所有渠道的客户咨询汇集到同一个界面，跨渠道保留对话记录，并根据客服的专长和空闲情况智能分配。

**成功指标**：
- 平均响应时间从 4 小时降到 1 小时
- 工具切换时间减少 80%（从 2.3 小时降到 0.5 小时以内）
- 客户满意度从 3.8 提升到 4.5（满分 5 分）
- 客服人效提升 35%

## 背景

**为什么是现在**：过去 6 个月客户满意度下降了 15%，主要原因是响应慢。我们最大的竞争对手上季度推出了统一客服工作台，销售通话中已经频繁听到。客服团队年流失率达 45%，"工具太复杂"是最常被提到的不满之一。

**战略对齐**：这与公司第一季度"客户留存提升 10%"的目标，以及客服团队"平均处理时长降低 25%"的 OKR 对齐。

**用户研究摘要**：我们访谈了 12 位客服，观察了 20 小时的客服工作。关键发现：
- 客服 35% 的时间花在查找以往互动的背景上
- 65% 的升级是因为缺少对话记录
- 客服把工具切换评为每天最大的不满（痛点 9.2 / 10）
- 当前客服体验的 NPS 为 -12

## 用户故事与使用场景

**US1：统一收件箱**
作为客服，我想在一个地方看到所有客户咨询，以便不错过紧急请求，并能有效排出优先级。

验收标准：
- 收件箱显示来自邮件、聊天和社交媒体的咨询
- 咨询按优先级排序（紧急、高、普通、低）
- 客服可以按渠道、客户或状态筛选
- 新咨询到达时实时更新

**US2：跨渠道背景**
作为客服，我想看到完整的对话记录，无论来自哪个渠道，以便给出一致、有依据的回复，而不必让客户重复说明。

验收标准：
- 时间线视图按时间顺序显示所有互动
- 每次互动显示渠道、时间和内容
- 客户档案显示基本信息和账户信息
- 可以查看以往的问题和解决方案

[继续写满 5 到 7 个用户故事……]

示例触发语

• “写一份 PRD。”
• “给这个功能写产品需求文档。”
• “写功能规格说明。”
• “给新功能写需求文档。”