AI产品PRD模板
很多刚接触产品工作的人，一听到「写 PRD」就觉得这是一件需要丰富经验才能做的事。甚至有人觉得模板会限制创造力，不如自由发挥。但实际经验告诉我们恰恰相反：模板不是限制创造力，而是让你不遗漏关键信息。当你面对一个 AI 产品需求时，模型选型、Prompt 管理、输出质量控制这些维度，如果没有结构化框架，非常容易在写需求时漏掉——而这些问题在开发后期才会暴露，代价远高于前期多花半小时填写文档。
本文提供一套完整的 AI 产品 PRD 模板，覆盖 10 个核心模块，每个模块都有填写说明和示例。无论你是刚转行做产品经理的新人，还是第一次写 AI 产品需求的工程师，都可以直接套用。
为什么 AI 产品需要专属 PRD 模板
传统产品的 PRD 围绕「用户旅程」展开：用户从 A 页面到 B 页面，点击某个按钮，完成某个任务。产品经理需要描述清楚页面交互、字段校验、异常处理，基本就能覆盖大部分需求。
AI 产品多了一个关键角色：模型。需求文档不再只是「用户 → 产品」的二元关系，而是「用户 → 产品 → 模型 → 产品 → 用户」的三元交互。这带来了几个传统 PRD 不会遇到的问题：
| 维度 | 传统产品 PRD | AI 产品 PRD |
|---|---|---|
| 核心对象 | 用户界面与交互流程 | 用户界面 + 模型能力 + Prompt 策略 |
| 输出确定性 | 输入相同则输出相同 | 同一输入可能产生不同输出，需要定义质量边界 |
| 异常处理 | 网络错误、数据校验失败 | 模型幻觉、超时、Token 超限、输出格式异常 |
| 迭代方式 | 功能上线后相对稳定 | Prompt 和模型版本需要持续调优，要有版本管理 |
| 成本结构 | 主要是开发和运维成本 | 每次 API 调用都有 Token 成本，需要监控用量 |
| 评估标准 | 功能是否可用、交互是否流畅 | 除了可用，还需要评估输出质量、一致性、安全性 |
这些差异意味着，如果你在写 PRD 时只考虑功能层面，不考虑模型层面的需求，开发团队就可能在上线后才发现输出质量不达标、成本超出预算、或者模型响应时间过长影响体验。
完整 PRD 模板：10 个模块
以下模板按模块组织，每个模块包含三部分内容：填写说明告诉你这个模块要写什么，填写要点列出常见的坑和注意事项，示例给出一段可直接参考的填写内容。
模块一：产品概述
填写说明： 用 3-5 句话说清楚这个产品是什么、为谁解决什么问题、核心价值主张是什么。不需要长篇大论，重点是让任何读到这份文档的人，在 30 秒内理解你要做什么。
填写要点：
- 避免使用「打造全方位智能解决方案」这类空洞描述
- 要明确提到目标用户和核心场景
- 如果有参考竞品，可以简要提及差异化定位
示例：
本产品是一款面向跨境电商卖家的 AI 商品文案生成工具。用户输入商品基本信息（名称、类目、卖点），系统自动生成适配 Amazon、Shopify 等不同平台的多语言商品描述。核心价值是将文案撰写时间从 30 分钟缩短到 2 分钟，同时支持 8 种语言，帮助卖家快速拓展海外市场。
模块二：产品目标
填写说明： 列出这个产品或功能要达到的可量化目标。建议使用 SMART 原则——具体、可衡量、可实现、相关、有时限。
填写要点：
- 至少包含一个核心指标（North Star Metric）
- 区分「必须达成」和「期望达成」的目标
- AI 产品建议额外加上模型效果相关指标（准确率、生成满意度等）
示例：
| 目标类型 | 目标描述 | 衡量指标 | 目标值 | 截止时间 |
|---|---|---|---|---|
| 核心指标 | 提升卖家文案产出效率 | 单篇文案生成时间 | ≤ 30 秒 | 上线后 2 周 |
| 质量指标 | 生成文案可用率 | 用户无需大幅修改即可使用的比例 | ≥ 75% | 上线后 4 周 |
| 商业指标 | 付费转化 | 免费用户转付费用户比例 | ≥ 8% | 上线后 8 周 |
| 成本指标 | 控制生成成本 | 单篇文案平均 Token 成本 | ≤ $0.02 | 上线即生效 |
模块三：目标用户
填写说明： 明确描述产品的目标用户是谁。建议用「用户画像」的方式，包含基本属性、使用场景、核心痛点、当前替代方案。
填写要点：
- 不要写「所有互联网用户」这种过于宽泛的描述
- 区分主要用户和次要用户
- AI 产品要考虑用户的技术背景——用户是否理解 AI 的概念，会影响你的交互设计
示例：
主要用户： 跨境电商中小卖家，年营收 $10万-$500万，团队 2-10 人，通常在 Amazon、Shopify 等平台经营。技术背景较弱，日常使用翻译工具+自己的英文水平撰写商品文案。核心痛点是文案质量不稳定、多语言翻译成本高、新品上架速度慢。当前替代方案包括雇佣外包写手（$5-15/篇）、使用 ChatGPT 手动生成（需要自己写 Prompt，质量不稳定）。
次要用户： 跨境服务商和代运营公司，管理多个店铺，需要批量生成文案，对 API 接入和批量操作有需求。
模块四：用户故事
填写说明： 用标准格式描述用户的使用场景：「作为 [某类用户]，我希望 [做某件事]，以便 [达到某个目的]」。每个用户故事要附带验收标准。
填写要点：
- 先覆盖核心场景，再补充边缘场景
- AI 产品的用户故事要包含「对输出结果的操作」——用户不满意时如何调整
- 考虑首次使用和重复使用的差异
示例：
US-01： 作为一个跨境卖家，我希望输入商品名称和卖点后自动生成英文商品描述，以便快速上架新品。
- 验收标准：输入商品名称 + 3 个卖点关键词，30 秒内生成 150-300 词的英文描述，包含商品特点和卖点信息。
US-02： 作为一个跨境卖家，我希望可以对生成的文案进行调整（修改语气、长度、侧重点），以便获得更满意的结果。
- 验收标准：提供「更正式/更活泼」「更简洁/更详细」等调整选项，调整后 15 秒内返回新版本，保留上一版本供对比。
US-03： 作为一个跨境卖家，我希望生成的文案中不包含竞品品牌名和不实承诺，以便避免因违规被平台处罚。
- 验收标准：输出内容经过安全过滤，不包含已知竞品品牌名、不含「best」「#1」等绝对化用语、不含虚假功效承诺。
模块五：功能需求
填写说明： 按模块列出所有功能点，每个功能点包含功能描述、优先级、交互说明。建议用 P0/P1/P2 标注优先级。
填写要点：
- P0 是上线必须的，P1 是上线后第一个迭代要做的，P2 是可以延后的
- AI 产品需要额外标注与模型相关的功能（Prompt 模板、模型选择、输出后处理）
- 每个功能要考虑异常情况
示例：
| 编号 | 功能名称 | 优先级 | 功能描述 | 异常处理 |
|---|---|---|---|---|
| F-01 | 商品信息输入 | P0 | 用户填写商品名称、类目、卖点（最多 5 个关键词）、目标平台、目标语言 | 输入为空时提示必填；超过字数限制时截断并提示 |
| F-02 | AI 文案生成 | P0 | 调用大语言模型，基于输入信息生成商品描述 | 模型超时（>30s）提示重试；生成内容为空时自动重试 1 次；输出长度不足时补充生成 |
| F-03 | 文案调整 | P1 | 用户可对已生成的文案调整语气、长度、侧重点 | 调整后新内容与原内容差异过小时提示用户 |
| F-04 | 历史记录 | P1 | 保存用户生成过的所有文案，支持搜索和复制 | 历史数据保留 90 天；单用户最多保存 500 条 |
| F-05 | 批量生成 | P2 | 支持 CSV 导入商品信息，批量生成文案 | 单次批量上限 50 条；超过限制提示分批上传 |
模块六：页面需求
填写说明： 描述产品包含哪些页面，每个页面的核心元素和交互逻辑。如果是新功能，说明与现有页面的关系。
填写要点：
- 不需要在这个模块写详细交互稿，但要说清楚页面结构和关键元素
- AI 产品的页面要包含「生成中」状态和「结果展示」区域
- 考虑加载状态、空状态、错误状态的展示
示例：
页面 1：文案生成页（核心页面）
- 左侧：输入区域，包含商品名称（文本框）、类目（下拉选择）、卖点（标签输入，最多 5 个）、目标平台（单选）、目标语言（下拉选择）、「生成」按钮
- 右侧：结果区域，生成中显示进度动画和预计等待时间；生成完成后显示文案内容，顶部提供操作按钮（复制、导出、调整、重新生成）
- 空状态：右侧显示示例文案和操作引导
页面 2：历史记录页
- 列表展示，每条显示商品名称、生成时间、目标平台、语言
- 支持按关键词搜索、按时间筛选
- 点击进入详情页查看完整文案
模块七：数据需求
填写说明： 说明产品需要哪些数据支撑，包括用户输入数据、模型输出数据、业务统计数据。对于 AI 产品，还要说明训练/微调数据的收集策略。
填写要点：
- 明确数据的存储方式和保留期限
- AI 产品要规划数据飞轮——用户的使用数据如何反哺模型优化
- 注意数据隐私合规（GDPR、CCPA 等）
示例：
| 数据类型 | 内容 | 存储方式 | 保留期限 | 用途 |
|---|---|---|---|---|
| 用户输入 | 商品名称、类目、卖点、平台和语言偏好 | PostgreSQL | 永久（用户可删除） | 生成依据 + 分析用户偏好 |
| 模型输出 | 生成的文案内容、调整记录 | PostgreSQL | 90 天 | 展示给用户 + 质量分析 |
| 质量反馈 | 用户对文案的评分（满意/不满意）、修改幅度 | PostgreSQL | 永久 | Prompt 优化、模型评估 |
| Token 用量 | 每次调用的输入/输出 Token 数 | PostgreSQL + Redis 缓存 | 永久（聚合统计） | 成本监控、计费依据 |
| 用户行为 | 页面访问、功能使用频率 | ClickHouse | 180 天 | 产品分析、功能优化 |
模块八：验收标准
填写说明： 定义整个产品或功能模块上线前必须满足的条件。不同于用户故事的验收标准（那是针对单个功能的），这里是整体维度的验收。
填写要点：
- 包含功能验收、性能验收、安全验收、AI 效果验收
- AI 产品的效果验收要有量化指标，不能只写「输出质量好」
- 建议准备验收用的测试用例集
示例：
| 验收维度 | 验收条件 | 测试方法 |
|---|---|---|
| 功能完整性 | P0 功能全部可用，P1 功能完成度 ≥ 80% | 逐条对照功能清单验收 |
| 生成质量 | 100 条测试用例中，可用率 ≥ 75% | 使用预定义测试用例集，由 3 人独立评估 |
| 生成速度 | 平均生成时间 ≤ 15 秒（P95 ≤ 30 秒） | 压测工具模拟 100 并发 |
| 安全防护 | 输出内容不包含竞品品牌名、绝对化用语 | 使用敏感词库测试 50 组输入 |
| 成本控制 | 单篇文案平均成本 ≤ $0.02 | 统计 1000 次生成的 Token 消耗 |
| 异常处理 | 模型超时、API 错误时有合理的降级方案 | 模拟模型服务不可用，验证降级逻辑 |
模块九：非功能需求
填写说明： 描述产品在性能、安全、可用性、兼容性等方面的要求。这些需求不会直接体现在功能上，但直接影响用户体验和系统稳定性。
填写要点：
- AI 产品要特别关注响应时间和并发能力
- 出海产品要考虑多地域部署和 GDPR 合规
- 模型调用要有 fallback 策略
示例：
| 类别 | 需求描述 | 指标 |
|---|---|---|
| 性能 | 页面首屏加载时间 | ≤ 2 秒 |
| 性能 | 文案生成响应时间（不含模型调用） | ≤ 500ms |
| 可用性 | 系统整体可用性（含模型服务） | ≥ 99.5% |
| 安全 | 用户数据传输加密 | HTTPS + TLS 1.3 |
| 安全 | 用户数据隔离 | 多租户数据严格隔离 |
| 合规 | 数据隐私 | 符合 GDPR 要求，支持用户数据删除请求 |
| 兼容性 | 浏览器支持 | Chrome、Safari、Firefox、Edge 最新 2 个版本 |
| 国际化 | 界面语言 | 首发支持英文、中文，界面文案与生成内容分离 |
模块十：排期和里程碑
填写说明： 将开发工作拆分为可管理的阶段，每个阶段有明确的交付物和验收节点。
填写要点：
- AI 产品要预留 Prompt 调优和模型评估的时间
- 不要把所有工作都塞进一个阶段
- 建议为模型效果不达预期预留缓冲时间
示例：
| 阶段 | 时间 | 交付物 | 验收标准 |
|---|---|---|---|
| M1：基础架构 | 第 1-2 周 | 项目脚手架、数据库设计、用户系统 | 用户可注册登录 |
| M2：核心生成 | 第 3-4 周 | 商品信息输入 + AI 文案生成 + Prompt 模板 V1 | 可以生成基本文案，可用率 ≥ 60% |
| M3：效果优化 | 第 5-6 周 | Prompt 迭代、输出后处理、质量评估 | 可用率提升至 ≥ 75% |
| M4：体验完善 | 第 7-8 周 | 历史记录、文案调整、错误处理 | P1 功能完成，整体可用 |
| M5：上线准备 | 第 9 周 | 压测、安全扫描、验收测试 | 满足所有验收标准 |
| M6：正式发布 | 第 10 周 | 上线、监控告警、用户反馈收集 | 生产环境稳定运行 |
AI 产品特有的需求模块
以上 10 个模块适用于大多数产品。但 AI 产品还有几个特殊维度，需要在 PRD 中额外说明。如果遗漏这些内容，开发团队在实施时会频繁回来确认，拖慢整体进度。
模型选择与版本管理
你需要在 PRD 中明确：使用哪个模型（GPT-4o、Claude Sonnet、Gemini 等）、选择依据是什么、是否需要支持多模型切换、模型版本更新的策略。
| 考虑因素 | 说明 |
|---|---|
| 模型能力 | 不同模型在不同任务上表现差异明显，文案生成和代码生成的最佳选择可能不同 |
| 成本 | 不同模型的 Token 单价差异可达 10 倍以上 |
| 延迟 | 模型推理速度直接影响用户等待时间 |
| 可用性 | 需要考虑地域限制和服务稳定性 |
| 版本策略 | 模型提供商更新版本时，是自动跟随还是锁定版本 |
Prompt 管理
Prompt 是 AI 产品的「业务逻辑」，需要像代码一样管理。PRD 中要说明 Prompt 的存储方式、版本管理策略、A/B 测试方案。
建议包含的内容：
- Prompt 模板与代码分离，支持运营或产品人员独立修改
- Prompt 版本管理：每次修改有记录，支持回滚
- 变量管理：Prompt 中哪些部分是动态的（用户输入）、哪些是固定的（指令和约束）
- A/B 测试：不同 Prompt 版本的效果对比机制
输出质量控制
AI 模型的输出具有不确定性，PRD 中需要定义质量控制策略：
| 控制环节 | 措施 | 说明 |
|---|---|---|
| 输入预处理 | 用户输入清洗和标准化 | 去除特殊字符、标准化格式，减少模型误解 |
| 生成中 | 参数调优（temperature、top_p 等） | 创意类任务可调高 temperature，事实类任务应调低 |
| 输出后处理 | 格式校验 + 敏感词过滤 | 确保输出格式符合预期，过滤不当内容 |
| 用户反馈 | 满意度收集 + bad case 记录 | 形成数据飞轮，持续优化 Prompt 和模型选择 |
两个完整的案例
案例一：AI 客服助手
以下是一份 AI 客服助手 PRD 的关键模块填写示例。
产品概述：
面向 SaaS 企业的 AI 客服助手，接入企业知识库，自动回答用户的产品使用问题。目标是减少 60% 的人工客服工单量，将平均首次响应时间从 5 分钟缩短到 10 秒。
目标用户：
主要用户： SaaS 企业的终端用户，在使用产品时遇到问题需要帮助。技术水平参差不齐，描述问题时往往不够清晰。
次要用户： SaaS 企业的客服团队，负责审核 AI 回答质量、处理 AI 无法解决的问题、维护知识库内容。
核心用户故事：
US-01： 作为终端用户，我希望在遇到问题时直接提问并获得准确回答，以便快速解决问题继续工作。
- 验收标准：问题与知识库匹配时，10 秒内返回准确答案，答案引用知识库来源。
- 边缘场景：问题不在知识库范围内时，明确告知无法回答并提供转人工选项。
US-02： 作为客服人员，我希望可以查看 AI 的所有回答记录和用户满意度，以便持续优化知识库。
- 验收标准：提供回答记录面板，支持按满意度排序、按时间段筛选、标记 bad case。
AI 特有需求：
- 模型选择：Claude Sonnet，依据是长文本理解能力强、回答准确性高、成本适中。
- RAG 策略：知识库文档切片大小 500 字，相似度阈值 0.7，返回 Top-3 片段作为上下文。
- 安全策略：AI 不回答知识库以外的问题，不执行任何操作指令（如「帮我删除账号」），输出经过 PII 过滤。
- 降级策略：模型服务不可用时，自动切换到 FAQ 关键词匹配模式。
案例二：AI 周报生成器
以下是一份 AI 周报生成器 PRD 的关键模块填写示例。
产品概述：
面向项目经理和团队 leader 的 AI 周报生成工具。自动汇总团队成员本周的工作记录（来自 Jira、Git commit、日报等），生成结构化的团队周报。核心价值是将周报撰写时间从 1 小时缩短到 5 分钟。
产品目标：
| 目标类型 | 目标描述 | 衡量指标 | 目标值 |
|---|---|---|---|
| 效率指标 | 减少周报撰写时间 | 从开始撰写到完成的时间 | ≤ 5 分钟（原来平均 60 分钟） |
| 质量指标 | 周报信息完整度 | 覆盖团队成员工作项的比例 | ≥ 90% |
| 满意度 | 用户满意度 | 周报质量评分（1-5 分） | ≥ 4.0 |
核心用户故事：
US-01： 作为项目经理，我希望系统自动从 Jira 拉取团队成员本周完成的任务，以便我不需要逐一询问。
- 验收标准：授权 Jira 后，自动获取本团队成员本周状态变为「Done」的任务，按成员分组展示。
US-02： 作为项目经理，我希望 AI 将零散的工作记录整理成结构化的周报，以便直接发送给管理层。
- 验收标准：输出包含「本周完成」「进行中」「下周计划」「风险项」四个模块，语言简洁专业。
AI 特有需求：
- 模型选择：GPT-4o-mini，依据是任务以文本摘要为主、不需要复杂推理、成本敏感。
- Prompt 策略：不同输出模块使用不同 Prompt 模板——「本周完成」侧重简洁罗列，「风险项」侧重分析和判断。
- 数据源管理：支持 Jira、Git、自定义文本输入，每种数据源有独立的解析逻辑。
- 隐私处理：周报中不包含代码内容、不包含敏感项目信息，输出前经过信息过滤。
- 可编辑性：AI 生成的内容用户必须可以修改，修改后的版本作为正例反馈用于优化。
使用 PRD 模板的完整流程
这个流程有几个关键节点需要注意：
-
先想清楚再写文档。 在填写产品概述和目标之前，先花时间想清楚你要做什么、为谁做、为什么做。这个阶段的思考质量直接决定 PRD 的质量。
-
AI 相关需求不是可选项。 如果你的产品包含 AI 能力，模型选择、Prompt 管理、输出质量控制这三个模块必须填写。缺少这些信息，开发团队无法评估技术可行性。
-
评审环节要拉上工程师。 AI 产品的 PRD 评审，工程师的参与尤其重要——模型能力边界、技术可行性、成本估算这些维度，产品经理容易过于乐观。
PRD 各模块填写要点速查表
| 模块 | 核心问题 | 常见错误 | 建议篇幅 |
|---|---|---|---|
| 产品概述 | 做什么、为谁做、为什么做 | 描述过于抽象，没有具体场景 | 100-200 字 |
| 产品目标 | 成功长什么样 | 目标不可量化，缺少时间约束 | 3-5 个目标 |
| 目标用户 | 谁会使用 | 用户定义过宽，没有区分主次 | 1-3 个用户画像 |
| 用户故事 | 用户怎么用 | 缺少验收标准，遗漏边缘场景 | 5-15 个故事 |
| 功能需求 | 具体做什么 | 没有优先级，缺少异常处理 | 按 P0/P1/P2 分组 |
| 页面需求 | 界面长什么样 | 过度设计交互细节 | 按页面结构描述 |
| 数据需求 | 数据从哪来、怎么用 | 忽略数据隐私和保留策略 | 列出数据表 |
| 验收标准 | 怎样算完成 | 只有功能验收，缺少 AI 效果验收 | 按维度列出 |
| 非功能需求 | 系统要达到什么标准 | 忽略 AI 特有的性能和成本要求 | 按类别列出 |
| 排期里程碑 | 什么时候交付 | 没有预留 Prompt 调优时间 | 按阶段拆分 |
传统产品 PRD 与 AI 产品 PRD 完整对比
| 对比维度 | 传统产品 PRD | AI 产品 PRD |
|---|---|---|
| 需求核心 | 用户旅程和功能逻辑 | 用户旅程 + 模型能力 + Prompt 策略 |
| 输出描述 | 确定性描述（输入 A 得到输出 B） | 概率性描述（输入 A 得到质量在 X 范围内的输出） |
| 异常定义 | 网络错误、校验失败、权限不足 | 额外包含模型幻觉、超时、格式异常、成本超限 |
| 迭代重点 | 功能迭代为主 | Prompt 调优和模型升级是持续工作 |
| 评估指标 | DAU、转化率、留存率 | 额外需要生成质量评分、Token 成本、响应延迟 |
| 团队协作 | PM + 设计 + 前端 + 后端 | 额外可能需要 AI 工程师、Prompt 工程师、数据标注 |
| 风险管理 | 功能延期、技术风险 | 额外包含模型效果不达预期、成本失控、合规风险 |
PRD 质量检查清单
在提交 PRD 进入评审之前，对照以下清单逐条检查：
- 产品概述清晰：任何不了解背景的人，读完概述后能理解你要做什么
- 目标可量化：每个目标都有具体的数值指标和时间节点
- 用户画像具体：不是「所有用户」，而是有明确的属性、场景和痛点
- 用户故事完整：覆盖核心场景和主要边缘场景，每个故事都有验收标准
- 功能优先级明确：P0/P1/P2 标注清晰，P0 是上线必须的
- 异常处理覆盖：每个功能都考虑了异常情况和降级方案
- AI 需求不遗漏：模型选择、Prompt 管理、输出质量控制三个模块已填写
- 成本已评估：Token 成本、API 调用成本已估算，在预算范围内
- 数据合规已确认：涉及用户数据的存储、传输、删除策略已明确，符合 GDPR 等要求
- 验收标准可执行：验收标准有具体的测试方法和通过条件，不是「体验好」这种模糊描述
- 排期合理：预留了 Prompt 调优和模型效果评估的时间，有缓冲期
- 工程师已参与：技术可行性已与工程师确认，没有明显不可行的需求
写在最后
模板的价值不在于格式本身，而在于它帮你建立了一套思考框架。当你按照这 10 个模块逐一填写时，你实际上在系统性地思考产品的方方面面——从用户需求到技术实现，从功能逻辑到成本控制，从上线标准到迭代策略。
对于 AI 产品来说，这种系统性尤其重要。模型能力的不确定性、输出质量的波动性、Token 成本的累积性，这些特点决定了你不能像传统产品那样只关注功能层面。模型选型、Prompt 管理、输出质量控制——这三个 AI 特有的维度，是你在写 PRD 时必须额外投入精力的地方。
最后一个建议：不要等到 PRD 写完才给工程师看。在填写过程中，遇到不确定的技术可行性问题，随时和工程师沟通。AI 产品的技术边界不像传统产品那样明确，提前沟通可以避免写出「看起来很好但实现不了」的需求。
参考资料
- A Proven AI PRD Template by Miqdad Jaffer (Product Lead @ OpenAI) - Product Compass
- Write a PRD for a Generative AI Feature - Reforge
- AI PRD Template - Product School
- AI产品的需求文档怎么写，与传统产品的PRD有何异同 - 人人都是产品经理
- AI产品的PRD应该怎么写？ - 人人都是产品经理
- PRD Template for AI Agent - MakeMyPRD
- What is a Product Requirements Document (PRD)? - Atlassian
- 12x PRD Examples & Real PRD Templates - Hustle Badger