---
name: wp
description: 从 RequirementsDoc.md 生成 PRD.md，将需求文档转化为结构化的产品需求文档。
---

# Write PRD

> **文档定位**：PRD 是「价值主张」文档，使用业务语言描述产品要解决什么问题、为谁创造什么价值。面向产品、业务、管理层沟通。

当用户调用 `/wp` 时，执行以下步骤：

## 1. 读取源文档

读取 `doc/RequirementsDoc.md` 文件。

如果文件不存在，提示用户：
> RequirementsDoc.md 不存在，请先创建需求文档。

如果已存在 `doc/PRD.md`，同时读取作为参考（保持风格一致）。

## 2. 分析需求文档

从 RequirementsDoc 中提取以下信息：

### 2.1 产品定位

- 产品名称
- 目标用户
- 核心价值主张
- 竞品对比（如有）

### 2.2 功能需求

- 功能模块划分
- 各模块详细需求
- 功能优先级（P0/P1/P2）

### 2.3 非功能需求

- 性能要求
- 安全要求
- 兼容性要求
- 可用性要求

### 2.4 约束条件

- 技术约束
- 业务约束
- 时间约束

## 3. 生成 PRD

按以下结构生成 PRD 文档：

```markdown
# {产品名称} - 产品需求文档 (PRD)

## 文档信息

| 项目 | 内容 |
|------|------|
| 版本 | v1.0 |
| 创建日期 | {YYYY-MM-DD} |
| 状态 | 草稿 |

## 1. 产品概述

### 1.1 产品背景

{从 RequirementsDoc 提取，说明产品解决的问题和市场机会}

### 1.2 产品定位

{目标用户、核心价值、差异化优势}

### 1.3 产品目标

| 目标 | 指标 | 衡量方式 |
|------|------|----------|
| {业务目标} | {量化指标} | {如何衡量} |

## 2. 用户故事

PRD 以用户故事为核心驱动，所有功能需求都应对应到具体的用户故事。

### 2.1 用户角色定义

| 角色 | 描述 | 核心目标 | 痛点 |
|------|------|----------|------|
| {角色1} | {角色描述} | {核心目标} | {当前痛点} |

### 2.2 用户故事列表

按优先级排列的用户故事：

#### P0 - 核心故事

| ID | 用户故事 | 验收标准 |
|----|----------|----------|
| US-001 | 作为{角色}，我想要{功能}，以便{价值} | {验收标准} |

#### P1 - 重要故事

| ID | 用户故事 | 验收标准 |
|----|----------|----------|
| US-xxx | 作为{角色}，我想要{功能}，以便{价值} | {验收标准} |

#### P2 - 次要故事

| ID | 用户故事 | 验收标准 |
|----|----------|----------|
| US-xxx | 作为{角色}，我想要{功能}，以便{价值} | {验收标准} |

### 2.3 用户旅程

**【必须】使用流程图展示核心用户旅程：**

```
┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  触发点     │ ──▶ │  关键步骤   │ ──▶ │  目标达成   │
│  {描述}     │     │  {描述}     │     │  {描述}     │
└─────────────┘     └─────────────┘     └─────────────┘
        │                   │                   │
        ▼                   ▼                   ▼
   {用户感受}          {用户感受}          {用户感受}
```

{描述用户完成核心任务的完整流程，从触发点到目标达成}

## 3. 功能需求

> 功能需求与用户故事的对应关系

### 3.1 功能架构

**【必须】使用树状图或模块图展示功能架构：**

```
{产品名称}
├── {模块A}
│   ├── {功能A1}
│   └── {功能A2}
├── {模块B}
│   ├── {功能B1}
│   └── {功能B2}
└── {模块C}
    └── {功能C1}
