别把 AI 交付当成“写代码”：为什么 AI 工程化需要一套完整的“回归测试集”

在 AI Lab 的交付现场，很多团队习惯于用“调优 Prompt”来解决 Bug。当用户反馈某个 Case 报错时，工程师迅速修改 Prompt，验证该 Case 通过，然后宣布 Bug 修复。

但这种做法在 AI 工程化中极其危险。因为 LLM 的非确定性意味着：你修复了 Case A，极大概率在不经意间破坏了已经通过的 Case B、C 和 D。

1. “打地鼠”式交付的死循环

我们曾经历过一个典型的场景：为一个法律文档分析系统优化提取精度。
- 第一天：修复了“合同金额提取错误”，结果导致“签署日期提取”开始出现幻觉。
- 第二天：修复了日期问题，结果导致原本正常的“违约条款判定”变得过于保守。
- 第三天：试图通过增加 Few-Shot 来统一两者，结果导致模型输出格式偶尔崩溃。

这种“打地鼠”式的开发模式让交付周期无限拉长，且团队对系统的信心降至冰点。

2. 构建 AI 时代的“黄金数据集 (Golden Dataset)”

要打破这个循环，唯一的路径是建立一套不可妥协的回归测试集。这不再是简单的单元测试，而是一套包含 $\text{Input} \rightarrow \text{Expected Output}$ 的黄金样本库。

工程化实施路径：

• 样本分级 (Tiering)：将样本分为 P0（核心功能，必须 100% 通过）、P1（边缘场景，允许少量波动）、P2（探索性场景）。
• 自动化评测流水线 (Eval Pipeline)：每次修改 Prompt 或模型版本后，强制运行全量 P0 测试集。使用 LLM-as-a-Judge 或精确匹配来判定通过率。
• 回归报告 (Regression Report)：不仅报告通过率，更要列出 Previously Pass $\rightarrow$ Now Fail 的具体样本。这才是决定是否允许发布的核心指标。

3. 从“感觉不错”到“数据证明”

AI 工程化的本质是将“玄学调优”转化为“量化迭代”。当你能自信地说出“这次 Prompt 修改提升了 P0 集的准确率从 88% 到 92%，且没有引入任何 P0 回归”时，交付才真正进入可控状态。

结论是： 在 AI Lab 中，一个完善的评测集比一个强大的模型更重要。没有回归测试的 AI 交付，本质上是在进行一场豪赌。