Prompt 的版本管理与 CI

传统软件的逻辑在代码里，有 Git、有 CI、有回滚。AI 应用的逻辑有相当一部分在 prompt 里——但很多团队把 prompt 当成"配置字符串"随手改，结果：改了一句 prompt 线上就崩、想回滚发现没存历史、A/B 测试无从下手、谁改了什么没记录。

Prompt 应该当代码一样管。这篇讲怎么做。

一、Prompt 是逻辑，不是文案

一个关键认知转变：prompt 是产品逻辑的一部分，不是"文案"。它决定了模型怎么行为、输出什么格式、调什么工具——改 prompt 等于改业务逻辑。逻辑变更却没有版本控制和回归测试，早晚出事。

所以 prompt 理应享受代码的待遇：

• 版本化（Git）。
• 评审（PR）。
• 测试（评测集）。
• 灰度（逐步发布）。
• 回滚。

二、第一步：把 prompt 抽出来、进 Git

很多人 prompt 散在代码各处（"拼一个 system prompt"），改一次要找半天。第一步是集中 + 版本化：

• 把所有 prompt 抽到独立目录/文件（prompts/*.md 或 prompts/*.ts）。
• 进 Git，改动走 PR 评审。
• prompt 里带版本号 + 变更说明（注释或 frontmatter）。

prompts/
  customer_support.system.md    # 带 version: 1.2.0
  extraction.user.md
  README.md                      # 各 prompt 用途、变更原则

这一步零成本，但立刻获得"谁改了什么、为什么改、什么时候改"的可追溯性。

三、第二步：Prompt 和代码分离部署

进一步：prompt 不要硬编码进二进制/镜像，而是可独立更新。这样改 prompt 不用重新发版（发版要分钟到小时，prompt 调优要频繁迭代）。

常见做法：

• prompt 存配置中心 / DB / KV。
• 应用启动 + 运行时从配置加载 prompt。
• 改 prompt = 改配置，秒级生效。
• 但仍走 Git + 评审 + CI（配置的 source of truth 在 Git，CI 同步到配置中心）。

工具：Langfuse、Promptflow 等专门做 prompt 管理 + 版本 + 灰度。也可自己用 Git + 配置中心搭。

四、第三步：评测进 CI（最关键）

光版本化不够，要能判断"这次改动变好还是变坏"。这就回到评测：prompt 改动跑评测集，分数下降拦下来。

一套最小 CI 流程：

PR 改了 prompt
  → CI 触发: 跑评测集
      ├ 旧版 prompt 跑一遍(baseline)
      ├ 新版 prompt 跑一遍
      └ 对比各指标(faithfulness / 业务正确率 / 格式合法率)
  → 指标下降超阈值 → PR 检查失败(阻止合并)
  → 指标持平/上升 → 允许合并

这个 CI 是 prompt 工程化的分水岭。没有它，改 prompt 全凭感觉；有了它，每次改动有客观依据。评测集不必大（20–50 条覆盖核心场景即可），关键是有 + 每次跑。

五、第四步：灰度发布

即便评测过了，prompt 上线仍有风险（评测集覆盖不到的真实分布）。所以学代码的灰度：

• 影子流量（shadow）：新 prompt 跑真实流量但不返回给用户，对比新旧输出差异。
• 百分比灰度：5% → 25% → 100%，每档观察质量指标和用户反馈。
• 按人群灰度：先内部用户/小白鼠用户，再全量。

灰度让 prompt 改动的爆炸半径可控——出问题影响少数人，快速回滚。

六、第五步：可回滚

改 prompt 翻车了，要能秒回滚。要求：

• prompt 每个版本可寻址（版本号/commit）。
• 生产 prompt 配置指向某版本，切换即可回滚。
• 回滚不需要重新发版（prompt 和代码分离部署的价值在这）。

最好还能自动监控 + 一键回滚：质量指标突降（用户负反馈飙升、JSON 解析失败率上升），自动切回上一版。

七、团队协作：prompt 评审

prompt 不是工程师的专利——产品、运营、甚至领域专家都有发言权。但散在代码里，非工程人员没法参与。把它抽成文件 + PR + 评审后：

• 产品/领域专家能在 PR 里直接评论 prompt 措辞。
• 评测结果附在 PR 上，评审有数据支撑。
• prompt 变更有明确记录，便于复盘。

让懂业务的人参与 prompt 设计，是 prompt 质量的关键——纯工程师写的 prompt 常常"技术上对、业务上别扭"。

小结

把 prompt 当代码管，五步走：

1. 集中 + 进 Git：可追溯、可评审。
2. 和代码分离部署：改 prompt 不用发版。
3. 评测进 CI：改动有客观依据，下降即拦。
4. 灰度发布：爆炸半径可控。
5. 可回滚：翻车秒回。

这套做下来，prompt 工程从"凭感觉改字符串"变成"可回归、可灰度、可回滚的工程"。它的投入比想象小（评测集 + CI 是大头），但回报巨大——大多数 AI 应用的线上事故，都源于"改了一句 prompt 不知道为什么就崩了"。把 prompt 纳入工程化，是从"demo 跑得好"到"生产稳得住"的必经一步。