别让“Prompt 调优”成为 AI 交付的遮羞布：为什么你需要一套可量化的“回归基准线”

在 AI Lab 的实际交付过程中，我经常听到一种声音：“这个效果还没达到预期，我再调一下 Prompt。”

这句话听起来很专业，但实际上，它是 AI 工程化中最危险的陷阱之一。很多团队将 LLM 应用的迭代简化为了一个“玄学循环”：修改 Prompt $\rightarrow$ 运行几个 Case $\rightarrow$ 感觉好了一点 $\rightarrow$ 上线 $\rightarrow$ 用户反馈崩了 $\rightarrow$ 继续修改 Prompt。

这种缺乏量化基准的“体感调优”，本质上是在用随机碰撞代替工程管理。

“体感调优”的三个致命缺陷

1. **回归失效（Regression Blindness）**：当你为了修复 Case A 的错误而修改 Prompt 时，你可能在无意中破坏了之前已经跑通的 Case B 和 C。由于没有全量回归，这种破坏在上线前是不可见的。

2. **边际效用递减**：在没有基准线的情况下，你很难判断当前的 Prompt 优化是否已经触及模型能力的上限，还是仅仅在进行低效的文字游戏。

3. **无法量化交付进度**：面对老板或客户时，“感觉好多了”不是一个合格的进度汇报。一个合格的工程汇报应该是：“当前版本在核心链路的准确率从 65% 提升至 82%，Bad Case 主要集中在 XX 场景。”

构建“回归基准线”的三步走策略

要摆脱这种困境，你需要将“调优”转化为“实验”。

第一步：构建最小可行性数据集（Golden Set）

不要试图覆盖所有场景，而是挑选出 50-100 个最具代表性的 Case。这个数据集应包含：

- **Happy Path**：最核心、必须正确的标准路径。

- **Edge Cases**：已知的边界条件和历史 Bad Cases。

- **Negative Cases**：明确要求模型拒绝或处理异常的输入。

每个 Case 必须包含：`Input` $\rightarrow$ `Expected Output (or Key Constraints)` $\rightarrow$ `Reasoning`.

第二步：定义多维度的评测指标（Evaluation Metrics）

放弃单一的“LLM-as-a-Judge”（虽然它很有用），引入组合指标：

- **硬指标（Hard Match）**：对于结构化输出（JSON/XML），使用 Schema 校验和关键字段匹配。

- **软指标（Semantic Similarity）**：使用 BERTScore 或特定领域的关键词覆盖率。

- **逻辑断言（Logic Assertions）**：检查输出中是否包含必须出现的步骤或禁词。

第三步：建立“版本 $\rightarrow$ 分数”映射表

每次修改 Prompt 后，强制运行全量 Golden Set，生成一份对比报告：

- **Pass Rate**: 总通过率的变化。

- **Regression Count**: 新引入的错误数量。

- **Improvement Count**: 修复的旧错误数量。

只有当 `Improvement > Regression` 且 `Pass Rate` 提升时，该版本才具备上线资格。

写在最后

AI 工程化的核心不在于寻找那个“完美的 Prompt”，而在于构建一套能够快速发现错误、量化改进并防止退化的系统。

当你不再说“我再试一次”，而是说“这次迭代提升了 4% 的召回率”时，你才真正从一个 Prompt 工程师变成了 AI 系统工程师。