上周，一个在阿里做产品的朋友发朋友圈：
"写了3天PRD，开发看了5分钟说看不懂，又花了2天改。"
"感觉自己在做无用功。"
下面一堆产品经理点赞。
有人留言："同感。PRD越写越长，越来越没人看。"
还有人说："我现在都不知道PRD该写成什么样了。"
PRD越写越累，价值感越来越低。
这是大部分产品经理的困境。
在腾讯做产品这些年，我见过太多PRD：
以前的标准是："好的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花的时间，比做需求分析还多
我见过很多产品经理：
正常吗？
不正常。
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该是"动态"的：
示例：
[需求变更]
原需求：标签最多5个
新需求：标签最多10个
[AI自动识别影响]
- 数据字段定义（第3章）
- 前端表单校验（第5章）
- 后端接口参数（第7章）
- 测试用例（第9章）
[AI生成变更清单]
- [ ] 更新数据字段说明
- [ ] 更新前端校验规则
- [ ] 更新后端接口文档
- [ ] 更新测试用例
[自动通知]
- @前端开发 张三
- @后端开发 李四
- @测试 王五
三、我在腾讯学到的PRD方法论
在腾讯这些年，我总结了一套写PRD的方法：3层结构+5W2H模板。
3层结构
第1层：决策层（Why & What）
第2层：方案层（How）
第3层：实现层（Detail）
为什么分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分钟完成全面检查，发现遗漏和矛盾。
时间对比
五、腾讯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"
}
}
3.4 页面交互
页面：列表页
布局：
[搜索框] [筛选] [新建按钮]
--------------------------
[内容卡片1]
[内容卡片2]
[内容卡片3]
--------------------------
[分页]
元素：
交互：
异常状态：
3.5 验收标准
附录
A. 参考资料
B. 变更记录
C. 待确认问题
上周，一个在阿里做产品的朋友发朋友圈：
"写了3天PRD，开发看了5分钟说看不懂，又花了2天改。"
"感觉自己在做无用功。"
下面一堆产品经理点赞。
有人留言："同感。PRD越写越长，越来越没人看。"
还有人说："我现在都不知道PRD该写成什么样了。"
**PRD越写越累，价值感越来越低。**
这是大部分产品经理的困境。
在腾讯做产品这些年，我见过太多PRD：
- 动辄50页，开发说"看不完"
- 写得很细，上线后发现需求理解错了
- 写得很快，遗漏了关键场景
以前的标准是："好的PRD就是详细的PRD"。
AI时代不一样了。
今天我想聊聊，AI时代的PRD该长什么样，以及我在腾讯学到的PRD方法论怎么和AI结合。
---
## 一、传统PRD遇到的3大困境
### 困境1：写得越详细，越没人看
传统PRD的逻辑：**越详细越好。**
很多产品经理会这样写：
功能描述：
- 2. 系统进行数据校验
2.1 如果数据格式正确，继续
2.2 如果数据格式错误，提示"XX格式错误" - 3. 系统调用后台接口
3.1 如果接口返回成功，跳转到成功页面
3.2 如果接口返回失败，提示"提交失败，请重试"
这样写有什么问题？
**开发根本不需要这么详细的流程。**
开发真正需要的是：
- 这个功能要解决什么问题
- 输入什么，输出什么
- 边界条件是什么
- 异常情况怎么处理
传统PRD把大量篇幅花在"描述流程"上。
结果：
- 产品经理写得累
- 开发看得累
- 关键信息被淹没
### 困境2：写PRD花的时间，比做需求分析还多
我见过很多产品经理：
- 需求分析：2天
- 写PRD：5天
正常吗？
**不正常。**
PRD是需求分析的输出，不该比需求分析本身还耗时。
为什么会这样？
传统PRD写作有太多重复劳动：
- 整理需求背景（从会议纪要、聊天记录里扒）
- 画流程图（反复调整布局）
- 写异常场景（一个个枚举）
- 整理数据字段（手动做表格）
- 写验收标准（想半天怎么写）
这些工作重要，但大部分是机械性的。
以前没办法，只能硬写。
AI时代不一样了。
这些机械活可以交给AI。
### 困境3：PRD更新成本太高，文档腐化
需求会变。
这是常态。
传统PRD最大的问题：**更新成本太高。**
改一个需求，要改PRD的多个章节：
- 需求背景要改
- 功能描述要改
- 流程图要重画
- 数据字段要调整
- 验收标准要更新
改一次，半天没了。
很多产品经理干脆：
- 不改了，口头和开发说一下
- 等上线后再补文档
PRD就这么腐化了。
变成"历史文件"。
**维护成本太高，文档和实际开发脱节。**
这才是传统PRD最致命的问题。
---
## 二、AI时代的PRD，该长什么样？
我的答案：**结构化+可追溯+动态更新。**
### 特征1：结构化——机器能读，人能快速定位
传统PRD给人看，是"文档"。
AI时代的PRD，给"人+机器"看，要"结构化"。
什么叫结构化？
**用统一格式组织信息，AI也能理解。**
举例：
**传统写法：**
用户可以在列表页点击"编辑"按钮，进入编辑页面。
编辑页面包含标题、内容、标签等字段。
用户修改后点击"保存"，系统更新数据。
功能：内容编辑
触发条件：
输入：
处理逻辑：
输出：
- • 成功：编辑表单页面（包含标题、内容、标签字段）
数据变更：
结构化有什么好处？
**AI能理解** - 可以自动检查PRD完整性
**开发能快速定位** - 想看什么直接跳
**测试能直接转用例** - 输入输出定义清楚
### 特征2：可追溯——每个需求都有来源和决策依据
传统PRD最大的问题：**你不知道为什么要做这个需求。**
开发会问："为什么要加这个字段？"
你只能说："产品需要。"
但为什么产品需要？用户场景是什么？不加会怎样？
这些信息在传统PRD里往往缺失。
**AI时代的PRD，每个需求都应该有清晰的来源。**
示例：
需求：增加"标签"字段
需求来源：
- • 用户访谈（2024-06-10，用户A/B/C）
- • 用户原话："我想给内容分类，但现在只能用文件夹，不够灵活"
业务目标：
数据支撑：
不做的后果：
方案选择：
参考资料：
这样写有什么好处？
**开发理解为什么要做** - 不是产品拍脑袋
**方案有理有据** - 可以讨论和挑战
**后续可复盘** - 上线后验证假设
### 特征3：动态更新——需求变了，文档秒级同步
传统PRD是"一次性"的：
- 写完→评审→开发→上线
- 中间改需求，手动更新文档
AI时代的PRD该是"动态"的：
- 需求变了，AI自动识别影响范围
- 自动更新相关章节
- 自动通知相关人
示例：
[需求变更]
原需求：标签最多5个
新需求：标签最多10个
[AI自动识别影响]
[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. What - 做什么
【注意】
**效果：** 5分钟生成决策层初稿。你只需要审核和调整。
### Step 2：AI生成方案层（10分钟）
**传统方式：** 自己想方案，画流程图，花1天
**AI方式：** AI生成多个方案对比
**Prompt：**
基于决策层信息，生成方案层部分。
【输入】
[粘贴决策层内容]
【输出要求】
1. Where - 功能入口
2. When - 实施计划
3. How - 解决方案
4. How much - 成本评估
【注意】
**效果：** 10分钟生成方案对比。你只需要选最合适的方案。
### Step 3：AI生成实现层（15分钟）
**传统方式：** 手动写功能描述、画流程图、整理数据字段，花2-3天
**AI方式：** AI生成结构化文档
**Prompt：**
基于方案层信息，生成实现层部分。
【输入】
[粘贴方案层内容]
【输出要求】
1. 功能详细设计
功能A：[功能名称]
触发条件：
输入：
处理逻辑：
输出：
异常处理：
2. 数据结构设计
3. 接口定义
接口1：创建内容
4. 页面交互
页面1：列表页
【注意】
**效果：** 15分钟生成实现层初稿。你只需要补充业务细节。
### Step 4：AI做完整性检查（5分钟）
**传统方式：** 自己检查，经常遗漏
**AI方式：** AI做checklist检查
**Prompt：**
对以下PRD进行完整性检查。
【输入】
[粘贴完整PRD]
【检查清单】
【输出】
**效果：** 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"
}
}
3.4 页面交互
页面：列表页
布局：
[搜索框] [筛选] [新建按钮]
--------------------------
[内容卡片1]
[内容卡片2]
[内容卡片3]
--------------------------
[分页]
元素：
交互：
异常状态：
3.5 验收标准
附录
A. 参考资料
B. 变更记录
C. 待确认问题
六、3个关键建议
建议1：别让AI替你思考
AI能帮你生成文档框架。
但不能替你做判断：
AI是助手，你是决策者。
建议2：PRD要持续迭代，不是一次性文档
需求会变。
PRD也要跟着变。
用AI降低更新成本：
建议3：PRD要给不同角色看不同内容
别一份PRD打天下：
用AI生成不同版本的PRD。
最后说几句
做了10年产品，我越来越觉得：
PRD不是目的，是工具。
PRD的目的是：
AI不能替你想清楚需求。
但能帮你更快把想法变成文档。
PRD 2.0的核心价值：
想获得完整的腾讯PRD模板，关注公众号"Kris产品成长之路"，回复：
PRD模板
我发你完整版。
你的PRD现在什么样？遇到过什么痛点？评论区聊聊。
这篇文章对你有帮助，分享给你的产品经理朋友，一起升级到PRD 2.0。
粤ICP备14082021号
免费POC，
零成本试错
