PRD 2.0：AI时代的需求文档长什么样子（附腾讯模板）

AI时代，PRD不再是冗长文档，而是结构化、可追溯的动态工具。本文结合腾讯实践，为你重塑PRD的价值与写法。
核心内容：
1. 传统PRD面临的三大困境与低效根源
2. AI时代PRD的核心特征：结构化、可追溯、动态更新
3. 腾讯的PRD方法论与实用模板分享

上周，一个在阿里做产品的朋友发朋友圈：

"写了3天PRD，开发看了5分钟说看不懂，又花了2天改。"

"感觉自己在做无用功。"

下面一堆产品经理点赞。

有人留言："同感。PRD越写越长，越来越没人看。"

还有人说："我现在都不知道PRD该写成什么样了。"

PRD越写越累，价值感越来越低。

这是大部分产品经理的困境。

在腾讯做产品这些年，我见过太多PRD：

• • 动辄50页，开发说"看不完"
• • 写得很细，上线后发现需求理解错了
• • 写得很快，遗漏了关键场景

以前的标准是："好的PRD就是详细的PRD"。

AI时代不一样了。

今天我想聊聊，AI时代的PRD该长什么样，以及我在腾讯学到的PRD方法论怎么和AI结合。

一、传统PRD遇到的3大困境

困境1：写得越详细，越没人看

传统PRD的逻辑：越详细越好。

很多产品经理会这样写：

12345678910
功能描述：
1. 用户点击"提交"按钮
2. 系统进行数据校验
   2.1 如果数据格式正确，继续
   2.2 如果数据格式错误，提示"XX格式错误"
3. 系统调用后台接口
   3.1 如果接口返回成功，跳转到成功页面
   3.2 如果接口返回失败，提示"提交失败，请重试"
4. 系统记录操作日志
...

这样写有什么问题？

开发根本不需要这么详细的流程。

开发真正需要的是：

• • 这个功能要解决什么问题
• • 输入什么，输出什么
• • 边界条件是什么
• • 异常情况怎么处理

传统PRD把大量篇幅花在"描述流程"上。

结果：

• • 产品经理写得累
• • 开发看得累
• • 关键信息被淹没

困境2：写PRD花的时间，比做需求分析还多

我见过很多产品经理：

• • 需求分析：2天
• • 写PRD：5天

正常吗？

不正常。

PRD是需求分析的输出，不该比需求分析本身还耗时。

为什么会这样？

传统PRD写作有太多重复劳动：

• • 整理需求背景（从会议纪要、聊天记录里扒）
• • 画流程图（反复调整布局）
• • 写异常场景（一个个枚举）
• • 整理数据字段（手动做表格）
• • 写验收标准（想半天怎么写）

这些工作重要，但大部分是机械性的。

以前没办法，只能硬写。

AI时代不一样了。

这些机械活可以交给AI。

困境3：PRD更新成本太高，文档腐化

需求会变。

这是常态。

传统PRD最大的问题：更新成本太高。

改一个需求，要改PRD的多个章节：

• • 需求背景要改
• • 功能描述要改
• • 流程图要重画
• • 数据字段要调整
• • 验收标准要更新

改一次，半天没了。

很多产品经理干脆：

• • 不改了，口头和开发说一下
• • 等上线后再补文档

PRD就这么腐化了。

变成"历史文件"。

维护成本太高，文档和实际开发脱节。

这才是传统PRD最致命的问题。

二、AI时代的PRD，该长什么样？

我的答案：结构化+可追溯+动态更新。

特征1：结构化——机器能读，人能快速定位

传统PRD给人看，是"文档"。

AI时代的PRD，给"人+机器"看，要"结构化"。

什么叫结构化？

用统一格式组织信息，AI也能理解。

举例：

传统写法：

123
用户可以在列表页点击"编辑"按钮，进入编辑页面。
编辑页面包含标题、内容、标签等字段。
用户修改后点击"保存"，系统更新数据。

结构化写法：

12345678910111213141516171819202122232425
## 功能：内容编辑
 
**触发条件：**
- 入口：列表页"编辑"按钮
- 权限：内容创建者或管理员

**输入：**
- 内容ID
- 用户权限token

**处理逻辑：**
1. 验证用户权限
2. 加载内容数据
3. 渲染编辑表单

**输出：**
- 成功：编辑表单页面（包含标题、内容、标签字段）
- 失败：权限错误提示页面

**数据变更：**
| 字段 | 类型 | 必填 | 说明 |
|-----|------|-----|------|
| title | string | 是 | 标题，不超过50字 |
| content | text | 是 | 正文内容 |
| tags | array | 否 | 标签，最多5个 |

结构化有什么好处？

AI能理解 - 可以自动检查PRD完整性

开发能快速定位 - 想看什么直接跳

测试能直接转用例 - 输入输出定义清楚

特征2：可追溯——每个需求都有来源和决策依据

传统PRD最大的问题：你不知道为什么要做这个需求。

开发会问："为什么要加这个字段？"

你只能说："产品需要。"

但为什么产品需要？用户场景是什么？不加会怎样？

这些信息在传统PRD里往往缺失。

AI时代的PRD，每个需求都应该有清晰的来源。

示例：

123456789101112131415161718192021222324252627
## 需求：增加"标签"字段
 
