做完一个AI产品，我重新理解了PRD这件事
青钰 / CyberHuck 基于一个医药 AI 翻译 Agent V3 的真实迭代，提出 AI 产品 PRD 与传统软件 PRD 的底层差异：传统 PRD 默认程序确定，AI 产品 PRD 必须承认模型不确定，并把 Prompt 变更、显式权衡、Bad Case 池、风险标注、评测权重和 Human in the Loop 都写进产品定义。
基本信息
- 来源类型：网页文章（人人都是产品经理 · 产品设计栏目）
- 原文位置：
raw/articles/2026-05-18-002628-tg-b666c3.fetched.md - 原始 Telegram stub：
raw/articles/2026-05-18-002628-tg-b666c3.md - 原文 URL：https://www.woshipm.com/pd/6394140.html
- 作者：青钰、CyberHuck
- 发布日期：2026-05-13
- 原文字数：6464 字 / 阅读时长约 26 分钟
- 消化日期：2026-05-26
- 抓取说明：本机 Chrome 不可用，
baoyu-url-to-markdown本地 CDP 抓取失败后降级到defuddle.mdAPI，正文保存为.fetched.md文件。
核心观点
-
AI 产品 PRD 的底层假设从“程序确定”变成“模型不确定”。传统软件只要写清 if A then B 的功能逻辑，AI 产品却要面对同一输入今天输出 X、明天输出 Y 的现实。PRD 不再只是功能清单，而要成为“不确定性治理文档”：记录模型变化、Prompt 变更、错误闭环、评测权重、人机边界和产品决策依据。
-
AI 产品 PRD 应是流动文档，而不是上线前快照。作者的 AI 翻译 Agent PRD 在 Prompt 章节保留 v1.0 到 v3.0 的完整 Changelog：某版本因数字错译加入数字校验，某版本因用户反馈“不够专业”细化角色描述，某版本在用户修改率降不下去时新增独立审核 Prompt。原因是模型、知识库和用户预期都在变，三个月前的决策如果没有留痕，很快就会变成无人能解释的历史包袱。
-
AI 产品 PRD 里最值钱的不只是“做什么”，而是“为什么不做另外几个方案”。术语注入场景中，作者明确比较了 RAG 与 Prompt 注入：RAG 技术更高级，但术语库只有 100 多条时需要向量库、Embedding 和额外调用成本；Prompt 注入更低配，却在当前规模足够，触发条件写成“术语库 500+ 条再切 RAG”。这种显式权衡能避免每次被问“为什么不用 RAG/微调/Agent 框架”时重新论证。
-
Bad Case 池是 AI 产品 PRD 的核心章节，因为 AI 出错不是异常，而是必然。开篇的医药翻译案例中，“Phase III clinical trial”被翻成“临床 2 期”，2 期与 3 期在监管文件中差一个字却可能造成严重后果。作者用 Bad Case 池记录错误样本、错误类型、根因、修复方案、5+ 条历史 case 回归验证、关联 case 和状态；累计 47 条，闭环修复 43 条，闭环率 91.5%。
-
AI 产品真正要缓解的用户心理负担，是“我不知道哪里可能不准”。作者最初以为翻译用户只要“更准”，把术语库和四层 Prompt 做完后用户修改率从 35% 降到 22%，但仍不够。后来他发现用户第一动作是全文通读，因为不知道哪里可能有风险；V2 加入
[需确认]标注后，用户只需 review 风险点，修改率降到 12%，信任也随之建立。 -
评测权重本身就是产品定义，应该按错误代价的不可逆程度反推。作者的 AI 翻译 Agent 用四维评分：准确性 40%、安全性 30%、专业度 20%、有用性 10%，其中安全性错误几乎不可逆，所以设置“0 分一票否决”红线。不同场景的权重完全不同：电商可能相关性与多样性优先，办公工具效率是核心、准确性是底线，创意工具惊喜感可能高于准确性，代码助手则“可运行”和“不删用户代码”优先。
-
AI 产品 PRD 不能一味追求全自动，而要主动设计“人在哪里介入”。作者把 HITL 分成三层：L1 输出标注（
[需确认]风险点）、L2 修改追踪（记录用户改了哪里反哺迭代）、L3 主动反馈（一键报错进入 Bad Case 池）。专业场景下，全自动常常是伪命题；如果不设计人工复核入口，用户只能核对 100% 输出，效率反而下降。 -
AI 可以辅助写 PRD，但“为什么这样决定”的判断段落必须由人写。作者承认 12 章节 PRD 的模板和部分初稿由大语言模型辅助，但最有价值的判断——用户要的不是更准而是知道哪里可能不准、评测权重按错误代价反推、Bad Case 池才是护城河——都来自自己作为 owner 和高频用户的真实使用。
-
PRD 是 PM 的成长史。作者最后把 7 条心得收束为同一件事：如何在不确定性里做产品。AI 产品 PRD 不只是写给开发的功能说明，而是 PM 如何识别风险、记录权衡、暴露不确定性、设计人机协作和持续沉淀判断力的历史记录。
实操内容保留
本节保留原文中可直接复用的 PRD 结构、错误闭环、评测权重和 HITL 设计方法。
代码/配置
（本文无实操代码/配置）
Prompt 模板
（本文未给出完整 Prompt 模板，但强调 PRD 中必须保留 Prompt Changelog：每次改 Prompt、切模型、发现 Bad Case，都记录版本、修改原因、效果变化和触发条件。）
操作步骤
AI 产品 PRD 七个必备章节
| 章节 | 传统 PRD 常见写法 | AI 产品 PRD 需要补充 |
|---|---|---|
| 版本与 Changelog | 写完归档 | 持续记录 Prompt、模型、知识库和用户预期变化 |
| 功能清单 | 写“我要做什么” | 写“我为什么不做另外几个方案” |
| 错误管理 | 上线后由开发/测试处理 bug | 在 PRD 中内置 Bad Case 池和闭环机制 |
| 用户需求 | 显性用户故事 | 捕捉“我不知道哪里不准”等隐性心理负担 |
| 评测体系 | 开发后测试用例 | 产品定义阶段写清指标权重和红线 |
| 人机边界 | 越自动越好 | 明确人在哪里介入、何时复核、如何反馈 |
| AI 协作写作 | AI 生成文档 | AI 辅助框架，人负责判断段落 |
Bad Case 池字段模板
| 字段 | 用途 |
|---|---|
| 错误样本 | 保存原始输入、AI 输出和正确结果 |
| 错误类型 | 例如数字错译、术语错译、幻觉、引用错误、越界生成 |
| 根因分析 | 归因到 Prompt 哪一层、知识库缺失、模型能力边界或输入歧义 |
| 修复方案 | 修改 Prompt、加入规则、补充术语库、增加审核 Prompt 或改产品交互 |
| 验证结果 | 用 5+ 条历史 case 回归测试，确认没有修一个坏一片 |
| 关联 Case | 关联同类错误，避免重复分析 |
| 状态 | 待归因 / 修复中 / 已验证 / 已沉淀 |
五步闭环：归档 → 归因 → 修复 → 验证 → 沉淀。
评测权重设计方法
- 列出产品输出质量的关键维度，例如准确性、安全性、专业度、有用性、效率、多样性、惊喜感、可运行性。
- 对每个维度追问：“如果这个维度出错，代价多严重、是否可逆？”
- 代价最高且不可逆的维度设置最高权重或 0 分一票否决红线。
- 在 PRD 中写清每个维度的判定标准，而不是只写一个总分。
- 随着 Bad Case 池增长，定期调整权重和红线。
作者示例：医药翻译 Agent 的四维评分为准确性 40%、安全性 30%、专业度 20%、有用性 10%，安全性设置 0 分一票否决。
Human in the Loop 三层设计
| 层级 | 设计 | 目的 |
|---|---|---|
| L1 输出标注 | [需确认] 自动标注不确定字段 | 让用户从核对 100% 输出变成 review 风险点 |
| L2 修改追踪 | 自动记录用户修改了哪些地方 | 把用户修正转成后续 Prompt / 规则迭代依据 |
| L3 主动反馈 | 一键报错按钮 | 让用户主动提交 Bad Case 入池，形成反馈闭环 |
关键概念
- AI产品PRD — 本文核心实体；把传统功能说明升级为 AI 产品不确定性治理、评测权重、错误闭环和人机协作边界文档。
- AI产品经理工作流 — 本文补充“文档写作 AI 辅助”之外的更深层命题：AI 产品 PRD 不是让 AI 写得更快，而是让 PM 把不确定性治理写清楚。
- AI评估计分板 — 本文的“按错误代价反推评测权重”和红线一票否决，与评估计分板的 Golden Set / R-U-B / 红线池同源。
- 人机协同 — 本文的 HITL 三层设计把人机协同落到具体 AI 产品交互：标注不确定性、追踪修改、一键反馈。
- AI竞品分析 — 两者共同强调 AI PM 的护城河是评测与判断力；本文聚焦 PRD 和产品设计，竞品分析聚焦评测集与竞品方法论。
- 提示词工程 — Prompt Changelog、数字校验规则和独立审核 Prompt 都说明提示词不是一次性文本，而是需要版本化治理的产品资产。
与其他素材的关联
-
与 2026-05-09-pm-ai-playbook 的关系：那篇提出“PRD 最难的是组织结构，AI 做 80% 框架、人做 20% 判断”；本文进一步说明 AI 产品 PRD 的 20% 判断具体写什么——写不确定性、错误闭环、评测权重、技术权衡和人机边界。
-
与 2026-05-11-ai-evaluation-scoreboard 的关系：评估计分板从企业级评测基础设施角度讲 Golden Set、R-U-B 三维和 LLM-as-a-Judge；本文从 PRD 角度讲评测体系如何进入产品定义本身，尤其是“安全性 0 分一票否决”和“按错误代价反推权重”。
-
与 2026-05-20-ai-pm-competitive-analysis 的关系：AI 竞品分析强调“AI PM 最大差异是会不会做 AI 评测”；本文把同一命题落到 PRD 写作：评测权重、Bad Case 池、回归验证和显式权衡都必须写进 PRD。
-
与 2026-05-23-woshipm-sop-as-cot-agent-clone-expert 的关系：SOP as CoT 讲如何把专家隐性流程编译进 Agent；本文讲如何把 AI 产品迭代中的隐性判断编译进 PRD。两者本质都是把隐性经验变成可复用、可维护的系统资产。
-
与 2026-05-25-woshipm-ai-pm-onboarding-sop 的关系：入职摸底文档把新人对陌生业务的理解持续写回，本文的 AI 产品 PRD 把 PM 对不确定性、错误和权衡的理解持续写回；两者都把“文档”从交付物变成持续演进的认知资产。
原文精彩摘录
原文写的是 Phase III clinical trial，AI 给我翻成了「临床 2 期」。……临床 2 期是小范围疗效验证，几十到几百人；3 期是大规模确证试验，上千人，是产品上市前的最后一关。监管文件里 2 和 3 弄混，是要出大事的。
如果 AI 就是会犯这种错而我们还在用它，这个产品到底要怎么设计才能不出大事？更进一步，一份 AI 产品的 PRD 要写成什么样，才能容纳「AI 会犯错」这种根本现实？
我那份 PRD 的 Prompt 章节有一个完整的 Changelog，从 v1.0 到 v3.0，每个版本改了什么、为什么改、改完什么效果，全部留痕。
关键是 5 步闭环：归档、归因、修复、验证、沉淀。到现在累计 47 条，闭环修复 43 条，闭环率 91.5%。
用户用 AI 翻译，最大的心理负担不是「翻译不准」，是「我不知道哪里可能翻得不准」。
AI 产品的核心不是「做到 100% 准确」（你做不到），是「诚实地暴露不确定性」。用户不需要 AI 完美，用户需要 AI 诚实。
在大多数垂直专业场景下，全自动是个伪命题。它不仅做不到，还会让用户失去对产品的信任。
做 AI 产品 PRD 这件事本身，就是 AI 产品 PM 日常工作的一面镜子。你怎么和 AI 协作写 PRD，决定了你的产品里怎么设计 AI 和用户的协作。