上周，一个在阿里做产品的朋友发朋友圈：
“写了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分钟完成全面检查，发现遗漏和矛盾。
### 时间对比
| 环节 | 传统方式 | 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模板。
### 模板结构
`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 验收标准
| 功能 | 验收标准 | 验收方法 |
| — | — | — |
| 创建内容 | 点击提交后2秒内完成 | 性能测试 |
| 搜索 | 输入关键词300ms内返回结果 | 性能测试 |
| 权限 | 非创建者无法编辑 | 功能测试 |
* * *
## 附录
### A. 参考资料
* • 用户访谈记录：[链接]
* • 竞品分析：[链接]
* • 数据报告：[链接]
### B. 变更记录
| 版本 | 日期 | 变更内容 | 变更人 |
| — | — | — | — |
| v1.0 | 2024-06-14 | 初始版本 | [姓名] |
### 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. 渲染编辑表单
**输出：**
* • 成功：编辑表单页面（包含标题、内容、标签字段）
* • 失败：权限错误提示页面
**数据变更：**
| 字段 | 类型 | 必填 | 说明 |
| — | — | — | — |
| title | string | 是 | 标题，不超过50字 |
| content | text | 是 | 正文内容 |
| tags | array | 否 | 标签，最多5个 |
`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]
**输出：**
* • 成功：[描述]
* • 失败：[描述]
**异常处理：**
| 异常情况 | 处理方式 | 提示信息 |
| — | — | — |
| 权限不足 | 阻止操作 | “您没有权限” |
| 网络异常 | 重试3次 | “网络异常” |
## 2. 数据结构设计
| 字段名 | 类型 | 长度 | 必填 | 默认值 | 说明 |
| — | — | — | — | — | — |
| id | int | – | 是 | 自增 | 主键 |
| title | string | 50 | 是 | – | 标题 |
## 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 验收标准
| 功能 | 验收标准 | 验收方法 |
| — | — | — |
| 创建内容 | 点击提交后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的核心价值：
* • 让你有更多时间思考需求本身
* • 而不是在文档格式上浪费时间
