别把“Prompt 调优”当成工程能力：在 AI 交付中建立“确定性契约”的实战思考

在 AI Lab 的实际交付过程中，我观察到一个非常普遍的误区：很多工程师将大部分精力投入到了所谓的“Prompt 调优”中。他们通过不断地尝试不同的措辞、增加示例（Few-shot）、甚至在 Prompt 中加入“你是一个资深的专家”这类心理暗示，试图通过这种方式来提高模型输出的稳定性。

然而，从工程化交付的角度来看，依赖 Prompt 调优来保证质量是一种极其危险的行为。因为 Prompt 本质上是一种“软约束”，它在面对模型版本升级、输入分布漂移或长文本干扰时，表现出的是极强的随机性。

真正的 AI 工程能力，不应该是如何写出更好的 Prompt，而应该是如何在不确定的模型输出与确定的业务需求之间，建立一套“确定性契约”。

从“希望它正确”到“强制它正确”

在一个典型的 AI 任务流中，如果你的验收标准是“输出看起来像那么回事”，那么你永远无法实现真正的自动化交付。我们需要将关注点从 Prompt 的措辞转移到**结构化契约**上。

1. 强类型输出契约 (Schema Enforcement)

不要指望模型通过 \`Please output in JSON format\` 来保证格式。在生产环境中，必须使用 JSON Schema 或 Pydantic 等工具进行强校验。如果模型输出不符合 Schema，直接触发重试机制或回退到预定义的安全模板，而不是试图在代码里用复杂的正则去解析一个可能缺失字段的 JSON。

2. 状态机驱动的链路拆解

一个复杂的 AI 任务如果被塞进一个巨大的 Prompt 里，其失败率会随着逻辑复杂度呈指数级增长。实战经验告诉我们，应该将任务拆解为多个微小的、可验证的状态节点。

- **节点 A**：仅负责提取实体 $\rightarrow$ 通过正则/Schema 校验 $\rightarrow$ 进入节点 B。

- **节点 B**：基于实体进行逻辑推理 $\rightarrow$ 通过预设的知识库比对 $\rightarrow$ 进入节点 C。

这种方式将一个巨大的“黑盒”变成了多个可观测的“灰盒”，任何环节的失效都可以被精准定位并针对性优化。

“负面样本集”比“正向示例”更重要

很多团队在做 Few-shot 时，倾向于给模型提供几个完美的正确示例。但在实际工程中，**定义什么是“错误”比定义什么是“正确”要高效得多**。

我们建立了一套名为 \`Negative-Case Library\` 的机制：记录所有导致系统崩溃、产生幻觉或违反安全策略的真实输入及其对应的错误输出。在迭代过程中，我们不追求模型能写出多么惊艳的答案，而追求模型能够稳定地避开这些已知的坑。

当一个新的 Prompt 版本发布时，它必须通过所有历史负面样本的回归测试（即：不再产生之前的错误），才能被认为具备上线资格。这才是真正的质量底线。

总结：工程化的本质是消除随机性

AI 的魅力在于其创造力（随机性），但工程的本质则是消除随机性。

如果你发现自己每天花 4 个小时在调整 Prompt 里的一个形容词，那么你可能陷入了“炼金术师”的陷阱。请试着把目光移向：

- 如何定义更严苛的输出 Schema？

- 如何将长链路拆解为可验证的状态机？

- 如何构建一套覆盖全场景的负面样本回归集？

只有当我们将 AI 模型视为一个“不可靠但强大的组件”，并为其构建一套可靠的工程外壳时，AI Lab 的交付才能真正从“Demo 阶段”走向“生产阶段”。