prd-template

PRD 模板技能

此技能可帮助按照行业最佳实践编写专业的产品需求文档。

在流程中的位置——决策链的中段

这是产品决策链的第二步：/assumption-mapper → prd-template → /rice-prioritisation → /roadmap-narrative。它接收 /assumption-mapper 提供的风险最高的假设（如果运行过 /assumption-mapper，请读取其映射结果，而不要重新猜测风险），并将 PRD 的成功指标交给 /rice-prioritisation——这个设定了基线的数字将成为 RICE 的 Impact。共享术语（问题陈述、假设、成功指标、来源）统一定义在 docs/craft/product-decisions.md 中；请严格使用其中的定义。

流程

PRD 应从外向内撰写——始终先写问题，再写解决方案——共分为四个阶段。阶段 1 是基础：如果 PRD 建立在模糊的问题之上，那么即使全文打磨得再精致，最终仍然是错的。

1. 确定问题陈述。 用一句话说明谁在何时遇到了什么问题，以及不解决该问题会付出什么代价。不要提解决方案。以下所有内容都必须与此对应。 完成标准： 问题陈述独立成立，不含任何功能名称，且陌生人也能说清楚“解决”意味着什么。
2. 设定成功指标基线。 用一个数字证明问题已得到解决——包含其当前基线以及达到什么变化才算成功。如果上游的 /assumption-mapper 有风险项，请在此将其列为待解决问题，而不是默默押注。 完成标准： 指标有基线（或明确标注为尚未设定基线），且衡量的是问题本身，而不是活动量。
3. 起草各章节，并逐一追溯到上游。 填写下方模板，确保每项需求和用户故事都能追溯到问题陈述；删除无法追溯的内容。为事实标注来源——猜测的数字应标为 [hunch]。 完成标准： 每项需求都能追溯到问题陈述，且每项事实声明都带有 [data]/[hunch]/[assumption] 标签。
4. 交接。 明确列出成功指标和相关计划，以便 /rice-prioritisation 能根据此处的指标评估 Impact，而不是重新编造一个指标。 完成标准： PRD 明确写出指标和范围，且 /rice-prioritisation 无需再次询问即可进行评估。

必需输入

根据已提供的信息开展工作。如果缺少以下任一项，仍需产出完整内容：用合理的假设填补每处空缺，并标注 (假设，需确认)，最后列出这些假设。只有在核心主题本身缺失（无内容可写）时，才先提问。

• 功能或产品名称
• 要解决的问题（从用户的角度描述）
• 目标用户（角色、情境、想要完成的任务）
• 成功指标（如何判断是否奏效？）
• 范围（MVP 与完整愿景——包含和不包含哪些内容）
• 关键利益相关者（需要审核和批准的人员）

从 Brain 读取 / 写入 Brain

如果存在 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. 实施计划

• 阶段 1（MVP）：首个版本包含的内容
• 阶段 2：接下来的内容
• 阶段 3：未来的增强功能

8. 未决问题

• 仍需做出的决定
• 需要咨询的利益相关者
• 所需研究

9. 附录

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

每次输出都以简短的假设与缺口部分结尾：列出两到四条要点，说明因输入未提及而做出的假设，以及最可能显著影响输出的缺失信息。如果没有任何假设或缺失信息，请用一句话说明。

写作指南

语气：清晰、简洁、可执行
读者：工程师、设计师、利益相关者
篇幅：功能类文档力求 3-6 页，产品类文档力求 8-12 页

最佳实践：

• 使用具体示例，而非抽象描述
• 不仅说明“是什么”，也要说明“为什么”
• 确保需求可测试
• 链接至支持材料
• 随着决策的做出及时更新

优秀 PRD 的特点

✅ 应该：

• 从用户视角撰写
• 包含具体的成功指标
• 考虑边缘情况
• 链接至研究与数据
• 明确说明权衡取舍

❌ 不应该：

• 撰写实现细节（那属于技术规格）
• 假设所有人都了解背景
• 让需求含糊不清
• 忽略“为什么”
• 忘记无障碍要求

评分标准（0–40）

交付前，请先为此技能的任何输出评分；32 分及以上即可交付。

