ac0f086821
- 完成 T-001A: 前端项目初始化 (Next.js 14 + TypeScript + Tailwind CSS) - 完成 T-001B: 后端项目初始化 (FastAPI + SQLAlchemy + asyncpg) - 完成 T-002: 数据库配置 (KolVideo 模型 + 索引 + 测试) - 完成 T-003: 基础 UI 框架 (Header/Footer 组件 + 品牌色系) - 完成 T-004: 环境变量配置 (前后端环境变量) Co-Authored-By: Claude <noreply@anthropic.com>
319 lines
7.7 KiB
Markdown
319 lines
7.7 KiB
Markdown
---
|
||
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 中的重要需求
|
||
- [ ] 文档结构完整，无空章节（或标注"待补充"）
|