你的 PRD 只是一个未经测试的 Prompt —— 直到你对其进行评测

打开过去六个月内发布的任何 AI 功能的系统提示词（System Prompt），将其与授权该功能的 PRD 并排阅读。你会发现这两个文档在互相争吵。PRD 写道：“助手应该是提供帮助且专业的，避免胡编乱造，如果无法回答则体面地拒绝。”系统提示词则写道：“你是一个 AI 助手。保持简洁。如果不确定，说‘我不知道’。绝不捏造事实。”PRD 占了一整页。提示词只有九行。它们之间的鸿沟就是你本季度发布的所有行为 Bug 的所在地。

这种便利的虚构说法认为，提示词只是 PRD 的“实现细节”。实际关系恰恰相反。提示词是模型执行的契约；而 PRD 是由一个从未编译过它的作者用模型听不懂的语言编写的契约草案。每一个 AI 功能的 PRD 都是一个未经测试的提示词。那些承认这一点并在签字确认前通过评估（Eval）运行 PRD 的团队，发布的功能会少一个上线后产生意外的根源。

这并不是在争论 PM 是否应该写提示词。而是在争论你为 AI 功能签署的交付物必须按照评估运行时行为的相同标准进行评估，因为在实践中，两者最终会几乎完全相同。PRD 正在进行提示词工程。只是它自己还没意识到。

PRD 散文与提示词散文是不同的语言

传统的 PRD 是为人类共识而优化的。它带有修饰余地，包含感性语言（“令用户愉悦”）、矛盾的约束条件（“回答要详尽但保持简短”），以及假设读者可以通过询问办公室同事来消除歧义的语气说明。这些不是 PM 写作的缺陷 —— 它们是一个文档的功能，其主要工作是在工程师动键盘之前，让五个利益相关者对方向达成一致。

系统提示词是为不同的读者优化的。模型没有办公室可以去到处询问。“回答要详尽但保持简短”最终会取决于模型最后关注到的指令，并受到周围上下文偏置权重的修正。像“令用户愉悦”这样的愿景，会坍缩成基础模型训练分布所认为的“愉悦”，在任何一个普通的星期二，这通常介于“开头加个表情符号”和“在结尾段落使用三个感叹号”之间。PRD 的修饰余地并不是安全保障；它们是模型将为你解决的歧义，而你在上线生产环境之前都无法看到结果。

这种不匹配在三个地方表现得最明显。语气说明很难转化，因为 PM 散文中的语气是一种感觉（Vibe），而系统提示词中的语气是 Token 选择的概率分布。边界情况行为（“如果用户询问不恰当的内容，请体面地处理”）很难转化，因为模型需要知道什么是“不恰当”、什么是“体面”，以及该输出什么兜底字符串。验收标准也很难转化，因为 PM 将其编写为场景（“当用户询问 X 时，系统应该 Y”），而提示词需要将其作为模型可以应用于从未见过的输入的策略（Policy）。

将 PRD 视为权威的三种失败模式

当团队将 PRD 视为真相来源并将提示词视为实现时，会出现三种可预见的失败模式。

第一，沉默的重新解读鸿沟。工程师将 PRD 转化为提示词时，会做出数百个 PRD 未预料到的微决策：如何表达拒绝、约束条件的排列顺序、是否包含少样本（Few-shot）示例、将哪个护栏（Guardrail）放在提示词顶部还是底部（顶部通常获胜，但 PRD 从未说明哪个优先级最高）。PM 在 PRD 上签字；模型执行工程师的解读；没有人能指出它们在哪里发生了分歧，因为没有 Diff。

第二，仅针对 PRD 的行为测试。QA 根据 PRD 的验收标准编写测试用例。用例通过了。然后模型遇到了与测试用例完全不同的输入 —— 因为 PRD 测试用例源自 PM 对用户的想象，而真实用户要怪异得多。生产环境中的行为偏离了 PRD 的描述，但 PRD 从未声称除了自身之外还针对任何东西进行过测试，因此没有人能说清这种差距是一个 Bug 还是一个未定义的领域。

第三，上线后的提示词蠕变。生产流量暴露了 PRD 未能预测的失败模式。工程师修补提示词。每一次修补都是对契约的微小修正，但没有人将其更新回 PRD，因为 PRD 现在已是一个陈旧的产物，而提示词才是真实行为的所在地。六个月后，PRD 说一套，提示词做另一套，如果不阅读提示词的 Diff，团队就失去了阐述产品应该做什么的能力。

加载中…