AI如何稳定输出JSON？从字段设计、格式校验到失败重试的实用指南

AI输出JSON时，最容易被忽略的事实是：合法JSON不等于可靠数据。模型可能返回多余说明、遗漏字段、使用错误类型，甚至生成格式正确但内容不真实的值。因此，稳定的结构化输出应当被当作一项接口工程来设计，而不是只依赖一段提示词。

一、先定义数据结构，再编写提示词

开始调用模型前，先明确每个字段的名称、类型、是否必填、允许的取值范围以及嵌套关系。比如客服工单可以包含工单编号、问题分类、紧急程度、摘要和待办事项，其中紧急程度可以限制为低、中、高三种枚举值，待办事项则定义为字符串数组。

字段定义越具体，后续校验越容易。对于价格、数量、日期、链接等字段，还应提前规定格式和边界。例如价格使用数字而不是带货币符号的文本，数量不能为负数，链接必须符合应用侧要求的格式。提示词中可以说明只返回对象本身，不添加Markdown代码块或解释文字，但这只能降低风险，不能百分之百保证结果始终合法。

二、根据接口能力选择输出方式

不同调用方式的可靠性并不相同。模型原生结构化输出通常可以根据预先定义的结构约束生成结果，适合对字段和类型要求较高的接口。JSON模式一般主要帮助模型返回JSON对象，但不一定覆盖业务层面的必填项、枚举值和内容规则。普通文本提示的约束最弱，适合简单场景，但仍然需要应用侧解析。

无论采用哪种方式，都不要跳过服务端校验。结构化输出减少了格式漂移，却不能替代业务规则，也不能验证模型填写的商品价格、网页信息或任务参数是否真实、是否适用于当前业务。

三、应用侧至少执行四层检查

1. JSON解析：先判断响应能否被解析为合法JSON。解析失败时，记录原始响应并进入错误处理流程。
2. Schema校验：检查顶层类型、必填字段、字段类型、数组元素类型、嵌套关系和枚举值。
3. 字段清洗：去除不应出现的首尾空白，统一可接受的日期或文本格式，并拒绝无法安全转换的值。清洗不能悄悄改变业务含义。
4. 长度与业务检查：限制摘要、标题和数组数量的长度，检查价格不能为负数、链接字段不能为空等业务条件。

例如批量提取网页商品信息时，可以要求输出商品名、价格、币种和链接。解析后不仅要检查价格是不是数字，还要检查价格范围、币种是否在允许列表内，以及链接是否符合系统接收规则。即使全部校验通过，也应把这些字段视为待核验的数据，而不是事实证明。

四、为不同错误设计有限重试

重试不应是无限循环。应用可以先区分错误类型：解析失败说明格式不正确，字段缺失说明结构不完整，类型错误说明字段值与定义不符，业务校验失败则可能是内容不满足规则。将具体错误摘要反馈给模型，通常比重复发送完全相同的请求更有针对性。

重试提示应明确指出待修复的字段和约束，并要求只返回完整JSON。例如缺少紧急程度时，提示可以要求补齐该字段，并限定只能使用低、中、高之一。系统应设置有限次数，达到上限后进入降级方案：返回人工审核队列、使用安全默认值，或拒绝提交而不继续下游处理。对于涉及金额、权限或外部操作的任务，不宜在校验失败时自动执行。

五、记录响应与校验结果

每次请求都应保留必要的原始响应、解析结果、Schema错误、业务校验结果、重试次数和最终处理状态。日志中要注意脱敏，避免保存不必要的个人信息或敏感内容。按错误类型统计后，可以发现是字段设计不清、提示词不完整，还是某类输入经常触发失败。

还可以准备一组固定测试样本，覆盖正常输入、缺失信息、超长文本、特殊字符和格式异常等情况。每次调整字段定义、提示词或模型调用方式后重新运行，观察解析成功率和校验失败分布。这样，优化依据来自可复现的结果，而不是个别成功案例。

六、三个常见落地场景

• 客服工单转换：将用户描述转换为分类、优先级、摘要和待办数组，校验枚举值与文本长度后再进入工单系统。
• 商品信息提取：提取商品名称、价格、币种和链接，分别执行类型、范围、格式和非空检查。
• 任务参数生成：让模型生成可被后端消费的任务名称、输入范围和执行选项，涉及权限或实际操作时先经过人工或规则审核。

稳定输出JSON的核心不是寻找一句万能提示词，而是把模型视为可能出错的上游组件。先定义结构，再选择合适的输出能力，随后进行解析、Schema校验、清洗、业务检查和有限重试，并用日志与回归测试持续改进，才能真正减少格式漂移对系统的影响。