Prompt 即文档：当系统 Prompt 成为唯一可信的交付物时

一位产品经理在 Slack 上私聊你，询问当客户要求助手取消订阅时会发生什么。你开始凭记忆输入答案，然后又自我怀疑，于是打开系统提示词读了 30 秒。你粘贴回一份摘要。他们向你道谢后继续忙别的了。三小时后，支持团队问了同样的问题。到了周四，合作伙伴负责人把提示词的截图贴进了交易审查中。

这就是“提示词即文档”（prompt-as-documentation）反模式。当你第一次意识到这种情况发生时，感觉会很棒。你花了六个星期调优的制品，现在成了产品功能的权威真理来源。产品经理在读它，支持团队在读它，销售团队在读它，甚至某个角落的设计师也在读它。你的工作成了支柱，这在以前的服务层代码中从未有过。你可以通过计算有多少不相干的人能凭记忆调出这个文件来证明这一点。

这种良好的感觉大约持续一周。然后，一位客户用了一个你的 few-shot 示例从未预料到的短语申请退款，模型即兴发挥，支持工程师读了提示词，告诉客户机器人会执行 X，结果机器人执行了 Y，客户投诉升级。你整个周五都在向三个人解释，“提示词写了什么”和“模型做了什么”并不是同一个制品。它们相关，但不等同。这种区别一直是过去一个季度里每个棘手调试环节的根源，而不知为何，房间里竟然没一个人感到惊讶。

这值得仔细思考，因为起因是真实的。提示词确实是你拥有的最及时的制品。禁止阅读提示词是错误的解决方法。正确的做法是构建那些理应比提示词更及时的制品，并教导组织提示词到底代表了什么。

为什么提示词默认胜出

PRD 已经有六个月历史了。它是在 eval 集出现之前、在迁移到更小模型之前、在法务团队要求你增加税务建议拒绝模式之前编写的。PRD 描述的是功能；而提示词描述的是功能，外加 17 个补丁、4 个后续事件，以及创始人在看完竞争对手演示后的午夜加进去的两段话。按任何衡量“产品今天到底能做什么”的合理标准来看，提示词都赢了。

Wiki 页面更糟。Wiki 描述的是宣讲时的产品，而不是交付时的产品。其中一半内容引用的是两个模型版本前的模型行为。没人更新它，因为没人读它；没人读它，因为没人更新它。

发布说明是营销产物。它们描述表面变化（“我们优化了取消流程中的语气”），而不描述机制（“我们在系统提示词中增加了三句话并收紧了一个 few-shot 示例，副作用是机器人现在拒绝处理讽刺”）。想要预测边缘情况行为的产品经理无法从发布说明中进行推导。相比之下，提示词包含了实际的指令。一位有积极性的读者可以在脑海中模拟机器人的反应（虽然模拟得很烂），但这总比没有好。

因此，由于自然损耗，提示词成了规格说明书。不是因为有人决定让它成为规格，而是因为它成了唯一被迫保持最新的文档。所有其他制品都会衰减。提示词不会，因为它是运行环境（runtime）。

提示词不是什么

提示词是概率系统的输入。模型执行提示词的方式不像编译器执行源代码。它在以提示词为条件的分布中进行采样。同一个提示词会产生不同的输出，这取决于用户的措辞、对话历史、时间（如果检索到的上下文随时间变化）、模型版本（如果你的供应商在没通知你的情况下更新了模型），以及你在预发布环境设为 0.7 却在生产环境忘了设为 0.2 的温度值（temperature）。

这并非一个小瑕疵。这正是“提示词即文档”反模式危险的根本原因。

非工程师在阅读提示词时，会假设机器人会按照提示词所说的去做。提示词写着：“如果用户要求退款，询问他们是哪个订单，然后检查政策，最后提供全额退款或商店余额。”因此，当支持团队询问“机器人会提供商店余额吗？”时，支持工程师读到那一行，说是的，并告诉已经等待了两小时的客户他们将获得商店余额。结果客户得到的是全额退款，因为模型判定客户的语气过于沮丧，不值得冒险尝试“商店余额”这个分支。提示词没有撒谎，只是提示词并不等同于实际运行逻辑。

提示词中的条件逻辑读起来像确定性的英语。“如果 X，那么 Y。”受过代码训练的读者会将其视为分支。而模型将其视为在来自提示词其余部分和对话的沉重噪声下的微弱偏好。Few-shot 示例读起来像支持行为的罗列。其实不然——它们是模型进行插值的演示。读者推断出的是契约。但提示词不是契约。它更像是一封语气强硬的建议信，模型在阅读它的同时，依然在自行其是。

模型还会根据长度、位置、近期性以及哪些 token 恰好落在该轮的注意力模式中，来忽略提示词的部分内容。生产团队发布过一些提示词，其中整段话在结构上都是失效的——它们要么超出了模型的有效注意力窗口，要么被更近期的指令抵消了，要么被消耗上下文配额的冗长检索块淹没了。提示词看起来做了一件事，模型却做了另一件事。几周来都没人发现，因为涉及这些问题的少数案例足够罕见，完全可以归咎于用户操作失误。

加载中…