# Lesson 14: PRD 创建：AI 辅助的需求文档

## 本课目标

- 掌握 BMM PM 代理（John）的完整使用方法
- 理解 PRD 创建工作流（CP）的 12 步流程
- 学会使用 PRD 验证（VP）和编辑（EP）工作流
- 实操使用 John 创建一份完整的 PRD

## 核心内容

### 认识产品主理人代理：John

John 是 BMM 模块中的 PM 代理，定位是"产品管理老兵"。他有 8 年以上 B2B 和消费产品的发布经验，精通市场研究、竞争分析和用户行为洞察。

**John 的性格**：像一个侦探——不停地问"为什么"，直戳本质，用数据说话，砍掉一切不必要的东西。

**核心理念**：

- PRD 来自用户访谈，不是模板填空
- 先发布能验证假设的最小产品
- 技术可行性是约束条件，用户价值才是驱动力

**启动 John**：

```bash
/bmad-pm
```

John 的完整菜单：

```
[MH] 重新显示菜单
[CH] 与代理聊天
[CP] 创建 PRD：引导式创建产品需求文档
[VP] 验证 PRD：检验 PRD 是否全面、精简、组织良好
[EP] 编辑 PRD：更新已有的 PRD
[CE] 创建 Epics 和 Stories：创建驱动开发的规格清单
[IR] 实现就绪检查：确保 PRD、UX、架构和 Epics 都对齐
[CC] 路线纠正：发现重大变更时的应对流程
[PM] 启动派对模式
[DA] 结束对话
```

### PRD 创建工作流（CP）：12 步完整流程

这是 John 最核心的能力——通过结构化引导帮你创建一份专业的 PRD。

**重要概念**：John 使用"步骤文件架构"（Step-file Architecture），每个步骤是一个独立的指令文件，严格按顺序执行，不能跳步。

> **延伸阅读**：PRD 创建完成后，它会成为后续所有工作的基石——**Lesson 15** 的需求拆解会将 PRD 拆成 Epics/Stories，**Lesson 21（阶段 4）**的 `/plan` 命令会基于 Stories 生成开发任务计划，**Lesson 22（阶段 4）**的 `/tdd` 会将 Story 的 BDD 验收标准转化为自动化测试。

```
Step 01: 初始化
        ↓ 检查是否有已有 PRD，确定是新建还是继续
Step 02: 需求发现
        ↓ 通过引导式对话挖掘你的产品愿景
Step 02b: 愿景定义
        ↓ 明确产品的愿景和目标
Step 02c: 执行摘要
        ↓ 撰写一段话总结整个产品
Step 03: 成功指标
        ↓ 定义可衡量的成功标准
Step 04: 用户旅程
        ↓ 描述核心用户如何使用产品
Step 05: 领域定义
        ↓ 明确产品的领域范围和术语
Step 06: 创新元素
        ↓ 整合 CIS 的创新发现（如果有的话）
Step 07: 项目类型
        ↓ 确定项目类型（Web App/Mobile/API 等）
Step 08: 范围定义
        ↓ 明确 MVP 范围，什么做什么不做
Step 09: 功能性需求
        ↓ 详细的功能需求清单
Step 10: 非功能性需求
        ↓ 性能、安全、可用性等要求
Step 11: 打磨
        ↓ 检查一致性，修补遗漏
Step 12: 完成
        ↓ 输出最终 PRD 文档
```

每个步骤之间，John 会给你选项：

```
[a] 高级引导 —— 深入探讨当前话题
[c] 继续 —— 进入下一步
[p] 派对模式 —— 多角色讨论
[y] YOLO —— 让 John 自动完成
```

### PRD 模板的结构和关键字段

John 输出的 PRD 遵循一个标准化模板，核心结构如下：

```markdown
# 产品需求文档 - {{项目名称}}

**作者：** {{你的名字}}
**日期：** {{创建日期}}

## 1. 执行摘要
一段话说清楚：这是什么产品、为谁做、解决什么问题、核心价值

## 2. 产品愿景和目标
- 产品愿景：长远的方向
- 核心目标：短期要实现的
- 成功指标：怎么衡量成功

## 3. 用户角色和画像
- 主要用户群体
- 次要用户群体
- 反面用户（谁不是我们的用户）

## 4. 用户旅程
- 核心使用流程
- 关键触点
- 情感曲线

## 5. 功能性需求
- 核心功能（Must Have）
- 重要功能（Should Have）
- 锦上添花（Nice to Have）

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

## 7. 范围定义
- MVP 范围
- 明确排除项
- 后续迭代计划

## 8. 领域和技术约束
- 行业监管要求
- 技术栈约束
- 第三方依赖
```

### PRD 验证工作流（VP）：13 步质量检查

写完 PRD 不代表结束——John 还提供一个严格的 13 步验证流程，确保 PRD 的质量：

