故障复盘：根本原因竟是一个无人负责的提示词

故障复盘进行得非常顺利，直到遇到了一个没人能回答的问题。下午 2:14，结构化输出错误激增，某个收入工作流停滞了 90 分钟。时间线还原得很清晰：三周前，有人修改了系统提示词（system prompt），多加了几个关于“对话语气”的词，这在特定输入下悄悄导致模型偏离了 JSON 契约。修复方法很简单，只需一行代码回滚。但接下来的部分很难：有人问是谁做的改动，谁审核的，以及未来哪个团队负责维护这个提示词。房间里陷入了沉默。没有 Pull Request，没有审核人。改动是某个人在晚上 11 点通过厂商控制面板操作的，而那个人已经不记得这回事了。

那种沉默才是真正的事故。JSON 契约的失效只是症状。根因在于，系统中杠杆率最高的一处行为逻辑，竟然没有负责人，没有变更历史，也没有走任何管理其他生产环境变更的流程。模型没有出错。模型完全按照指令行事。失败之处在于，“指令”本身完全脱离了变更管理。

这是目前最常见的生产环境 AI 事故之一，而且几乎从未被正确命名。复盘报告在根因栏写下“提示词退化（prompt regression）”然后就此揭过。但“提示词退化”描述的是代码表现。真正的根因是组织架构图上的一个漏洞。

提示词是如何脱离流程的

没有人决定免除对提示词的审核。它是通过“渐进式积累”发生的，这个路径值得追踪，因为它解释了为什么这种差距如此普遍。

它通常始于代码文件中的一个常量。在这个阶段，提示词处于版本控制之下纯属偶然——因为它存在于一个 .py 或 .ts 文件中，所以它拥有 diff 记录、代码追溯（blame line）和审核人，就像其他任何代码一样。这是生命周期中唯一一个提示词受到妥善治理的时刻，而团队往往在没注意到的情况下就跳过了这个阶段。

接着，摩擦出现了。提示词的迭代既快又频繁——远快于周围的代码。在收到真实用户反馈后，支持人员需要调整语气；当底层模型升级时，摘要器需要新的指令；在生成了一些令人尴尬的内容后，副驾驶（copilot）需要更严格的护栏。每一个改动都只是微小的措辞调整，而为了一个小小的措辞调整去走完整个 PR、CI 运行和部署流程，显得异常笨重。于是，有人将提示词移入配置文件，接着存入数据库行，最后放入带有可视化编辑器的提示词管理面板——而这种面板的核心卖点就是：你可以无需工程师、无需部署、无需等待即可更改提示词。

这在生产力上确实是巨大的进步，但也正是提示词离开“治理大楼”的过程。每一步都通过移除检查点“提升”了迭代速度。最终的结果是：一个控制生产环境中模型行为的字符串，可以被多个职能部门的人员编辑，却没有任何控制措施——diff、评审、负责人、回滚、审计追踪——而这些对于团队来说，在配置项（config flag）甚至业务逻辑中都是不可或缺的。

为什么提示词是最不该脱离管理的

你可能会争辩说，并非所有事情都需要沉重的审核。许多生产环境的配置编辑得很随意，也没出什么大乱子。问题在于，提示词是这种松散治理下最糟糕的候选对象，原因有三点。

它们拥有系统中最高的“单位字符行为占比”。 正如上述事故所示，三个词的改动就能让结构化输出的错误率产生数量级的波动。没有任何其他产出物能在修改一个句子后，就悄悄重写产品对每个用户的表现。具有同等影响半径的代码更改在评审中是不可能被忽略的，而具有同等影响半径的提示词更改看起来却像是在纠正拼写错误。

它们的失败是非局部的且延迟的。 错误的提示词编辑很少抛出异常，它改变的是分布。输出变得稍差一点、稍显冗赘、稍不太符合格式——而且只发生在你未测试的那一小部分输入中。变更发布时看起来很正常，仪表盘保持绿色，而退化在几天后才表现为下游指标的模糊上升。到那时，这次编辑已被埋在三周无关的活动之下，这正是此类事故诊断起来如此痛苦的原因。

它们处于组织的接缝处。 提示词是由最接近问题的人编写的——调整语气的 PM、解决重复投诉的支持主管、编写新功能的工程师。这很健康，领域知识理应存在于提示词中。但“最接近问题”并不等同于“对生产环境产出物负责”，大多数团队从未弥合这一差距。最适合编辑提示词的人在提示词出错时并不负责，而负责的人却看不到这些编辑。一份 2025 年对一千多个生产环境 LLM 部署的调研发现，运维纪律问题——漂移、版本控制、变更处理——是导致 Agent 失败的主要原因，远超模型本身的质量问题。模型很少是薄弱环节，提示词周围的流程才是。

揭示问题的复盘提问

加载中…