这次翻车本来能拦住：把一个坏输出变成回归测试

上周，一条面向客户的回答错了。团队改了 Prompt，手查了几个例子，重新上线。两周后，另一位客户收到了同一类错误。第一次修的是那句话，不是失败本身。

回归测试从相反方向开始：让一个坏输出变成每次变更前都会跑一遍的案例。 它不能证明系统很好，只能证明同一类失败再出现时，团队会看见。

一个坏输出，还不是可运行的测试

“模型答得不好”没法运行。一个回归案例需要让另一位复核者能够重现失败：

• 用户实际提供的输入；
• 模型当时收到的上下文，包括来源版本；
• 用可观察属性写出的期望行为；
• 逐字保留的实际输出；
• 失败标签和严重程度；
• 分类的复核者和日期。

没有上下文版本，案例以后可能“通过”得莫名其妙：变的是来源，不是模型。没有期望属性，团队会争论语气，而不是失败的性质。没有严重度，每个失败都一样紧急，门很快就会被忽略。

案例不需要保存完整生产记录，只需要能够重放决定，同时不暴露个人数据。把客户姓名脱敏，保留政策版本，保存真正导致失败的那段输入。

把输出变成案例，不是轶事

一张有用的表有六个字段：

字段	记录什么	为什么重要
案例编号	稳定标识	把失败、测试和修复连起来
切片	退款、资格、负责人归属等	防止案例变成一次性特例
输入	用户消息与相关上下文	让失败可重放
期望属性	必须为真的性质，不是逐字答案	允许合法表达变化
实际输出	逐字保留的失败结果	说明“坏”具体指什么
严重度	关键、主要、次要	决定是否阻断发布

期望属性最难写。“应该更好”不可测试。“必须引用当前退款政策版本，且不得声称已批准”可以。属性可以由规则、评分表或人来检查；方法不重要，重要的是团队对“什么算失败”达成一致。

案例一：退款政策回答通过了复核

客服助手回答：“年费套餐 30 天内可退款。”引用的页面是真实政策，但已经是两个季度前的版本。现行政策是 14 天窗口，首月之后还要按比例计算。

团队加了一个案例，包含三个属性：

1. 回答引用当前政策版本；
2. 回答不声称退款已获批准；
3. 边缘情况转人工。

这个案例用小检查运行，不做整段答案对比。规则检查当前版本号是否存在、批准语气是否出现；复核者阅读边缘情况的转交路径。下一次 Prompt 变更前，这个失败就会重新出现。

关键细节是：测试不要求一字不差。只要保留这三个属性，另一种解释也能通过。这样模型换一种说法时，测试仍然有用。

反例：会议纪要虚构了负责人

第二个团队用“和参考摘要对比”测试会议纪要。模型写得很顺，措辞也接近，测试通过。上线后，纪要却把行动项分配给了错误的人。

参考摘要本身也写错了负责人，因为它是凭记忆整理的。测试复制了错误，而不是抓住错误。

团队把参考换成基于逐字稿的检查：

• 每个行动项必须引用负责人接受任务的那句话；
• 没有明确负责人的行动项标为“未指派”；
• 不能因为某人先发言就推断他是负责人。

这个案例说明，只做“和标准答案对比”不够。标准答案可能错，措辞相似度还可能奖励同一个错误。优先选择能对来源核查的属性。

回归门放在哪里

回归集只有自动运行才有价值。团队把它放在三类变更前：

变更	运行	阻断条件
Prompt 或系统消息	完整回归集	任一关键案例失败
模型或版本	完整集 + 延迟/成本检查	关键失败或成本超上限
检索来源或切块	检索案例 + 回答案例	引用来源缺失或过期
输出解析或 schema	格式案例 + 回答抽样	schema 错误或字段静默丢失

门不要求平均分完美，只要求关键失败为零，主要失败有复核过的解释。平均分会藏住真正重要的一条：退款批准、错误负责人、泄露文档。

团队还保留基线。新模型可能平均更好，却在关键切片更差。发布判断看分切片结果，不看一个总数。

每次变更跑什么

从真实发生过的失败开始，再加两个邻居：

• 一个结构相似但不完全相同的近邻；
• 一个应该继续通过的对照。

退款案例的近邻可以是月付套餐的不同窗口；对照可以是简单的账单地址修改，它根本不该提退款。这样团队不会只对一句话过拟合。

在冻结基线和候选版本上各跑一遍，记录：

• 关键通过率；
• 分切片通过率；
• 人工复核发现的误放行；
• 复核者分歧；
• 延迟和成本，因为更安全但慢十倍的模型可能无法上线。

测试不是一次性的验收文档，而是活的回归集。案例不再相关时，带着理由退休；新失败出现时，先加案例，再发布。

什么时候不该加测试

不是每个坏输出都值得做回归案例。以下情况可以跳过：

• 任务没有稳定的验收属性（开放式头脑风暴、一次性创作）；
• “失败”只是复核者无法达成一致的语气偏好；
• 输入无法在不保留敏感数据的情况下存储和重放；
• 这个案例测试的行为，产品根本不依赖。

这些情况用复核表或定性抽样更合适。一个塞满模糊案例的回归集会被团队关掉，那比没有更糟。

不适用边界

这套流程适合分类、抽取、政策回答、客服草稿等有可观察验收属性的任务。它不能替代完整评测体系、人工复核或安全测试，也不保证系统安全；它只是防止已知失败再次发生。如果团队写不出期望属性，或留不住上下文版本，先修这两件事，再加案例。