1、PRD的本质：为什么AI产品需要PRD？
说实话，我见过太多AI项目翻车了。
不是技术不行，是压根没人想清楚要做什么。你想想看，一个团队吭哧吭哧训练了三个月模型，结果发现业务方要的根本不是这个——这种场景，我经历过至少五次。
所以今天咱们聊聊PRD。说白了，它就是AI产品的「施工图纸」。
1.1 为什么AI产品需要PRD？
传统软件PRD大家都很熟，但AI产品的PRD有个本质区别——不确定性。
传统软件的逻辑是确定的：用户点A按钮，系统执行B操作。但AI产品呢？模型输出可能今天和明天不一样，数据分布变了效果就崩了。这种「不可控」才是AI产品最大的坑。
我个人的习惯是，AI产品的PRD必须回答三个核心问题：
- 输入是什么？——数据从哪里来，格式是什么，质量怎么保证
- 输出是什么？——模型要预测什么，准确率多少算及格，什么情况算失败
- 边界在哪里？——模型做不了的怎么办，降级方案是什么
核心观点：AI产品的PRD不是写功能的，是写「预期管理」的。它要告诉所有人：这个模型能做到什么，做不到什么，以及做不到的时候我们怎么办。
举个例子。我之前做过一个智能客服项目，业务方说「我要一个能回答所有问题的机器人」。这听起来很美好对吧？但实际做起来，你会发现用户问「今天天气怎么样」和「我的订单为什么还没到」完全是两码事。如果没有PRD把场景切分清楚，开发团队会陷入无休止的「加需求」循环。
1.2 PRD在AI开发流程中的位置
AI开发流程，我一般分成六个阶段：
| 阶段 | 核心工作 | PRD的作用 |
|---|---|---|
| 需求分析 | 业务方沟通、场景定义 | 明确目标，划定边界 |
| 数据准备 | 数据采集、清洗、标注 | 定义数据规格和质量标准 |
| 模型开发 | 特征工程、模型训练 | 提供评估指标和验收标准 |
| 模型评估 | 离线测试、A/B测试 | 判断是否达到上线标准 |
| 部署上线 | 模型部署、监控搭建 | 定义降级和回滚策略 |
| 持续迭代 | 数据回流、模型更新 | 记录版本和效果变化 |
你看，PRD不是只在开头写一份就完事了。它贯穿整个流程，每个阶段都要回头对照PRD，看看有没有偏离。
我曾经遇到过一个项目，数据团队花了两周时间清洗数据，结果发现标注标准和模型需求完全不匹配——标注的是「情感极性」，模型要的是「意图分类」。这就是典型的PRD没写清楚数据规格的后果。
1.3 PRD的核心价值
总结下来，PRD对AI产品的核心价值有三点：
- 对齐预期——让业务方、产品经理、算法工程师、工程团队对「做什么」达成共识
- 降低风险——提前识别数据、模型、工程层面的风险点，避免后期返工
- 提供基准——模型效果好不好，不是靠感觉，而是靠PRD里写的指标
一个小技巧：我习惯在PRD里加一个「失败场景」章节。专门写模型表现不好时怎么办。比如「当置信度低于0.6时，转人工处理」。这个章节看起来不起眼，但上线后能救你无数次。
嗯，这里要注意一点。很多团队把PRD写成了「功能说明书」，列了一堆「系统应该支持XXX」。但AI产品的PRD，核心应该是「模型行为描述」——不是写系统有什么功能，而是写模型在各种输入下应该有什么表现。
举个例子：
❌ 错误写法：
系统支持用户上传图片进行识别
✅ 正确写法：
用户上传图片后，模型输出识别结果
- 图片清晰度达标时，识别准确率应 ≥ 95%
- 图片模糊或遮挡时，模型应返回「无法识别」并提示用户重新拍摄
- 识别耗时不超过 2 秒
你看，后者才是AI产品需要的PRD。它明确了输入条件、输出标准、异常处理。算法工程师看到这个就知道怎么调参，工程团队知道怎么设计接口，测试知道怎么写用例。
避坑指南：我曾经犯过一个错误——在PRD里写了「模型准确率应达到99%」。结果业务方拿着这个数字去跟客户承诺，最后模型死活达不到，整个项目延期两个月。后来我学乖了，PRD里的指标一定要加前提条件，比如「在测试集A上准确率≥95%，在测试集B上准确率≥90%」。这样既给了团队空间，也管理了业务方的预期。
最后说一句。PRD不是写给别人看的，是写给自己和团队的一份「契约」。它帮你把模糊的想法变成可执行的方案。没有PRD的AI项目，就像没有地图的探险——你可能走得很快，但大概率会走偏。
下一章，咱们聊聊怎么写一份好的AI产品PRD，从结构到细节，我会把我踩过的坑都告诉你。