个人知识库

AI产品PRD

40分钟阅读

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-07-26-youtube-claude-code-nano-banana-astra-site：PRD 被定义为 Claude Code 写第一行代码前的 结构决策全集——有哪些页/区块、内容落点、用户各阶段应感受与行动。与 CLAUDE.md 组成「呼吸包」：PRD 是蓝图（what/体验），CLAUDE.md 是建造标准（how/禁区）。复杂设计站在第一版能跑之后，应用 对照 PRD 的 audit 找出缺失与 under-built（案例：行星系统是 PRD 指定中心件却未实现），再生成实现计划执行——避免多数 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-18-ai-product-prd（同一作者 CyberHuck 的原始完整文章）：

  • 7 条心法的底层逻辑统一：文章完整阐释了这 7 条心法背后的统一思维——“如何在不确定性里做产品”，这是 AI 产品 PM 和传统 PM 的真正鸿沟。每条心法都是应对”模型不确定性”这个根本挑战的不同切面。
  • PRD 就是 PM 的成长史：作者强调这份 PRD 不是给开发看的功能清单，而是 PM 自己成长和决策演进的记录。三个月后回看 v1.0，会像看陌生人写的东西一样，这说明 AI 产品迭代速度之快。
  • 从”Phase III → 临床 2 期”错误中惊醒：这个医药翻译的致命案例是作者对 AI 产品 PRD 产生全新理解的转折点。这不是功能问题，而是系统性地”如何容纳 AI 会犯错这种根本现实”的问题。
  • AI 产品的方案空间是发散的：传统软件做 CRUD 技术栈翻不出花来，但 AI 产品的方案空间发散——今天最优明天可能就不是了。所以必须把当时的判断逻辑写下来，否则每次有人问”你为什么不用 RAG/微调/Agent 框架”都得重新论证。
  • 简化处理 vs 完整处理：短素材（≤1000 字）走简化流程（只生成摘要页、提取 1-3 个关键概念、跳过主题页和 overview 更新），长素材走完整流程（完整的实体页创建/更新、主题页维护、Bad Case 回归）。这个分级处理原则也适用于 AI 产品设计中的资源分配。
  • 最大成本是身份上的：作者说 Bad Case 池的最大成本不是工程上的，是”身份上的”——PM 必须自己高频使用产品才能发现最反直觉的问题。很多 AI PM 做产品自己从来不当用户，这在 AI 产品上是大忌。
  • 这份 PRD 本身是 AI 辅助+人判断的协作产物：模板和部分初稿由 AI 生成，但”用户要的不是更准而是知道哪里可能不准”、”评测权重按错误代价反推”、”Bad Case 池才是护城河”这些核心判断，AI 给不了，必须来自 PM 亲自蹲守和踩坑。

来自 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-07-01-woshipm-ai-prd-full-workflow（冰冰酱的全自动 AI 产品工作流）：

  • PRD 不再是起点，而是逻辑和结构讨论清晰后的交付物：作者的成熟自动化链路是”上下文读取 → 逻辑梳理 → 原型构建 → 文档撰写 → 版本维护”，PRD 排在原型结构确认之后。新需求启动时先不写 PRD，只与 AI 共同梳理”问题地图”（待决策问题列表 + 潜在争议方案列表 + 直接动笔最易出错点预警），沿地图往下走再构建文档和原型，根基更稳。这与本页”显式权衡比功能清单更值钱”是同一逻辑在工作流层面的延伸——把权衡前置到写文档之前。
  • 变更记录训练法 是让 AI 从”模仿”走向”理解”的关键：只喂最终稿 AI 学到的是结果，喂”初稿→终稿”的演变过程 AI 才能学到判断力。看到”点击后跳转”被反复改成含”目标页面、参数保留、异常处理、成功反馈”的详尽描述，AI 才真正理解”研发能直接执行的需求粒度”。这为本页”Prompt Changelog 要留痕”提供了训练侧的镜像——Changelog 不只是给人看的迭代记录，也是喂给 AI 学习判断标准的高价值语料。
  • 用 GitLab + Markdown 管 PRD 版本带来三重收益：清晰的变更记录（diff 自动生成，无需口头解释修改点）、与研发工作流打通（研发直接通过链接访问文档做 AI Coding，无需手动导出 PDF）、连续的工作上下文（上下文断了或切模型时，git 记录和变更记录让新会话快速找回准确上下文）。这把本页”流动 PRD”从理念落到了具体的工程基础设施。
  • 自检 3 轮 + 每发现一次规律就回写规则 + 大任务分阶段 compact 是让系统稳定运转的核心习惯：每版产出后让 AI 以研发/测试/老板视角反复 review 逻辑漏洞和前后矛盾（一般 3 轮达到较好准确性），把重复出现的问题升级为 Skill 或模板中的永久规则，复杂任务按里程碑切分并在每阶段完成后 compact 压缩上下文。这与本页 Bad Case 池”归档→归因→修复→验证→沉淀”闭环同源——都是把偶发问题固化为系统能力。

