提示词也是代码
很多团队把提示词放在文档或聊天记录里，改完靠"试试看"。一旦出问题，无法回答三个基本问题：
改了什么、为什么改、改之前怎么样。把提示词当代码管理，这三件事自然就有答案。
五件要做的事
- 进版本库：提示词是文本文件，纳入 Git，改动可 diff、可回滚；
- 带版本号：每次请求记录
prompt_version，线上结果才能归因到具体版本； - 参数化：把变量（用户输入、检索片段、风格选项）与模板分离，避免拼字符串拼出意外；
- 配评测集：改动前后跑同一批样本（见"评测集"那篇），比较正确率与失败类型；
- 灰度发布：新版本先给一小部分流量，指标不退化再全量。
目录结构建议
prompts/
answer/v3.txt 正文模板
answer/v3.meta.json 版本、作者、变更说明、目标评测集
answer/CHANGELOG.md 人写的变更历史
- 模板里用
{{var}}这类明确占位符，不要用字符串拼接； - 模板里不要写"如果 xxx 就 yyy"式的复杂分支——分支放在代码里，模板保持可读。
变更说明要写什么
一条好的变更说明包含：动机（要修什么问题）、做法（改了什么）、证据（评测集上的变化）、回滚方式。
只有"优化了一下措辞"这种说明，下次没人敢动它。
常见反模式
- 线上直接改提示词（没有版本、没有记录）；
- 同一个功能存在多份"差不多"的模板，没人知道哪份在生效；
- 提示词里塞了时效性信息（价格、日期），过一阵就变成错的；
- 把用户输入直接插进模板的指令区（这是注入面，输入应放在明确的数据区）。
落地顺序
- 先把当前线上的提示词原样落到文件并打上版本号（不改内容，只留痕）；
- 加上
prompt_version日志字段； - 建最小评测集（100~300 条）；
- 之后每次改动走：改文件 → 跑评测 → 灰度 → 全量 → 记变更说明。