**需求来源：**
- 用户访谈（2024-06-10，用户A/B/C）
- 用户原话："我想给内容分类，但现在只能用文件夹，不够灵活"

**业务目标：**
- 提升内容组织效率
- 降低用户找内容的时间成本

**数据支撑：**
- 60%用户有内容分类需求
- 用户平均查找时间5分钟（行业平均2分钟）

**不做的后果：**
- 用户继续用低效的文件夹方式
- 可能流失到竞品（XX产品已有标签功能）

**方案选择：**
- 方案A：文件夹+标签（推荐）
- 方案B：只优化文件夹
- 选择理由：标签更灵活，满足多维度分类需求

**参考资料：**
- 用户访谈记录：[链接]
- 竞品分析：[链接]
- 数据报告：[链接]

这样写有什么好处？

开发理解为什么要做 - 不是产品拍脑袋

方案有理有据 - 可以讨论和挑战

后续可复盘 - 上线后验证假设

特征3：动态更新——需求变了，文档秒级同步

传统PRD是"一次性"的：

• • 写完→评审→开发→上线
• • 中间改需求，手动更新文档

AI时代的PRD该是"动态"的：

• • 需求变了，AI自动识别影响范围
• • 自动更新相关章节
• • 自动通知相关人

示例：

1234567891011121314151617181920
[需求变更]
原需求：标签最多5个
新需求：标签最多10个

[AI自动识别影响]
- 数据字段定义（第3章）
- 前端表单校验（第5章）
- 后端接口参数（第7章）
- 测试用例（第9章）

[AI生成变更清单]
- [ ] 更新数据字段说明
- [ ] 更新前端校验规则  
- [ ] 更新后端接口文档
- [ ] 更新测试用例

[自动通知]
- @前端开发 张三
- @后端开发 李四
- @测试 王五

三、我在腾讯学到的PRD方法论

在腾讯这些年，我总结了一套写PRD的方法：3层结构+5W2H模板。

3层结构

第1层：决策层（Why & What）

• • 为什么要做？
• • 要解决什么问题？
• • 成功标准是什么？

第2层：方案层（How）

• • 怎么解决？
• • 有哪些方案？
• • 为什么选这个？

第3层：实现层（Detail）

• • 具体怎么实现？
• • 数据结构是什么？
• • 异常情况怎么处理？

为什么分3层？

不同角色关注点不一样：

• • 老板关注第1层 - 值不值得做
• • 开发关注第2+3层 - 怎么做
• • 测试关注第3层 - 边界条件

传统PRD把3层混一起。

导致：

• • 老板看不到重点（淹没在细节里）
• • 开发看不到全局（只看到实现细节）

分层之后，每个角色快速定位自己需要的信息。

5W2H模板

这是腾讯内部广泛用的需求分析模板：

Why - 为什么做
业务目标、用户痛点、数据支撑

Who - 给谁做
目标用户、用户画像、使用场景

What - 做什么
功能列表、优先级、范围边界

Where - 在哪做
功能入口、使用路径、页面位置

When - 什么时候做
里程碑、上线时间、灰度计划

How - 怎么做
方案设计、交互逻辑、技术实现

How much - 成本多少
开发工时、资源需求、ROI分析

这套模板最大的价值：逼你把需求想清楚。

如果某个W/H回答不出来，说明需求没想透。

四、AI+腾讯方法论：PRD 2.0实战

现在，我把腾讯方法论和AI结合，形成了新的PRD写作流程。

Step 1：AI生成决策层（5分钟）

传统方式： 自己写需求背景，花半天

AI方式： AI基于需求材料直接生成

Prompt：

123456789101112131415161718192021222324252627282930
基于以下需求材料，生成PRD的决策层部分。
 
【输入材料】
- 用户访谈记录：[粘贴]
- 业务目标：[粘贴]
- 数据分析：[粘贴]

【输出要求】
按5W2H模板，生成：

## 1. Why - 为什么做
- 业务目标（用数据说话）
- 用户痛点（用用户原话）
- 数据支撑（用具体数据）
- 不做的后果（说清楚影响）

## 2. Who - 给谁做
- 目标用户（具体画像）
- 典型场景（3-5个）
- 用户旅程（关键路径）

## 3. What - 做什么
- 核心功能（必须做）
- 辅助功能（可选）
- 不做什么（边界）

【注意】
- 每个结论都要有证据支撑
- 用具体数据，不要模糊表达
- 用用户原话，不要自己解读

效果： 5分钟生成决策层初稿。你只需要审核和调整。

Step 2：AI生成方案层（10分钟）

传统方式： 自己想方案，画流程图，花1天

AI方式： AI生成多个方案对比

Prompt：

1234567891011121314151617181920212223242526272829303132333435363738
基于决策层信息，生成方案层部分。
 
【输入】
[粘贴决策层内容]

【输出要求】
## 1. Where - 功能入口
- 推荐方案（含理由）
- 备选方案（含优缺点对比）

## 2. When - 实施计划
- 里程碑（具体时间节点）
- 灰度方案（10%→30%→100%）
- 风险评估（可能的风险）

## 3. How - 解决方案
- 方案A：[描述]
  - 优点：[列出]
  - 缺点：[列出]
  - 成本：[人天]
