打开过去六个月内发布的任何 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，团队就失去了阐述产品应该做什么的能力。
将 PRD 视为必须通过 Eval 的 Prompt 草案
解决这个问题的准则并不是“用 prompt 格式编写 PRD”。这是一个错误的做法——PRD 承担着真实的人类对齐工作，这是 prompt 无法替代的。这项准则是：将起草 prompt 作为 PRD 的一部分，为了评审目的将它们视为同一个产物，并要求两者在签收（sign-off）前都必须通过 eval。
具体来说，PRD 流程增加了几个新阶段。在需求编写完成后，工程师（或在工程师协助下的 PM）起草第一版系统 prompt，将需求转化为可操作的指令。这并不是最终的 prompt——这是一次翻译练习，而这一过程中的摩擦会暴露 PRD 中所有定义不明确的地方。（“我们该如何表述拒绝？”“等等，什么拒绝？——我们没讨论过拒绝的情况。”）
接着是 eval。这不是最终产品的 eval——而是一个 PRD 阶段的 eval，包含 20 到 50 个案例，用来检验 PRD 所声明的行为。其中一半的案例应该是对抗性的：PRD 验收标准中未提及的输入、没人想到要测试的边缘情况、模糊的用户意图。针对 eval 运行 prompt 草案。通过率是衡量 PRD 散文式描述转化为运行时行为效果的指标。如果 prompt 通过了 95% 的案例，说明 PRD 大致是可执行的；如果只通过了 60%，说明 PRD 在行为契约的定义上存在缺失，而这些缺失现在你可以看到并修复。
修复过程是迭代的。eval 暴露出的每一个失败模式都会追溯到 PRD：哪一句话导致了这种错误行为？要么收紧 PRD，要么给 prompt 增加新指令，或者两者兼而有之。最终签收的产物包括 PRD、prompt 草案和 eval 评分卡。PM 签收的是一个经过测试的行为契约，而不是一个经过讨论的愿望。
当团队真正采用这种模式时会发生什么
会发生两个结构性的转变。首先是 PM 的写作水平在选择压力下得到提升，这种方式就像代码评审成为标准后工程师的写作水平得到提升一样。PM 看到自己的含糊其辞（hedges）导致 eval 失败后，就会停止含糊。PM 看到矛盾的约束条件导致不可预测的结果后，就会开始明确立场。PRD 变得更短、更具指导性、更容易翻译——这并不是因为 PM 在做 prompt 工程，而是因为 eval 在教他们什么样的文字能经受住从人类读者到模型读者的转换。
其次是 prompt 变成了一个共同创作的产物，而不是一个黑盒实现。PM 不写 prompt，但他们会阅读它。他们知道它的存在。他们可以指出执行他们所关心的拒绝政策的那行指令。当线上事故追溯到某条 prompt 指令时，PM 可以参与诊断，因为 prompt 不再是一个外来物。这终结了“我签收的是这份 PRD，为什么机器人会做 X”这种对话，这种对话通常会浪费上线后复盘整整一周的时间。
还有一个元收益（meta-benefit）：eval 测试套件的寿命比 PRD 更长。PRD 是为发布而写的，然后就被遗忘了。在 PRD 阶段评审期间编写的 eval 案例，将成为该功能生命周期内的回归测试套件。当模型迁移导致行为异常时，eval 能捕捉到。当 prompt 补丁修复了一处却破坏了另一处时，eval 能捕捉到。PRD 阶段的 eval 是团队将在未来几年不断补充的行为测试套件的第一笔存款。
这种准则在什么时候值得这些摩擦
并非每个 PRD 都需要这样做。将 LLM 作为内部辅助工具的功能——代码审查建议、草稿摘要，任何有人类始终检查输出的场景——基本上可以沿用旧的“先 PRD 后实现”流程，因为人就是 eval。对齐失效的成本受限于人类能发现多少。
在 模型的输出即产品 的功能中，这种准则的价值就体现出来了。聊天界面、自主代理、任何代表用户执行操作的东西、任何与客户交流的东西。任何行为倒退是面向客户的 bug 而非面向开发者的 bug 的场景。在这些功能中，PRD 不仅仅是在对齐利益相关者——它在定义一个将被执行数百万次的行为契约。将其视为未经测试的 prompt 并让 eval 发现定义不明确的地方，是解决此类 bug 最廉价的方式，否则线上版本的 bug 将代价高昂。
这一切背后更深层的意识是，在模型即产品的功能中，PM 工作与 AI 工程工作之间的边界比旧的组织架构图所示要薄得多。PRD 是工程，prompt 是产品，而 eval 则是它们的交汇点。在签收流程中建立这种交汇点的团队，在发布 AI 功能时会遇到更少的意外。不这样做的团队将继续感到意外——并继续归咎于模型，而他们实际交付的产物其实是一份无人编译的 PRD。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
