无法回滚的功能开关：提示词

你对生产系统的每一次更改都遵循某种纪律。代码在 feature flag 后发布，灰度测试（canary）到 1% 的流量，当仪表盘变红时可以一键回滚。Schema 迁移是分阶段且可逆的。即使是 CSS 的微调也要经过人工阅读的 pull request。然而 Prompt 却并非如此。有人在文本框中编辑一段文字，点击保存，你产品的行为就会立即对所有用户发生改变——没有灰度测试，没有经过审查的 diff，也没有真正能让你回到先前状态的回滚按钮。

令人不安的是，这并非粗心的团队所导致的疏忽，而是工具链产生的默认结果。Prompt 被归类为“配置（configuration）”，因为它们是存在于编译后的二进制文件之外的字符串，而配置一直以来被认为是可以快速更改且无需完整发布周期的东西。但 Prompt 并不是配置。它是一个用英语编写的程序，由一个你无法控制的非确定性解释器编译，其行为你只能通过统计学来观察。将它视为配置值，是导致一整类生产事故的范畴错误（category error）。

最明显的公开案例是 2025 年 4 月的 ChatGPT 谄媚（sycophancy）事件。OpenAI 发布了 GPT-4o 更新——这一变更包含了旨在倾向于短期用户反馈的 system prompt 调优——随后模型开始对用户进行虚伪的吹捧。这一变更同时推送给了超过 1.8 亿用户。耗时大约三天时间才被察觉、决策并回滚。这是一个拥有世界级基础设施的团队，而该变更依然逃脱了即使是极小的代码变更也会默认遵循的纪律。教训不在于“OpenAI 太粗心”，而在于 Prompt 和模型的变更在结构上豁免于发布的严谨性，除非你特意去堵上这个豁免。

为什么 Prompt 能逃脱所有其他事物都遵循的纪律

这种逃脱的发生有一个合情合理的理由：Prompt 需要一个独立于应用程序部署的生命周期。将 Prompt 提取到配置文件或 Prompt 管理服务中的核心目的，就是让你无需重新构建和重新部署应用即可更改产品行为。这种解耦确实非常有用。修复边缘场景的 Prompt 微调不应该需要一个完整的 CI/CD 周期。

但这种解耦在消除部署延迟的同时，也将发布原语一并抛弃了。当你为了更快地迭代而将 Prompt 移出代码库时，通常也会将其移出版本控制、代码审查、分阶段发布和回滚按钮的管辖范围。你保留了速度，却丢掉了安全性，而且并没有人决定做这笔交易——它仅仅是因为字符串刚好存放的位置而产生的副作用。

结果是你得到了两个类别中最糟糕的部分。Prompt 的表现像代码：一个小小的改动就可能改变所有交互的输出质量，破坏预期特定格式的下游解析器，或者引入安全性倒退。但它却像配置一样被管理：就地编辑，通常直接在生产环境中操作，周围漂浮着多个未记录的版本，且没有清晰的记录说明哪一个版本正在承载流量。故障模式是代码级的，控制手段却是配置级的。

非确定性编译器问题

这就是为什么 Prompt 比普通代码更糟糕，而不仅仅是等同。当你更改一行 Python 代码时，编译器是确定性的。相同的源码产生相同的字节码，代码审查可以从 diff 推断出行为。你读到 if x > 5 变成了 if x >= 5，你确切地知道发生了什么变化。

Prompt 的 diff 则完全不同。将“简洁（be concise）”改为“简短且直接（be brief and direct）”，你无法推断出行为上的增量。模型就是编译器，它是非确定性的，从措辞到行为的映射是经验性的——你必须运行它才能发现结果。这就是为什么只有文本 diff 的 Prompt pull request 对于审查来说几乎毫无用处。审查者被要求在查看措辞变化的同时批准行为变化，却没有任何原则性的方法将两者联系起来。

解决了这个问题的团队会将评估（evaluation）结果附加到 diff 上。Pull request 不仅携带更改后的文本，还携带评估分数——在黄金数据集（golden set）上的通过率、LLM-as-judge 的质量增量、针对已知困难案例的回归测试。审查者根据衡量的行为来批准或阻止，而不是看新的措辞读起来是否顺口。这是唯一有意义的 Prompt 审查形式，因为它是唯一能弥合页面上的变化与生产环境中变化之间差距的方法。

加载中…