- 方案B：[描述]
  - 优点：[列出]
  - 缺点：[列出]
  - 成本：[人天]
- 推荐方案：[A/B]
- 推荐理由：[说明]

## 4. How much - 成本评估
- 开发成本：[人天]
- 设计成本：[人天]
- 测试成本：[人天]
- 总成本：[人天]
- ROI分析：[预期收益/成本]

【注意】
- 至少给出2个方案对比
- 成本要具体到人天
- ROI要可量化

效果： 10分钟生成方案对比。你只需要选最合适的方案。

Step 3：AI生成实现层（15分钟）

传统方式： 手动写功能描述、画流程图、整理数据字段，花2-3天

AI方式： AI生成结构化文档

Prompt：

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960
基于方案层信息，生成实现层部分。
 
【输入】
[粘贴方案层内容]

【输出要求】
## 1. 功能详细设计

### 功能A：[功能名称]

**触发条件：**
- 入口：[描述]
- 权限：[描述]

**输入：**
- 参数1：[类型、必填、说明]
- 参数2：[类型、必填、说明]

**处理逻辑：**
1. [步骤1]
2. [步骤2]
3. [步骤3]

**输出：**
- 成功：[描述]
- 失败：[描述]

**异常处理：**
| 异常情况 | 处理方式 | 提示信息 |
|---------|---------|---------|
| 权限不足 | 阻止操作 | "您没有权限" |
| 网络异常 | 重试3次 | "网络异常" |

## 2. 数据结构设计

| 字段名 | 类型 | 长度 | 必填 | 默认值 | 说明 |
|-------|------|-----|------|--------|------|
| id | int | - | 是 | 自增 | 主键 |
| title | string | 50 | 是 | - | 标题 |

## 3. 接口定义

### 接口1：创建内容
- 路径：POST /api/content
- 请求参数：[列出]
- 返回结果：[列出]
- 错误码：[列出]

## 4. 页面交互

### 页面1：列表页
- 布局：[描述]
- 元素：[列出]
- 交互：[描述]
- 异常状态：[空状态、加载中、错误]

【注意】
- 用表格形式展示结构化数据
- 异常情况要全面
- 接口定义要具体

效果： 15分钟生成实现层初稿。你只需要补充业务细节。

Step 4：AI做完整性检查（5分钟）

传统方式： 自己检查，经常遗漏

AI方式： AI做checklist检查

Prompt：

123456789101112131415161718192021222324252627282930313233
对以下PRD进行完整性检查。
 
【输入】
[粘贴完整PRD]

【检查清单】
1. 决策层完整性
   - [ ] 是否说清楚为什么做
   - [ ] 是否有数据支撑
   - [ ] 是否有用户原话
   - [ ] 是否有成功标准

2. 方案层完整性
   - [ ] 是否有方案对比
   - [ ] 是否说明选择理由
   - [ ] 是否评估成本
   - [ ] 是否有风险识别

3. 实现层完整性
   - [ ] 是否覆盖所有功能点
   - [ ] 是否定义数据结构
   - [ ] 是否处理异常情况
   - [ ] 是否有验收标准

4. 逻辑一致性
   - [ ] 决策层和方案层是否对应
   - [ ] 方案层和实现层是否对应
   - [ ] 是否有自相矛盾的地方

【输出】
- 缺失项清单
- 矛盾项说明
- 优化建议

效果： 5分钟完成全面检查，发现遗漏和矛盾。

时间对比

五、腾讯PRD模板（附下载）

基于腾讯方法论和AI能力，我整理了一份PRD 2.0模板。

模板结构

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657
# PRD：[功能名称]
 
## 文档信息
- 版本：v1.0
- 作者：[姓名]
- 日期：2024-06-14
- 状态：草稿/评审中/已通过
- 关联文档：[链接]

---

## 第1层：决策层（Why & What）

### 1.1 Why - 为什么做

**业务目标：**
- 目标1：[具体目标]（当前XX → 目标XX）
- 目标2：[具体目标]（当前XX → 目标XX）

**用户痛点：**
- 痛点1：[描述]
  - 用户原话："[引用]"
  - 影响：[数据]
- 痛点2：[描述]
  - 用户原话："[引用]"
  - 影响：[数据]

**数据支撑：**
- 数据1：[具体数据]（来源：[XX报告]）
- 数据2：[具体数据]（来源：[XX分析]）

**不做的后果：**
- 后果1：[描述]
- 后果2：[描述]

**成功标准：**
- 指标1：从XX提升到XX
- 指标2：从XX提升到XX

### 1.2 Who - 给谁做

**目标用户：**
| 用户类型 | 占比 | 特征 | 核心需求 |
|---------|------|------|---------|
| 新用户 | 40% | 首次使用 | 快速上手 |
| 低频用户 | 30% | 月度使用 | 记住路径 |
| 高频用户 | 30% | 日常使用 | 提升效率 |

**典型场景：**
1. 场景1：[描述]
   - 频率：[高/中/低]
   - 痛点：[描述]
2. 场景2：[描述]
   - 频率：[高/中/低]
   - 痛点：[描述]

**用户旅程：**

