提示词版本管理（Prompt Versioning），就是像管理代码一样管理提示词：每次修改都有版本号、变更说明和记录，能对比、能回滚、能灰度发布，还能把线上效果归因到具体版本。
打个比方。后厨菜谱上写着“盐少许”。张师傅今天随手改成“盐半勺”，没告诉任何人。第二天客人投诉太咸，你翻记录也找不到谁改的。提示词就是 AI 产品的菜谱。它看着只是一段自然语言，却直接决定输出格式、语气和边界。改一个词，客服机器人可能从“礼貌拒绝”变成“乱承诺”，也可能让下游程序解析失败。
把提示词当代码管，至少做四件事：
- 改动留痕：唯一版本号，记录作者、时间、变更说明和评测结果。
- 可回滚：线上出问题，一键切回上一版。
- 灰度发布：先给少量流量或内部用户，观察指标再放大。
- 归因：日志记录本次请求用了哪版提示词，效果好坏能定位到具体改动。
它和相邻概念不同：提示词工程（Prompt Engineering）关心“怎么写好”；模型版本管理（Model Versioning）关心“换不换底层模型”；A/B 测试（A/B Testing）关心“怎么比较两个版本”。提示词版本管理是承载这些动作的基础设施。
| 维度 | 提示词版本管理 | 模型版本管理 |
|---|---|---|
| 改动对象 | 提示词文本 | 模型权重或服务版本 |
| 改动成本 | 极低，几分钟 | 较高，需部署评估 |
| 常见风险 | 随手改、无记录、难回滚 | 流程重、影响面大 |
| 关键动作 | 留痕、对比、灰度、归因 | 评测、发布、监控、回滚 |
反直觉的是，提示词改动往往比模型升级更容易出事故。模型升级有明确版本、发布说明和评审，大家会紧张；提示词改动却被当成“改句话”，在后台文本框里就能生效，没有评审、没有回归测试、没有回滚预案。可它同样影响所有用户，而且更隐蔽：模型没换，输出却变了，排查时容易先怀疑模型，绕一圈才发现是提示词。
对从业者，实用做法：把提示词放进版本库或提示词管理平台，上线前跑固定评测集，灰度放量，日志带上版本 ID，出问题先回滚再分析。对普通职场人，“AI 回答变了”不一定是模型升级，可能只是有人改了提示词。遇到异常时，多问一句“最近改过提示词吗？能回滚吗”，往往比反复调参数更快定位。具体工具与流程以团队规范和官方页面为准。