```
VP-01: 发现——找到要验证的 PRD
VP-02: 格式检测——PRD 是否符合标准格式
VP-02b: 一致性检查——内容是否前后一致
VP-03: 密度验证——信息是否足够充分
VP-04: 简报覆盖度——是否覆盖了产品简报的所有要求
VP-05: 可度量性——成功指标是否真的可以衡量
VP-06: 可追溯性——每个需求是否可以追溯到用户目标
VP-07: 实现泄漏检查——PRD 里是否掺杂了技术实现细节
VP-08: 领域合规——是否符合行业特定要求
VP-09: 项目类型验证——是否符合所选项目类型的标准
VP-10: SMART 验证——需求是否具体、可衡量、可实现、相关、有期限
VP-11: 整体质量评估——通篇的质量打分
VP-12: 完整性检查——是否有遗漏的部分
VP-13: 报告输出——生成验证报告
```

**验证报告示例**：

```
PRD 验证报告
====================

总评分：87/100（优秀）

✅ 格式规范：符合标准
✅ 信息密度：充分
⚠️ 可度量性：3 个指标缺少基准值
✅ 可追溯性：所有需求可追溯
⚠️ 实现泄漏：2 处包含技术实现细节
✅ SMART 检查：通过

需要修改的问题：
1. 成功指标"提升用户留存"缺少具体数字 → 建议改为"月留存率从 X% 提升到 Y%"
2. 第 5.3 节包含 API 接口设计 → 建议移到架构文档
3. 非功能需求缺少"数据备份"要求 → 建议补充
```

### PRD 编辑工作流（EP）

当你需要修改已有 PRD 时，使用 EP 工作流。它支持两种场景：

1. **修改现有 PRD**：保留原始结构，只修改指定部分
2. **旧格式转换**：把非标准格式的 PRD 转成 BMM 标准模板

EP 的 4 步流程：

```
EP-01: 发现——找到要编辑的 PRD，理解修改需求
EP-01b: 旧格式转换（如果需要）
EP-02: 审查——展示 PRD 现状，确认修改范围
EP-03: 编辑——逐项修改，每次修改都确认
EP-04: 完成——保存更新后的 PRD
```

### 实操：使用 John 创建一份完整的 PRD

**场景**：为前面头脑风暴和创新策略分析中选定的"AI 辅助记账工具"创建 PRD。

**步骤 1：启动 John**

```bash
/bmad-pm
```

**步骤 2：选择 [CP] 创建 PRD**

```
你：CP

John：好的，我们要从头创建一份新的 PRD。
让我先了解一下背景——你能跟我聊聊你的产品想法吗？
它是为谁做的？解决什么问题？
```

**步骤 3：描述你的产品**

```
你：我想做一个面向中小企业的 AI 记账工具。

核心差异化：
- AI 自动识别和分类发票
- 智能现金流预测
- 行业对标分析（告诉你跟同行比怎么样）

我们之前做过创新策略分析，报告在 planning-artifacts 目录下。
```

**步骤 4：跟着 John 走完 12 步**

John 会像一个经验丰富的产品主理人那样追问你：

```
John：有意思。但我要问几个尖锐的问题——

1. "中小企业"太宽泛了。具体是哪种？
   餐饮店？电商卖家？自由职业者？
   不同类型的记账需求天差地别。

2. "AI 自动分类"听起来很酷，但用户真的需要吗？
   你验证过吗？还是你觉得他们需要？

3. 你说的"行业对标"——数据从哪来？
   这涉及数据源的可行性问题。

先回答这几个问题，我们再往下走。
```

**步骤 5：PRD 逐步成型**

每个步骤完成后，John 会把当前内容追加到 PRD 文件中。你可以随时查看进度：

```
John：Step 3 完成。到目前为止 PRD 包含：
✅ 执行摘要
✅ 产品愿景和目标
✅ 成功指标（3 个核心 KPI）

接下来是用户旅程的定义。准备好了吗？
[a] 深入讨论  [c] 继续  [p] 派对模式  [y] YOLO
```

**步骤 6：PRD 完成并保存**

最终的 PRD 文件保存在 `planning-artifacts/` 目录下。

### PRD 质量标准和验证清单

一份好的 PRD 应该通过以下检查：

| 检查项 | 标准 | 常见问题 |
|--------|------|---------|
| 执行摘要 | 一段话说清楚产品核心 | 太啰嗦或太模糊 |
| 用户画像 | 具体到可以想象出一个真人 | "所有人"不是用户画像 |
| 成功指标 | 有数字、有基准、有时间 | "提升用户体验"不是指标 |
| 功能需求 | 描述"做什么"不描述"怎么做" | 掺杂技术实现细节 |
| 非功能需求 | 有具体的性能/安全标准 | "系统要快"不是标准 |
| 范围定义 | 明确列出"不做什么" | 范围无边界 |
| 可追溯性 | 每个功能对应一个用户目标 | 功能找不到用户需求来源 |