发现需求 → 寻找入口 → 完成任务 → 验证结果
   ↓          ↓          ↓          ↓
 [痛点1]   [痛点2]    [痛点3]    [痛点4]

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137
 
### 1.3 What - 做什么

**核心功能（必须做）：**
- [ ] 功能1：[描述]（优先级：P0）
- [ ] 功能2：[描述]（优先级：P0）

**辅助功能（可选）：**
- [ ] 功能3：[描述]（优先级：P1）
- [ ] 功能4：[描述]（优先级：P2）

**不做什么（边界）：**
- ❌ 功能X：[描述]（理由：[说明]）
- ❌ 功能Y：[描述]（理由：[说明]）

---

## 第2层：方案层（How）

### 2.1 Where - 功能入口

**方案对比：**
| 方案 | 优点 | 缺点 | 影响 |
|-----|------|------|------|
| 方案A：一级菜单 | 可见性高 | 占用位置 | 新用户+30% |
| 方案B：二级菜单 | 不占位置 | 可见性低 | 新用户-20% |

**推荐方案：** 方案A
**理由：** [说明]

### 2.2 When - 实施计划

**里程碑：**
- Week 1-2：需求评审+设计
- Week 3-4：开发
- Week 5：测试
- Week 6：灰度上线

**灰度方案：**
- Week 6：10%用户（观察数据）
- Week 7：30%用户（验证效果）
- Week 8：100%用户（全量）

**风险评估：**
| 风险 | 概率 | 影响 | 应对方案 |
|-----|------|------|---------|
| 风险1 | 中 | 高 | [方案] |
| 风险2 | 低 | 中 | [方案] |

### 2.3 How - 解决方案

**方案A：[方案名称]**
- 描述：[详细描述]
- 优点：[列出]
- 缺点：[列出]
- 成本：[人天]
- 周期：[时间]

**方案B：[方案名称]**
- 描述：[详细描述]
- 优点：[列出]
- 缺点：[列出]
- 成本：[人天]
- 周期：[时间]

**推荐方案：** 方案A
**理由：** [详细说明]

### 2.4 How much - 成本评估

**开发成本：**
- 前端：[人天]
- 后端：[人天]
- 测试：[人天]
- 设计：[人天]
- 总计：[人天]

**ROI分析：**
- 投入：[人天 × 日薪]
- 预期收益：[具体指标提升 × 商业价值]
- ROI：[收益/投入]

---

## 第3层：实现层（Detail）

### 3.1 功能详细设计

#### 功能A：[功能名称]

**触发条件：**
- 入口：[位置]
- 权限：[要求]

**输入：**
| 参数 | 类型 | 必填 | 说明 |
|-----|------|------|------|
| param1 | string | 是 | [说明] |

**处理逻辑：**
1. [步骤1]
2. [步骤2]
3. [步骤3]

**输出：**
- 成功：[描述]
- 失败：[描述]

**异常处理：**
| 异常 | 处理 | 提示 |
|-----|------|------|
| 权限不足 | 阻止 | "无权限" |
| 网络异常 | 重试 | "网络错误" |

### 3.2 数据结构设计

**表：content**
| 字段 | 类型 | 长度 | 必填 | 默认 | 说明 |
|-----|------|-----|------|------|------|
| id | int | - | 是 | 自增 | 主键 |
| title | varchar | 50 | 是 | - | 标题 |
| content | text | - | 是 | - | 内容 |
| user_id | int | - | 是 | - | 创建人 |
| created_at | datetime | - | 是 | now() | 创建时间 |

### 3.3 接口定义

