| 编辑推荐: |
本文主要介绍了AI时代的需求文档长什么样相关内容，希望对您的学习有所帮助。
文章来自于微信公众号Kris产品成长之路，由火龙果软件Alice推荐。 |
|
上周，一个在阿里做产品的朋友发朋友圈：
"写了3天PRD，开发看了5分钟说看不懂，又花了2天改。"
"感觉自己在做无用功。"
下面一堆产品经理点赞。
有人留言："同感。PRD越写越长，越来越没人看。"
还有人说："我现在都不知道PRD该写成什么样了。"
PRD越写越累，价值感越来越低。
这是大部分产品经理的困境。
在腾讯做产品这些年，我见过太多PRD：
• 动辄50页，开发说"看不完"
• 写得很细，上线后发现需求理解错了
• 写得很快，遗漏了关键场景
以前的标准是："好的PRD就是详细的PRD"。
AI时代不一样了。
今天我想聊聊，AI时代的PRD该长什么样，以及我在腾讯学到的PRD方法论怎么和AI结合。
一、传统PRD遇到的3大困境
困境1：写得越详细，越没人看
传统PRD的逻辑：越详细越好。
很多产品经理会这样写：
功能描述：
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也能理解。
举例：
传统写法：
用户可以在列表页点击"编辑"按钮，进入编辑页面。
编辑页面包含标题、内容、标签等字段。
用户修改后点击"保存"，系统更新数据。
|
结构化写法：
## 功能：内容编辑
**触发条件：**
- 入口：列表页"编辑"按钮
- 权限：内容创建者或管理员
**输入：**
- 内容ID
- 用户权限token
**处理逻辑：**
1. 验证用户权限
2. 加载内容数据
3. 渲染编辑表单
**输出：**
- 成功：编辑表单页面（包含标题、内容、标签字段）
- 失败：权限错误提示页面
**数据变更：**
| 字段 | 类型 | 必填 | 说明 |
|-----|------|-----|------|
| title | string | 是 | 标题，不超过50字 |
| content | text | 是 | 正文内容 |
| tags | array | 否 | 标签，最多5个 |
|
结构化有什么好处？
AI能理解 - 可以自动检查PRD完整性
开发能快速定位 - 想看什么直接跳
测试能直接转用例 - 输入输出定义清楚
特征2：可追溯——每个需求都有来源和决策依据
传统PRD最大的问题：你不知道为什么要做这个需求。
开发会问："为什么要加这个字段？"
你只能说："产品需要。"
但为什么产品需要？用户场景是什么？不加会怎样？
这些信息在传统PRD里往往缺失。
AI时代的PRD，每个需求都应该有清晰的来源。
示例：
## 需求：增加"标签"字段
**需求来源：**
- 用户访谈（2024-06-10，用户A/B/C）
- 用户原话："我想给内容分类，但现在只能用文件夹，不够灵活"
**业务目标：**
- 提升内容组织效率
- 降低用户找内容的时间成本
**数据支撑：**
- 60%用户有内容分类需求
- 用户平均查找时间5分钟（行业平均2分钟）
**不做的后果：**
- 用户继续用低效的文件夹方式
- 可能流失到竞品（XX产品已有标签功能）
**方案选择：**
- 方案A：文件夹+标签（推荐）
- 方案B：只优化文件夹
- 选择理由：标签更灵活，满足多维度分类需求
**参考资料：**
- 用户访谈记录：[链接]
- 竞品分析：[链接]
- 数据报告：[链接]
|
这样写有什么好处？
开发理解为什么要做 - 不是产品拍脑袋
方案有理有据 - 可以讨论和挑战
后续可复盘 - 上线后验证假设
特征3：动态更新——需求变了，文档秒级同步
传统PRD是"一次性"的：
• 写完→评审→开发→上线
• 中间改需求，手动更新文档
AI时代的PRD该是"动态"的：
• 需求变了，AI自动识别影响范围
• 自动更新相关章节
• 自动通知相关人
示例：
[需求变更]
原需求：标签最多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：
基于以下需求材料，生成PRD的决策层部分。
【输入材料】
- 用户访谈记录：[粘贴]
- 业务目标：[粘贴]
- 数据分析：[粘贴]
【输出要求】
按5W2H模板，生成：
## 1. Why - 为什么做
- 业务目标（用数据说话）
- 用户痛点（用用户原话）
- 数据支撑（用具体数据）
- 不做的后果（说清楚影响）
## 2. Who - 给谁做
- 目标用户（具体画像）
- 典型场景（3-5个）
- 用户旅程（关键路径）
## 3. What - 做什么
- 核心功能（必须做）
- 辅助功能（可选）
- 不做什么（边界）
【注意】
- 每个结论都要有证据支撑
- 用具体数据，不要模糊表达
- 用用户原话，不要自己解读
|
效果： 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要可量化
|
效果： 10分钟生成方案对比。你只需要选最合适的方案。
Step 3：AI生成实现层（15分钟）
传统方式： 手动写功能描述、画流程图、整理数据字段，花2-3天
AI方式： AI生成结构化文档
Prompt：
基于方案层信息，生成实现层部分。
【输入】
[粘贴方案层内容]
【输出要求】
## 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：
对以下PRD进行完整性检查。
【输入】
[粘贴完整PRD]
【检查清单】
1. 决策层完整性
- [ ] 是否说清楚为什么做
- [ ] 是否有数据支撑
- [ ] 是否有用户原话
- [ ] 是否有成功标准
2. 方案层完整性
- [ ] 是否有方案对比
- [ ] 是否说明选择理由
- [ ] 是否评估成本
- [ ] 是否有风险识别
3. 实现层完整性
- [ ] 是否覆盖所有功能点
- [ ] 是否定义数据结构
- [ ] 是否处理异常情况
- [ ] 是否有验收标准
4. 逻辑一致性
- [ ] 决策层和方案层是否对应
- [ ] 方案层和实现层是否对应
- [ ] 是否有自相矛盾的地方
【输出】
- 缺失项清单
- 矛盾项说明
- 优化建议
|
效果： 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模板。
模板结构
# 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]
### 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"]
}
|
• 返回结果：
{
"code": 200,
"data": {
"id": 123,
"created_at": "2024-06-14 10:00:00"
}
}
|
• 错误码：
| 错误码 |
说明 |
| 400 |
参数错误 |
| 401 |
未授权 |
| 500 |
服务器错误 |
页面交互
页面：列表页
布局：
[搜索框] [筛选] [新建按钮]
--------------------------
[内容卡片1]
[内容卡片2]
[内容卡片3]
--------------------------
[分页]
|
元素：
• 搜索框：实时搜索，300ms防抖
• 筛选：支持多选，最多3个条件
• 新建按钮：悬浮在右下角
交互：
• 点击卡片：进入详情页
• 长按卡片：显示操作菜单
• 下拉刷新：重新加载数据
异常状态：
• 空状态：显示"暂无内容"+ 引导新建
• 加载中：显示骨架屏
• 错误：显示"加载失败"+ 重试按钮
验收标准
| 功能 |
验收标准 |
验收方法 |
| 创建内容 |
点击提交后2秒内完成 |
性能测试 |
| 搜索 |
输入关键词300ms内返回结果 |
性能测试 |
| 权限 |
非创建者无法编辑 |
功能测试 |
附录
A. 参考资料
• 用户访谈记录：[链接]
• 竞品分析：[链接]
• 数据报告：[链接]
B. 变更记录
| 版本 |
日期 |
变更内容 |
变更人 |
| v1.0 |
2024-06-14 |
初始版本 |
[姓名] |
C. 待确认问题
•问题1：[描述]（负责人：XX）
•问题2：[描述]（负责人：XX）
上周，一个在阿里做产品的朋友发朋友圈：
"写了3天PRD，开发看了5分钟说看不懂，又花了2天改。"
"感觉自己在做无用功。"
下面一堆产品经理点赞。
有人留言："同感。PRD越写越长，越来越没人看。"
还有人说："我现在都不知道PRD该写成什么样了。"
**PRD越写越累，价值感越来越低。**
这是大部分产品经理的困境。
在腾讯做产品这些年，我见过太多PRD：
- 动辄50页，开发说"看不完"
- 写得很细，上线后发现需求理解错了
- 写得很快，遗漏了关键场景
以前的标准是："好的PRD就是详细的PRD"。
AI时代不一样了。
今天我想聊聊，AI时代的PRD该长什么样，以及我在腾讯学到的PRD方法论怎么和AI结合。
---
## 一、传统PRD遇到的3大困境
### 困境1：写得越详细，越没人看
传统PRD的逻辑：**越详细越好。**
很多产品经理会这样写：
|
功能描述：
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也能理解。**
举例：
**传统写法：**
|
用户可以在列表页点击"编辑"按钮，进入编辑页面。
编辑页面包含标题、内容、标签等字段。
用户修改后点击"保存"，系统更新数据。
功能：内容编辑
触发条件：
• 入口：列表页"编辑"按钮
• 权限：内容创建者或管理员
输入：
• 内容ID
• 用户权限token
处理逻辑：
1. 验证用户权限
2. 加载内容数据
3. 渲染编辑表单
输出：
• 成功：编辑表单页面（包含标题、内容、标签字段）
• 失败：权限错误提示页面
数据变更：
| 字段 |
类型 |
必填 |
说明 |
| title |
string |
是 |
标题，不超过50字 |
| content |
text |
是 |
正文内容 |
| tags |
array |
否 |
标签，最多5个 |
结构化有什么好处？
**AI能理解** - 可以自动检查PRD完整性
**开发能快速定位** - 想看什么直接跳
**测试能直接转用例** - 输入输出定义清楚
### 特征2：可追溯——每个需求都有来源和决策依据
传统PRD最大的问题：**你不知道为什么要做这个需求。**
开发会问："为什么要加这个字段？"
你只能说："产品需要。"
但为什么产品需要？用户场景是什么？不加会怎样？
这些信息在传统PRD里往往缺失。
**AI时代的PRD，每个需求都应该有清晰的来源。**
示例：
|
需求：增加"标签"字段
需求来源：
• 用户访谈（2024-06-10，用户A/B/C）
• 用户原话："我想给内容分类，但现在只能用文件夹，不够灵活"
业务目标：
• 提升内容组织效率
• 降低用户找内容的时间成本
数据支撑：
• 60%用户有内容分类需求
• 用户平均查找时间5分钟（行业平均2分钟）
不做的后果：
• 用户继续用低效的文件夹方式
• 可能流失到竞品（XX产品已有标签功能）
方案选择：
• 方案A：文件夹+标签（推荐）
• 方案B：只优化文件夹
• 选择理由：标签更灵活，满足多维度分类需求
参考资料：
• 用户访谈记录：[链接]
• 竞品分析：[链接]
• 数据报告：[链接]
这样写有什么好处？
**开发理解为什么要做** - 不是产品拍脑袋
**方案有理有据** - 可以讨论和挑战
**后续可复盘** - 上线后验证假设
### 特征3：动态更新——需求变了，文档秒级同步
传统PRD是"一次性"的：
- 写完→评审→开发→上线
- 中间改需求，手动更新文档
AI时代的PRD该是"动态"的：
- 需求变了，AI自动识别影响范围
- 自动更新相关章节
- 自动通知相关人
示例：
|
[需求变更]
原需求：标签最多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：**
|
基于以下需求材料，生成PRD的决策层部分。
【输入材料】
• 用户访谈记录：[粘贴]
• 业务目标：[粘贴]
• 数据分析：[粘贴]
【输出要求】
按5W2H模板，生成：
1. Why - 为什么做
• 业务目标（用数据说话）
• 用户痛点（用用户原话）
• 数据支撑（用具体数据）
• 不做的后果（说清楚影响）
2. Who - 给谁做
• 目标用户（具体画像）
• 典型场景（3-5个）
• 用户旅程（关键路径）
3. What - 做什么
• 核心功能（必须做）
• 辅助功能（可选）
• 不做什么（边界）
【注意】
• 每个结论都要有证据支撑
• 用具体数据，不要模糊表达
• 用用户原话，不要自己解读
**效果：** 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要可量化
**效果：** 10分钟生成方案对比。你只需要选最合适的方案。
### Step 3：AI生成实现层（15分钟）
**传统方式：** 手动写功能描述、画流程图、整理数据字段，花2-3天
**AI方式：** AI生成结构化文档
**Prompt：**
|
基于方案层信息，生成实现层部分。
【输入】
[粘贴方案层内容]
【输出要求】
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：**
|
对以下PRD进行完整性检查。
【输入】
[粘贴完整PRD]
【检查清单】
1. 决策层完整性
•是否说清楚为什么做
•是否有数据支撑
•是否有用户原话
•是否有成功标准
2. 方案层完整性
•是否有方案对比
•是否说明选择理由
•是否评估成本
•是否有风险识别
3. 实现层完整性
•是否覆盖所有功能点
•是否定义数据结构
•是否处理异常情况
•是否有验收标准
4. 逻辑一致性
•决策层和方案层是否对应
•方案层和实现层是否对应
•是否有自相矛盾的地方
【输出】
• 缺失项清单
• 矛盾项说明
• 优化建议
**效果：** 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]
### 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"]
}
|
• 返回结果：
{
"code": 200,
"data": {
"id": 123,
"created_at": "2024-06-14 10:00:00"
}
}
|
• 错误码：
| 错误码 |
说明 |
| 400 |
参数错误 |
| 401 |
未授权 |
| 500 |
服务器错误 |
3.4 页面交互
页面：列表页
布局：
[搜索框] [筛选] [新建按钮]
--------------------------
[内容卡片1]
[内容卡片2]
[内容卡片3]
--------------------------
[分页]
|
元素：
• 搜索框：实时搜索，300ms防抖
• 筛选：支持多选，最多3个条件
• 新建按钮：悬浮在右下角
交互：
• 点击卡片：进入详情页
• 长按卡片：显示操作菜单
• 下拉刷新：重新加载数据
异常状态：
• 空状态：显示"暂无内容"+ 引导新建
• 加载中：显示骨架屏
• 错误：显示"加载失败"+ 重试按钮
验收标准
| 功能 |
验收标准 |
验收方法 |
| 创建内容 |
点击提交后2秒内完成 |
性能测试 |
| 搜索 |
输入关键词300ms内返回结果 |
性能测试 |
| 权限 |
非创建者无法编辑 |
功能测试 |
附录
A. 参考资料
• 用户访谈记录：[链接]
• 竞品分析：[链接]
• 数据报告：[链接]
B. 变更记录
| 版本 |
日期 |
变更内容 |
变更人 |
| v1.0 |
2024-06-14 |
初始版本 |
[姓名] |
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的核心价值：
• 让你有更多时间思考需求本身
• 而不是在文档格式上浪费时间
| 
订阅