写PRD的痛苦，每个产品经理都懂
你脑子里有一个好想法。
用户痛点清晰、解决方案明确、商业价值可算。但当你打开文档编辑器，面对空白页面，突然不知道从哪下笔。
写太细？开发说你过度设计了。写太粗？设计说没法做。给领导看？领导问"你怎么没考虑XXX场景"。
PRD不是日记，也不是脑暴记录。它是一份让一群人朝着同一个方向干活的说明书。写得好，项目顺；写得烂，返工三次起步。
这个模板解决的就是这件事——把你脑子里的那团想法，变成一份结构完整、细节充分、开发和设计都能看懂的PRD。
核心模板：PRD自动生成
把下面这段复制到 ChatGPT 或 Claude：
你是一位资深产品经理，擅长写清晰、可落地的产品需求文档（PRD）。请根据以下信息帮我生成一份完整的PRD。
【产品/功能名称】
[一句话描述你要做什么]
【目标用户】
[谁会用这个功能？尽量具体，如：25-35岁一线城市白领]
【用户痛点】
[用户遇到了什么问题？为什么现有方案不够好？]
【核心价值主张】
[这个功能解决了什么？对用户有什么直接好处？]
【功能范围】（MVP范围）
1. [功能点1]
2. [功能点2]
3. [功能点3]
[列出你认为的核心功能，不用完美]
【非功能需求】（如有）
- 性能要求：[如：页面加载<2秒]
- 兼容性：[如：支持iOS 15+/Android 10+]
- 安全性：[如有特殊要求]
【约束条件】
- 上线时间：[如：6周内]
- 团队资源：[如：1前端+1后端+1设计]
- 技术限制：[如有]
请输出一份完整的PRD文档，包含以下章节：
## 1. 概述
- 背景与目标（为什么要做这个）
- 成功指标（怎么衡量做成功了）
## 2. 用户画像与场景
- 核心用户画像（1-2个）
- 用户使用场景（按用户旅程描述：触发→行为→结果）
## 3. 功能需求详述
对每个功能点，按以下格式描述：
- 功能名称
- 用户故事（As a [用户], I want to [行为], so that [价值]）
- 前置条件
- 主流程（步骤1,2,3...）
- 异常流程（出错时怎么处理）
- 界面元素说明（按钮、文案、布局建议）
- 数据字段（需要存储/展示的字段及类型）
## 4. 信息架构
- 页面/模块之间的关系
- 导航结构
## 5. 交互说明
- 关键页面的交互细节（动画、跳转、状态变化）
- 空状态/加载中/错误状态的展示
## 6. 数据埋点需求
- 需要追踪的关键事件
- 每个事件的参数
## 7. 非功能需求
- 性能指标
- 安全与权限
- 兼容性要求
## 8. 排期与里程碑
- 建议的开发阶段划分
- 关键节点
## 9. 风险与待定事项
- 已知的技术风险
- 需要进一步确认的问题
格式要求：
- 使用Markdown格式
- 语言简洁，避免模糊表述（不要用"大概""可能"）
- 每个功能点都要有异常流程
- 如果某些信息缺失，用「待确认」标注并说明需要谁来决定
快速版（3分钟搞定框架）
来不及填那么多信息？用这个精简版先出骨架：
我是一个产品经理，想做一个[产品/功能名称]。
核心信息：
- 目标用户：[一句话]
- 解决的问题：[一句话]
- 核心功能：[3个功能点]
请帮我生成一份PRD大纲，包含：
1. 产品概述
2. 用户场景
3. 功能列表（含优先级：P0/P1/P2）
4. 信息架构
5. 关键交互说明
6. 数据埋点
7. 风险与待定
每个章节写2-3句话概要，不需要展开细节。
场景变体
变体一：功能迭代PRD
不是从零做产品，而是在现有产品上加新功能：
在上面的模板基础上，额外补充以下信息：
【现有产品背景】
- 产品名：[名称]
- 当前版本：[vX.X]
- 这个功能在现有产品中的位置：[哪个模块/页面]
【改动范围】
- 新增页面：[是/否，如有则描述]
- 修改现有页面：[列出]
- 修改接口：[如有]
- 不影响的部分：[说明]
额外要求：
- 在PRD中标注「新增」「修改」「删除」三类改动
- 对修改的部分，说明旧逻辑和新逻辑的差异
- 给出灰度发布建议（先对多少用户开放）
变体二：B端后台需求
B端产品和C端很不一样，用户少但逻辑复杂：
在上面的模板基础上，替换以下字段：
【目标用户】
- 角色：[如：运营人员 / 客服 / 仓库管理员]
- 使用频率：[每天用 / 偶尔用 / 一次性]
- 技术水平：[专业 / 一般 / 新手]
【业务流程】
[描述这个功能涉及的业务流转，如：申请→审批→执行→验收]
额外要求：
- 每个操作要有权限控制说明（谁能看、谁能改、谁能删）
- 列表页要有筛选、排序、分页的详细说明
- 表单页要有校验规则（必填/格式/长度）
- 操作日志要记录哪些字段
- 批量操作的边界条件（一次选100个和选10000个有什么不同）
变体三：AI功能需求
如果你的产品里要加AI能力，这个变体专门针对：
在上面的模板基础上，额外补充：
【AI能力描述】
- AI做什么：[如：智能推荐 / 自动分类 / 文本生成]
- 输入是什么：[用户提供的数据]
- 输出是什么：[给用户的结果]
- 准确率要求：[如有]
额外要求：
- 描述AI结果的展示方式（置信度、解释、人工覆盖入口）
- 冷启动方案（新用户/无数据时怎么办）
- 反馈机制（用户怎么告诉AI"这个不对"）
- 成本控制（每次调用大概花多少钱，要不要限频）
使用技巧
先写用户故事，再写功能列表。 很多PM写PRD的顺序反了——先列一堆功能点，再回头编用户场景。正确顺序是先想清楚"谁在什么情况下用什么解决问题"，再从场景里自然推导出功能。
异常流程比正常流程更重要。 开发最怕的不是功能复杂，而是"没说到"。正常流程人人都会写，但断网了怎么办、数据为空怎么办、权限不足怎么办——这些才是PRD拉开差距的地方。
用「待确认」代替模糊词。 不要写"可能需要"“大概这样”。写「待确认：由XX在XX日期前决定」。这样既不会卡住文档，也不会让开发猜。
让设计先看信息架构。 PRD的信息架构章节就是设计的起点。在写详细功能之前，先把页面关系图画出来，设计师看一眼就知道整体结构对不对。
PRD不是一次性文档。 开发过程中有新发现，随时更新PRD。但记住：改了就要通知到所有人。一个过时的PRD比没有PRD更糟糕。
效果示例
输入：
【产品/功能名称】
商品评价智能摘要
【目标用户】
淘宝买家，浏览商品评价的用户
【用户痛点】
商品评价动辄几百上千条，用户没时间一条条看。差评集中在几个点上，好评也重复说同样的东西。
【核心价值主张】
用AI把海量评价浓缩成几条关键信息，让用户3秒内了解商品真实口碑。
【功能范围】
1. 自动提取评价中的高频关键词
2. 生成正面/负面评价摘要
3. 展示评价分布（好评率、中评率、差评率）
4. 用户可点击摘要跳转到对应评价
【约束条件】
- 上线时间：4周
- 团队：1前端+1后端+1设计+1算法
- 技术限制：使用现有NLP模型，不自训练
AI输出（摘要）：
1. 概述
- 背景：用户浏览商品评价时信息过载，平均需要3分钟才能从数百条评价中提取有效信息。
- 目标：将评价阅读时间缩短至30秒以内，提升转化率和用户满意度。
- 成功指标：评价页停留时间↓30%，含评价的商品转化率↑5%，用户评价摘要点击率>40%。
2. 用户画像与场景
- 画像：小美，28岁，网购频率高，习惯先看评价再下单，但经常看完放弃。
- 场景：小美在商品详情页 scrolling 到评价区 → 看到密密麻麻的评价 → 点"全部评价" → 翻了十几条 → 关掉了页面。
- 新场景：小美看到评价摘要 → “材质透气性一般，但做工精细” → 3秒做出判断 → 继续浏览或下单。
3. 功能需求详述
3.1 评价智能摘要
- 用户故事：作为一个买家，我希望快速看到评价的核心观点，这样我不用翻几百条评价就能了解商品优缺点。
- 主流程：用户打开商品评价区 → 顶部显示摘要卡片 → 摘要分为「好评聚焦」和「差评聚焦」两个Tab → 每个Tab展示3-5条AI生成的摘要句。
- 异常流程：评价数量<10条时，不展示摘要，显示"评价数量较少"提示。
- 数据字段：商品ID、评价总数、摘要文本数组、生成时间戳。
3.2 评价情感分布
- 主流程：摘要下方展示饼图/条形图，显示好评/中评/差评比例。
- 交互：点击某个颜色区块，下方列表过滤显示对应情感的评价。
- 异常流程：情感分布过于均匀（各占30%-40%）时，不展示分布图，改为文字描述"评价较为分散"。
4. 数据埋点
review_summary_viewed：摘要卡片曝光（参数：item_id, summary_version）review_summary_click：点击摘要（参数：item_id, summary_type: positive/negative）review_summary_jump：从摘要跳转到评价（参数：item_id, review_id）review_sentiment_filter：筛选情感评价（参数：item_id, sentiment: pos/neutral/neg）
5. 风险与待定
- 待确认：摘要生成延迟是否可接受？（当前NLP模型推理耗时约2秒）—— 需要算法团队评估
- 待确认：摘要的更新频率？（每次用户访问都重新生成 vs 缓存TTL）—— 待定
- 风险：极端情况下AI可能误判情感（如反讽评价"这质量真是绝了"），需设置人工审核入口
结果： 这份PRD给了开发清晰的功能边界和异常处理方案，设计师可以直接从中提取页面结构，测试团队也能据此编写用例。原本需要3轮沟通才能对齐的内容，一份PRD就搞定了。
PRD自检清单
每次写完PRD，花2分钟过一遍这个清单：
- 每个功能都有用户故事吗？（没有用户故事的 fonction 不要写）
- 每个功能都有异常流程吗？（正常流程人人都会写）
- 优先级标注了吗？（P0/P1/P2，别把所有事都标成P0）
- 数据字段定义清楚了吗？（类型、长度、是否必填）
- 界面元素有具体描述吗？（不要只写"一个按钮"，写"一个蓝色的确认按钮，位于表单右下角"）
- 「待确认」事项都标注了决策人和截止时间吗？
- 埋点方案写了吗？（上线后没数据，等于盲人摸象）
什么时候不该用
- 你只是想要一个功能点子。 这个模板是写PRD的，不是 brainstorming 工具。如果你还在想"要不要做"，先用 brainstorming-prompt。
- 功能极其简单。 如果只是加一个"关于我们"页面，不需要PRD。直接跟设计师说一声就行。
- 你没有目标用户信息。 PRD的灵魂是用户场景。如果你连谁在用都不知道，AI也帮不了你。先做用户调研。
进阶用法
PRD + 技术方案联动。 PRD写完后，把功能需求章节复制给技术团队，让他们基于PRD写技术方案。PRD里的异常流程和数据字段，就是技术方案的输入。
PRD + 测试用例联动。 QA团队可以直接从PRD的功能需求和异常流程中提取测试用例。正常流程对应正向用例，异常流程对应边界用例。
PRD + 设计稿联动。 把PRD的信息架构章节发给设计师，让她先出页面流程图。流程图画完再出高保真，比直接画页面快得多。
💡 下次接到新需求，别急着打开文档编辑器。先跑一遍这个模板，拿到PRD初稿再手动调整。你会发现，原来写PRD也可以很快。