AI 功能的 PRD：为什么你的旧模板会让你在悬崖边失足

确定性软件的 PRD 模板已经演变成了一种肌肉记忆。问题陈述、用户故事、验收标准、边缘情况、成功指标、范围削减。工程师知道如何阅读它，产品经理（PM）知道如何填写它，设计师知道该从哪些章节提取原型图。这是一个被磨损得恰到好处的产物，它交付了一代又一代的 CRUD 应用、仪表盘和 SaaS 工作流。

它也没有“模型在 5% 的情况下会出错”的字段，没有“我们接受的评估（Eval）合格分”的字段，没有“当模型拒绝回答时用户会看到什么”的字段，也没有“该 PRD 锁定了哪个提示词（Prompt）版本，以及发布后允许谁进行更改”的字段。每一个按照这种模板交付的 AI 功能，都带有一份谁也没写下来的隐性契约。复盘总是让人们在遭遇挫折后才痛苦地意识到这一点。

这种差距并非风格上的不匹配。确定性的 PRD 假设系统通过一个行为预先已知的函数将输入映射到输出。工程师可以枚举边缘情况，因为其表面是有限的。QA 可以编写测试用例，因为同样的输入会产生同样的输出。验收标准可以是一个检查列表，因为通过或失败是明确的。对于一个核心逻辑是随机模型的功能，这些假设都不成立。

当 PM 将旧模板的 PRD 交给 AI 工程团队时，会发生三件事：PM 编写了他们无法测试的验收标准；工程师针对一个未指定的标准进行交付，并希望没人注意到；设计师只画出理想路径（Happy path）的屏幕。接着功能上线了，模型在一类没人命名的输入上表现糟糕，团队在事故频道中发现——每个人脑子里的隐性契约并不相同。

解决方法不是写更长的 PRD。解决方法是增加四个新章节，将系统的概率性质写入文档，以便在任何人编写代码之前使契约变得明确。

行为矩阵取代验收清单

一个确定性的验收标准看起来是这样的：“给定一个具有管理员角色的用户，当他们点击删除时，记录被移除，审计日志被更新。”它之所以有效，是因为输入空间是可枚举的，且输出是二进制的。

对于 AI 功能，输入空间实际上是无限的，而输出是一种分布。你不能写“给定一个用户提示词，当他们点击提交时，模型返回正确答案”——对于“正确”没有行级别的定义。你能写的是行为矩阵（Behavior Matrix）：一张表格，其行是功能必须处理的输入类别，其列是每个类别可接受的失效模式。

一个支持摘要（Support-summarization）功能可能有这样的行：“带有截图附件的工单”、“非英语语种的工单”、“关于产品领域以外主题的工单”、“消息情感混杂的工单”。对于每一行，矩阵都会命名一个目标行为、一个可接受的降级方案和一个禁止的输出。非英语行可能会说明——目标：以用户语言生成摘要；可接受的降级：以英语生成摘要并带有语言检测免责声明；禁止：静默翻译，对人工座席隐藏原始语言。

矩阵强制进行了 PM 和工程师以往通过依赖检查列表而规避的对话。它让 PM 承诺哪些输入类别在范围内，让工程师承诺哪些失效模式是可忍受的，给设计师一张拒绝和降级状态的地图去绘制，而不仅仅是一个理想路径的屏幕。它还为 QA 提供了尊重系统概率性质的可测试项：矩阵是针对样本而非单个案例进行评估的。

评估集标注指明发布的分数阈值

确定性 PRD 有一个“成功指标”章节，命名了业务结果——转化率提升、留存率、NPS。这些仍然属于 PRD。但对于 AI 功能，文档还需要一个作为发布门槛的质量标杆，且该标杆存在于评估空间（Eval-space），而非指标空间（Metric-space）。

这个标注包含三个部分。首先是数据集：一个命名的、有版本的评估集（Eval set），团队将针对该集合运行功能测试。它可以是人工筛选的代表性输入集、从生产环境采样的切片，或者是为团队无法有机收集的类别生成的合成集。PRD 中通过名称和版本引用数据集，以便“我们运行了评估”具有单一且明确的含义。其次是指标：将该数据集上的模型输出转化为分数的函数。它可能是精确匹配（Exact match）、BLEU、评分制的 LLM-as-judge 准则、人工评分的质量分数，或其组合。第三是阈值：功能在发布前必须达到的分数，以及必须回滚的分数下限。

大多数团队都会掉进一个陷阱：让工程师在事后通过一条没人存档的 Slack 消息来设定阈值。如果没有在工作开始前将数字写入 PRD，“我们运行了评估”就会变成一种仪式，其结果在会议中被社交化讨论后便被遗忘。正确的模式是团队用于性能预算（Performance budgets）的模式：文档中的一个数字，由 PM 负责，预先进行辩论，并且只能通过带有书面记录的显式修订来更改。

加载中…