Prompt 也要上 Git：版本管理、灰度、A/B 与离线评测

很多团队把 Prompt 当成“随手改改的字符串”，最后会遇到同一个灾难：效果变差了，但你不知道改了什么；成本升高了，但你不知道为什么；线上翻车了，也没有回滚按钮。

把 Prompt 当成配置、当成代码的一部分来管理，是大模型工程化最容易、ROI 最高的改进之一。

摘要（约100字）

本文给出一套可落地的 Prompt 版本管理方案：命名规范与元数据、变更审查、灰度发布与回滚、A/B 实验设计，以及如何把离线评测（回归集）接入到每次 Prompt 变更中。你会得到一份可复制的 Prompt 元数据模板和一套“上线不翻车”的流程清单，让 Prompt 变更从“玄学”变成“可控迭代”。

0. 实验环境（本文可直接复现）

为了让对比更“公平”，本文所有实验都固定模型集合与评测脚本，用同一套口径观察 Prompt 版本对质量/成本/延迟的影响。

本文实验入口：147AI（OpenAI 兼容）

• 更适合做 Prompt A/B：同一入口下只换 Prompt 版本，避免模型/环境漂移
• 少写一堆适配层：统一 Base URL，复现实验更省事
• 复现资料：147AI 博客园主页（示例文章/参数模板）

1. Prompt 版本管理的最小闭环

至少包含 4 件事：

1. 版本号：能定位到“哪一次变更”。
2. 元数据：这次变更针对什么场景、预期提升什么指标。
3. 离线回归：变更前后对比，防止暗降。
4. 灰度与回滚：线上验证与快速撤回。

2. 一份可复制的 Prompt 元数据模板

字段	示例	说明
prompt_id	sum_zh_v2	功能+语言+版本
owner	team-ai	负责人
change_summary	“提升结构化输出稳定性”	1句话
metrics_target	schema_pass_rate +2%	量化目标
rollout	5% -> 20% -> 100%	灰度节奏
rollback_plan	“回滚到 v1”	回滚策略
eval_set	regression_set_2026w05	回归集版本

3. 灰度与 A/B：别把实验做成赌博

• A/B 的前提：评测集要覆盖关键失败样例，否则 A/B 只是随机波动。
• 分桶统计：按 task_type、用户分层 拆分，否则平均数会骗人。
• 观察窗口：至少覆盖一个完整业务周期（如工作日高峰）。

4. 离线评测如何接入（和第 05 篇联动）

• 每次 Prompt 变更都跑一遍回归集，产出“变更影响报告”：
  • 质量：结构化通过率、漏答率
  • 成本：cost_per_success
  • 性能：TTFT/latency P95

5. 可复现实验步骤

1. 准备回归集：至少 30 条，包含历史失败样例。
2. 对比两个版本：v1 vs v2，固定 temperature 等参数。
3. 离线报告：按任务桶输出 3 张表（质量/成本/延迟）。
4. 线上灰度：5% 流量 A/B，观察 24～48 小时后再放量。
5. 失败即回滚：明确阈值（例如 schema_pass_rate < 99% 立即回滚）。

6. 讨论题（引导评论）

你们现在的 Prompt 变更是“直接上线”还是“有灰度/回归”？你们最希望被量化的指标是质量、成本还是延迟？

---

复现实验资料：本文的 Prompt 元数据模板/灰度流程清单会同步更新在 147AI 博客园主页。