来自 2026-07-05-woshipm-ai-requirement-analysis-report（光点神奇的 AI 需求分析三步法）：

  • AI 辅助写 PRD 的前置步骤是“逐轮采访”，不是直接生成文档：作者明确反对一上来输入“帮我写一个采购执行报表需求文档”。正确做法是让 AI 先围绕“谁用、看什么、解决什么决策、数据从哪来、多频繁”逐个追问，把 PM 自己没想清楚的上下文逼出来，再生成文档。
  • 需求文档的可执行性来自约束，而不是篇幅：整理 prompt 要求每部分不超过 200 字、不写“提升体验/赋能决策”空话、每条都能直接给研发看。这与 AI 产品 PRD 的核心原则一致：文档不是漂亮话，而是把字段、来源、计算方式、异常和边界写清。
  • 评审前的多角色挑战是 PRD 自检机制：让 AI 扮演需求方、后端研发、测试三类角色，分别从业务价值、数据可实现性、边界 case 验证角度挑刺。采购员字段、最低订单数门槛、分批到货超期口径这类问题，本质上都是 PRD 在字段、统计和验收层面的缺口。
  • 需求分析流程可以沉淀为 AI需求分析三步法 / Skill：采访→整理→挑战的骨架稳定，适合写成 PM 的需求分析 Skill。它把“写 PRD”前的提问、整理和质疑流程固化下来，让 AI 稳定提醒 PM 不要遗漏关键上下文。

来自 2026-07-07-woshipm-agent-safety-guardrails（怂怂的AI脑内小剧场的 Agent 安全护栏设计）：

  • Agent PRD 必须把安全护栏写成可执行需求，而不是上线前补异常提示：Agent 的职责边界、不能做什么、哪些输入高风险、哪些输出必须带依据、哪些操作需要二次确认、哪些场景必须转人工，都应该进入 PRD 正文。本文把 Agent安全护栏 从技术风控提升为产品定义问题。
  • Agent 安全需求要从准确性、风险分层和行动边界三层展开：安全不是只靠拦截实现的，很多安全问题本质上是知识不准、检索不相关、任务拆解混乱、工具调用无边界。PRD 需要先写清知识来源、推理步骤、证据追溯，再写低/中/高风险场景的不同处理路径。
  • 风险路由 应成为 Agent PRD 的关键流程：系统要根据用户在问什么、用户是谁、Agent 要操作什么、结果能否撤回、历史上是否异常来决定护栏强度。低风险请求可快速响应，中风险请求要检查，高风险请求必须停下来确认。
  • 可撤回性原则 是流式输出和审核前置的 PRD 判断口径：能收回的内部问答可以先输出后校验；客户邮件、法律意见、投资建议、报销审批、订单状态修改等不可撤回或高代价任务必须先校验后交付，并保留人类授权或强规则兜底。
  • Agent PRD 的复盘指标应包括护栏命中率、误拦率、漏拦案例、人工接管比例、响应延迟和用户放弃率：这些指标让安全护栏不再是口号，而是可被 AI评估计分板 接住的持续迭代系统。

