给 AI 写 PRD 和给传统软件写 PRD,差的不是格式是思维方式

给 AI 写 PRD 和给传统软件写 PRD，差的不是格式，是思维方式

很多产品经理第一次给 AI 项目写 PRD，直接把传统模板拿来改了几个字就交上去了。

结果评审不通过、上线后翻车、成本失控、合规被驳回。

问题不在能力，在于模板。传统 PRD 模板是为确定性软件设计的，AI 产品天生不确定。用确定性的框架管不确定的系统，必然出问题。

这篇文章把 AI PRD 和传统 PRD 的核心差异整理出来，结合大厂审批 AI 项目时新增的 8 个关键章节，帮你写出一份能过评审、能落地、能持续运营的 AI PRD。

AI PRD 和传统 PRD 的根本差异

传统 PRD 关注的是「系统要做什么」。输入是什么、处理逻辑是什么、输出是什么。每个环节都是确定的。

AI PRD 关注的是「系统能做多好」。输入可能模糊、输出可能不完美、模型可能犯错。每个环节都有概率。

这个根本差异决定了 AI PRD 必须新增以下内容：

一、风险等级与 Confidence 阈值矩阵

放在哪：项目背景后，核心需求前。

传统 PRD 不写这个，因为传统软件的输出是确定的。AI 不一样，同一个输入可能给出不同输出，而且可能出错。

写什么：

• 项目风险等级：高、中、低。医疗诊断、金融风控是高风险；内容推荐、文案生成是低风险。
• Confidence 阈值矩阵：高风险场景模型置信度要 0.90 以上才输出，中风险 0.80，低风险 0.70。低于阈值就触发兜底。
• 预估多少比例的请求会触发兜底链。这个数字决定你的成本和用户体验。

为什么不写不行：评审一定会问「翻车了怎么办」。没有明确的风险边界，项目过不了评审。

二、Eval 集设计与上线 NoGo 标准

放在哪：核心功能后，数据章节前。

传统软件测试用用例，AI 产品用 Eval 集。区别是 Eval 集要覆盖真实场景的多样性，不只是 happy path。

写什么：

• Eval 集大小：最少 200 条。包含正常 case、bad case、对抗样本、边界样本。
• Eval 集结构：单元测试、链路测试、端到端测试，三层金字塔。
• 上线 NoGo 标准：准确率低于多少不能上、翻车率超过多少不能上、P95 延迟超过多少不能上。这些指标要量化。

为什么不写不行：没有 Eval 集的产品上线后，覆盖不足会导致投诉率激增。工程团队也不知道什么时候算「做完了」。

三、兜底链分层 SOP

放在哪：错误处理 / 异常流程章节。

AI 一定会犯错。关键不是防止犯错，是犯错之后怎么办。

写什么：

• 三层兜底结构：L1 自动降级（换更可靠的模型或规则）、L2 规则兜底（硬编码返回安全内容）、L3 人工兜底（转人工处理）。
• 各层占比目标：理想状态 L1 覆盖 80%，L2 覆盖 15%，L3 控制在 5% 以内。
• 每层触发率的告警阈值。L3 突然从 5% 跳到 20%，说明模型出问题了。

为什么不写不行：工程团队需要按这个 SOP 写代码。兜底逻辑不清晰，月成本可能高到被叫停。

四、Token 成本预算

放在哪：成本估算 / 商业可行性章节。

传统软件的成本是服务器和人力，AI 产品的成本是按 token 计费的模型调用。每次请求成本不一样，输入越长、模型越强，成本越高。

写什么：

• 单次请求成本：同时提供 P50 和 P95 分位数。P50 代表典型情况，P95 代表极端情况。
• 日 / 月预算上限。
• 超预算的降级策略：自动切换便宜模型、限速、关闭非核心功能。

为什么不写不行：CFO 在 Review 时一定会问成本。很多 AI 项目上线后月消耗远超预期，被老板直接叫停。

