别把“Prompt 调优”当成工程交付：为什么 AI 项目需要一套可量化的“回归测试集”

在 AI Lab 的实际交付过程中，很多团队最容易陷入的误区就是：把 Prompt 的反复迭代（Tuning）等同于产品的工程化交付。

很多开发者在交付前会经历这样一个循环：发现一个 Case 报错 $\rightarrow$ 修改 Prompt $\rightarrow$ 测试该 Case 通过 $\rightarrow$ 发现另一个 Case 报错 $\rightarrow$ 再次修改 Prompt。这种“打地鼠”式的开发模式，在项目初期能快速出 Demo，但在面对复杂业务逻辑和大规模用户输入时，会导致系统鲁棒性极差。

“打地鼠”陷阱与回归失效

当你为了修复 Case B 而修改 Prompt 时，你很难在没有自动化验证的情况下确认：这次修改是否破坏了之前已经修复的 Case A。

在传统的软件工程中，我们通过单元测试（Unit Test）和集成测试来保证功能的稳定性。但在 AI 交付中，由于 LLM 输出的随机性和非确定性，很多团队习惯于“肉眼观察”或“抽样检查”。这种做法在面对数百个边缘场景（Edge Cases）时完全失效。

构建“原子级”回归测试集 (Regression Test Set)

要摆脱 Prompt 调优的泥潭，必须建立一套可量化的回归测试集。这套集合不应该是随机的样本，而应该是基于业务逻辑拆解的“原子能力验证点”。

1. 定义原子能力 (Atomic Capabilities)

不要测试“整个流程是否正确”，而要将流程拆解为原子能力。例如一个法律文档分析助手：
- 能力 A： 能否准确提取合同中的主体名称？
- 能力 B： 能否识别出违约条款中的时间期限？
- 能力 C： 能否在文档缺失关键信息时给出明确提示而非幻觉？

2. 构建黄金数据集 (Golden Dataset)

为每个原子能力准备 10-20 个典型 Case，包含：
- 正向样本： 标准输入 $\rightarrow$ 标准预期输出。
- 负向样本： 异常输入/干扰信息 $\rightarrow$ 预期的拒绝响应或错误处理。
- 边界样本： 极长文本、极端格式、多语言混合输入 $\rightarrow$ 系统不崩溃且维持核心逻辑。

3. 实现自动化评分机制 (Evaluation Pipeline)

不要依赖人工打分，建立三层验证体系：
- 硬匹配 (Exact Match)： 用于提取类任务（如 JSON Key 是否存在）。
- LLM-as-a-Judge： 使用更高能力的模型（如 GPT-4o 或 Claude 3.5）作为裁判，根据预设的评分量表（Rubric）对输出质量进行打分（1-5 分）。
- 语义相似度 (Semantic Similarity)： 通过 Embedding 计算输出与标准答案的余弦相似度。

工程实践建议

在实际操作中，建议将这套流程集成到 CI/CD 中。每次修改 Prompt 或更换模型版本后，自动触发全量回归测试。如果某个原子能力的得分下降超过 5%，则禁止合并代码。

结论： AI 项目的成熟标志不是 Prompt 写得多么精妙，而是你拥有一套能够告诉你“这次修改破坏了什么”的量化指标体系。只有将“玄学调优”转化为“工程验证”，AI 应用才能真正从 Lab Walkthrough 进入生产环境。