提示词改完效果变差，回滚的目标不是“把措辞改回去”，而是把一个已知可用的旧版本原样切回来，并且能确认切回来了。所以先看两件事：旧版本文本是否还完整存在，线上调用是否按版本号取提示词。如果提示词还散落在代码字符串或平台编辑框里、没有版本号也没进日志，回滚本身就会变成一次新的改动，风险不比原来小。通常建议先把提示词落成带版本号的固定文件或配置项，调用侧只认版本号，出问题时改版本号而不是手改文案。
提示词效果变差时，先确认差异是否由提示词引起，再回滚。做法是把旧提示词当作不可变版本找回，在调用侧按版本号切换，而不是手工重写文案；回滚后靠固定样本集和日志里的版本字段确认生效。若同期还改过模型、参数、检索或工具定义，需要一起评估或分别验证，否则只回滚提示词可能看不出变化。
先确认当前场景和目标
回滚成立的前提是：改动前后处理的是同一类输入，且最近一次变更确实动过提示词，例如改了措辞、加了约束规则、换了输出格式、调整了示例，或把系统提示和用户提示的分工改了。如果同期还换过模型、调过温度或最大输出长度、换过知识库、改过工具描述，那么“效果变差”可能是叠加结果，只回滚提示词未必有效。
动手前建议先确认这几项，缺哪项就补哪项：
- 旧版本原文是否完整可找回：git 历史、配置中心的历史版本、发布记录、请求日志里记下的提示词版本号，任一渠道能还原即可。
- 问题是否可复现：拿同一批输入重跑，能稳定重现变差，说明适合用回归样本比较；只是零散偶发，则要先把样本收集起来再判断。
- 线上请求是否能区分版本：日志或响应里有没有 prompt_version 这类字段，没有的话，回滚后无法确认到底跑的是哪一版。
- 谁有权改线上配置：回滚往往要走发布或配置变更流程，权限和审批时间要提前算进去。
按这个顺序处理
顺序建议是“先冻结现状，再找回旧版本，最后用版本号切换”，不要跳步。手工把文案改回记忆中的样子，很容易漏掉换行、示例或格式约束，反而引入新的差异。
- 冻结当前版本。把线上正在用的提示词完整导出，连同模型名、温度、最大输出长度、上下文拼接模板一起记下来，打一个明确的标签，例如 v3-bad。这一步是为了事后能做 diff，也避免回滚过程中又被动改动。
- 找回旧版本原文。用版本库或配置中心历史找出上一个稳定版本，确认它是当时线上实际使用的完整文本，而不是草稿分支。
- 在调用侧切版本号。把配置里的当前版本指回旧版本，代码和拼接逻辑不动。切换范围先从小流量或内部账号开始，不要一次性全量。
- 记录差异和决定。把新旧两版的实际 diff、回滚原因、回滚时间写进变更记录，方便后面定位到底是哪一句改动导致的退化。
如果提示词已经按目录管理，仓库结构大致如下，每个版本一个文件、不改历史文件，只增不改：
prompts/
support_reply/
v2.txt # 上一个稳定版本
v3.txt # 当前效果变差的版本
manifest.json # 记录哪个版本在用manifest 里只放指针和元信息，让“当前用哪版”成为一处可改的配置：
{
"name": "support_reply",
"active": "v2",
"versions": {
"v2": {"file": "v2.txt", "note": "回滚目标"},
"v3": {"file": "v3.txt", "note": "疑似导致效果下降"}
}
}找回旧文本常用几条命令，先看目录历史，再看具体文件内容：
git log --oneline -- prompts/support_reply/
git diff v2 v3 -- prompts/support_reply/
git show 提交号:prompts/support_reply/v2.txt调用侧的建议写法是：提示词由配置决定，代码只负责取用和记录版本，不在业务代码里拼文案。下面是通用骨架，具体函数名按自己项目替换：
prompt_text = load_prompt(cfg["name"], cfg["active"])
logger.info("prompt_version=%s", cfg["active"])
result = call_model(system=prompt_text, user=user_input)如果日志里原本没有版本字段，建议先补上再回滚，否则回滚之后只能靠“感觉变好了”来判断，出了问题也不好追。
改完后怎么验证
回滚完成的第一个信号不是输出变好，而是“确实在跑旧版本”。按下面几步观察，力度从确定到推断：
- 确认版本生效：在日志或响应里看到 prompt_version 已经是回滚目标的版本号，且新请求不再出现 v3 标记。这是可核验的一步，先做。
- 清理可能残留的缓存：如果链路里有按提示词内容或语义做的缓存、结果缓存，回滚后要确认旧缓存不会把新结果盖掉，必要时清理或等缓存自然过期。
- 用固定样本集回归：准备一批历史失败样本加上一批正常样本，同一输入分别跑回滚前后两版，逐条比对输出结构是否合规、关键字段是否齐全、拒绝或空答的比例是否恢复正常。样本量不用大，但要在改动前后用同一批。
- 看业务侧的可观察信号：人工抽检一段时间内的实际请求，关注格式解析失败、需要人工兜底、用户重复追问这类现象是否回落。观察窗口要覆盖一个完整业务周期，避免只看几小时就下结论。
预期信号是：版本字段一致、样本集表现回到改动前水平、异常现象减少。如果回滚后版本号对了但效果没回来，说明问题大概率不在提示词本身，需要继续往模型、参数、检索或输入分布上查。
容易忽略的边界
回滚提示词只是止血，不是修复。几个容易踩的点值得提前知道：
- 旧提示词可能依赖旧环境。如果旧版本是配着旧模型、旧工具描述、旧检索拼装方式写的，单独回滚提示词、其余不动，效果可能仍与当初不同。这种情况要么把相关项一起回退，要么把提示词按新环境重新适配。
- 多环境不一致。测试、预发、线上各有一份提示词副本时，只回滚其中一个环境会造成“本地好了线上没好”，回滚前先确认副本是否同源。
- 缓存和异步任务会滞后。排队中的异步任务、已生成待发送的内容、按内容哈希缓存的回答，都可能继续携带旧版本行为，需要单独处理，别把它们当成回滚失败。
- 回滚范围要写清楚。如果近期上线了多个提示词改动，要明确回滚到哪个版本，而不是笼统“回到上一版”，否则容易退过头，丢掉中间必要的修复。
- 不适用条件。如果旧版本根本没有留存，或者线上从未记录版本号，不建议凭记忆手工复原，正确做法是先冻结当前文本、建好版本管理，再用新版本逐步对照调整。
回滚稳定之后，建议再做一次范围很小的对照：把 v3 相对 v2 的改动拆成几句，一次只加回一句并跑同一批样本，定位到具体是哪条改动带来退化。这样下一次调整提示词时，就不用再靠整版回滚来兜底。