← Retour aux guides

让大模型稳定返回JSON：从Schema到校验重试的实战流程

先把“格式一致”定义成可验收的契约

许多团队要求模型“返回JSON”，却仍会遇到字段缺失、数组变成字符串、前后夹带解释文字等问题。根源是要求不够可验证。以商品信息抽取为例，不要只写“返回名称和价格”，而要明确响应对象固定为 {"status":"ok","data":{"name":"","price":0,"currency":"CNY"},"errors":[]}。同时规定价格必须是数字、币种只能取指定枚举值、无法识别时用 null，而不是让模型自行发明“未知”或空字符串。

步骤一：先写Schema，再写提示词

在调用模型前，先由后端或产品团队确定JSON Schema。Schema应覆盖字段类型、必填项、枚举值、数值范围和嵌套层级。对于订单、简历、发票等复杂内容，尤其要规定数组元素的对象结构，避免同一字段有时是对象、有时又是列表。

• 必填字段：如任务编号、处理状态、结果对象。
• 可空字段：信息缺失时返回 null，不能省略字段。
• 数组字段：没有结果时返回 []，不要返回“无数据”。
• 枚举字段：例如状态仅允许 pending、success、failed。

提示词只负责解释业务语义。例如说明“price为税后金额，无法判断币种时currency填写CNY并在errors记录原因”。Schema负责限制机器可读格式，两者不要互相替代。

步骤二：优先使用结构化输出能力

如果所选模型和接口支持JSON Schema或工具调用，应优先将Schema作为请求参数传入，并开启接口提供的严格模式。这样模型生成阶段就会受到字段结构约束，比仅靠自然语言提示稳定得多。若当前模型不支持严格结构化输出，也应在系统提示中明确：只输出一个合法JSON对象、不使用Markdown代码块、不添加任何解释文字。

不要把“请严格返回JSON”当作唯一保障。模型仍可能因上下文过长、字段定义冲突或输出截断而失效。因此，客户端必须把响应当作不可信输入处理。

步骤三：降低生成过程中的随机性

格式型任务通常不需要创意。将temperature设置在0到0.2之间，并固定系统提示、字段顺序和示例格式。给一个完整且真实的正例即可；堆叠十几个示例容易挤占上下文，反而让模型忽略最新规则。还要为输出预留足够的max tokens，JSON在闭合大括号前被截断，是线上解析失败的常见原因。

输入内容与指令应明确分隔。比如将用户原文标记为“待抽取内容”，并要求模型把其中的指令视为数据而非新规则，可降低用户文本中“忽略上文”等提示注入对输出格式的影响。

步骤四：在服务端执行解析、校验和有限重试

生产流程应按“JSON解析→Schema校验→业务校验”三层执行。第一层确认能否解析；第二层检查字段类型、必填项和枚举值；第三层检查业务合理性，例如价格不能为负数、结束时间不能早于开始时间。可使用Ajv、Pydantic等校验工具实现这一层。

• 解析失败时，记录原始响应并发起一次修复请求，附上具体错误，例如“price必须为数字”。
• Schema通过但业务失败时，仅反馈失败字段，避免模型重写全部结果。
• 最多重试一到两次；持续失败则返回标准化错误对象，避免无限消耗额度。
• 记录模型版本、提示词版本和校验错误码，方便定位格式漂移。

步骤五：用稳定模型路由控制成本

格式一致性不代表每个任务都要使用最高价模型。可先用能力较强的模型完善Schema和边界案例，再为重复性的分类、抽取任务选择更经济的模型，并保持同一生产链路的模型版本稳定。无论使用Claude还是GPT，真正影响稳定性的核心仍是Schema、校验和可观测性，而不是单纯更换模型。

用59API快速落地这套流程

59API提供Claude Opus、Sonnet、Haiku、Fable及GPT模型的按量付费访问，采用原生官方质量模型，不做降级处理，适合在开发阶段对比不同模型的结构化输出表现，再按任务成本进行路由。其API地址为 https://api.59api.com，并兼容Claude Code、Codex及OpenAI SDK；已有OpenAI SDK项目通常只需调整基础地址和模型配置即可接入。对于需要频繁重试、批量抽取和多模型回归测试的团队，这种低成本方式尤其便于控制预算。准备把输出格式纳入工程规范时，可以注册59API，先用一组固定测试样本验证你的Schema与校验链路。