spec-coding-skills/.claude/skills/wp/SKILL.md

name	description
wp	从 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 文档：

# {产品名称} - 产品需求文档 (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 中的重要需求
• 文档结构完整，无空章节（或标注"待补充"）