模型替换或 prompt 改写带来的风险，比大多数事故都更安静：不是新版本更差，而是没人赶在用户之前量过它。LLM 回归测试和 prompt 变更验证存在的意义，就是让这种测量变成例行公事。工作集是三件产物加五个步骤。产物：一套带已知正确答案的真实输入 golden set、给新输出打分的 grader，以及一次把变更放到线上流量旁边先跑、再决定是否替换的 shadow run。步骤：定义成功标准、构建集合、选择评分方法、跑 shadow，然后套用事先定好的阈值。这是本站变更验证层的第一篇；“迁移手册讲的是你依赖的模型下线时该怎么办，这一篇讲的是在采纳变更之前先证明它。
LLM 回归测试：先把成功标准定下来
Claude 的官方评估指南开头就有一句值得裱起来的话：构建一个成功的 LLM 应用，始于清楚定义你的成功标准，然后设计评估来衡量它们，而这个循环是 prompt engineering 的核心。同一份指南还补充说，大多数用例都需要沿多个成功标准做多维评估，而这正是团队把“这次变更有没有搞坏什么”压缩成一个数字时跳过的那部分。
有用的标准是具体的、可衡量的、可达到的、相关的。“表现良好”一条都不占；“在我们定义的标签上准确分类情感”则全占。对一次 API 集成来说，四个类别足以覆盖大多数需求：
- 任务保真度。输出是否真的回答了用户的请求，包括在罕见或困难的输入上？
- 格式与结构。下游代码能解析它吗？它遵守了你的系统所依赖的契约吗？
- 安全与拒答行为。模型是否拒绝了该拒绝的，并且没有拒绝不该拒绝的？
- 成本与稳定性。用量水平和错误率在这里充当代理指标，这正是成本指南在其操作顺序中赋予验证的同一种护栏角色。
把每条标准写成评审者能够判断“过或不过”的句子。如果你读它的定义都判断不出是否通过，那么下游的任何分数都无法比较。
Golden set 评估：从生产采样，按边缘场景组织
golden set 是一组冻结的输入与期望输出配对，它的第一条规则是来源：从真实生产流量中采样，不要凭空编造输入。编出来的例子是拿模型去测你的想象，而想象恰好是问题里已经被解决的那部分。
第二条规则是按边缘类别组织，而不是按方便组织。官方示例评估把用例围绕那些历史上会搞坏系统的输入来组织，包括讽刺、混合情感、误导性标题、话题突变、依赖对话很早之前的上下文，以及受保护健康信息之类的敏感信息。把这套分类法拿过来改造：你集合里的每个类别都应当对应你的应用曾经被搞糊涂、或者可能被搞糊涂的一种方式。
关于规模，请保持定性，同时在两个方向上都严格：小到每次有意义的变更都能跑完整套（包括在 CI 里），又宽到你识别出的每个边缘类别都有代表。跑得太久的集合会被跳过；只覆盖 happy path 的集合给你虚假的信心。把集合和评分逻辑一起做版本管理，并用审查代码的方式审查对其中任何一项的改动，因为集合现在已是你系统契约的一部分。
LLM grader、基于代码的检查，以及如何选择裁判
评分是流程变得机械化的地方，官方指南按可靠性给这些方法排序：优先基于代码的评分，因为它最快、最可靠、最可扩展；当判断力确实必要时用人工评审，代价真实；当问题足够微妙、规则无法表达时，用基于 LLM 的评分。实践中，顺着这个顺序往下走，你会得到：
- 基于代码的检查。与 golden 答案精确匹配（
output == golden_answer，通常在规范化空白和大小写之后）以及字符串匹配检查（key_phrase in output）覆盖了惊人比例的用例，而且运行成本为零。可机器检查的输出格式会扩大这一类别，这也是让输出在结构上可验证这一更广泛的教训。 - 基于 LLM 的评分。对于语气、连贯性或其他定性标准，由模型裁判按照评分细则给输出打分。有两条官方提示很重要：写出详细、清晰的评分细则；并且通常用与生成输出的模型不同的模型来评估，因为自我评估带有自己的偏差。
- 人工评审。最灵活、质量最高，但慢且贵；指南的建议是能避免就避免。把它留给校准另外两种方法。
在 OpenAI 这边，evals 把这一切打包成一个可描述的测试：一个 eval 配置有data_source_config（测试数据的 schema）和testing_criteria（判断模型输出是否正确的一批 grader）；运行会接收测试输入并产出结果，你来分析、迭代，文档把这个循环比作行为驱动开发。同一页面直接说出了本文的论点：编写 eval 来了解应用相对预期的表现，尤其是在升级或尝试新模型时，是构建可靠应用必不可少的组成部分。Grader 是评分那一侧：它们把参考答案与模型生成的答案对比，可以给部分分而不是严格通过或失败，文档列出的类型包括字符串检查、文本相似度和基于代码的检查，并且可以嵌套和组合。两个页面都带有关于评估工具演进的过渡说明：把机制部分当作活的文档，构建时对着官方页面核实细节，并查看弃用说明里哪些适用于你当前的账号。evals 页面把时间线写得很直白：OpenAI 正在弃用 Evals 平台；现有的 evals 内容在过渡窗口内仍然可用；Evals 将于 2026 年 10 月 31 日对现有用户变为只读；平台计划于 2026 年 11 月 30 日关闭。Grader 作为其所支撑的 evals 和微调工作流的一部分，也在被弃用。当前时间线请见官方弃用页面：https://developers.openai.com/api/docs/deprecations#2026-06-03-evals-platform。实际结论也由此而来：golden set 和评分逻辑是你自己的资产，所以要给它们做版本管理、保持可迁移，并把围绕它们的托管功能视为可替换的。
Shadow 流量测试：把变更放在生产旁边跑
切换前的最后一件产物是 shadow run：把真实流量切一片复制给新模型或新 prompt，记录一切，不给用户返回任何东西。因为 shadow 路径从不回答用户，所以它是在零用户风险下看清变更是如何作用于今天真实输入、而不是昨天 golden set 的唯一办法。
在两条路径上比较你会在生产里监控的那些表面：
- 格式合规性，以输出能解析并通过校验的频率衡量；
- 拒答率，按类别拆分；
- 错误响应的分布，使用标准分诊中的状态码族；
- 真实并发下的限流与拒绝行为；
- 用量水平和缓存命中行为，让成本意外在账单到来之前浮现；
- 机制层面的行为：tool calling 的模式，比如哪些工具被以什么参数调用，以及流是否干净地终止；tool calling 指南讲了为什么这些表面值得有自己的回归检查。
两条纪律让 shadow run 保持诚实。第一，shadow 路径不能消耗生产配额，也不能给面向用户的路径增加延迟；如果它做到了，你造出的是一个事故，不是一次测试。第二，shadow 记录必须打上标记，并被排除在生产指标和看板之外，因为一个静默混合了 shadow 与真实流量的指标，会污染你日后想要的每一次比较。以工具调用比较为例：它之所以存在，是因为一次变更可以通过所有文本检查，却仍然改变工具的调用方式。
阈值与回滚开关
在第一次运行之前就把切换标准书面定好，否则你最终会把标准调到刚好吻合出现的结果。阈值应当既是定性的，又是具体的：
- 关键用例相对 golden set 必须零回归；
- 边缘用例上的每一次失败都必须有解释，而不是耸耸肩；
- 成本和用量指标必须留在这个变更的预算范围内。
与之对应的要求是一个回滚开关：旧模型或旧 prompt 必须只差一次配置改动就能恢复，而且你应当真的、故意地排练一次恢复，而不是等到压力之下才第一次用。然后把结论写在样本集旁边，就像模型选择决策在基于约束的选择指南里记录理由一样，因为下一个做变更的人会先读你的笔记，再读文档。
常见失败模式
- 只覆盖 happy path。修法：围绕上面的边缘类别组织 golden set，并按类别审查覆盖情况。
- 模型给自己打分。修法：用另一个模型做评估，或者在答案可由规则判定时优先用基于代码的检查。
- 平均值改善了，于是变更上线。修法：把关键用例放在零回归要求下，与聚合分数分开评估。
- 机制表面被忽略。修法：把工具调用行为和流终止明确写进回归清单，而不只是文本质量。
- shadow 流量漏进生产指标。修法：打标签、隔离，保持看板干净。
- 结果出来之后才定阈值。修法：先写切换标准；它是实验设计的一部分，不是实验的结论。
- 什么都没记录。修法：样本集、评分逻辑、运行结果和决策一起进版本控制。
验证清单
- 先写成功标准，多维且可判定，然后再设计任何测试。
- golden set 从真实输入中采样；按边缘类别组织；保证它在每次变更时都能跑。
- 按可靠性给评分方法排序：先基于代码的检查，微妙之处用带清晰细则的 LLM 裁判并配独立的评估模型，人工用于校准。
- 用真实流量对变更做 shadow run；比较格式、拒答、错误、限流、用量与缓存行为，以及工具调用和流结束这类机制层面的行为。
- shadow 数据单独打标，排除在生产指标和配额之外。
- 在运行前设定阈值，并保留一个排练过的一步回滚。
- 把集合、评分逻辑、结果和决策一起记录下来，这样下一次变更能从证据出发。
这些都不是什么奇巧机械，而这正是重点：你所选择的变更与你所造成的事故之间的差别，通常就是一组成套的用例、一种评分方法，和一次在生产旁边跑的 shadow。当你的调用走的是兼容端点时，端点层面的细节在平台自己的文档里。