维度	0	5	10
问题依据	从公司视角陈述问题，或在没有证据的情况下断言问题	从用户视角描述问题，但支持数据模糊（“用户感到沮丧”），且未引用研究	问题属于用户，使用当前状况数据量化，并通过“为什么是现在”解释变化；所有主张均可追溯至所引用的研究
需求可测试性	需求是模糊的品质描述（“快”“直观”），审核者无法验证	大多数需求具体，但验收标准不充分，非功能性需求则是套话	每个 P0/P1/P2 项和 NFR 均可验证（阈值、百分位数、标准），且均可追溯至用户故事或研究发现
指标严谨性	缺少成功指标，或仅有百分比而没有基线	已提供基线和目标，但指标只衡量采用情况——无法发现功能成功而业务受损的情况	每项指标都有“基线 → 目标”，指标组合既涵盖结果，也涵盖采用情况，并至少有一项护栏，防止为了达成指标而损害用户
范围与风险诚实度	MVP 与后续阶段混为一谈；未列出待解决问题	已区分阶段，但没有说明划分边界的原因，且掩盖了分歧	每个阶段边界都有明确原因；范围外的需求已记录并注明重新纳入的条件；待解决问题均列有负责人、截止日期及每种答案的成本

质量检查

• 问题陈述从用户视角出发（而非公司视角）
• 成功指标具体且可衡量
• 用户故事包含验收标准
• 需求可测试（不模糊）
• 明确列出待解决的问题
• 实施计划区分 MVP 与后续阶段

反模式

• 不要从公司视角撰写需求——每项需求都必须追溯到用户需求
• 不要加入“系统应该很快”这类模糊需求——每项需求都必须可测试
• 不要混淆 MVP 与后续阶段——明确说明首个版本的范围内和范围外内容
• 不要只用百分比表示成功指标而不提供基线——说明当前状态和目标
• 不要跳过待解决的问题——尚未解决的假设都是风险；揭示这些风险是 PM 的职责

PRD 开篇示例

# PRD: Multi-Channel Customer Support Dashboard

## Overview

**Problem Statement**: Support teams are currently managing customer inquiries across email, chat, and social media using three separate tools, leading to delayed responses, duplicated work, and inconsistent customer experiences. On average, support agents waste 2.3 hours per day switching between tools and manually tracking conversation history.

**Proposed Solution**: Build a unified dashboard that aggregates customer inquiries from all channels into a single interface, maintains conversation history across channels, and provides intelligent routing based on agent expertise and availability.

**Success Metrics**:
- Reduce average response time from 4 hours to 1 hour
- Decrease tool-switching time by 80% (from 2.3 to <0.5 hours)
- Improve customer satisfaction score from 3.8 to 4.5 (out of 5)
- Increase support agent productivity by 35%

## Context & Background

**Why Now**: Customer satisfaction has declined 15% over the past 6 months, primarily due to slow response times. Our top competitor launched a unified support dashboard last quarter, and we're hearing about it in sales calls. Support team turnover is at 45% annually, with "tool complexity" cited as a top frustration.

**Strategic Alignment**: This aligns with our Q1 company objective to "Improve customer retention by 10%" and our support team's OKR to "Reduce average handle time by 25%."

**User Research Summary**: We conducted interviews with 12 support agents and observed 20 hours of support sessions. Key findings:
- Agents spend 35% of their time finding context from previous interactions
- 65% of escalations are due to lack of conversation history
- Agents rated tool-switching as their #1 daily frustration (9.2/10 pain)
- Current NPS for support experience is -12

## User Stories & Use Cases

**US1: Unified Inbox**
As a support agent, I want to see all customer inquiries in one place so that I don't miss urgent requests and can prioritize effectively.

Acceptance Criteria:
- Inbox shows inquiries from email, chat, and social media
- Inquiries are sorted by priority (urgent, high, normal, low)
- Agent can filter by channel, customer, or status
- Real-time updates when new inquiries arrive

**US2: Cross-Channel Context**
As a support agent, I want to see the full conversation history regardless of channel so that I can provide consistent, informed responses without asking customers to repeat themselves.

Acceptance Criteria:
- Timeline view shows all interactions chronologically
- Each interaction displays channel, timestamp, and content
- Customer profile shows demographics and account information
- Previous issues and resolutions are accessible

[Continue with 5-7 total user stories...]

示例触发语

• “撰写 PRD。”
• “为此功能撰写产品规格说明。”
• “撰写功能规格说明。”
• “为新功能撰写需求文档。”