提示词就是代码
提示词一改，线上输出立刻变，影响面等同于一次发版，却常被当成文案随手热改。工程做法是把它当代码管：放独立文件进版本库、改动走评审、写明变更原因，并绑定一套固定评测集，每次修改跑同一批题目对比结果，让效果变化可复现、可归因、可回滚。这套做法与厂商无关，只与「线上跑的是哪一版」这件事有关。
基本信息
| 存放方式 | 仓库内独立目录，按能力分文件，如 prompts/summarize/v3.txt |
|---|---|
| 版本标识 | 文件名带版本号或日期，线上用配置项指向当前版本 |
| 变更记录 | CHANGELOG 写明改动内容、原因、评测结论与负责人 |
| 评测集 | 20-30 条真实用户题目加评分标准，人工或模型评审 |
| 发布流程 | 评审、灰度、全量三步，配置开关支持一键回滚 |
| 写入权限 | 提示词文件与线上配置项只允许授权成员修改 |
典型使用场景
- 多人协作时避免出现「谁把线上提示词改乱了」这类无法回溯的问题
- 模型换代或更换系统提示后做回归，确认老提示词在新模型上依然成立
- 新提示词先切 5% 流量灰度，比对通过率与单次成本再全量
- 排查质量下滑：调出当时的提示词版本与评测记录复现问题现场
- 对客交付与内部审计：能说明线上每一版提示词的来源与改动理由
最小闭环示例
最小闭环示例
mkdir -p prompts/summarize # 按能力建目录，一个能力一个文件
cp prompts/summarize/v3.txt prompts/summarize/v4.txt # 基于线上版本改，不要从零重写
git add prompts/summarize/v4.txt # 提示词与代码同库同评审
python eval.py --prompt prompts/summarize/v4.txt --suite suite_summarize.jsonl # 跑固定评测集
python eval.py --prompt prompts/summarize/v3.txt --suite suite_summarize.jsonl # 与线上版本对比同批题目
# 结论写进 prompts/summarize/CHANGELOG.md，再让线上配置指向新版本
kubectl set env deploy/api PROMPT_SUMMARIZE=v4 # 先切灰度环境的配置项
# 观察通过率与成本曲线无异常后切生产；出问题改回 v3 即完成回滚四个必备环节
| 环节 | 关键动作 | 缺失后果 |
|---|---|---|
| 评测集 | 真实题目加固定评分标准 | 改好改坏只能靠感觉 |
| 变更记录 | 写清改动内容与评测结论 | 效果回归时无法归因是哪次改动 |
| 灰度发布 | 按流量比例切换新版本 | 一次性影响全部用户 |
| 回滚手段 | 保留上一版文件加配置开关 | 出事只能紧急改代码重新发布 |
评测集要从线上真实问题里攒，不要用自造题目：自造题容易被提示词措辞「喂熟」，线上仍会翻车。题目要覆盖空输入、超长输入与边界问法。
用模型做评审适合批量初筛，边界样本与高风险样本必须人工看。只盯单一指标如「是否通顺」会掩盖格式与事实性退化，至少同时看格式合规率与事实错误率。