五、数据脱敏与 Bad Case 回流机制

放在哪：运营 / 数据章节。

AI 产品上线只是开始。模型好不好，要看上线后的真实反馈。

写什么：

• 用户反馈如何回流到训练集。谁收集、谁标注、谁审核。
• Bad case 标注 SOP：谁来标、怎么标、多久审一次。
• 模型迭代周期：周迭代还是月迭代。
• 数据脱敏的具体指标：哪些字段必须脱敏、脱敏到什么程度。

为什么不写不行：没有数据回流机制，模型无法持续优化。半年后竞品迭代了三轮，你的模型还在用上线时的版本。

六、合规审核

放在哪：合规 / 风控章节。

这个章节传统 PRD 也有，但 AI 产品的合规要求完全不同。

写什么：

• 数据脱敏 SOP：用户数据进入模型前必须经过哪些处理。
• 内容安全过滤层：输入和输出各需要一层过滤。
• 偏见审计：覆盖性别、地域、年龄、收入等维度，保留审计痕迹。
• 所有模型决策必须可回溯。用户问「为什么给我这个结果」，要能给出解释。

为什么不写不行：GDPR、个保法、网信办都有明确要求。不合规的项目法务会直接驳回，没有商量余地。

七、灰度方案与回滚 SOP

放在哪：上线计划章节。

传统软件灰度看的是功能有没有 bug，AI 产品灰度看的是模型表现稳不稳定。

写什么：

• 灰度分桶：建议 5%、20%、50%、100% 四档。每档跑多久、看什么指标。
• Kill Switch：一键关停功能，紧急情况用。
• 回滚条件：翻车率、触发率超过阈值后自动回滚。
• 回滚 SOP：谁有权回滚、多久内完成。

为什么不写不行：AI 产品翻车风险高。全量上线出问题，DAU 可能一天掉一半。

八、持续运营指标

放在哪：运营 / 监控章节。

传统软件上线后监控的是 QPS、延迟、错误率。AI 产品还要监控模型本身。

写什么：

• 模型漂移监控（MAD）：模型表现会不会随时间变差。
• 翻车率监控与告警阈值。
• 触发率监控与分层报表：多少请求走了 L1、多少走了 L2、多少走了 L3。
• 周复盘 SOP：每周看一次数据，调整阈值和策略。
• 月预算偏差告警：超预算 20% 自动告警。

为什么不写不行：没有监控指标，问题可能积累几个月才被发现。到时候用户已经流失，赔偿已经产生。

三个维度理解 AI PRD 的升级

面试被问到 AI PRD 和传统 PRD 的区别，可以从三个维度回答：

输入侧：AI 的输入不确定，所以需要 Confidence 阈值和 Eval 集。传统软件输入是结构化的，AI 输入可能是自然语言。

输出侧：AI 的输出不确定，所以需要兜底链、Token 成本预算、灰度回滚。传统软件输出是确定的，不需要这些。

运营侧：AI 需要持续优化，所以需要数据回流、模型漂移监控、偏见审计。传统软件上线后基本稳定，不需要持续迭代模型。

总结

AI PRD 不是传统 PRD 加几个章节。它是完全不同的思维方式。

传统 PRD 假设系统是确定的，AI PRD 承认系统是不确定的。

传统 PRD 关注功能是否实现，AI PRD 关注功能做多好、翻车怎么办、成本兜得住吗。

传统 PRD 上线就结束，AI PRD 上线才开始。

能想清楚这些差异，写出来的 PRD 才能过评审、能落地、能持续运营。

免责声明：本文内容仅为个人学习分享，提及的工具/服务仅限合法合规使用，如有侵权请联系删除。

感谢你的阅读。

如果这篇文章对你有帮助，欢迎：

• 点赞支持
• 分享给朋友
• 在评论区分享你的想法

关注「AI 工程化实战派」，不空谈虚概念，只输出务实干货。

期待和你的交流！