产品需求文档生成器

SKILL.md

---
name: prd-generator
version: 1.4.0
description: |
  产品经理最耗时的活：把一个想法变成PRD。告诉我你的产品思路，6步生成完整PRD：产品定位、用户画像、用户故事、功能清单（含RICE排序）、验收标准、里程碑。从「我有个想法」到「研发可以直接干活」。
  触发词：PRD、产品需求文档、需求文档、PRD生成、功能需求、用户故事、验收标准、需求规格、产品规划、需求分析、MRD、BRD、产品方案、需求说明书、MVP定义、功能优先级
  排除：技术方案(用technical-solution)、UI设计稿、项目排期(用甘特图工具)、商业计划书
---

# 产品需求文档生成器 📄

## 核心流程（6 Steps）

### Step 1: 产品定位分析
- 明确产品愿景：一句话描述产品价值
- 定义目标市场：TAM/SAM/SOM市场规模
- 竞品分析：3-5个竞品对比（功能/定位/优劣势）
- 产品差异化：核心竞争壁垒

### Step 2: 用户画像构建
- 主要用户角色：2-3个核心Persona
- 每个Persona包含：基本信息/痛点/目标/使用场景
- 用户旅程地图：从认知→注册→使用→留存的全流程
- 标注关键决策点和流失风险点

### Step 3: 用户故事编写
- 格式：作为{角色}，我想要{功能}，以便{价值}
- 按用户旅程组织故事线
- 标注验收标准（Given-When-Then）
- 按Epic→Story→Task三级拆解

### Step 4: 功能清单与优先级
- MoSCoW法则：Must/Should/Could/Won't
- RICE评分排序：Reach×Impact×Confidence/Effort
- 识别MVP范围（Must+高RICE的Should）
- 功能依赖关系图

### Step 5: 非功能需求
- 性能：响应时间/并发/QPS
- 安全：认证/授权/加密/审计
- 可用性：SLA/容灾/降级
- 兼容性：浏览器/设备/系统版本
- 数据合规：GDPR/个人信息保护

### Step 6: PRD输出
- 完整文档：背景/定位/用户画像/用户故事/功能/非功能/里程碑/风险/附录
- 面向开发可执行
- 版本变更记录模板

## 输出模板

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📄 PRD | {产品名} | v1.0
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
## 1. 背景与目标
问题/机会：{描述}
产品愿景：{一句话}
成功指标：{可量化}

## 2. 产品定位
目标市场：{TAM/SAM/SOM}
竞品对比：{表格}
差异化优势：{核心壁垒}

## 3. 用户画像
Persona 1: {名称}
- 角色：{身份}
- 痛点：{核心问题}
- 目标：{期望达成}
- 场景：{使用情境}

## 4. 用户故事
US1: 作为{角色}，我想要{功能}，以便{价值}
  验收：Given{条件} When{操作} Then{结果}
  优先级：Must/Should/Could

## 5. 功能清单
| 功能 | 优先级 | RICE分 | 依赖 |
|------|--------|--------|------|

MVP范围：{功能列表}

## 6. 非功能需求
性能/安全/可用性/兼容性

## 7. 里程碑
M1: {时间} - MVP上线
M2: {时间} - V1.1迭代

## 8. 风险与应对
| 风险 | 概率 | 影响 | 应对 |
|------|------|------|------|
```

## 边界约束
1. **可执行性**：PRD需开发能直接理解和实施
2. **MVP优先**：先定义最小可行版本
3. **变更管理**：需求变更有记录和审批流程
4. **数据驱动**：决策尽量用数据支撑而非直觉
5. **范围控制**：明确标注"不做什么"比"做什么"更重要

## Output Language
中文输出

## Anti-rationalization

| 借口 | 正确做法 |
|------|----------|
| "用户故事随便写几个意思到了就行" | 每个核心功能必须有完整的用户故事（角色+功能+价值），且附带Given-When-Then验收标准 |
| "MVP就是把所有功能都标为Must Have" | 必须严格按RICE评分排序，MVP只包含Must级+RICE分最高的Should级，通常不超过总功能的40% |
| "非功能需求写'性能要好'就够了" | 非功能需求必须有具体数值指标：响应时间<Xms、并发>Y、SLA>Z%、具体兼容性范围 |
| "用户画像一个就够了，反正产品很简单" | 必须构建2-3个核心Persona，每个包含基本信息/痛点/目标/使用场景四要素 |
| "功能依赖关系太复杂，不画了" | 必须输出功能依赖关系图，标注阻塞关系和可并行开发的功能组 |
| "验收标准开发应该能理解，不用写那么细" | 每个用户故事的验收标准必须用Given-When-Then格式，确保开发和测试无歧义 |
| "竞品分析太花时间，不写了" | PRD中必须包含3-5个竞品对比，至少覆盖功能/定位/优劣势三个维度 |