把提示词当代码管：版本、测试、回滚，一个都不能少

一个很常见的场景：线上回答质量下降，排查半天，最后发现有人在文档里改了提示词，系统在凌晨重新加载，没人知道是谁、为什么、改了什么。

提示词就是代码。 它决定行为、影响输出、会在没有警告的情况下改变系统。但它的管理成熟度，通常比代码落后五年。

一、提示词必须进版本库

最低标准：放在代码仓库里，随代码一起 review 和发布。不要放在文档、表格或某个后台的文本框里。

三条具体做法：

• 一个文件一个提示词，文件名即 ID，例如 prompts/support/reply_v3.md；
• 变量用显式占位符（{{user_name}}），渲染时做类型检查，不允许拼接字符串；
• 修改必须走 PR，PR 描述里必填两项：“改了什么行为”和“跑了哪些测试”。

进阶一点：把提示词拆成可组合的块（角色、约束、工具说明、输出格式），按场景组装。这样改一处约束不用复制十份文件，也避免十个提示词版本互相漂移。

二、每次改动都要有测试

不需要复杂框架，但必须有一个固定的评估集。最小可用版本：

• 20–50 个代表性输入，覆盖主路径 + 已知失败案例；
• 可判定的检查项，优先用规则（格式、必含字段、长度、禁止词），其次用模型裁判；
• 跑完存一份基线分数，与上次对比。

关键纪律：不通过就不发布。如果某次改动的收益是“语气更好了”，但让格式遵循率从 98% 掉到 90%，就该放弃——格式错误会直接导致下游解析失败，而语气好没人量化得出来。

三、灰度与回滚

提示词没有任何“编译期检查”，所以必须靠运行时保护：

1. 按流量比例灰度，先 5%，观察 24 小时；
2. 同时保留旧版本，回滚是切换配置而不是重新部署；
3. 设自动熔断：解析失败率、空回复率、平均长度异常波动超过阈值，自动切回旧版本；
4. 记录版本号到日志，每条回答都能追溯是哪个提示词版本产出的。

第 4 条最容易被省，但它是事后分析的唯一依据。没有它，你只能看到“昨天开始变差”，看不到“昨天切了哪个版本”。

四、三个真实踩过的坑

坑一：改提示词解决了 A，弄坏了 B。 提示词的修改几乎从来不是局部的。为“简短回答”加一句删减指令，往往同时删掉了必要的免责声明。所以评估集必须覆盖所有已知必须存在的元素。

坑二：模型升级后，提示词没动，行为变了。 提示词和模型是耦合的。换模型必须重跑评估集，不能假设“只是换了引擎”。

坑三：few-shot 例子越加越多。 例子能显著改善效果，但也会把输出往例子的风格上拉，同时推高成本和上下文长度。当例子超过 5–6 个，就该考虑把稳定规则写进指令，而不是继续堆例子。

五、一个落地顺序

如果团队现在什么都没做，按这个顺序补，一两天可以完成前两步：

1. 把线上提示词导出到仓库，打上当前版本号；
2. 建评估集（先 20 条，用真实线上问题）；
3. 加版本号日志；
4. 加灰度开关与回滚；
5. 把提示词改动纳入 PR 流程。

前两步做完，你已经能回答“上周改了什么”。这个问题回答不了，后面所有优化都是在盲飞。