别让“Prompt 调优”成为交付的黑盒：建立 AI 交付的版本基准线

在 AI Lab 的实际交付现场，最容易陷入的陷阱之一就是所谓的“Prompt 调优循环”。

很多团队在交付初期会经历这样一个场景：工程师发现模型输出不符合预期 $\rightarrow$ 修改 Prompt $\rightarrow$ 测试几个 Case $\rightarrow$ 觉得 OK 了 $\rightarrow$ 上线 $\rightarrow$ 客户反馈某个之前正常的 Case 现在挂了 $\rightarrow$ 再次修改 Prompt。

这种“打补丁”式的迭代方式，本质上是在用一个不可控的变量（自然语言）去修补另一个不可控的变量（概率模型）。如果没有一套严格的版本基准线（Baseline），Prompt 的每一次微调都像是在玩一场没有地图的扫雷游戏。

从“感觉 OK”到“量化 OK”

在工程化交付中，我们需要将 Prompt 从“文学创作”转变为“配置管理”。

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

不要依赖于随机抽取的测试集。一个合格的交付项目必须拥有一套由业务专家审核过的黄金数据集。它应该包含：
- 边界 Case：那些最容易触发模型幻觉或拒绝回答的极端输入。
- 回归 Case：历史上出现过且被修复的问题点。
- 基准 Case：定义什么是“正确”的标准答案。

2. 实现 Prompt 的版本化管理

严禁直接在代码或数据库中硬编码 Prompt。建议采用以下结构：
prompts/{category}/{version}/system_prompt.txt
每次修改 Prompt 时，必须增加版本号（如 v1.0.1 $\rightarrow$ v1.0.2），并记录修改的具体原因（例如：“修复了在处理多轮对话时丢失上下文的问题”）。

3. 建立自动化评测流水线 (Eval Pipeline)

每次 Prompt 更新后，必须强制运行全量黄金数据集评测。评测指标不能仅靠 LLM-as-a-Judge，而应结合：
- 确定性校验：检查输出是否包含必须的 JSON 字段、是否符合正则格式。
- 语义相似度：计算与标准答案的 Cosine Similarity 或使用 BERTScore。
- 负向指标：统计出现特定违禁词或错误模式的频率。

实战教训：一次关于“礼貌”的翻车

我们在一个金融类 AI 助手项目中曾遇到过这种情况：为了让模型显得更专业、更有礼貌，我们将 System Prompt 中的语气词进行了微调。结果在通过了小规模抽检后上线，却发现模型在处理某些紧急报错请求时，因为过于冗长的礼貌开场白，导致关键的错误代码被截断或被用户忽略，严重影响了排障效率。

这次事故告诉我们：任何对 Prompt 的微调，都可能在概率分布上产生非线性的偏移。

给交付团队的建议

如果你现在正处于 AI 项目的交付压力中，请立即停止那种“试一次 $\rightarrow$ 改一次”的低效循环。

尝试建立一个简单的表格：
| 版本 | 修改点 | 通过率 (Golden Set) | 回归失败数 | 结论 |
| :--- | :--- | :--- | :--- | :--- |
| v1.2 | 增加约束条件 A | 92% $\rightarrow$ 95% | 2 | PASS (可上线) |
| v1.3 | 修改语气为专业风 | 95% $\rightarrow$ 91% | 8 | FAIL (回滚) |

只有当你的 Prompt 修改能够通过量化的数据证明其“净收益”为正时，它才具备进入生产环境的资格。AI 的交付不是艺术创作，而是严谨的工程实验。