别让“Prompt 调优”成为工程化的遮羞布：AI Lab 交付中的结构化输出与 Schema 强制约束

在 AI Lab 的实际交付中，很多团队在面对模型输出不稳定时，最习惯的反应是：“再写几句 Prompt，给它几个 Few-Shot 例子，应该能搞定。”

这种思维方式在 Demo 阶段非常有效，但在真正的工程化交付（Production-ready）中，过度依赖 Prompt 调优往往成了掩盖系统架构缺陷的“遮羞布”。当你试图通过增加 Prompt 长度来解决一个概率性的格式错误时，你实际上是在用一种不可预测的手段去对抗另一种不可预测性。

从“希望它输出 JSON”到“强制它符合 Schema”

在早期的 Agent 开发中，我们经常在 Prompt 末尾加上：Please output in JSON format. Ensure the keys are 'status' and 'reason'.

结果是：模型在 95% 的时间里表现完美，但在剩下的 5% 时间里，它可能会突然加上 ```json 的 Markdown 标签，或者在 JSON 结尾多出一个逗号，导致下游解析器直接崩溃。

工程化的底线是：不要信任 LLM 的自觉性。

在 AI Lab 的成熟交付链路中，我们采取的是“Schema-First”策略：
1. 定义严格的 Pydantic 模型/JSON Schema：首先定义数据结构的真理来源（Source of Truth），而不是在 Prompt 中描述它。
2. 利用 Function Calling / Tool Use：将输出目标定义为工具调用。这迫使模型进入一种特定的解码模式，其格式稳定性远高于纯文本生成。
3. 强校验与自动重试机制：在解析层引入严格的验证逻辑。如果输出不符合 Schema，立即触发一次带有错误信息的重试（Error-feedback loop），而不是简单地报错。

实战教训：为什么 Few-Shot 不能替代结构化约束？

我曾见过一个处理复杂金融报表的项目，团队尝试通过提供 10 个完美的 Few-Shot 例子来引导模型提取数据。结果发现，随着输入文档长度增加，模型开始在长文本的干扰下丢失对格式的记忆。

当我们把这套逻辑改为 Structured Output (如 OpenAI 的 json_schema 或本地模型的 Constrained Decoding) 后，解析成功率从 88% 直接提升到了 99.9%。

核心差异在于： Few-Shot 是在给模型提供“参考答案”，而结构化约束是在给模型安装“护栏”。前者依赖于模型的模仿能力（概率），后者依赖于解码时的 token 过滤（确定性）。

给 AI 工程实践者的三条建议

1. Prompt 是用来定义逻辑的，不是用来定义格式的。如果你发现自己在 Prompt 里花了大量篇幅描述 JSON 的 key 该怎么写，请立刻转向 Function Calling 或结构化输出接口。
2. 建立“解析失败 $\rightarrow$ 反馈 $\rightarrow$ 重试”的闭环。不要试图一次性写出完美的 Prompt 来消除所有错误，而要构建一个能够自我修复的 pipeline。
3. 脱离对特定模型的依赖。当你使用结构化约束而非特定模型的 Prompt Trick 时，你的系统将更容易在不同规模的模型（如从 GPT-4o 到 Llama-3）之间迁移。

真正的 AI 工程化，就是把 LLM 当成一个极其聪明但极不守规矩的员工——你不能指望他每次都记得格式要求，你得给他一套他无法绕过的填表系统。