大模型API怎么稳定输出JSON？结构约束、校验与失败重试指南

在导航站或内容管理系统中，让大模型输出JSON只是第一步。模型可能返回格式正确但字段缺失的数据，也可能把不存在的官网、错误的分类ID或不符合业务规则的内容写入结果。因此，稳定接收结构化结果的关键不是只优化提示词，而是建立“约束生成—解析—校验—失败处理”的完整链路。

先区分三种结构化方式

提示词要求JSON是最基础的方式，例如要求模型只返回对象，不要输出解释文字。这种方法实现简单，但模型仍可能漏字段、增加无关字段，或在内容前后添加Markdown代码围栏。

JSON模式通常用于要求响应符合JSON语法。它主要解决能否被解析的问题，并不一定规定对象中必须有哪些字段。不同服务对该模式的参数名称、支持范围和异常行为可能不同，接入前应以目标接口文档和实际测试结果为准。

按JSON Schema约束的结构化输出会进一步描述字段类型、必填项、枚举值以及是否允许额外字段。它比单纯要求JSON更适合自动入库，但Schema能约束结构，不代表模型生成的名称、官网或分类判断一定真实正确，事实核验仍需由业务代码完成。

先设计可校验的数据结构

以将AI工具介绍转换成导航站记录为例，可以规定名称、官网、分类和限制字段：

• name：字符串，必填，长度不能为零。
• official_url：字符串，可要求为规范化网址；若资料中没有官网，应允许明确的空值，而不是让模型猜测。
• category_id：整数，必填，只能使用系统已存在的分类ID。
• limitations：字符串或字符串数组，描述已知限制；未知内容应标记为未知。

如果接口支持Schema，可将字段类型和必填项交给接口约束，并根据服务能力决定是否关闭额外字段。若接口不支持Schema，也要在提示词中列出唯一字段名、示例结构和禁止输出的内容，同时在调用端保留完整校验。

调用端采用三层校验

1. 解析校验：读取响应文本并执行JSON解析。解析前可处理接口明确允许的代码围栏，但不要用宽松的字符串截取掩盖异常。解析失败时记录原始响应、请求标识和错误原因。
2. 结构校验：检查返回值是否为对象，必填字段是否存在，字段类型是否正确，枚举值是否在允许范围内，以及是否出现未定义字段。JSON语法正确，只能说明文本能被解析，不能说明结构完整。
3. 业务校验：查询category_id是否存在，检查official_url是否为空或格式异常，核对名称是否重复，并根据人工审核或已有资料判断官网和限制描述是否可接受。涉及外部事实时，应把模型结果视为待核验数据。

三层校验最好分别返回明确错误，例如“JSON解析失败”“缺少category_id”“分类ID不存在”，这样重试时才能把可修复的问题传回模型，而不是笼统提示“请重新生成”。

分别处理常见失败情况

拒绝回答

模型可能因为请求内容、安全策略或输入资料不足而拒绝生成。此时应识别接口返回的拒绝状态或拒答字段，不要把拒答文本当作JSON继续解析。可以记录原因并转人工处理；若是资料缺失，应补充输入，而不是无条件重复相同请求。

输出截断

当响应达到输出长度上限时，JSON可能只生成了一半。应检查接口的完成原因、响应状态或服务提供的截断标记。截断结果不应直接修补后入库，可在扩大合理输出空间或减少输入内容后重试。

解析或校验失败

对于少量可修复错误，可以把校验错误和原始任务摘要发送给模型，要求只返回修正后的对象。重试必须设置上限，例如单次任务最多重试两到三次，并采用递增等待或请求级超时。达到上限后进入失败队列，保留原始响应和校验日志，避免请求循环和成本失控。

一个适合入库的处理顺序

系统收到模型响应后，可按以下顺序执行：先确认HTTP响应和服务状态，再判断是否拒答或截断；随后解析JSON，执行Schema或等价的结构校验，最后执行分类存在性、网址非空规则、重复记录和人工审核等业务检查。只有全部通过，才写入正式数据表；未通过的结果进入待处理记录，不覆盖已有有效数据。

实际接入时，不同大模型服务对JSON模式、Schema关键字、额外字段和拒答信息的支持并不相同。应为目标服务建立最小测试集，覆盖正常输出、缺字段、错误类型、超长响应和拒答场景，并以接口实际返回为准。这样才能把结构化输出从一次性的提示词技巧，变成可监控、可回退、可审计的工程流程。