Codex 提示词改坏了怎么回滚？
很多团队把 Codex 接入业务后，会不断优化提示词：今天加输出格式，明天加语气限制，后天又加异常处理。短期看结果变好了，过一段时间却发现老样例退化、字段丢失、回答变长、人工复核更累。提示词不是随手改的备注，它需要版本、样例和回滚点。
适用场景：不是一次对话，而是可复用流程
如果你只是临时让 Codex 帮忙解释一段代码，提示词不必管理得太重。但只要提示词被用于固定流程，比如生成客服回复、整理会议纪要、抽取合同字段、辅助代码改动或 AI 自动化办公，就应该像配置一样管理。尤其是输出要进入业务系统时，可以先看 JSON 输出契约，再决定提示词如何约束字段。
提示词改坏的表现通常不是立刻报错，而是慢慢偏移：标题风格变了，重要字段缺了，回答引用不再清楚，或者 Codex 开始做超出权限的修改。之前整理仓库上下文的步骤可以参考 接手旧项目时让 Codex 读懂仓库，提示词版本管理则是让这些上下文变化可追踪。
操作步骤：每次改动都能解释
1. 建一个提示词版本文件
不要只在聊天窗口里改。把提示词放到仓库、知识库或配置表，至少包含 version、owner、目的、适用场景、输入字段、输出要求、禁止事项、最近修改原因。每次变更只解决一个问题，比如“减少空泛话术”或“补充错误码字段”，不要一次塞进十条新规则。
version: prompt-ticket-summary-2026-06-20-a
owner: support-team
purpose: 将工单内容整理为摘要、分类和下一步动作
change_reason: 增加人工复核字段，避免模型直接给出退款结论
rollback_to: prompt-ticket-summary-2026-06-16-b2. 准备固定样例集
样例集比口头感觉可靠。至少准备正常样例、边界样例、缺信息样例、敏感样例和历史失败样例。每次改提示词后，让 Codex 或脚本批量跑这些样例，记录输出差异。若你用 Codex 改功能，也可以沿用 Codex 改完功能后的验收清单，把提示词验收当作配置变更的一部分。
3. 明确回滚触发条件
回滚不是情绪判断。可以写成条件：固定样例通过率低于 95%，关键字段缺失超过 1 条，回答长度超过阈值，拒答边界被破坏，人工复核意见集中反映误导。触发后先回滚提示词，再分析是样例不足、模型变化、业务规则变化还是提示词过度约束。
常见问题/避坑：提示词越长不一定越稳
很多人发现输出不对，就继续往提示词里加限制，最后变成一段没人愿意读的说明。过长提示词会挤占上下文预算，也会让模型在互相冲突的规则里摇摆。更稳的做法是把稳定规则写进系统提示词，把业务资料放进检索或输入字段，把输出结构交给 schema 校验，把审核交给人工流程。模型提示词、AI 模型接口参数和业务代码各做各的事。
另一个坑是没有记录模型名。提示词没改，但模型版本、默认模型或 CCSwitch 配置变化，也可能导致输出差异。如果遇到 Codex 仍调用旧模型或配置没生效，可以先看 CCSwitch 改了配置但 Codex 仍用旧模型怎么办。
检查清单：提交提示词前先过一遍
- 本次修改只有一个明确目标，并写清 change_reason。
- 固定样例集包含正常、边界、缺信息、敏感和历史失败样例。
- 输出差异被记录，关键字段、长度和拒答边界都有检查结果。
- 回滚版本可找到，且回滚后能恢复上一版流程。
- 模型名、温度、最大输出长度和调用入口没有被无意改变。
验收标准可以很朴素：新版本解决了目标问题，没有破坏旧样例，没有让人工复核成本明显上升。对开发者 AI 调用来说，提示词版本管理不是形式主义，而是减少“昨天还好好的今天不行了”的排查成本。把提示词当配置管理，Codex 才能更稳定地参与代码、内容和办公流程。
FAQ：提示词要不要和代码一起发布
如果提示词只影响个人使用，可以单独保存在团队文档里；如果提示词影响线上接口、客服回复、报表生成或审批流，就应该和代码、配置或数据库版本一起发布。至少要知道哪一天、谁、因为什么原因改了它。上线后如果用户反馈结果变差，才能把模型名、提示词版本和业务数据对上。
还有一种情况是产品同事直接在后台改提示词，开发同事不知道。这时建议后台保存草稿版和已发布版，发布前必须跑固定样例。Codex 可以辅助比较两版差异，指出新增约束是否互相冲突，但最终是否发布仍应由业务负责人确认。提示词改动越频繁，越需要小步提交和可回滚记录。