来自 2026-07-08-woshipm-skill-validation-version-handoff（Zoe产品手记的 Skill 验证、版本与交接）：

  • Skill 迭代记录与 AI 产品 PRD 的 Prompt Changelog 同源：Skill 每次修改都应记录“解决什么、为什么改、怎么验证”，这与 AI 产品 PRD 中记录 Prompt、模型、知识库和 Bad Case 变化的逻辑一致。区别只是对象不同：PRD 记录产品级不确定性治理，Skill 版本记录 记录程序性知识本身的迭代证据。
  • 输入边界和停止条件应前置进入需求文档：文章强调不要只写“请提供业务背景”，而要写清必须输入、不能输入、缺失时是否停止。这对 AI 产品 PRD 也适用：高风险 Agent、需求分析和自动生成文档类产品，应在 PRD 中把必填输入、输入缺失处理、转人工和停止条件写成一级需求，而不是放在提示词末尾。
  • 事实标签 是 PRD 里暴露不确定性的轻量机制：AI 产品 PRD 已强调 [需确认]、置信度、引用来源和 HITL；本文补充了更通用的输出标签：已确认、推断、待确认。它让 PRD 中的 AI 输出、需求分析和方案建议不再以单一笃定口吻呈现，而是主动标出哪些内容需要人工确认。
  • 交接条件是从个人 PRD/Skill 走向团队资产的最低线：如果一个 Skill 或 AI 产品流程只在作者手中能用，说明很多判断仍在个人脑中。Skill 交接条件 要求写清输入、事实、验证、停止和确认人，对团队 PRD 模板同样重要：文档不仅要让当前团队开发，还要让下一个 PM、测试、运营或 Agent 能理解边界。

来自 2026-07-10-woshipm-product-knowledge-base-prd-ui-code（诸葛铁铁的产品知识库）：

  • AI 写 PRD 的上限不取决于提示词细不细，而取决于有没有产品现状：模型能把眼前功能写得像样，却会漏相邻模块与上下游；缺的不是一段文字，而是“产品今天怎么运行”的可机读状态。这与本页“AI 可辅助写 PRD，但判断段落必须由人负责”形成工程侧补充——人的判断之外，还需要 产品知识库 提供生效规则与影响面。

  • PRD 不应只是变更日志堆叠：每份需求文档保存一次改动，多年后难以还原现状；长上下文无法自动消解版本冲突。AI 产品 PRD 的“流动文档 / Changelog”应进一步落到功能级当前生效规则（位置、规则、角色、更新时间），旧逻辑更新而非只追加。

  • 写 PRD 时要强制做影响传播检查：商品字段变更要顺着客户端详情、搜索推荐、库存价格、订单快照等关系检查页面/接口/表/历史兼容/测试；把“顺手多想一步”从个人经验变成系统清单。

  • 全链路生成（PRD→UI→代码）依赖全链路对齐与三层能力：知识可定位、影响可追踪、变更可验证。任何一层停在旧版本，AI 生成的 PRD/UI/代码都可能一本正经改错地方。

  • 未来差距在“可操作的产品世界模型”，不在更长提示词：当需求变成“针对产品状态的变更指令”，PRD 工作流的上游就从空白提示词切换为检索产品知识库 + 影响图 + 验证门禁。

  • 2026-07-20-youtube-shopify-ai-toolkit-headless-store：Chrome Signal 案例把 PRD 当成 Agent 的项目真相源，而不是事后补文档。PRD 写清品牌身份（futuristic Gundam + sports universe）、受众、void/chrome/signal/noise 设计系统、页面范围、技术栈（Next.js/Hydrogen/Tailwind/Framer Motion/Vercel）与行为边界，Claude Code 再分 foundation → 页面体验 → commerce hardening + motion → production polish 四阶段执行。作者原话：PRD separates a focused, intentional build from one where the AI is making decisions you actually did not ask it to make。对 AI 编程/电商交付的启示：没有 PRD，AI 容易产出 generic dark ecommerce template；有 PRD，才能把 lookbook 级体验、drop/waitlist、metafields lore 与 SEO/JSON-LD 验收串成一致决策。

  • 2026-07-21-youtube-xiangyu-claude-code-video-app（翔宇工作流）：用真实数字反证「产品设计不清晰的代价就是重构」——4 个月约 $4300 token、9600 条对话、5.5 万行 TypeScript、16 次大版本重构，主因是一开始没把边界与流程想清楚。实操上用自定义 command n8n-2prd 把已验证的 n8n 工作流反向提成 PRD：分析工作流类型 → 提取外部 URL → 输出摘要 → 交互式追问需求 → SDK 调研 → 生成完整 PRD。理由是 n8n 节点流本身已定义输入/输出/触发/格式/步骤/外部服务/串并行/产物，是天然的 PRD 骨架。还强调 SDK 选型写进设计阶段：误用谷歌旧版 AI SDK（不支持隐式缓存）导致一次大视频跑出 100+ 美元账单；最终换成 Google GenAI 新版 SDK。与 Shopify 案例同属「PRD 先行再让 Claude Code 执行」，差别在素材源：Shopify 靠人写品牌/设计系统，翔宇靠 从可运行自动化反向编译 PRD。

