提示与版本回归

学习目标

读完本课你能给 AI 应用建立和代码一样的「改前必跑测试」纪律：任何提示或模型配置的修改，都跑一遍固定样例、产出对比报告，并把接受的退步记录在案。

问题场景

你把助手的 system prompt 修了一句「回答更简洁」，随手测了两问，挺好。三天后同事发现：问「为什么我的文档搜不到」时，助手只回一句「检查资料格式」——以前那个「先解释状态字段、再给排查步骤」的详细回答没了。简洁性提上来了，排查引导悄悄退回去了，而这条退步在任何一次单点测试里都碰不到。代码改坏有测试拦着，提示改坏也得有东西拦着——这就是回归（regression testing，回归测试）。

核心解释

回归 = 固定样例（A31）+ 分层评估（A32）+ 版本对比。流程四步，写进日常纪律：

1. 改动：提示词、模型名、温度、检索参数——任何影响行为的配置都算。改动先落版本号。
2. 跑回归：同一份评估集全量跑一遍（管道与线上一致）。
3. 出对比报告：与上一版本逐样例比，每个样例标 improved / regressed / unchanged，退步的用 A32 推理表定位到层。
4. 归档：版本号 + 变更说明 + 报告 + 已知退步清单，一起存档。

版本记录的最小结构：

{
  "version": "prompt-v4",
  "change": "system prompt 增加「回答分步骤」要求；温度 0.7→0.5",
  "date": "2026-10-26",
  "eval_run": { "cases": 10, "improved": 3, "regressed": 1, "unchanged": 6 },
  "regressions_accepted": [
    {
      "case": "case-edge",
      "detail": "口语问题回答变长，改写命中不变但引用变多",
      "reason": "为换 3 例答案质量提升，接受此退步",
      "watch": "若继续恶化（引用错配）再回滚"
    }
  ]
}

# 对比脚本的用法示意：两个版本的报告一比，退步一目了然
node compare.js reports/prompt-v3.json reports/prompt-v4.json
# => case-edge: unchanged -> regressed (answer: invented +1)
# => case-001:  unchanged -> improved  (citation: added)

如何验证回归流程有效：故意做一个「必然退步」的改动（比如把 system prompt 里「引用课程编号」的要求删掉），跑回归，报告必须逐样例标出哪些样例的引用要求挂了。测不出你制造的退步的回归流程，等于没有。

示例拆解

一次真实决策的完整记录（报告 → 决策 → 归档）：

prompt-v3 → prompt-v4（加「分步骤」要求）
  改进 3 例：排查类问题回答结构变清晰（answer 层 must_state 全过）
  退步 1 例：case-edge 答案变长、引用变多（answer 层变慢，citation 层冗余）
  决策：接受退步，原因：排查引导价值 > 冗余引用代价
  归档：regressions_accepted 里写明 watch 条件（引用错配即回滚）

关键点：

• 「回归全绿才能上线」太理想，正确标准是「退步全部知情」：改进常伴随代价，关键是每个退步都被看见、被决策、被记录——而不是悄悄发生。
• 已知退步清单是记忆：v4 接受的退步，v5 改提示时最容易复发。清单让下一个人（包括三个月后的你）不用重新踩一遍。
• 模型配置变更同样是「版本变更」：换模型（A20 换嵌入模型）、改温度、调检索 top-k，都可能让固定样例的表现变化——回归的触发条件是「影响行为的改动」，不限于提示文本。
• 提示文本本身要进 Git（refs：Git 官方文档）：版本号对应 Git 提交，报告归档引用提交哈希——「这个行为是哪版提示带来的」永远可追溯。
• 与 A30 复盘的联动：复盘发现的坏案例（rejected 建议、编造回答）直接进评估集成为新的回归样例——评估集随经验生长。

动手任务

1. 为你的评估集跑一次「基线」：当前版本的分层报告存成 prompt-v1.json——没有基线，以后所有对比都无从谈起。
2. 做一次受控改动：在 system prompt 里删掉一条明确要求（如「术语首现给中英文对照」），跑回归，验证报告能标出受影响的样例——这就是本课要求的「回归流程自检」。
3. 编写归档：为刚才的改动写一版 JSON 记录（version/change/eval_run/regressions_accepted），检查 watch 条件是否具体可判定。

常见错误

• 凭感觉改提示不跑回归：单点测试的覆盖面就是你恰好想到的问题——A31 建评估集的全部意义就在这一刻兑现。
• 回归只看通过率变化：通过率持平不代表没变化——可能有改有退相互抵消，必须逐样例对比。
• 退步不做决策直接吞掉：报告里有退步但没人决定「接受还是修」，下次跑出来还是它，最后大家不看报告了。每个退步都要走「接受/修复/回滚」三选一。
• 版本号只在脑子里：「上上周那个好用的版本」无法回滚，因为提示文本没有版本化。提示是代码，按代码的纪律管。

检查与复盘

自查清单：

• 能说出回归四步（改动 → 跑样例 → 对比报告 → 归档）及每步产物
• 能解释「退步全部知情」为什么优于「全绿才能上线」
• 你的评估集有基线报告，改动有版本记录与 watch 条件

参考资料

• OpenAI 文档：API Reference - Evals —— 版本化评估运行的结构参照
• Git 官方文档 —— 提示与配置版本化的载体
• 恭喜走到这里：A18-A33 的检索、安全、评估串成了完整的 AI 应用工程闭环。下一步可以把这套纪律用在你自己的项目里。