#### 接口：创建内容
- **路径：** POST /api/content
- **请求头：** Authorization: Bearer {token}
- **请求参数：**
```json
{
  "title": "string",
  "content": "string",
  "tags": ["string"]
}

• • 返回结果：

1234567
{
  "code": 200,
  "data": {
    "id": 123,
    "created_at": "2024-06-14 10:00:00"
  }
}

• • 错误码：

  错误码	说明
  400	参数错误
  401	未授权
  500	服务器错误

3.4 页面交互

页面：列表页

布局：

1234567
[搜索框]  [筛选] [新建按钮]
--------------------------
[内容卡片1]
[内容卡片2]
[内容卡片3]
--------------------------
[分页]

元素：

• • 搜索框：实时搜索，300ms防抖
• • 筛选：支持多选，最多3个条件
• • 新建按钮：悬浮在右下角

交互：

• • 点击卡片：进入详情页
• • 长按卡片：显示操作菜单
• • 下拉刷新：重新加载数据

异常状态：

• • 空状态：显示"暂无内容"+ 引导新建
• • 加载中：显示骨架屏
• • 错误：显示"加载失败"+ 重试按钮

3.5 验收标准

附录

A. 参考资料

• • 用户访谈记录：[链接]
• • 竞品分析：[链接]
• • 数据报告：[链接]

B. 变更记录

C. 待确认问题

• •问题1：[描述]（负责人：XX）
• •问题2：[描述]（负责人：XX）

1234567891011121314151617181920212223242526272829303132333435363738
 
上周，一个在阿里做产品的朋友发朋友圈：

"写了3天PRD，开发看了5分钟说看不懂，又花了2天改。"

"感觉自己在做无用功。"

下面一堆产品经理点赞。

有人留言："同感。PRD越写越长，越来越没人看。"

还有人说："我现在都不知道PRD该写成什么样了。"

**PRD越写越累，价值感越来越低。**

这是大部分产品经理的困境。

在腾讯做产品这些年，我见过太多PRD：
- 动辄50页，开发说"看不完"
- 写得很细，上线后发现需求理解错了
- 写得很快，遗漏了关键场景

以前的标准是："好的PRD就是详细的PRD"。

AI时代不一样了。

今天我想聊聊，AI时代的PRD该长什么样，以及我在腾讯学到的PRD方法论怎么和AI结合。

---

## 一、传统PRD遇到的3大困境

### 困境1：写得越详细，越没人看

传统PRD的逻辑：**越详细越好。**

很多产品经理会这样写：
 

功能描述：

1. 1. 用户点击"提交"按钮
2. 2. 系统进行数据校验
   2.1 如果数据格式正确，继续
   2.2 如果数据格式错误，提示"XX格式错误"
3. 3. 系统调用后台接口
   3.1 如果接口返回成功，跳转到成功页面
   3.2 如果接口返回失败，提示"提交失败，请重试"
4. 4. 系统记录操作日志
   ...

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495
 
这样写有什么问题？

**开发根本不需要这么详细的流程。**

开发真正需要的是：
- 这个功能要解决什么问题
- 输入什么，输出什么
- 边界条件是什么
- 异常情况怎么处理

传统PRD把大量篇幅花在"描述流程"上。

结果：
- 产品经理写得累
- 开发看得累
- 关键信息被淹没

### 困境2：写PRD花的时间，比做需求分析还多

我见过很多产品经理：
- 需求分析：2天
- 写PRD：5天

正常吗？

**不正常。**

PRD是需求分析的输出，不该比需求分析本身还耗时。

为什么会这样？

传统PRD写作有太多重复劳动：
- 整理需求背景（从会议纪要、聊天记录里扒）
- 画流程图（反复调整布局）
- 写异常场景（一个个枚举）
- 整理数据字段（手动做表格）
- 写验收标准（想半天怎么写）

这些工作重要，但大部分是机械性的。

以前没办法，只能硬写。

AI时代不一样了。

这些机械活可以交给AI。

### 困境3：PRD更新成本太高，文档腐化

需求会变。

这是常态。

传统PRD最大的问题：**更新成本太高。**

改一个需求，要改PRD的多个章节：
- 需求背景要改
- 功能描述要改
- 流程图要重画
- 数据字段要调整
- 验收标准要更新

改一次，半天没了。

很多产品经理干脆：
- 不改了，口头和开发说一下
- 等上线后再补文档

PRD就这么腐化了。

变成"历史文件"。

**维护成本太高，文档和实际开发脱节。**

这才是传统PRD最致命的问题。

---

## 二、AI时代的PRD，该长什么样？

我的答案：**结构化+可追溯+动态更新。**

### 特征1：结构化——机器能读，人能快速定位

传统PRD给人看，是"文档"。

AI时代的PRD，给"人+机器"看，要"结构化"。

什么叫结构化？

**用统一格式组织信息，AI也能理解。**

举例：

**传统写法：**

用户可以在列表页点击"编辑"按钮，进入编辑页面。
编辑页面包含标题、内容、标签等字段。
用户修改后点击"保存"，系统更新数据。

12
 
**结构化写法：**

功能：内容编辑

触发条件：

• • 入口：列表页"编辑"按钮
• • 权限：内容创建者或管理员

输入：

• • 内容ID
• • 用户权限token

处理逻辑：

1. 1. 验证用户权限
2. 2. 加载内容数据
3. 3. 渲染编辑表单

输出：

• • 成功：编辑表单页面（包含标题、内容、标签字段）
• • 失败：权限错误提示页面

数据变更：

12345678910111213141516171819202122232425
 
结构化有什么好处？

**AI能理解** - 可以自动检查PRD完整性

**开发能快速定位** - 想看什么直接跳

**测试能直接转用例** - 输入输出定义清楚

### 特征2：可追溯——每个需求都有来源和决策依据

传统PRD最大的问题：**你不知道为什么要做这个需求。**

开发会问："为什么要加这个字段？"

你只能说："产品需要。"

但为什么产品需要？用户场景是什么？不加会怎样？

这些信息在传统PRD里往往缺失。

**AI时代的PRD，每个需求都应该有清晰的来源。**

示例：
 

需求：增加"标签"字段

需求来源：

• • 用户访谈（2024-06-10，用户A/B/C）
• • 用户原话："我想给内容分类，但现在只能用文件夹，不够灵活"

业务目标：

• • 提升内容组织效率
• • 降低用户找内容的时间成本

数据支撑：

• • 60%用户有内容分类需求
• • 用户平均查找时间5分钟（行业平均2分钟）

不做的后果：

• • 用户继续用低效的文件夹方式
• • 可能流失到竞品（XX产品已有标签功能）

方案选择：

• • 方案A：文件夹+标签（推荐）
• • 方案B：只优化文件夹
• • 选择理由：标签更灵活，满足多维度分类需求

参考资料：

• • 用户访谈记录：[链接]
• • 竞品分析：[链接]
• • 数据报告：[链接]

12345678910111213141516171819202122
 
这样写有什么好处？

**开发理解为什么要做** - 不是产品拍脑袋

**方案有理有据** - 可以讨论和挑战

**后续可复盘** - 上线后验证假设

### 特征3：动态更新——需求变了，文档秒级同步

传统PRD是"一次性"的：
- 写完→评审→开发→上线
- 中间改需求，手动更新文档

AI时代的PRD该是"动态"的：
- 需求变了，AI自动识别影响范围
- 自动更新相关章节
- 自动通知相关人

示例：
 

[需求变更]
原需求：标签最多5个
新需求：标签最多10个

[AI自动识别影响]

• • 数据字段定义（第3章）
• • 前端表单校验（第5章）
• • 后端接口参数（第7章）
• • 测试用例（第9章）

[AI生成变更清单]

• •更新数据字段说明
• •更新前端校验规则
• •更新后端接口文档
• •更新测试用例

[自动通知]

• • @前端开发 张三
• • @后端开发 李四
• • @测试 王五

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081
 
---

## 三、我在腾讯学到的PRD方法论

在腾讯这些年，我总结了一套写PRD的方法：**3层结构+5W2H模板。**

### 3层结构

**第1层：决策层（Why & What）**
- 为什么要做？
- 要解决什么问题？
- 成功标准是什么？

**第2层：方案层（How）**
- 怎么解决？
- 有哪些方案？
- 为什么选这个？

**第3层：实现层（Detail）**
- 具体怎么实现？
- 数据结构是什么？
- 异常情况怎么处理？

**为什么分3层？**

不同角色关注点不一样：
- 老板关注第1层 - 值不值得做
- 开发关注第2+3层 - 怎么做
- 测试关注第3层 - 边界条件

传统PRD把3层混一起。

导致：
- 老板看不到重点（淹没在细节里）
- 开发看不到全局（只看到实现细节）

分层之后，每个角色快速定位自己需要的信息。

### 5W2H模板

这是腾讯内部广泛用的需求分析模板：

**Why - 为什么做**
业务目标、用户痛点、数据支撑

**Who - 给谁做**
目标用户、用户画像、使用场景

**What - 做什么**
功能列表、优先级、范围边界

**Where - 在哪做**
功能入口、使用路径、页面位置

**When - 什么时候做**
里程碑、上线时间、灰度计划

**How - 怎么做**
方案设计、交互逻辑、技术实现

**How much - 成本多少**
开发工时、资源需求、ROI分析

这套模板最大的价值：**逼你把需求想清楚。**

如果某个W/H回答不出来，说明需求没想透。

---

## 四、AI+腾讯方法论：PRD 2.0实战

现在，我把腾讯方法论和AI结合，形成了新的PRD写作流程。

### Step 1：AI生成决策层（5分钟）

**传统方式：** 自己写需求背景，花半天

**AI方式：** AI基于需求材料直接生成

**Prompt：**

基于以下需求材料，生成PRD的决策层部分。

【输入材料】

• • 用户访谈记录：[粘贴]
• • 业务目标：[粘贴]
• • 数据分析：[粘贴]

【输出要求】
按5W2H模板，生成：

1. Why - 为什么做

• • 业务目标（用数据说话）
• • 用户痛点（用用户原话）
• • 数据支撑（用具体数据）
• • 不做的后果（说清楚影响）

2. Who - 给谁做

• • 目标用户（具体画像）
• • 典型场景（3-5个）
• • 用户旅程（关键路径）

3. What - 做什么

• • 核心功能（必须做）
• • 辅助功能（可选）
• • 不做什么（边界）

【注意】

• • 每个结论都要有证据支撑
• • 用具体数据，不要模糊表达
• • 用用户原话，不要自己解读

12345678910
 
**效果：** 5分钟生成决策层初稿。你只需要审核和调整。
 
### Step 2：AI生成方案层（10分钟）
 
**传统方式：** 自己想方案，画流程图，花1天
 
**AI方式：** AI生成多个方案对比
 
**Prompt：**

基于决策层信息，生成方案层部分。

【输入】
[粘贴决策层内容]

【输出要求】

1. Where - 功能入口

• • 推荐方案（含理由）
• • 备选方案（含优缺点对比）

2. When - 实施计划

• • 里程碑（具体时间节点）
• • 灰度方案（10%→30%→100%）
• • 风险评估（可能的风险）

3. How - 解决方案

• • 方案A：[描述]
• • 优点：[列出]
• • 缺点：[列出]
• • 成本：[人天]
• • 方案B：[描述]
• • 优点：[列出]
• • 缺点：[列出]
• • 成本：[人天]
• • 推荐方案：[A/B]
• • 推荐理由：[说明]

4. How much - 成本评估

• • 开发成本：[人天]
• • 设计成本：[人天]
• • 测试成本：[人天]
• • 总成本：[人天]
• • ROI分析：[预期收益/成本]

【注意】

• • 至少给出2个方案对比
• • 成本要具体到人天
• • ROI要可量化

12345678910
 
**效果：** 10分钟生成方案对比。你只需要选最合适的方案。
 
### Step 3：AI生成实现层（15分钟）
 
**传统方式：** 手动写功能描述、画流程图、整理数据字段，花2-3天
 
**AI方式：** AI生成结构化文档
 
**Prompt：**

基于方案层信息，生成实现层部分。

【输入】
[粘贴方案层内容]

【输出要求】

1. 功能详细设计

功能A：[功能名称]

触发条件：

• • 入口：[描述]
• • 权限：[描述]

输入：

• • 参数1：[类型、必填、说明]
• • 参数2：[类型、必填、说明]

处理逻辑：

1. 1. [步骤1]
2. 2. [步骤2]
3. 3. [步骤3]

输出：

• • 成功：[描述]
• • 失败：[描述]

异常处理：

2. 数据结构设计

3. 接口定义

接口1：创建内容

• • 路径：POST /api/content
• • 请求参数：[列出]
• • 返回结果：[列出]
• • 错误码：[列出]

4. 页面交互

页面1：列表页

• • 布局：[描述]
• • 元素：[列出]
• • 交互：[描述]
• • 异常状态：[空状态、加载中、错误]

【注意】

• • 用表格形式展示结构化数据
• • 异常情况要全面
• • 接口定义要具体

12345678910
 
**效果：** 15分钟生成实现层初稿。你只需要补充业务细节。
 
### Step 4：AI做完整性检查（5分钟）
 
**传统方式：** 自己检查，经常遗漏
 
**AI方式：** AI做checklist检查
 
**Prompt：**

对以下PRD进行完整性检查。

【输入】
[粘贴完整PRD]

【检查清单】

1. 1. 决策层完整性
• •是否说清楚为什么做
• •是否有数据支撑
• •是否有用户原话
• •是否有成功标准
2. 2. 方案层完整性
• •是否有方案对比
• •是否说明选择理由
• •是否评估成本
• •是否有风险识别
3. 3. 实现层完整性
• •是否覆盖所有功能点
• •是否定义数据结构
• •是否处理异常情况
• •是否有验收标准
4. 4. 逻辑一致性
• •决策层和方案层是否对应
• •方案层和实现层是否对应
• •是否有自相矛盾的地方

【输出】

• • 缺失项清单
• • 矛盾项说明
• • 优化建议

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879
 
**效果：** 5分钟完成全面检查，发现遗漏和矛盾。

### 时间对比

| 环节 | 传统方式 | AI方式 | 节省 |
|-----|---------|--------|------|
| 决策层 | 4小时 | 5分钟+1小时审核 | 70% |
| 方案层 | 1天 | 10分钟+2小时审核 | 75% |
| 实现层 | 2-3天 | 15分钟+4小时补充 | 80% |
| 检查 | 2小时 | 5分钟+30分钟确认 | 70% |
| **总计** | **5天** | **1天** | **80%** |

---

## 五、腾讯PRD模板（附下载）

基于腾讯方法论和AI能力，我整理了一份PRD 2.0模板。

### 模板结构

```markdown
# PRD：[功能名称]

