提示词是代码：要有版本、有评测、有回滚。
提示词也是代码
很多团队把提示词放在文档或聊天记录里，改完靠"试试看"。一旦出问题，无法回答三个基本问题：
改了什么、为什么改、改之前怎么样。把提示词当代码管理，这三件事自然就有答案。
五件要做的事
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. 之后每次改动走：改文件 → 跑评测 → 灰度 → 全量 → 记变更说明。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：给 AI 功能做降级设计：上游挂了，用户还能用
下一篇：多轮对话的上下文管理：摘要、锚点与按需检索 →
第 14 / 171 篇