实用信息

AI 产品 PRD 最小模板

# AI 产品 PRD
 
## 1. 背景与问题定义
- 用户显性需求
- 用户隐性心理负担
- AI 能力边界与错误代价
 
## 2. 目标与非目标
- 本版本做什么
- 明确不做什么
- 不做的原因与未来触发条件
 
## 3. 功能流程
- 用户流程
- AI 输出流程
- 异常与回退流程
 
## 4. Prompt / 模型 / 知识库 Changelog
- 版本
- 修改原因
- 修改内容
- 效果数据
 
## 5. 技术方案显式权衡
- 评估过的方案
- 优劣与成本
- 当前选择
- 切换条件
 
## 6. Bad Case 池
- 错误样本
- 根因
- 修复
- 5+ 条回归验证
- 状态
 
## 7. 评测体系
- 评分维度
- 权重
- 红线一票否决
- 评测集来源
 
## 8. Human in the Loop
- 人在哪里介入
- AI 如何暴露不确定性
- 用户修改如何反哺
- 一键反馈入口

常见误区

  1. 把 AI 产品 PRD 写成传统功能清单：只写功能点，不写不确定性、错误闭环和评测权重，等于没有回答 AI 产品最核心的问题。
  2. 追求“更高级”的技术而不写约束：RAG、微调、Agent 框架都可能正确，也都可能过度设计；必须写清当前规模、成本和触发条件。
  3. Bad Case 只记录不归因：没有根因、修复和回归验证的 Bad Case 只是事故清单，不是能力资产。
  4. 把置信度展示当成示弱：诚实暴露不确定性不是降低产品形象，而是建立用户信任。
  5. 把全自动当作产品终点：专业场景中全自动常常是假目标；更可靠的目标是把人工复核成本压到最小。
  6. 让 AI 写完 PRD 的判断段落：AI 可以搭框架、补描述，但“为什么这样决定”必须来自 PM 的真实观察和责任判断。

与已有方法论的关系

方法论关系
AI评估计分板评估计分板是 AI 产品评测基础设施，AI产品PRD 是把评测权重、红线和 Bad Case 闭环写进产品定义的文档载体
人机协同AI产品PRD 通过 HITL 章节明确人机边界，把“AI 处理标准化、人处理不确定和负责”落成产品交互
AI竞品分析AI竞品分析强调评测集是护城河；AI产品PRD 强调评测权重和错误闭环必须在产品设计阶段定义
提示词工程Prompt 不是一次性输入，而是需要版本管理、回归验证和效果追踪的产品资产
工作SOPAI产品PRD 是 PM 把 AI 产品迭代经验写成 SOP 的一种形式，与个人工作 SOP 同源
产品知识库产品知识库提供“当前生效规则 + 影响关系 + 全链路对齐”，是 AI 写 PRD 时读取产品现状的上游底座；AI产品PRD 则定义不确定性治理、评测与 HITL 文档机制

相关页面

关系图谱

快速导航

反向链接