核心要点
提示当代码管理：纳入版本控制，可 diff、可评审、可追溯
每个提示版本绑定评测集跑回归，分数达标才发布
支持线上 A/B 对比与一键回滚到上一稳定版本
记录模型、版本、temperature 等参数，保证结果可复现
标准回答
Prompt 是配置也是代码，必须可版本化、可回归、可回滚
提示词一改，效果可能整体变化却没有编译错误提示，所以要用工程化手段管控。
1. 当代码管理
- 提示存入版本控制（Git 或专用提示管理平台），每次改动留下 diff 与 commit message，经过 code review，可追溯「谁在何时为何改」。
2. 绑定评测做回归
- 每个提示版本关联固定评测集，发布前自动跑（见评测驱动开发），分数不达标或较基线退化则阻断，避免「改好一个场景、改坏三个」。
3. A/B 与灰度
- 新旧版本线上小流量对比，用业务指标 + 离线评测共同决定是否全量。
4. 可回滚 + 可复现
- 版本号与部署解耦，出问题可一键回滚到上一稳定版。
- 同时记录绑定的模型 ID、模型版本、temperature/top-p 等参数——因为换模型或参数会改变行为，复现问题必须固定这些。详见 Prompt 优化与评估。
常见误区
⚠️ 常见踩坑
把提示词硬编码散落在代码里随手改、不留版本与评测记录，出问题无法回滚也无法复现；只记提示不记模型版本与参数，导致行为无法重现。
追问
追问 1：为什么版本管理不能只记 prompt 本身？
因为同一个提示在不同模型、不同模型版本或不同 temperature/top-p 下行为差异很大。要复现某次结果或定位回归，必须把模型 ID、版本号和采样参数与提示版本一起记录、一起绑定评测，否则「同样的提示却得到不同结果」无从追查。
追问 2：提示词回归测试和普通代码回归测试有何不同？
普通代码回归多为确定性 pass/fail；提示回归面对非确定输出，需用评测集 + 阈值（通过率/分数）判定，关注的是整体指标是否较基线退化，而非逐条精确相等，且评测集需随业务持续扩充。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。