### 与传统 PRD 写作的区别

| 维度 | 传统方式 | 用 John 创建 |
|------|---------|-------------|
| 过程 | 一个人闷头写 | 引导式对话，像做用户访谈 |
| 质量 | 依赖个人经验 | 有结构化的 12 步流程保障 |
| 验证 | 同事评审（主观） | 13 步自动化验证（客观） |
| 盲区 | 容易遗漏 | 每个步骤都有检查清单 |
| 迭代 | 大改动成本高 | EP 工作流支持精准编辑 |
| 格式 | 每个人风格不同 | 统一的标准模板 |
| 衔接 | 手动传递给下游 | 自动对接架构和开发流程 |

**最关键的区别**：John 不是帮你"填模板"，而是通过一系列深入的追问，帮你"想清楚"。很多 PM 在用 John 创建 PRD 的过程中会发现："原来这个问题我之前根本没想到。"

### 从 PRD 到下一步

PRD 创建完成后，有几个推荐的后续动作：

```
PRD 创建完成
    │
    ├── [推荐] 用 VP 验证一下 → 发现遗漏和问题
    │
    ├── [可选] 创建 UX 设计 → /bmad-create-ux-design
    │
    ├── [可选] 创建系统架构 → /bmad-create-architecture
    │
    └── [下一课] 创建 Epics 和 Stories → Lesson 15
```

## 🛠️ 实操练习

> **⚠️ 实操须知**：命令需在新 Claude Code session 中执行。详见 [practice-notice.md](../shared/practice-notice.md)

完成以下练习，掌握 PRD 创建工具。

### 练习 1：启动 John 并创建 PRD

```bash
# 运行以下命令启动 PM 代理
/bmad-pm
```

**任务**：
1. 选择 `[CP]` 开始创建 PRD
2. 使用前面课程中分析的产品方向作为输入
3. 完成 12 步 PRD 创建流程（至少走完 Step 1-8）
4. 获得 PRD 文档

**预期产出**：
- 执行摘要
- 产品愿景和目标
- 用户画像
- 功能性需求清单
- 保存在 `planning-artifacts/` 的 PRD 文档

### 练习 2：验证 PRD 质量

创建完 PRD 后，使用验证工作流：

```bash
/bmad-pm
# 选择 [VP] 验证 PRD
```

**任务**：
- 运行 13 步验证流程
- 查看验证报告，识别需要改进的地方
- 根据报告修改 PRD

### 练习 3：尝试 PRD 编辑工作流

如果你已有 PRD 需要修改：

```bash
/bmad-pm
# 选择 [EP] 编辑 PRD
```

**扩展练习**：尝试直接使用快捷命令

```bash
# 直接创建 PRD
/bmad-create-prd

# 直接验证 PRD
/bmad-validate-prd

# 直接编辑 PRD
/bmad-edit-prd
```

**检查清单**：
- [ ] 成功启动 `/bmad-pm`
- [ ] 完成 PRD 创建流程（至少 8 个步骤）
- [ ] PRD 文档已保存到 `planning-artifacts/`
- [ ] 运行了 PRD 验证（VP）
- [ ] 了解了 PRD 编辑工作流（EP）

---

## 常见问题

**Q: 创建一份 PRD 需要多长时间？**

A: 取决于你产品的复杂度和你的投入程度。简单产品：30-60 分钟。中等复杂度：1-2 小时。复杂产品：可能需要分多次会话完成。John 支持断点续传——下次启动时选 [CP] 可以继续上次的进度。

**Q: 我已经有 PRD 了，想让 John 帮我优化怎么办？**

A: 两种方式：(1) 用 VP 验证，找出问题清单，然后手动修改；(2) 用 EP 编辑工作流，让 John 引导你逐项修改。如果你的 PRD 格式和 BMM 不一样，EP 还支持格式转换。

**Q: PRD 里应不应该包含技术细节？**

A: 不应该。PRD 描述的是"做什么"和"为什么做"，不是"怎么做"。技术实现细节应该放在架构文档里。John 的验证工作流有专门的"实现泄漏检查"（VP-07），会帮你找出 PRD 里不该出现的技术内容。

**Q: 如果我在步骤中途想修改之前的内容怎么办？**

A: 在任何步骤中你都可以告诉 John："我想回去修改第 X 步的内容。" John 会帮你定位到那个部分进行修改，然后再回到当前步骤继续。

## 下一步

请调用 `AskUserQuestion` 展示以下选项，让学习者点击选择；从每条中提炼 1-5 个词作为 label，其余写入 description，不要要求输入数字：

- 进入下一课：Lesson 15 - 需求拆解：从 PRD 到 Epics 和 Stories
- 返回主菜单
- 退出学习

---
*阶段 2 | Lesson 14/26 (阶段内 4/6) | 上一课: Lesson 13.1 - 网站情报工具 | 下一课: Lesson 15 - 需求拆解*