## 文档信息
- 版本：v1.0
- 作者：[姓名]
- 日期：2024-06-14
- 状态：草稿/评审中/已通过
- 关联文档：[链接]

---

## 第1层：决策层（Why & What）

### 1.1 Why - 为什么做

**业务目标：**
- 目标1：[具体目标]（当前XX → 目标XX）
- 目标2：[具体目标]（当前XX → 目标XX）

**用户痛点：**
- 痛点1：[描述]
  - 用户原话："[引用]"
  - 影响：[数据]
- 痛点2：[描述]
  - 用户原话："[引用]"
  - 影响：[数据]

**数据支撑：**
- 数据1：[具体数据]（来源：[XX报告]）
- 数据2：[具体数据]（来源：[XX分析]）

**不做的后果：**
- 后果1：[描述]
- 后果2：[描述]

**成功标准：**
- 指标1：从XX提升到XX
- 指标2：从XX提升到XX

### 1.2 Who - 给谁做

**目标用户：**
| 用户类型 | 占比 | 特征 | 核心需求 |
|---------|------|------|---------|
| 新用户 | 40% | 首次使用 | 快速上手 |
| 低频用户 | 30% | 月度使用 | 记住路径 |
| 高频用户 | 30% | 日常使用 | 提升效率 |

**典型场景：**
1. 场景1：[描述]
   - 频率：[高/中/低]
   - 痛点：[描述]
