提示变更记录怎么写
按 Keep a Changelog 的风格记录每次提示变更：版本号、日期、改了什么、为什么改、回归结论如何、怎么回滚。它的作用是让三个月后的人能看懂“这个提示为什么长成现在这样”，而不是对着一份无从解释的措辞发问。
基本信息
| 记录内容 | 版本、日期、改动内容、动机、验证结果、回滚方式 |
|---|---|
| 版本对应 | 与提示版本号一一对应，版本号跳动必然有记录 |
| 动机部分 | 写清解决的问题与依据，不写“优化提示词”这类空话 |
| 回滚 | 写清切回哪个版本、通过什么开关切 |
| 自动化 | 可从流水线自动拼出草稿，人工补动机与回滚说明 |
典型使用场景
- 发版流程：合并前必须补上变更记录条目，否则门禁不通过
- 事故回溯：质量下滑时先翻变更记录，锁定可疑版本
- 交接与审计：新人通过记录理解每处措辞的由来
- 回滚决策：记录里带回滚方式，紧急时不用现查
- 多团队共用模板：变更记录是通知上游的正式凭据
变更记录示例
变更记录示例
## [1.3.0] - 2026-10-12
### 变更
- 输出由自由文本改为 JSON（title, points 数组）
- 要点数量上限设为 5 条
### 动机
- 下游解析错误率由 2.1% 降至 0.3%（回归集 v4）
### 回滚
- 切回 1.2.2：开关 prompt.summarize 指向 1.2.2
### 验证
- 回归集 v4 通过率 96.4%，误伤样例 0 条段落与要求
| 段落 | 要求 | 常见缺失 |
|---|---|---|
| 变更 | 逐条列出可观察的改动 | 只写优化了措辞 |
| 动机 | 附数据或具体问题 | 写感受不写依据 |
| 验证 | 写明回归集版本与结果 | 没有数据支撑 |
| 回滚 | 写明版本与切换方式 | 回滚时临时摸索 |
变更记录本身也要有版本规范：乱序追加、编号跳跃的记录，用起来比没有更麻烦。
记录里可以顺手写一条“当时考虑过但没选的方案与原因”：这类信息在半年后比改动本身更有参考价值，能避免反复讨论同一个取舍。