PRD生成

---
name: PRD生成
description: >
  输入功能需求描述，生成结构化PRD文档，含背景分析、目标定义、功能清单、交互说明、数据埋点和验收标准。
  按产品类型（B2C/B2B/内部工具/平台型）走差异化模板。连接~~Notion后可直接写入团队知识库。
  当用户说"写PRD"、"需求文档"、"产品需求"、"功能文档"、"PRD模板"、"撰写需求说明书"、"feature spec"、
  "产品需求文档"、"功能规格"、"需求规格说明"、"写需求"、"出需求文档"时触发。
argument-hint: "输入功能需求描述，如：做一个会员积分商城，用户可用积分兑换商品"
name_en: "prd-generation"
description_en: >
  Enter a feature description and generate a structured PRD complete with background analysis, goal
  definition, feature inventory, interaction specs, analytics events, and acceptance criteria. Uses
  differentiated templates based on product type (B2C / B2B / internal tool / platform). When
  connected to ~~Notion the PRD is written directly into the team wiki. Trigger when the user says
  "write a PRD", "product requirements", "feature spec", "PRD template", "requirement document",
  "product requirement document", "feature specification", "draft a PRD", "create a PRD", "generate
  requirements".
---

# PRD生成

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

## 工作方式

**独立能力（无需连接器）**

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

**增强能力（连接器加持）**

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

## 连接器（可选增强）

| 连接器 | 增强能力 |
|--------|---------|
| **Notion** | PRD写入 Notion 页面，搜索已有PRD作为参考 |
| **Figma** | 引用设计稿链接和组件规范，增强交互说明部分 |

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

## 输入要求

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

| 字段 | 必填 | 说明 |
|------|------|------|
| 功能描述 | 是 | 要做什么功能、解决什么问题，至少一句话 |
| 目标用户 | 否 | 面向谁，未提供则根据功能推断 |
| 业务目标 | 否 | 期望达成的业务指标（DAU、转化率、营收等） |
| 产品类型 | 否 | B2C/B2B/内部工具/平台型，未指定则自动推断 |
| 约束条件 | 否 | 技术限制、时间要求、资源限制 |
| PRD深度 | 否 | 概要版（评审用）/ 详细版（开发用），默认详细版 |

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

## 执行流程

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

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

| 产品类型 | PRD侧重模块 | 关键差异 |
|----------|-----------|---------|
| **B2C** | 用户体验流程、增长指标、A/B测试方案 | 重交互、重数据、多写用户旅程 |
| **B2B** | 权限模型、多租户、SLA、集成接口 | 重功能完备性、重安全合规、多写API对接 |
| **内部工具** | 操作效率、与现有系统集成、培训成本 | 重实用性、轻视觉、多写操作流程 |
| **平台型** | 多角色交互、供需匹配、生态规则 | 重角色拆分、重规则引擎、多写各角色视角 |

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

**B2B产品必须额外覆盖**：
- 权限矩阵（角色 x 功能 x 数据范围）
- 多租户数据隔离方案描述
- 与客户现有系统的集成接口清单

**平台型产品必须额外覆盖**：
- 各角色（供方/需方/平台运营）独立功能视角
- 供需匹配规则和排序策略
- 平台佣金/抽成/结算规则

### 第二步：结构化需求拆解

**如果连接了~~Notion：**
1. 搜索团队知识库中已有的相关PRD作为参考
2. 获取团队的PRD模板规范（如有）

**如果未连接：**
1. 使用内置标准模板结构

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

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

### 第三步：生成完整PRD

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

## 输出格式

```markdown
# 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质量自检

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

| 序号 | 检查项 | 判断标准 |
|------|--------|---------|
| 1 | 背景不空泛 | 回答了"为什么做"而非只说"需要做" |
| 2 | 目标可量化 | 至少一个数字型成功指标 |
| 3 | 用户画像具体 | 不含"所有用户"这种描述 |
| 4 | 业务规则穷举 | 无"等"、"其他情况"等模糊表述 |
| 5 | 异常流程覆盖 | 每个功能至少覆盖2个异常场景 |
| 6 | 验收标准可测试 | 使用Given-When-Then格式 |
| 7 | 数据埋点完整 | 核心操作路径均有埋点 |
| 8 | 无技术方案 | PRD只描述"做什么"，不写"怎么实现" |
| 9 | 优先级明确 | 功能模块标注了P0/P1/P2 |
| 10 | 排期有依据 | 工时评估考虑了开发/测试/联调 |

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

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

| 反模式 | 表现 | 正确做法 |
|--------|------|---------|
| **需求镀金** | 一期就写了50个功能点 | 划分MVP/V1.1/V2，一期聚焦核心3-5个功能 |
| **伪需求** | "用户可能需要..."没有数据或调研支撑 | 标注需求来源：用户反馈/数据分析/竞品参考/业务判断 |
| **交互越界** | PRD里写了按钮颜色、字号、布局 | 只描述信息层级和交互逻辑，视觉交给设计师 |
| **技术越界** | PRD里指定用Redis缓存、MySQL存储 | 只描述性能要求（如"<2秒"），实现方案交给技术 |
| **规则黑洞** | "按照业务规则处理"但不写具体规则 | 穷举每条规则的触发条件、处理逻辑、边界值 |

## 红线规则

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

## 输入不足处理

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

## 相关技能

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