2. 场景2：[描述]
   - 频率：[高/中/低]
   - 痛点：[描述]

**用户旅程：**

发现需求 → 寻找入口 → 完成任务 → 验证结果
   ↓          ↓          ↓          ↓
 [痛点1]   [痛点2]    [痛点3]    [痛点4]

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137
 
### 1.3 What - 做什么

**核心功能（必须做）：**
- [ ] 功能1：[描述]（优先级：P0）
- [ ] 功能2：[描述]（优先级：P0）

**辅助功能（可选）：**
- [ ] 功能3：[描述]（优先级：P1）
- [ ] 功能4：[描述]（优先级：P2）

**不做什么（边界）：**
- ❌ 功能X：[描述]（理由：[说明]）
- ❌ 功能Y：[描述]（理由：[说明]）

---

## 第2层：方案层（How）

### 2.1 Where - 功能入口

**方案对比：**
| 方案 | 优点 | 缺点 | 影响 |
|-----|------|------|------|
| 方案A：一级菜单 | 可见性高 | 占用位置 | 新用户+30% |
| 方案B：二级菜单 | 不占位置 | 可见性低 | 新用户-20% |

**推荐方案：** 方案A
**理由：** [说明]

### 2.2 When - 实施计划

**里程碑：**
- Week 1-2：需求评审+设计
- Week 3-4：开发
- Week 5：测试
- Week 6：灰度上线

