夜雨聆风“作者：阿钱适用范围：通用大模型（GPT-4/Claude/文心/通义/Kimi等）使用建议：将模板中的【】内容替换为实际项目信息，执行前先明确AI的角色定位
模板1：需求背景与目标定义
用途：从模糊的业务诉求中，快速生成结构化的需求背景、目标与成功指标。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 【角色】你是一位资深产品战略顾问，擅长从业务目标倒推产品需求。【输入】- 业务方原始诉求：【粘贴业务方的一段原话或会议纪要】- 当前产品现状：【简要描述现有功能或痛点】- 公司战略大背景：【如：降本增效、用户增长、合规改造等】【任务】请输出以下内容：1. 需求背景（用3-5句话说明为什么要做这件事，引用真实场景或数据）2. 核心用户与场景（列出最多3个典型场景，每个场景包含“谁、在什么情况下、想达成什么目标”）3. 业务目标（用具体、可衡量的指标描述，如“将XX转化率提升5%”）4. 成功标准（给出上线后判断项目成功的KPI，区分“必达”和“理想”）【输出格式】采用二级标题分段，语言简洁，每条不超过3行。
模板2：竞品功能分析
用途：针对某个具体功能，快速生成竞品对比分析，支撑PRD中的“差异化设计”章节。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 【角色】你是一位AI产品分析师，擅长从用户体验和功能架构维度拆解竞品。【输入】- 竞品列表：【列出2-4个竞品名称，如：钉钉AI助理、飞书智能伙伴、企业微信AI助手】- 功能范围：【需要分析的具体功能，如：智能客服的情绪识别】- 分析维度：【可选：功能入口、交互流程、准确率、收费模式、用户评价】【任务】请按以下结构输出竞品分析报告：1. 各竞品功能实现方式对比（表格形式，对比维度包括：功能完整性、交互易用性、技术路线、商业模式）2. 共性与差异总结（提炼2-3个行业共识，以及1-2个差异化亮点）3. 对自身产品的启示（直接给出“可借鉴”、“需规避”、“可超越”三项建议）【输出要求】- 若信息不足，请明确标注“根据公开资料推断，需实测验证”- 每条启示需附上简要理由
模板3：用户故事与场景枚举
用途：快速生成覆盖正常、异常、边界场景的用户故事，用于PRD的需求描述章节。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 【角色】你是一位用户体验专家，擅长以用户为中心设计场景用例。【输入】- 功能名称：【如：微信支付“亲属卡”】- 目标用户角色：【如：子女（赠卡方）、父母（收卡方）、平台运营】- 核心操作流程：【简要描述用户要完成的核心任务】【任务】请按以下格式输出用户故事与场景：1. 正常场景（Happy Path）- 列出3个最典型场景，格式：“作为【角色】，我想【做某事】，以便【达成目的】”2. 异常场景（Exception）- 列出至少4个，包括：网络异常、权限不足、数据为空、重复操作等3. 边界场景（Edge Case）- 列出至少3个，包括：极端数值、并发操作、特殊字符等4. 优先级建议（对上述场景按P0/P1/P2分级，并给出理由）【额外要求】- 每个场景后附上简要的“系统应如何响应”- 用emoji标注场景类型（✅正常、⚠️异常、🔲边界）
模板4：功能性需求（FR）生成
用途：基于用户故事，生成结构化的功能需求列表，可直接放入PRD的“功能需求”章节。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 【角色】你是一位技术产品经理，擅长将用户场景转化为可落地的功能点。【输入】- 功能模块名称：【如：智能客服-情绪识别模块】- 核心用户场景清单：【可使用模板3的输出结果】- 技术约束：【可选，如：必须兼容iOS/Android、单次请求响应小于200ms】【任务】请生成一份功能需求列表，按以下层级组织：1. 模块概述（一句话说明本模块的核心价值）2. 功能点清单（表格形式，列名：功能ID、功能名称、功能描述、输入、输出、触发条件、优先级）3. 业务规则（关键逻辑用 if-then 或 状态机 描述，例如：若置信度 < 0.7，则回退到默认策略）4. 依赖与前置条件（列出本功能依赖的其他系统、数据或环境）【输出格式】- 使用Markdown表格- 优先级：P0（必须有）、P1（应该有）、P2（可以有）- 语言精炼，每条功能描述不超过2行
模板5：非功能性需求（NFR）检查清单
用途：AI最容易遗漏的部分，专门用于生成和检查非功能需求（性能、安全、可用性等）。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 【角色】你是一位系统架构师，关注产品的性能、安全、可维护性。【输入】- 功能类型：【如：实时音视频通话、后台数据报表、用户登录】- 预估用户量/并发量：【如：日活10万，峰值QPS 500】- 合规要求：【可选，如：GDPR、等保三级、个人信息保护法】【任务】请按以下维度生成非功能性需求清单，每条需求需包含“具体指标”和“验收方法”：1. 性能（响应时间、吞吐量、并发数）2. 可用性（SLA要求、故障恢复时间）3. 安全性（数据加密、权限控制、日志审计）4. 可扩展性（水平扩容方案、数据库分片策略）5. 可维护性（日志规范、监控告警、配置热更新）6. 合规性（数据留存期限、用户同意授权、跨境传输）【输出格式】- 每个维度下以“需求ID: 描述（指标：xxx，验收：xxx）”列表输出- 对于无法量化的需求，请标注“待与架构师确认”
模板6：验收标准撰写
用途：为每个功能点生成Given-When-Then格式的验收标准，可直接交付给测试团队。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 【角色】你是一位QA工程师，擅长编写可执行的验收用例。【输入】- 功能点名称：【如：用户通过微信扫码登录Web端】- 前置条件：【如：用户已注册且账号状态正常】- 功能描述：【一段简要描述】【任务】请以 GIVEN-WHEN-THEN 格式输出验收标准，覆盖以下测试类型：1. 功能正确性（至少3条）2. 异常处理（至少2条，如输入错误、网络超时）3. 边界值（至少1条，如密码长度边界）4. 兼容性（如适用：不同浏览器/设备/分辨率）【格式示例】- GIVEN 用户已登录微信客户端- WHEN 用户在PC端点击“微信扫码登录”并扫描二维码- THEN 系统应在3秒内完成认证，并跳转到用户主页【额外要求】- 每条验收标准必须独立、可自动化测试- 标注每条标准的优先级（P0/P1/P2）
模板7：数据埋点需求
用途：生成PRD中必备的数据埋点清单，用于上线后的价值验证。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 【角色】你是一位数据产品经理，精通指标体系建设。【输入】- 业务目标及成功指标：【从模板1获取】- 核心用户路径：【用户从进入功能到完成目标的关键步骤】- 已有埋点规范：【如：事件命名规则、属性字段标准】【任务】请输出一份数据埋点需求文档：1. 页面浏览埋点（列出所有需要统计PV/UV的页面或弹窗）2. 点击事件埋点（每个可点击元素，包括按钮、链接、卡片）3. 业务成功埋点（如：情绪识别调用次数、准确率上报、转人工率）4. 用户属性埋点（需要上报的用户特征，如会员等级、设备类型）5. 埋点清单表格（列名：事件ID、事件名称、触发时机、必传属性、示例）【输出要求】- 区分“产品必需”和“分析可选”两类埋点- 给出核心漏斗的埋点串联逻辑（如：曝光→点击→成功→转化）
模板8：PRD 全文草稿生成
用途：整合以上所有模板的产出，一键生成结构完整的PRD初稿（最常用）。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 【角色】你是一位资深AI产品经理，擅长撰写结构清晰、逻辑严密的PRD。【输入】（请尽可能提供以下信息，缺失部分AI会留空并提示补充）- 需求名称：【XX功能/模块】- 版本号：【V1.0】- 作者/日期：【自动填充】- 需求背景与目标：【可用模板1的输出】- 竞品分析摘要：【可用模板2的输出】- 用户故事与场景：【可用模板3的输出】- 功能需求列表：【可用模板4的输出】- 非功能需求：【可用模板5的输出】- 验收标准概要：【可用模板6的关键条目】- 数据埋点需求：【可用模板7的输出】- 附录（原型链接、参考资料等）：【可选】【任务】请按以下标准PRD结构生成完整文档，每个章节必须有内容（信息不足处用【待补充：具体问题】标注）：1. 文档信息（版本历史、修订人）2. 需求概述（背景、目标、成功指标）3. 范围（In Scope / Out of Scope）4. 用户与场景（角色、用户故事、使用流程图）5. 功能需求（功能列表+业务规则+状态流转）6. 非功能需求（性能、安全、可用性等）7. 验收标准（关键流程的Given-When-Then）8. 数据埋点（埋点清单）9. 风险与依赖（技术风险、资源依赖、合规风险）10. 附录与参考资料【输出要求】- 使用Markdown标题层级，排版整洁- 每个章节末尾留出“审批记录”行（产品、研发、测试、设计签字栏）- 全文使用正式、无废话的商务语言
使用建议与进阶技巧
1. 先思考，后粘贴不要直接拿模糊的想法去套模板。先花10分钟手写或口述你的核心判断（要解决什么问题、为什么重要、怎么算成功），再交给AI。AI生成的质量与你输入的清晰度成正比。 2. 迭代式对话，而非一次性生成对AI的输出多轮追问： • “这里为什么这样写？有没有依据？” • “如果技术资源砍半，这个PRD里哪些可以砍掉？” • “请站在研发的角度，指出本PRD中含糊不清的地方。” 3. 建立团队提示词库把你们团队最成功的PRD反向拆解，提取出适合你们业务语境的提示词模板。定期复盘哪些提示词效果好，形成团队SOP。 4. 警惕AI幻觉对AI生成的验收标准、性能指标、竞品数据，务必人工核实。AI很容易编造出“看起来正确”的假数据。 5. 最后的PRD永远是人负责无论AI生成了多漂亮的文档，PRD的“责任人”签名必须是你。读一遍、改一遍、再读一遍，确保每一个判断都是你认可的。 📚 往期干货推荐