```

### 3.2 功能详情

#### 3.2.1 {模块名称}

| 功能点 | 描述 | 关联用户故事 | 优先级 | 验收标准 |
|--------|------|--------------|--------|----------|
| {功能1} | {描述} | US-001 | P0 | {标准} |

{重复以上结构覆盖所有模块}

## 4. 非功能需求

### 4.1 性能需求

| 指标 | 要求 | 说明 |
|------|------|------|
| {响应时间} | {要求} | {场景说明} |

### 4.2 安全需求

{数据安全、访问控制、合规要求}

### 4.3 兼容性需求

| 平台/环境 | 支持版本 |
|-----------|----------|
| {平台} | {版本} |

### 4.4 可用性需求

{SLA、故障恢复、监控告警}

## 5. 数据需求

### 5.1 数据模型

**【建议】使用 ER 图或表格展示核心实体关系：**

```
┌──────────┐       ┌──────────┐
│  实体A   │ 1───n │  实体B   │
├──────────┤       ├──────────┤
│ 字段1    │       │ 字段1    │
│ 字段2    │       │ 字段2    │
└──────────┘       └──────────┘
```

### 5.2 数据规范

| 字段 | 类型 | 说明 | 校验规则 |
|------|------|------|----------|
| {字段名} | {类型} | {说明} | {规则} |

## 6. 接口需求

### 6.1 外部接口

| 接口 | 用途 | 提供方 |
|------|------|--------|
| {接口名} | {用途} | {第三方} |

### 6.2 内部接口

{模块间接口规范}

## 7. 约束与依赖

### 7.1 技术约束

| 约束 | 说明 | 影响 |
|------|------|------|
| {约束} | {说明} | {影响范围} |

### 7.2 业务约束

{法规、政策、合同限制}

### 7.3 外部依赖

{第三方服务、团队依赖}

## 8. 里程碑规划

**【建议】使用时间线展示里程碑：**

```
Phase 1          Phase 2          Phase 3
   │                │                │
   ▼                ▼                ▼
┌──────┐        ┌──────┐        ┌──────┐
│ MVP  │ ────▶  │ v1.1 │ ────▶  │ v2.0 │
└──────┘        └──────┘        └──────┘
{日期}          {日期}          {日期}
```

| 阶段 | 目标 | 交付物 |
|------|------|--------|
| {阶段1} | {目标} | {交付物} |

## 9. 风险评估

| 风险 | 可能性 | 影响 | 应对措施 |
|------|--------|------|----------|
| {风险1} | 高/中/低 | 高/中/低 | {措施} |

## 附录

### A. 术语表

| 术语 | 定义 |
|------|------|
| {术语} | {定义} |

### B. 参考文档

- RequirementsDoc.md
```

## 4. 保存文档

将生成的 PRD 保存到 `doc/PRD.md`。

如果文件已存在，覆盖原文件（历史版本通过 git 追溯）。

## 5. 输出摘要

向用户展示生成摘要：

- PRD 文件路径
- 包含的功能模块数量
- 主要章节概览
- 建议的下一步操作（运行 `/rp` 评审）

---

## 可视化输出要求

PRD 作为「价值主张」文档，需要便于业务沟通理解，**必须包含**：

| 章节 | 可视化形式 | 必要性 |
|------|------------|--------|
| 2.3 用户旅程 | 流程图（ASCII） | **必须** |
| 3.1 功能架构 | 树状图/模块图 | **必须** |
| 5.1 数据模型 | ER 图 | 建议 |
| 8. 里程碑规划 | 时间线 | 建议 |

## 注意事项

- PRD 使用**业务语言**，避免过多技术术语
- PRD 内容必须完全来源于 RequirementsDoc，不要臆造需求
- 如果 RequirementsDoc 信息不完整，在对应章节标注"待补充"
- 保持语言风格与现有文档一致
- 优先级标注遵循 P0 > P1 > P2 规则
- 验收标准要具体可测试

## 质量检查

生成 PRD 后，自查以下项目：

- [ ] 所有用户故事都有唯一 ID（US-xxx）
- [ ] 所有用户故事都符合格式：作为{角色}，我想要{功能}，以便{价值}
- [ ] 所有功能点都关联到用户故事
- [ ] 所有功能点都有明确的优先级
- [ ] 所有功能点都有验收标准
- [ ] **用户旅程有流程图**
- [ ] **功能架构有模块图**
- [ ] 非功能需求有量化指标
- [ ] 无遗漏 RequirementsDoc 中的重要需求
- [ ] 文档结构完整，无空章节（或标注"待补充"）