**灰度方案：**
- Week 6：10%用户（观察数据）
- Week 7：30%用户（验证效果）
- Week 8：100%用户（全量）

**风险评估：**
| 风险 | 概率 | 影响 | 应对方案 |
|-----|------|------|---------|
| 风险1 | 中 | 高 | [方案] |
| 风险2 | 低 | 中 | [方案] |

### 2.3 How - 解决方案

**方案A：[方案名称]**
- 描述：[详细描述]
- 优点：[列出]
- 缺点：[列出]
- 成本：[人天]
- 周期：[时间]

**方案B：[方案名称]**
- 描述：[详细描述]
- 优点：[列出]
- 缺点：[列出]
- 成本：[人天]
- 周期：[时间]

**推荐方案：** 方案A
**理由：** [详细说明]

### 2.4 How much - 成本评估

**开发成本：**
- 前端：[人天]
- 后端：[人天]
- 测试：[人天]
- 设计：[人天]
- 总计：[人天]

**ROI分析：**
- 投入：[人天 × 日薪]
- 预期收益：[具体指标提升 × 商业价值]
- ROI：[收益/投入]

---

## 第3层：实现层（Detail）

### 3.1 功能详细设计

#### 功能A：[功能名称]

**触发条件：**
- 入口：[位置]
- 权限：[要求]

**输入：**
| 参数 | 类型 | 必填 | 说明 |
|-----|------|------|------|
| param1 | string | 是 | [说明] |

**处理逻辑：**
1. [步骤1]
2. [步骤2]
3. [步骤3]

**输出：**
- 成功：[描述]
- 失败：[描述]

**异常处理：**
| 异常 | 处理 | 提示 |
|-----|------|------|
| 权限不足 | 阻止 | "无权限" |
| 网络异常 | 重试 | "网络错误" |

### 3.2 数据结构设计

**表：content**
| 字段 | 类型 | 长度 | 必填 | 默认 | 说明 |
|-----|------|-----|------|------|------|
| id | int | - | 是 | 自增 | 主键 |
| title | varchar | 50 | 是 | - | 标题 |
| content | text | - | 是 | - | 内容 |
| user_id | int | - | 是 | - | 创建人 |
| created_at | datetime | - | 是 | now() | 创建时间 |

### 3.3 接口定义

#### 接口：创建内容
- **路径：** POST /api/content
- **请求头：** Authorization: Bearer {token}
- **请求参数：**
```json
{
  "title": "string",
  "content": "string",
  "tags": ["string"]
}

• • 返回结果：

1234567
{
  "code": 200,
  "data": {
    "id": 123,
    "created_at": "2024-06-14 10:00:00"
  }
}

• • 错误码：

  错误码	说明
  400	参数错误
  401	未授权
  500	服务器错误

3.4 页面交互

页面：列表页

布局：

1234567
[搜索框]  [筛选] [新建按钮]
--------------------------
[内容卡片1]
[内容卡片2]
[内容卡片3]
--------------------------
[分页]

元素：

• • 搜索框：实时搜索，300ms防抖
• • 筛选：支持多选，最多3个条件
• • 新建按钮：悬浮在右下角

交互：

• • 点击卡片：进入详情页
• • 长按卡片：显示操作菜单
• • 下拉刷新：重新加载数据

异常状态：

• • 空状态：显示"暂无内容"+ 引导新建
• • 加载中：显示骨架屏
• • 错误：显示"加载失败"+ 重试按钮

3.5 验收标准

附录

A. 参考资料

• • 用户访谈记录：[链接]
• • 竞品分析：[链接]
• • 数据报告：[链接]

B. 变更记录

C. 待确认问题

• •问题1：[描述]（负责人：XX）
• •问题2：[描述]（负责人：XX）
  

六、3个关键建议

建议1：别让AI替你思考

AI能帮你生成文档框架。

但不能替你做判断：

• • 这个需求值不值得做
• • 该选哪个方案
• • 优先级怎么排

AI是助手，你是决策者。

建议2：PRD要持续迭代，不是一次性文档

需求会变。

PRD也要跟着变。

用AI降低更新成本：

• • 需求变了，让AI识别影响范围
• • 自动生成变更清单
• • 自动通知相关人

建议3：PRD要给不同角色看不同内容

别一份PRD打天下：

• • 给老板看决策层
• • 给开发看方案层+实现层
• • 给测试看实现层+验收标准

用AI生成不同版本的PRD。

最后说几句

做了10年产品，我越来越觉得：

PRD不是目的，是工具。

PRD的目的是：

• • 帮你把需求想清楚
• • 帮团队达成共识
• • 帮后续复盘验证

AI不能替你想清楚需求。

但能帮你更快把想法变成文档。

PRD 2.0的核心价值：

• • 让你有更多时间思考需求本身
• • 而不是在文档格式上浪费时间

登录查看剩余 70% 内容