AI产品PRD
面向 AI 产品的不确定性治理文档：不只写功能清单，还要持续记录模型与 Prompt 变化、显式技术权衡、Bad Case 闭环、评测权重、人机介入位置和 PM 的关键判断。
简介
AI产品PRD 是传统产品需求文档在 AI 原生产品场景下的升级形态。传统软件 PRD 的底层假设是“程序是确定的”：输入 A，按照代码逻辑必然输出 B；因此 PRD 主要写清楚目标用户、功能流程、边界状态、交互细节和验收标准。但 AI 产品的底层假设不同：模型是概率系统，同一个输入可能因为模型版本、上下文、Prompt、知识库、温度参数或用户表达差异而产生不同输出。
2026-05-18-woshipm-ai-product-prd 用一个医药 AI 翻译 Agent 的真实迭代说明了这种差异：原文 “Phase III clinical trial” 被 AI 翻成“临床 2 期”。在医药监管语境里，2 期是几十到几百人的小范围疗效验证，3 期是上千人的上市前确证试验，一个数字错译就可能造成严重后果。这个案例迫使 PM 面对一个根本问题：如果 AI 一定会犯错，而产品仍然要使用 AI，PRD 应该怎样设计系统来容纳和治理这种错误？
因此，AI产品PRD 的核心不是“把 AI 功能描述得更炫”，而是把不确定性变成可追踪、可评估、可复核、可迭代的产品机制。它既是写给开发、算法、设计、测试和运营的协作文档，也是 PM 写给未来自己的决策档案。
关键信息
| 维度 | 内容 |
|---|---|
| 类型 | AI 产品管理方法论 |
| 核心问题 | 如何在模型不确定性中设计可靠产品 |
| 关键组成 | 流动 PRD、显式权衡、Bad Case 池、风险标注、评测权重、Human in the Loop、Prompt Changelog |
| 适用场景 | AI 翻译、对话 Agent、代码助手、AI 写作、AI 评测、专业决策辅助等 |
| 相关方法论 | AI评估计分板、人机协同、AI竞品分析、提示词工程、AI产品经理工作流 |
核心特性
一、PRD 从“上线前快照”变成“持续演进的日志”
AI 产品的模型、Prompt、知识库和用户预期都会持续变化。传统 PRD 在开发完成后归档，三个月后仍可作为相对稳定的事实依据；AI 产品 PRD 如果只记录上线前某一瞬间，很快就会变成失效快照。
在原文案例中，作者的 PRD 在 Prompt 章节保留完整 Changelog：v1.0 到 v3.0 每个版本改了什么、为什么改、效果如何全部留痕。某次因为编号错译加入数字校验规则；某次因为用户反馈“不够专业”细化角色描述；某次因为修改率卡在 22% 降不下去，新增独立审核 Prompt。这个 Changelog 的价值不只是管理 Prompt，而是让团队三个月后仍能理解当时为什么这样做。
实践原则：每次切模型、改 Prompt、补知识库、发现 Bad Case、调整评测权重，都应该进入 PRD 更新记录。
二、显式权衡比功能清单更值钱
AI 产品的方案空间比传统软件更发散。一个术语注入需求，可以用 RAG，可以用 Prompt 注入，可以微调，也可以做规则表；对话 Agent 可以上 Function Calling、记忆、向量库或结构化数据库；写作工具可以做多模型路由，也可以固定模型加任务模板。不同方案的优劣会随着数据规模、模型价格、时延要求和团队能力变化而变化。
原文中的术语注入案例很典型：RAG 技术更“高级”，但术语库只有 100 多条时，搭向量库、做 Embedding、每次多一次调用并不划算；Prompt 注入虽然低配，却在当前规模足够。作者在 PRD 中写明选择 Prompt 注入，并把切换条件设为“术语库 500+ 条时再切 RAG”。这就是 AI 产品 PRD 的显式权衡：不是证明自己用了最先进技术，而是说明在当前约束下为什么这个方案最合适。
实践原则：每个重要技术决策旁边都写四件事——评估过哪些方案、各自优劣、为什么现在选这个、什么条件触发换方案。
三、Bad Case 池是 PRD 内置机制，不是上线后补丁
AI 产品出错不是异常事件，而是必然事件。传统软件的 bug 管理常常在开发和测试系统中处理，PRD 未必需要专门章节；但 AI 产品必须在 PRD 中定义错误如何被捕获、归因、修复、验证并沉淀。
原文给出的 Bad Case 池字段包括：错误样本、错误类型、根因分析、修复方案、验证结果、关联 Case 和状态。闭环步骤是“归档 → 归因 → 修复 → 验证 → 沉淀”。作者累计 47 条 Bad Case，闭环修复 43 条，闭环率 91.5%。这组数字说明 Bad Case 池不是形式化表格，而是 AI 产品可靠性的增长飞轮。
实践原则：从 Day 1 建 Bad Case 池。哪怕只有一条，也要跑完归因、修复和回归验证；否则 AI 产品的错误只会反复以不同面貌出现。
四、PRD 要捕捉“用户不知道哪里不准”的隐性心理负担
AI 产品的用户需求不总是显性的。用户可能会说“我要翻译更准”，但真实负担是“我不知道哪里可能翻错，所以必须全文通读”。这类隐性心理负担很难用传统用户故事写出来，却决定产品是否真正可用。
作者的 AI 翻译 Agent 在 V1.5 通过术语库和四层 Prompt 把用户修改率从 35% 降到 22%，但仍未解决信任问题。后来加入 [需确认] 标注，让模型对自己不确定的专业术语、数字和编号主动标黄，用户的工作从“核对 100% 内容”变成“review 风险点”，修改率进一步降到 12%。更重要的是，用户开始提出自动检测输入语言等体验优化需求，说明他们已经从“怀疑准不准”转向“希望用得更顺”。
实践原则：AI 产品要给用户一个“不确定性信号”，可以是风险标注、置信度、引用来源、diff 预览或颜色高亮。形式不重要，核心是诚实地暴露不确定性。
五、评测权重是产品定义的一部分
传统 PRD 里评测常常被写成“通过测试用例”，开发后由 QA 执行；AI 产品的评测体系必须在产品定义阶段就写清楚，因为权重决定产品服务谁、优先解决什么问题、愿意为什么错误买单。
原文中的医药翻译 Agent 采用四维评分：准确性 40%、安全性 30%、专业度 20%、有用性 10%。权重不是拍脑袋，而是按“错误代价的不可逆程度”反推：安全性出错几乎没法回头，所以高权重，并设置 0 分一票否决。这个思路与 AI评估计分板 的红线池完全同源：业务生死线不能被总体平均分掩盖。
实践原则：先问“哪个维度错了我最害怕”，再决定评测权重。不同产品的答案不同：电商看相关性和多样性，办公工具看效率和底线准确，创意工具看多样性和惊喜感，代码助手看可运行与不删用户代码。
六、Human in the Loop 是产品设计核心，不是自动化失败的补丁
AI 产品不能把“全自动”当成默认目标。在垂直专业场景中，盲目全自动往往会让用户失去信任，因为用户不得不花更多时间通读和核验全部输出。真正的协作设计，是把 AI 能确定的部分交给 AI，把 AI 不确定或风险高的部分明确暴露给人。
原文把 HITL 设计分成三层：L1 输出标注，自动标注 [需确认]；L2 修改追踪，记录用户改了哪里并反哺迭代；L3 主动反馈，一键报错进入 Bad Case 池。这三层对应从“让人看到风险”到“让人的修改成为数据”再到“让用户主动参与错误闭环”的完整路径。
实践原则：PRD 中必须有“人在哪里介入”章节，写清什么由 AI 做、什么由人做、什么由 AI 先做但必须人 review。
七、AI 可辅助写 PRD，但判断段落必须由人负责
作者承认自己的 12 章节 PRD 模板和部分初稿由大语言模型辅助生成，但真正有价值的判断来自高频使用和亲自踩坑：用户要的不是更准而是知道哪里可能不准，评测权重按错误代价反推，Bad Case 池才是护城河。这些判断不是 AI 从模板里能写出来的。
这条原则对 PM 很关键：你如何用 AI 写 PRD，往往会映射到你如何设计 AI 产品。如果写 PRD 时把判断也外包给 AI，做出的产品也容易把判断外包给 AI，最终在专业场景里翻车。
不同素材中的观点
来自 2026-05-18-woshipm-ai-product-prd：
- AI 产品 PRD 与传统 PRD 的根本差异在于底层假设：传统软件默认程序确定，AI 产品必须承认模型不确定。
- PRD 必须从“一次性交付文档”变成“持续演进日志”，Prompt Changelog、模型切换、知识库变化和 Bad Case 都要留痕。
- 显式技术权衡是 AI 产品 PRD 的高价值章节：例如术语库 100+ 条时用 Prompt 注入，500+ 条再切 RAG，不为“高级技术”牺牲当前性价比。
- Bad Case 池是 AI 产品护城河。原文案例累计 47 条 Bad Case、闭环修复 43 条、闭环率 91.5%，说明错误归因和回归验证本身就是能力资产。
- 用户最需要的不是 AI 假装完美，而是 AI 诚实暴露不确定性；
[需确认]标注把用户核验成本从 100% 通读降为 review 风险点。 - 评测权重应按错误代价反推，安全性等不可逆维度需要高权重或 0 分一票否决。
- Human in the Loop 不等于低自动化，而是专业场景可用性的核心设计：输出标注、修改追踪、一键反馈组成从风险暴露到错误闭环的三层协作机制。
来自 2026-05-27-woshipm-ai-ecommerce-kol-agent：
- AI 产品 PRD 必须包含”商业模式反向约束产品形态”章节：Elaine.H 的电商 AI 导购 PRD 把 CPS 商业模式（商家付费 + 平台 30% + KOL 70% + 用户免费）和信任机制设计（品类券 vs SKU 专属券，从根本上切断 KOL 推高佣商品的动机）写进 PRD 的”产品定位”章节，与功能流程并列。这把 AI 产品 PRD 的边界从”技术权衡 + 评测权重 + Bad Case”扩展到”商业机制设计”——尤其在面向 C 端用户的高信任要求场景，商业模式的设计就是产品形态的一部分，不能放到 PRD 之外
- 多租户隔离架构是高阶 AI 产品 PRD 的标配章节：与单用户对话场景不同，海量分身（KOL Agent、企业租户、品牌账号）场景的 PRD 必须显式写清”路由策略 + 配置隔离 + 数据隔离 + 资源隔离”。本文给出的”达人 ID 路由到专属 Skills 配置实例（偏好规则、风格 Prompt、专属测评库）“是这类章节的可复用模板
- Agent 9 步处理流程是企业级对话 AI 产品 PRD 的通用模板：用户选择 → Agent 路由 → 意图提取 → 槽位补全 → 上下文融合 → 任务拆解与编排 → 技能执行 → 回复生成 → 记录与反思。这套 9 步流程对应 PRD 中”功能流程 + 异常处理 + Bad Case 闭环”三个章节，比传统的”用户流程图”信息密度高得多
- 测评真实性合规设计应作为单独章节：本文 PRD 中”测评摘要必须基于真实测评内容，严禁捏造达人观点；系统需在生成时进行置信度校验 + 事后抽检；生成内容需添加 ‘AI 生成’ 标识，测评摘要需标注 ‘基于达人过往测评整理’“——这套合规设计在医药、金融、电商代言等高合规场景必须成为 PRD 的一级章节，不能塞进”安全需求”附录
- 性能与成本指标必须显式写进 PRD：本文给出首 Token ≤ x00ms、端到端 ≤ 3s、月度可用性 ≥ 99.5%、首年 QPS 峰值 2000、单轮推理成本 ≤ 0.0xx 元等明确指标，把 2026-05-26-woshipm-ai-pm-core-knowledge 提出的 Tokenomics 思想落实为 PRD 中的硬指标
- PRD 的”未来触发条件”应该写清楚：本文虽未完整展开但已暗示 v2 升级路径（如多模态结构化解析能力的引入、Principle 决策框架替代规则兜底等），这与 2026-05-18-woshipm-ai-product-prd “切换条件应该明示”的原则同源
来自 2026-05-29-woshipm-ai-emotional-product-practice-methodology：
- 练手项目的文档链应拆为三份独立文档：BRD（决策文档：为什么做 / 不做什么）、POSTMORTEM（事实档案：只记录”发生了什么”）、LEARNINGS（第一人称反思：主观感受和情绪）。刻意分开的原因是：如果将来有人接手，他只需要看 POSTMORTEM 就能理解项目全貌，不用在情绪文字里筛选信息。文档是写给三个月后的自己的外部记忆——那时不会记得当初为什么选了这个模型、为什么砍了那个功能。
- BRD 中的
is_practice_project标记是后续所有决策的锚点：这个字段改变了三个决策——敢砍功能（不做清单比做的还多）、能接受降级（降级版的完成也是完成）、假设验证有边界（练手项目接受验证失败）。这个标记让 PRD 的”不做什么”从模糊的范围描述变成有纪律的决策框架。 - PRD 中必须包含”上线前强制检查清单”：AI 情绪产品的 PRD 设计了 5 项上线前强制检查（母语者复核词表、原声测试、热线实测等），全部未通过则不允许导入真实用户。这把 AI 产品 PRD 的验收标准从”功能可用”扩展到”安全合规”。
来自 2026-06-08-woshipm-ai-b-prd-retrospective：
- AI 辅助写 B 端 PRD 的三大现实痛点是 PRD 方法论的”地面实况”：本文作者在 B 端一线的长期使用中验证了三点：（1）AI 对基础格式、标准化内容表现稳定，但业务流程、状态流转、核心业务逻辑出错率显著升高；（2）审核模式从”人工评审”转向”AI 首检”——Markdown 格式对机器解析友好，团队全员接入 AI 后，PRD 上线前首先通过 AI 校验；（3）AI 对代码生成的优化成熟度远高于 PRD 长文本场景，Token 消耗大，综合效率提升有限。这三点直接验证了 2026-05-18-woshipm-ai-product-prd 的核心观点：AI 产品 PRD 必须显式承认不确定性并设计治理机制
- B 端 PRD 工具链仍在快速迭代期，尚无稳定最优解：作者先后测试 Antigravity → Trae + 火山引擎 Doubao-seed-2.0-code/pro 双模型（200 万免费 Token）→ Claude Code，最终确定 Claude Code + Obsidian + Axure + Mimo-v2.5-pro。核心判断：目前暂无针对中文 B 端 PRD 场景深度优化的 AI 模型，这意味着 PRD 方法论的”工具层”仍是开放问题
- Markdown 正在成为 PRD 主流格式，编辑器选型直接影响 AI 协作效率：作者对比 Trae、VS Code+插件、Typora、Obsidian 后选定 Obsidian（多标签页分屏 + 原生 Git 兼容），核心考量是多模块多版本对照编写和规避 AI 操作风险。这对 AI产品经理工作流 的启示是：PRD 格式标准化（Markdown）是 AI 辅助写作的前置条件
- Figma + MCP 的 PRD 联动生成”暂不具备落地条件”：作者实测 Claude 通过 MCP 生成 Figma 页面效果差、可用性低、Token 损耗严重，短期仍以 Axure 为主。这与 2026-06-02-woshipm-codex-agent-workbench 中 Junliu 用 Codex 生成 HTML 原型形成对比——说明不同原型工具的 AI 集成成熟度差异巨大
来自 2026-06-02-woshipm-codex-agent-workbench：
- PM × Agent 协作生成 PRD 的核心不是”写得快”而是”纠偏后继续推进”：Junliu 用 GEO 问题库 Agent PRD 案例说明，Codex 第一次把问题库 Agent 和检测 Agent 职责混在一起，PM 指出边界后 Codex 重新收敛理解，再把 PRD、SDD 和 HTML 原型继续推进。这个过程对 AI 产品 PRD 方法论的增量是：PRD 生成不应该是”一次生成完事”，而应该设计为”先让 Agent 复述理解 → PM 纠偏关键边界 → Agent 更新并推进”的多轮协作流程。作者给出了完整的 12 步”理解对齐”Prompt + PRD 生成 Prompt 模板，核心设计是强制 Agent 先做三件事：复述理解、暴露边界、列出待确认问题。
- AI 产品 PRD 的终极价值不是文档本身，而是把 PM 的 0-1 产品思考过程变成可执行、可检查、可复用的 Agent 工作流：PRD 解决”要做什么”，SDD 解决”怎么开发”，HTML 原型解决”用户如何操作”——三者连起来才接近一个可交付开发的 0-1 产品包。这把 AI 产品 PRD 从”文档工具”升级为”Agent 工作流的起点”。
实用信息
AI 产品 PRD 最小模板
# AI 产品 PRD
## 1. 背景与问题定义
- 用户显性需求
- 用户隐性心理负担
- AI 能力边界与错误代价
## 2. 目标与非目标
- 本版本做什么
- 明确不做什么
- 不做的原因与未来触发条件
## 3. 功能流程
- 用户流程
- AI 输出流程
- 异常与回退流程
## 4. Prompt / 模型 / 知识库 Changelog
- 版本
- 修改原因
- 修改内容
- 效果数据
## 5. 技术方案显式权衡
- 评估过的方案
- 优劣与成本
- 当前选择
- 切换条件
## 6. Bad Case 池
- 错误样本
- 根因
- 修复
- 5+ 条回归验证
- 状态
## 7. 评测体系
- 评分维度
- 权重
- 红线一票否决
- 评测集来源
## 8. Human in the Loop
- 人在哪里介入
- AI 如何暴露不确定性
- 用户修改如何反哺
- 一键反馈入口常见误区
- 把 AI 产品 PRD 写成传统功能清单：只写功能点，不写不确定性、错误闭环和评测权重，等于没有回答 AI 产品最核心的问题。
- 追求“更高级”的技术而不写约束：RAG、微调、Agent 框架都可能正确，也都可能过度设计；必须写清当前规模、成本和触发条件。
- Bad Case 只记录不归因：没有根因、修复和回归验证的 Bad Case 只是事故清单，不是能力资产。
- 把置信度展示当成示弱：诚实暴露不确定性不是降低产品形象，而是建立用户信任。
- 把全自动当作产品终点：专业场景中全自动常常是假目标；更可靠的目标是把人工复核成本压到最小。
- 让 AI 写完 PRD 的判断段落：AI 可以搭框架、补描述，但“为什么这样决定”必须来自 PM 的真实观察和责任判断。
与已有方法论的关系
| 方法论 | 关系 |
|---|---|
| AI评估计分板 | 评估计分板是 AI 产品评测基础设施，AI产品PRD 是把评测权重、红线和 Bad Case 闭环写进产品定义的文档载体 |
| 人机协同 | AI产品PRD 通过 HITL 章节明确人机边界，把“AI 处理标准化、人处理不确定和负责”落成产品交互 |
| AI竞品分析 | AI竞品分析强调评测集是护城河；AI产品PRD 强调评测权重和错误闭环必须在产品设计阶段定义 |
| 提示词工程 | Prompt 不是一次性输入，而是需要版本管理、回归验证和效果追踪的产品资产 |
| 工作SOP | AI产品PRD 是 PM 把 AI 产品迭代经验写成 SOP 的一种形式，与个人工作 SOP 同源 |