PRD生成

PRD生成

根据功能需求描述，生成可直接交付评审的产品需求文档（PRD）。内置产品类型分支（B2C/B2B/内部工具/平台型），不同类型侧重不同模块。包含PRD质量自检清单，确保文档完整度。

工作方式

独立能力（无需连接器）

• 按产品类型生成差异化PRD
• 完整功能设计 + 验收标准 + 数据埋点
• PRD质量自检清单（10项逐项校验）

增强能力（连接器加持）

• ~~Notion → 直接写入团队知识库，搜索历史PRD作为参考
• ~~设计工具（Figma） → 引用设计稿链接，嵌入设计规范参考

连接器（可选增强）

没有连接器也完全可以使用。

输入要求

用户需提供以下信息（缺失项主动追问）：

信息完整度判断：若用户仅说"写个PRD"未给需求，进入引导模式追问功能描述；若提供了功能描述+目标用户+业务目标，进入快速模式直接生成。

执行流程

第一步：需求解析与产品类型分支

解析用户输入，确定产品类型。不同类型的PRD侧重点差异显著：

类型自动推断规则：含"用户/会员/积分/商城"→B2C；含"企业/SaaS/CRM/后台管理"→B2B；含"内部/管理系统/工单"→内部工具；含"平台/市场/撮合/双边"→平台型。

B2B产品必须额外覆盖：

• 权限矩阵（角色 x 功能 x 数据范围）
• 多租户数据隔离方案描述
• 与客户现有系统的集成接口清单

平台型产品必须额外覆盖：

• 各角色（供方/需方/平台运营）独立功能视角
• 供需匹配规则和排序策略
• 平台佣金/抽成/结算规则

第二步：结构化需求拆解

如果连接了~~Notion：

1. 搜索团队知识库中已有的相关PRD作为参考
2. 获取团队的PRD模板规范（如有）

如果未连接：

1. 使用内置标准模板结构

功能拆解三步法：

1. 用户旅程法：画出用户从入口到完成目标的完整路径，每个节点即一个功能点
2. 角色拆分法：列出所有涉及的角色（终端用户、管理员、运营等），每个角色的操作即一个功能模块
3. CRUD法：对核心数据对象，梳理创建/读取/更新/删除四类操作

对每个功能模块，填充以下字段：

• 功能描述（一句话说做什么）
• 用户故事（作为[角色]，我希望[操作]，以便[价值]）
• 业务规则（穷举所有规则，不留模糊地带）
• 交互说明（操作入口 → 操作步骤 → 成功/失败反馈）
• 异常处理（网络超时、数据异常、权限不足等边界情况）

第三步：生成完整PRD

按以下模板输出。每个占位符旁标注了填充逻辑：

输出格式

# PRD：{功能名称}

**版本**：v1.0
**作者**：{产品经理名，用户未提供则写"[待填写]"}
**日期**：{当前日期}
**状态**：草稿

---

## 1. 背景与目标

### 1.1 背景
<!-- 填充逻辑：回答三个问题——为什么现在做？不做会怎样？做了能怎样？ -->
{问题现状 + 用户痛点 + 为什么现在是做的时机}

### 1.2 目标用户
<!-- 填充逻辑：用"[角色]+[特征]+[场景]"的格式，不泛泛说"所有用户" -->
| 用户角色 | 特征描述 | 核心诉求 | 使用场景 |
|---------|---------|---------|---------|

### 1.3 业务目标与成功指标
<!-- 填充逻辑：每个目标必须SMART化——有具体数字和截止时间 -->
| 目标 | 衡量指标 | 目标值 | 监测方式 |
|------|---------|--------|---------|

## 2. 需求概述
<!-- 填充逻辑：一段话概括核心需求，30字以内 -->

## 3. 功能详细设计

### 3.1 {功能模块1}
**功能描述**：{做什么}
**用户故事**：作为{角色}，我希望{操作}，以便{价值}
**优先级**：P0/P1/P2（P0=必须上线，P1=强烈建议，P2=锦上添花）

**业务规则**：
1. {规则1——写清楚触发条件和处理逻辑}
2. {规则2}

**交互流程**：
<!-- 填充逻辑：从入口开始，写到任务完成，覆盖正常流程+异常分支 -->
1. 用户从{入口}进入
2. {操作步骤}
3. 成功：{反馈}
4. 失败：{错误提示和处理方式}

**异常处理**：
| 异常场景 | 处理方式 | 用户提示 |
|---------|---------|---------|

（后续模块同上格式）

## 4. 非功能需求
<!-- 填充逻辑：B2C 侧重性能和体验，B2B 侧重安全和可用性 -->
| 类别 | 要求 | 验收标准 |
|------|------|---------|
| 性能 | {如：页面加载时间} | {如：<2秒} |
| 安全 | {如：数据加密} | {如：传输层TLS 1.2+} |
| 兼容性 | {如：浏览器/设备} | {如：Chrome/Safari/微信浏览器} |

## 5. 数据需求
<!-- 填充逻辑：列出所有需要采集的数据事件，用事件名+触发条件+属性格式 -->
| 事件名 | 触发条件 | 关键属性 | 用途 |
|--------|---------|---------|------|

## 6. 验收标准
<!-- 填充逻辑：每个功能模块至少3条AC，用Given-When-Then格式 -->
| 编号 | 场景 | Given（前提） | When（操作） | Then（预期结果） |
|------|------|-------------|-------------|-----------------|

## 7. 排期建议
<!-- 填充逻辑：拆到开发/测试/联调/上线四个阶段 -->
| 阶段 | 预估工时 | 依赖 | 风险点 |
|------|---------|------|--------|

## 8. 风险与依赖
| 风险 | 概率 | 影响 | 缓解措施 |
|------|------|------|---------|

## 附录
- 相关文档链接
- 竞品参考
- 设计稿地址

第四步：PRD质量自检

生成后按以下清单逐项检查：

不通过的项标注并提示修改建议。

PRD常见反模式（自检防护）

红线规则

1. PRD不写技术实现：不指定数据库类型、编程语言、框架选型
2. 不替代设计稿：不详细描述UI布局、配色、字号，只描述交互逻辑和信息层级
3. 不编造数据：用户未提供的业务数据（日活、转化率等）标注"[待补充]"
4. 不遗漏角色：涉及多角色的功能，每个角色的视角都要覆盖

输入不足处理

• 仅说"写个PRD"：追问功能描述，给出示例引导
• 只有一句话需求（如"做个商城"）：生成概要版PRD框架，标注需要补充的关键信息
• 需求过于庞大：建议拆分为多个PRD，先确定MVP范围

相关技能

• /用户故事拆解：PRD评审通过后，将功能拆解为开发可执行的User Story
• /竞品分析：PRD撰写前，先做竞品分析获取功能参考
• /需求优先级排序：多个需求并行时，用RICE排序确定优先级