当大模型只用于聊天时，输出格式稍有变化无关紧要。但一旦要把模型输出交给程序处理，比如写入数据库、调用接口、渲染页面，格式稳定性就成了生死问题：多一句“好的，以下是结果”、少一个右括号、把数字写成字符串，都可能让程序崩溃。 让大模型稳定输出 JSON，需要提示词、接口能力和程序校验三管齐下。

第一层：提示词设计

明确给出结构

在提示中清楚描述需要的 JSON 结构，包括每个字段的名称、类型、含义和取值范围。最直接的方式是给出一个示例结构：

{
  "sentiment": "positive | neutral | negative",
  "topics": ["string"],
  "summary": "string, 不超过 50 字",
  "needs_followup": true
}

说明边界情况

  • 某个字段没有信息时怎么办：填 null、空数组还是省略？
  • 枚举字段遇到不属于任何类别的情况怎么处理？
  • 数值的单位和精度是什么？

要求只输出 JSON

明确要求不输出任何解释性文字、不使用代码块标记，或者统一使用代码块以便程序提取。保持一致即可。

字段设计要简洁

  • 字段名清晰、无歧义；
  • 避免过深的嵌套；
  • 不要让一个字段承担多种含义；
  • 用枚举代替自由文本，降低不确定性。

第二层：利用结构化输出接口

主流大模型服务大多提供了专门的结构化输出能力：

  • JSON 模式：保证输出是合法的 JSON，但不保证符合你的具体结构；
  • Schema 约束输出：提供 JSON Schema，服务端在生成时约束输出严格符合该结构，这是目前最可靠的方式；
  • 工具调用：把需要的结构定义为一个工具的参数，模型调用工具时输出的参数就是结构化数据，参见 Function Calling 详解。

对于自部署的开源模型，一些推理引擎支持基于语法的约束解码，在生成每个 Token 时只允许符合语法的候选，从而保证输出格式正确。

需要注意，格式正确不等于内容正确。约束解码能保证结构合法，但字段的值是否准确，仍然需要后续校验。

第三层：程序校验与容错

解析前的清理

即使要求只输出 JSON，模型偶尔仍会附带代码块标记或前后说明。在解析前，可以提取第一个完整的 JSON 对象。

Schema 校验

使用 JSON Schema 校验库或数据校验框架，检查字段是否齐全、类型是否正确、枚举值是否合法、数值是否在合理范围内。

业务规则校验

  • 日期是否合法且在合理范围内；
  • 金额之和是否等于总额；
  • 引用的 ID 是否真实存在；
  • 文本字段是否超过长度限制。

失败重试

校验失败时，把错误信息反馈给模型要求修正，例如“字段 sentiment 的值必须是 positive、neutral 或 negative 之一，你输出的是 good”。通常一到两次重试就能修正大部分问题。设置最大重试次数，避免无限循环。

降级处理

多次重试仍失败时，记录日志、返回默认值或转人工处理，确保整个系统不会因为一次失败而崩溃。

提升内容准确性的技巧

  • 先推理后输出：对于需要判断的字段，可以在结构中增加一个“reasoning”字段放在前面，让模型先写出分析过程再给出结论，能提升判断准确率，参见思维链提示；
  • 降低采样温度：结构化输出任务通常使用较低的温度，参见采样参数实用指南；
  • 提供示例：对于复杂结构或判断标准，提供一两个完整的输入输出示例；
  • 拆分复杂结构：一次抽取几十个字段容易出错，可以拆成多次调用，每次处理一组相关字段。

监控与评测

在生产环境中持续监控：格式校验失败率、重试率、各字段的空值率和异常值分布。建立包含典型和边界输入的测试集，在修改提示词或更换模型后进行回归测试，参见如何构建评测集。

小结

让大模型稳定输出 JSON，需要三层保障：提示词清晰描述结构和边界情况，优先使用 Schema 约束的结构化输出接口，程序层面做好解析、校验、重试和降级。格式稳定只是第一步，字段内容的准确性还需要业务规则校验和持续评测来保证。