别在 AI 交付中迷信“Prompt 调优”：为什么“结构化输出 (Structured Output)”才是工程化的分水岭

在 AI Lab 的实际交付过程中，很多团队在面对模型输出不稳定、格式乱跳时，最本能的反应是：写更长的 Prompt。

他们会花数小时甚至数天去打磨一段极其复杂的指令，比如：“请严格按照 JSON 格式输出，不要包含任何解释文字，确保 key 是 lowercase_snake_case，如果缺失字段请填 null...”。结果是，模型在 90% 的情况下表现良好，但在剩下的 10% 中，它依然会偶尔加上一句 “Here is the JSON you requested:”，或者在某个深层嵌套的字段里漏掉一个引号。

对于 Demo 来说，这没问题；但对于要跑在生产环境、被下游代码解析的工程化项目来说，这 10% 的不确定性就是灾难。

从“祈祷”到“约束”

Prompt 调优本质上是一种“概率性祈祷”。你试图通过增加上下文权重，让模型在概率分布上倾向于某种格式。而真正的工程化分水岭在于：将对 Prompt 的依赖，转化为对 Schema 的约束。

在实际的 AI 工程实践中，我们建议采取以下三层递进的约束策略：

1. 第一层：强类型 Schema 定义 (Pydantic/JSON Schema)

不要在 Prompt 里描述 JSON 长什么样，而是直接定义一个 Pydantic 模型（或 JSON Schema）。
- 痛点：Prompt 描述的字段名可能会被模型微调（例如 user_id 变成了 userId）。
- 方案：使用支持 response_format={"type": "json_schema", "json_schema": ...} 的 API（如 OpenAI 或最新的本地路由模型）。这在推理层面强制模型遵循特定的语法树。

2. 第二层：输出截断与强制修复 (Post-processing Guardrails)

即便有了 Schema，网络传输或极端 Token 截断仍可能导致 JSON 不完整。
- 工程实践：引入轻量级的修复层（如 json-repair 或自定义正则截断）。
- 逻辑：先尝试标准 json.loads $\rightarrow$ 若失败 $\rightarrow$ 正则提取第一个 { 和最后一个 } $\rightarrow$ 若仍失败 $\rightarrow$ 调用极小规模的模型进行格式修复 $\rightarrow$ 最后才报错。

3. 第三层：少样本 (Few-Shot) 的结构化示例

与其告诉模型“不要做什么”，不如给它三个“正确且极端”的例子。
- 关键点：示例中必须包含边界情况（Edge Cases）。例如，如果某个字段可能为空，示例中必须有一个该字段为 null 的样本。这比写一万字指令有效得多。

实战教训：一个关于“状态机”的坑

我们在为一个自动化运维 Agent 构建状态转换逻辑时，最初使用了复杂的 Prompt 来要求模型输出 {"next_state": "...", "action": "..."}。结果发现模型在处理复杂链路时经常产生幻觉，输出一个不存在的状态名。

我们将其改为：
1. 枚举约束：将所有合法状态定义为 Enum 类型并传给 API 的 Schema 参数。
2. 验证闭环：解析出 next_state 后立即与状态机定义比对 $\rightarrow$ 不匹配则立即触发一次带有错误信息的重试（Retry with Error Feedback），而不是让下游代码崩溃。

给工程团队的建议

如果你发现你的团队正在陷入“为了让 AI 输出正确格式而不断修改 Prompt”的死循环中，请立刻停止这种行为。

记住：Prompt 是用来引导逻辑的，而 Schema 是用来保证交付的。

把精力从“如何写更好的指令”转移到“如何构建更鲁棒的解析管道”上。当你不再需要祈祷模型“这次千万别多说一句话”的时候，你的 AI 项目才真正进入了工程化阶段。