别让“Prompt 调优”成为你的心理安慰：AI 交付中的“确定性”陷阱

在 AI Lab 的交付现场，最常见的一个场景是：工程师面对一个失败的 Case，迅速修改 Prompt，增加一条约束（例如：“请确保输出格式为 JSON，不要包含任何解释”），然后重新运行。当这个 Case 通过后，工程师会产生一种“问题已解决”的错觉。

但事实是，这种基于单点 Case 的“打补丁”式调优，往往是在用一个 Bug 掩盖另一个 Bug。

确定性陷阱：从“看起来对了”到“真的对了”

很多团队在交付 AI 功能时，衡量标准是“抽样验证”。随机抽 10 个 Case，如果 8 个对了，就认为可用。这种方法在传统软件工程中是不可想象的——你不会因为 80% 的代码行能跑通就发布版本。

AI 工程化的核心挑战在于其概率性。当你为了修复 Case A 而修改 Prompt 时，你实际上是在高维空间中移动模型的决策边界。这个移动可能会在不经意间破坏原本正常的 Case B 和 C。

这就是所谓的“确定性陷阱”：你追求的是局部正确（Local Correctness），而牺牲了全局稳定性（Global Stability）。

实战方案：构建“黄金数据集” (Golden Dataset)

要摆脱这种焦虑，唯一的路径是将 AI 的验证从“感官判断”转向“量化度量”。

1. 定义黄金数据集

不要依赖随机抽样。你需要构建一个包含 50-200 个典型场景的黄金数据集。这个数据集必须包含：
- Happy Path: 标准输入 $\rightarrow$ 标准输出。
- Edge Cases: 空输入、极端长文本、非法格式、矛盾指令。
- Regression Cases: 历史上出现过的所有 Bug Case。

2. 实现自动化评测流水线

每次修改 Prompt 或更换模型版本后，必须强制运行全量评测：
- 硬匹配 (Exact Match): 对于格式要求严格的输出（如 JSON key）。
- 语义匹配 (LLM-as-a-Judge): 使用更高阶的模型（如 GPT-4o 或 Claude 3.5）作为裁判，根据预设的评分维度（准确性、完整性、语气）给结果打分。
- 业务指标 (Business Metric): 例如提取出的实体是否在数据库中真实存在。

3. 建立“回归基准线” (Baseline)

在任何优化开始前，先跑一遍当前版本的得分（例如：准确率 72%）。只有当新版本的得分 $\ge$ 基准线且关键 Case 全部通过时，才允许合并代码。

工程化反思：Prompt 是临时方案，流程才是长期资产

很多开发者把 Prompt 当成代码来写，试图通过极其复杂的指令集来实现所有逻辑。但经验告诉我们：Prompt 的复杂度与系统的脆弱性成正比。

真正的 AI 工程化应该是：
- 尽量简化 Prompt: 只负责核心推理和格式转换。
- 将逻辑外移: 能用 Python 代码实现的校验逻辑（如正则检查、类型转换），绝对不要交给 LLM 做。
- 闭环反馈: 将用户反馈的 Bad Case 直接转化为黄金数据集的新条目 $\rightarrow$ 触发评测 $\rightarrow$ 指导调优 $\rightarrow$ 回归验证。

当你不再说“我觉得这次改对了”，而是说“这次修改让黄金数据集的通过率从 82% 提升到了 85%，且没有引入回归 Bug”时，你才真正进入了 AI 工程化门槛。