大模型输出 JSON 总是漂移怎么办：提示词约束、结构化输出与服务端校验怎么选

线上工单分类接入大模型后，最难受的不是模型偶尔答错，而是它大多数时候返回得像 JSON，偏偏在高峰请求里少一个字段、把枚举值改成近义词，或者在对象后面顺手补一段解释。处理这类漂移，不能只在提示词末尾加一句“只输出 JSON”。更稳的做法是按风险分层：提示词负责表达意图，结构化输出负责约束格式，服务端校验负责决定数据能不能进入业务系统。

低风险原型可以先用提示词约束；只要结果要进入数据库、触发流程或影响用户，就应把结构化输出和服务端校验叠起来，最终以业务校验结果为准。

先判断：这份 JSON 是展示结果，还是业务输入

如果 JSON 只是客服页面上的摘要，偶发格式问题通常可以在展示层兜底；但如果它要写入工单表、生成退款审批或触发下游任务，风险就从“显示不好看”变成“状态被错误推进”。先看结果的去向，再谈选型。

我更建议给每个输出定义一个简单的风险等级：只读展示属于低风险，进入检索索引或运营报表属于中风险，改变订单、账务、权限和生产配置属于高风险。等级越高，越不能把模型自报的“格式正确”当成验收结论。

三种方案其实管的是三层风险

把三种方案放在一起比较，最容易犯的错是把它们当作互相替代的开关。它们解决的是不同层次的问题：提示词让模型理解你要什么，结构化输出让接口尽量按指定形状返回，服务端校验则在系统边界重新判断“这份结果能不能被接受”。

这一层次关系可以浓缩成四个业务节点：提示词约束表达意图，结构化输出限制结果形状，服务端校验拦截不合格数据，最后才是最终落库。中间任何一层失败，都应该停在当前层处理，而不是把坏数据继续往后传。

提示词约束：启动成本最低，但边界最软

提示词适合原型和低风险场景。你可以把字段名、类型、枚举值和禁止附加文本写清楚，再用一组正反例说明边界。这会改善输出习惯，也方便模型理解业务语义。

不过，提示词本质上仍是生成条件，不是协议验证器。上下文变长、问题变复杂、模型更换或输出接近长度上限时，格式承诺都可能变软。只要下游代码直接把返回内容当作可信对象，出错时就会很难定位：到底是模型没听懂，还是业务没有验收。

结构化输出：把形状交给接口能力管理

当供应商接口支持 JSON Schema 一类的结构化输出时，可以把对象、数组、必填字段、基本类型和部分枚举约束交给接口层。OpenAI 的 Responses API 文档把 JSON Schema 格式作为结构化输出配置的一种方式；Google Gemini 的官方文档也说明其结构化输出支持 JSON Schema 的一个子集，并明确区分了“返回固定格式”和“让模型执行外部动作”。这些能力能显著降低“多一句解释文字”或字段类型漂移的概率，但不能假设所有 Schema 关键字都被同样支持。

因此，选结构化输出时要核对三个东西：实际调用的模型是否支持、当前接口版本接受哪些 Schema 能力、失败时返回什么状态。不要只在本地用一个简单对象测通，就把递归对象、复杂约束和生产重试策略一起上线。

服务端校验：真正决定能否进入业务状态

服务端校验不是重复劳动，而是最后一道业务边界。除了 JSON 能否解析，还要检查必填字段、长度、枚举、数值范围、租户权限、订单当前状态以及字段之间的组合关系。例如“退款原因”虽然是合法字符串，但订单已经完成退款时，这个结果仍然不能触发第二次退款。

校验失败时保留原始响应的摘要、请求标识和规则命中项，返回一个可观测的失败状态；不要把失败结果悄悄改成默认值后写入。只有在规则确认通过后，才让最终落库或后续任务继续。

先把验收门槛写成数字，再决定是否重试

“格式更稳定”不是可验收的目标。针对需要入库的结果，至少应记录字段缺失数、非法枚举数、解析失败数和业务规则拒绝数。最低门槛可以先定为：字段缺失=0、非法枚举=0、解析失败必须拦截；业务规则拒绝则进入明确的人工复核或补问流程。

这里的当前值不是一张漂亮的监控图，而是一次请求的真实检查结果。若字段缺失为 1，就进入风险拦截，处理动作应是补问、重试或转人工；若四项检查均为 0，才进入“校验通过”和“写入结果”。重试也必须有上限，并且使用同一个业务幂等键，避免一次漂移变成多次副作用。

推荐组合：按业务动作逐层加固

低风险摘要先用提示词约束，配一个轻量 JSON 解析失败提示即可。报表、检索和标签数据建议启用结构化输出，并在服务端检查字段和枚举。审批、账务、权限、订单等高风险动作则需要三层都保留：提示词表达任务，结构化输出约束形状，服务端业务规则决定是否放行。

如果供应商暂时没有满足要求的结构化能力，也不要把风险全部交给提示词。可以先让模型返回普通文本，再由服务端进行严格解析、校验和人工复核；这不是最省事的方案，却能把不确定性挡在业务状态之外。

哪些场景不适合强行结构化

开放式创作、长篇解释和需要保留语气的对话，不一定适合把每个输出都压成固定对象。强行结构化会增加 Schema 维护、失败重试和长度管理成本，还可能让本来有价值的自然语言被截断。

同样，不要把结构化输出误当成事实正确或权限正确。它只能说明返回结果符合某种形状，不能证明模型识别的客户、金额、政策或业务状态是真的。事实核验和权限判断仍要回到可信数据源与业务系统。

一张表做最后决策

相关问题

结构化输出通过了，还需要解析 JSON 吗？

需要。接口能力降低格式错误概率，但服务端仍要处理网络异常、空结果、版本差异和业务字段校验，不能跳过最后一道边界。

校验失败应该立即重试吗？

先区分可恢复错误和业务拒绝。缺字段可以带着缺失项补问一次；权限、订单状态或金额不合法时不应盲目重试。

换模型后为什么要重新验收？

因为模型能力、Schema 支持范围、拒答行为和长度边界都可能不同。至少用固定样本覆盖必填字段、枚举、异常输入和业务拒绝路径。

提示词里要不要写“只输出 JSON”？

可以写，但把它当作意图提示而不是安全边界。真正的门禁仍应由结构化接口和服务端校验完成。

把“能返回”改成“能安全使用”

大模型输出 JSON 的稳定性，最终不是某一句提示词的胜负，而是输入意图、输出形状和业务状态三层是否各自有人负责。先明确结果会不会改变系统状态，再按风险增加结构化输出和服务端规则；把字段缺失、非法枚举和业务拒绝记录下来，团队才知道问题发生在哪里，也才有资格谈重试、换模型或放宽约束。