S19-J02 · 提示词的版本管理与回归测试

适用读者：提示词散落在代码/文档/聊天记录里，改完不知道影响谁的人。
前置：S19-J01。
覆盖旧文：—（E 驱动）
覆盖扩展：E-S19-010（提示词仓库结构）、E-S19-011（参数与提示词分开版本化）。
上一篇：S19-J01 · 提示词评估：怎么判断"改好了"
下一篇：S19-A01 · 提示词资产化。

1. 一句话结论

提示词要像代码一样管理：进仓库、可 diff、可评审、可回滚；并且把"提示词"与"运行参数"分开版本化——因为它们的变更风险完全不同。

2. 仓库结构（E-S19-010）

prompts/
├── README.md                 # 约定：命名、变量、负责人
├── weather/
│   ├── system.v3.txt         # 提示词正文（版本在文件名）
│   ├── variables.md          # 变量清单与含义
│   ├── params.yaml           # 运行参数（temperature/top_p/模型）
│   └── CHANGELOG.md          # 变更记录
└── evaluation/
    ├── weather.cases.jsonl   # 回归集
    └── weather.score.json    # 最近一次评分结果

文件	作用	为什么要独立
`system.vN.txt`	提示词正文	用文件名做版本，diff 清晰
`variables.md`	变量契约	避免"改模板没改代码"
`params.yaml`	参数	与提示词分开版本化（E-S19-011）
`CHANGELOG.md`	变更理由	半年后能看懂为什么改
回归集与评分	证据	评估可复跑

3. 为什么参数要分开版本化（E-S19-011）

变更	影响范围	风险
改提示词	语义、格式、风格	中-高（不可预测）
改 `temperature`	稳定性/多样性	中（影响可复现）
改模型版本	全部行为	最高（可能整体漂移）

混在一起的后果：出问题时分不清是"提示词改坏了"还是"参数/模型变了"。

做法：params.yaml 与 system.vN.txt 各自独立 commit，变更记录里写清哪一类变了。

4. 变更记录模板

## v4 · 2026-11-05
- 类型：提示词 / 参数 / 模型（三选一，分开记）
- 改动：在 Directive 后新增 "若数据不足，先追问再回答"
- 原因：回归集 case 7/12 出现"编造数据"
- 回归结果：18/20 通过（v3 为 13/20）；新增失败：case 19（格式变长）
- 决策：采纳（case 19 由 Format 单元修复，见 v5 计划）
- 回滚方式：`git revert` + 重新部署 v3

判据："六个月后别人能看懂为什么改吗？" 不能 → 记录不合格。

5. 回归测试怎么挂到 CI

步骤	做法	注意
触发	提示词文件变更时	不要每次提交都跑全量
执行	跑回归集（可批量）	控制成本：抽样 + 全量夜间
判定	通过率不低于基线	允许"持平"，不允许"下降"
阻断	下降 → 阻断合并	与 S01-J02 的 CI 闸门同源

成本控制：回归集越大越贵。做法是分层跑——关键用例每次跑，全量每晚跑。

6. 五个误区

误区	真相
"提示词写在代码里就行"	无法评审、无法独立回滚
"参数和提示词一起 commit"	出问题无法归因
"改完直接上线"	没有回归就没有证据
"回归集越大越好"	成本爆炸；要分层
"模型升级不用重测"	模型升级是最高的风险变更

7. 自检

提示词仓库的四个核心文件分别解决什么？
为什么参数与提示词要分开版本化？
变更记录里必须写哪几项？
回归测试怎么挂到 CI？成本怎么控？
模型升级为什么是最高风险变更？

8. 下一篇

S19-A01 · 团队提示词资产化：从个人技巧到可维护资产

最后一篇从"个人维护"升到"团队治理"：权限、审计、成本与质量看板。

本篇属于系列《S19 · AI 素养与学习方法》。扩展点 E-S19-010/011。