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 负责，预先进行辩论，并且只能通过带有书面记录的显式修订来更改。

标注还设定了评估集本身何时可以更改的规则。每个团队最终都会面临模型或提示词的更改，这些更改在现有评估集上得分很高，但用户感觉更糟。解决方法是扩展评估集——但扩展必须是一个刻意的事件，并且对当前发布版本所衡量的评估集版本的阈值更改进行冻结。如果没有这条规则，评估集就会变成一个移动的目标，总是与团队想要发布的任何内容保持一致。

回退规范：将拒绝、超时和工具故障视为功能

在确定性系统中，错误处理只是技术规范中的一个段落。而在 AI 功能中，拒绝和降级是用户可见产品的一部分，需要经过专门设计。

回退规范（Fallback Specification）中列出的行，应当是团队认为不属于 Bug 而是可接受的运行时状态的故障类型。拒绝回答（Refusal）：模型由于请求触及安全边界而拒绝响应。超时（Timeout）：模型或智能体依赖的工具未能在预算时间内返回结果。工具故障（Tool failure）：结构化工具调用返回了错误或格式错误的输出。置信度崩塌（Confidence collapse）：模型自身的评分信号低于团队设定的阈值，且团队决定与其提供糟糕的回答，不如不回答。上下文溢出（Context overflow）：输入超过了工作窗口，系统不得不进行截断。

针对每一行，规范需明确两点：用户看到什么，以及系统接下来做什么。面向用户的回答是设计师的工作——文案、布局、是否提供重试按钮、故障是直接可见还是隐藏在委婉的“我不知道”之后。系统侧的回答则是工程师的工作——输入是否转发给更小、更便宜的模型，是否进入人工审核队列，是否向调用代码显现结构化错误，或者是记录日志后继续运行。

这一章节揭示了一个事实：AI 功能拥有比确定性系统的二进制“成功/失败”丰富得多的错误空间，而这个错误空间正是用户体验的一部分。一个能优雅处理拒绝的功能，与一个只会抛出通用错误或（更糟的是）在模型不确定时一本正经地胡说八道的功能，感觉上是完全不同的产品。回退规范就是你决定交付哪种产品的地方。

提示词所有权字段：明确发布后谁可以更改行为

这一部分在传统的 PRD 中没有类比，因为确定性功能不会包含一个长达千词、能实质性改变行为且任何有代码库访问权限的工程师都能在五秒内修改的配置字符串。

系统提示词（System Prompt）是一份用英语编写的行为合约。一个小小的改动——增加一句关于语气的描述、删除一个拒绝条款、更换一个示例——就可能将该功能转化为一个截然不同的产品。如果你像对待常量文件一样对待这个字符串，团队最终就会遭遇“提示词漂移”（Prompt Drift）：生产环境中的版本不再与评估集评分时的版本匹配，而且没人能说清这种分歧是什么时候发生的。

PRD 的这个字段包含三个位置。所有者（Owner）：被允许合并系统提示词更改的角色或具体人员。审批路径（Approval path）：更改在合并前必须经过的审查——至少要以通过的分数重新运行评估集，通常还需要一名非作者的人工评审员。版本控制（Versioning）：提示词存放的位置，使得每一次生产环境请求都能追溯到特定版本，且回滚只需一次简单的提交撤销。这些都不是什么新颖的基础设施工作——团队几十年来一直在对代码进行类似的操作——但 PRD 是确立这种纪律的契约所在地，因为模型调优团队通常不会默认遵循这些规范。

同一个字段也涵盖了工具定义、评估集本身，以及任何行为变动在功能上等同于代码更改、但有时被视为内容的资产。任何会改变生产环境中功能表现的因素，都需要在规范中明确所有者和审批路径。

跳过这些内容的组织成本

关注这些并非为了追求文档的整洁，而是因为确定性 PRD 编码了一套跨职能契约——产品经理承诺什么，工程团队签约构建什么，设计方案画什么，测试团队针对什么进行测试。如果 AI 功能没有更新模板，交付时这些契约就会在关键环节缺失。

产品经理编写了工程师无法满足的验收标准，因为这些标准假设了确定性。工程师根据产品经理未曾见过且无法质疑的内部阈值进行交付。设计师画出了理想路径的界面，因为故障空间从未被枚举。测试团队针对某个快照编写测试用例，观察它们通过了一周，然后模型更新上线，所有的快照在一夜之间全部失效。领导层阅读了 PRD 并得出功能进展顺利的结论，因为文档对真正起支撑作用的部分保持了沉默。

当事故发生时——事故总会发生——复盘（Postmortem）会重新构建缺失的契约。有人会写一份文档描述该功能本应处理的输入类别。有人会写一份文档描述本应作为发布门禁的评估阈值。有人会写一份文档描述被跳过的回退路径。这些文档本质上就是原规范中从未出现过的 AI-PRD 章节。这些工作无论如何都会发生；区别在于，你是选择在功能发布前、当成本低廉且处于理论阶段时完成它，还是选择在发布后、当代价高昂且处于直播状态时完成它。

捷径是更新一次模板，从此不再接受缺少这四个章节的 AI 功能说明书。这不是为了增加流程负担，而是作为一种强制机制，促成那些无论如何都必须进行的对话。确定性 PRD 带领行业走过了上一代产品。下一代产品需要一份真正了解自己在交付什么的文档。