提示词版本管理：把提示词当代码来管

提示词散落在文档与聊天记录里，出问题就无法归因。本文给出五件必做事（进版本库、带版本号、参数化、配评测集、灰度发布）、目录结构建议与常见反模式。

提示词也是代码

很多团队把提示词放在文档或聊天记录里，改完靠"试试看"。一旦出问题，无法回答三个基本问题：

**改了什么、为什么改、改之前怎么样**。把提示词当代码管理，这三件事自然就有答案。

1. **进版本库**：提示词是文本文件，纳入 Git，改动可 diff、可回滚；

2. **带版本号**：每次请求记录 `prompt_version`，线上结果才能归因到具体版本；

3. **参数化**：把变量（用户输入、检索片段、风格选项）与模板分离，避免拼字符串拼出意外；

4. **配评测集**：改动前后跑**同一批**样本（见"评测集"那篇），比较正确率与失败类型；

5. **灰度发布**：新版本先给一小部分流量，指标不退化再全量。

```

prompts/

answer/v3.txt 正文模板

answer/v3.meta.json 版本、作者、变更说明、目标评测集

answer/CHANGELOG.md 人写的变更历史

```

模板里用 `{{var}}` 这类明确占位符，**不要**用字符串拼接；

模板里不要写"如果 xxx 就 yyy"式的复杂分支——分支放在代码里，模板保持可读。

一条好的变更说明包含：**动机**（要修什么问题）、**做法**（改了什么）、**证据**（评测集上的变化）、**回滚方式**。

只有"优化了一下措辞"这种说明，下次没人敢动它。

线上直接改提示词（没有版本、没有记录）；

同一个功能存在多份"差不多"的模板，没人知道哪份在生效；

提示词里塞了时效性信息（价格、日期），过一阵就变成错的；

把用户输入直接插进模板的**指令区**（这是注入面，输入应放在明确的数据区）。

1. 先把**当前线上**的提示词原样落到文件并打上版本号（不改内容，只留痕）；

2. 加上 `prompt_version` 日志字段；

3. 建最小评测集（100~300 条）；

4. 之后每次改动走：改文件 → 跑评测 → 灰度 → 全量 → 记变更说明。