大模型怎么稳定返回JSON？4个字段规则别只写在提示词里

大模型怎么稳定返回 JSON，很多人第一反应是在提示词末尾再加一句“必须输出合法 JSON”。这当然有用，但远远不够。真正接进页面、表格或业务流程时，下游程序还需要知道字段分别代表什么、没有答案时写什么、格式不对由谁处理。把这些规则只藏在一段自然语言提示里，模型偶尔多一句解释、漏一个键或把数字写成文字，后面的流程就可能一起断掉。

先定义一条业务记录，而不是先要求“像 JSON 一样回答”

假设你要把客户邮件整理成待办，先写清下游真正需要什么：任务标题、负责人、截止日期、原文证据和是否需要人工确认。不要让模型自己决定今天返回三项、明天返回五项。字段越少、含义越稳定，越适合首版验证；把十个不确定字段一次塞进去，通常只会制造更多看似合法、实际无法使用的空值。

{
  "tasks": [
    {
      "title": "需要处理的事项",
      "owner": "已明确的负责人；没有则为 null",
      "due_date": "YYYY-MM-DD；原文没有则为 null",
      "evidence": "支持该判断的原文片段",
      "needs_review": true
    }
  ]
}

这里最重要的不是花括号，而是每个字段都有可执行的约定。null 表示资料未给出，不等于让模型猜一个值；needs_review 让系统能够把不确定结果放到人工队列，而不是把它直接写进正式任务系统。

四层规则一起写，格式才更可用

1. 字段定义：给每个字段写清类型、单位和允许范围。日期只接受哪种格式，金额是否包含税，分类能取哪些值，都要在业务侧先定。
2. 缺失值：资料没有明确答案时统一使用什么表达。不要让同一类缺失今天写“未知”、明天写空字符串、后天又编一个推测。
3. 程序校验：在模型结果进入下游前检查必填键、类型、枚举值和长度。校验失败时保留原始响应，别静默截断后假装成功。
4. 失败回退：规定解析失败、内容不全或风险过高时怎么处理，例如提示用户补充资料、放入人工审核或返回一个明确的异常状态。

提示词负责表达，程序负责验证

提示词可以要求模型“只返回对象、不添加说明”“证据不足时填 null 并标记复核”，但不要把它当成最终的安全网。程序侧仍应验证能否解析、键是否齐全、值是否在允许范围；业务侧仍应抽样确认模型从原文得到的结论有没有被误读。三层各自承担一件事，出了问题才知道该改哪里。

火山引擎官网公开展示火山方舟的模型体验、推理和 API 接入入口。使用模型 API 时，应在当前控制台和官方文档核对所选模型是否支持你需要的参数与输出方式，不把本文的示例当作某个模型的固定接口承诺。尤其是涉及订单、合同、个人资料或对外内容时，结构正确不等于事实正确。

先用五条棘手样例验收，而不是只测正常输入

如果其中任何一条失败，不要立刻用更多提示词包住它。先分清失败是字段设计不清、输入本来缺信息、模型输出不符合预期，还是解析代码没有兜住异常。稳定输出不是一次性做完的特性，而是从小字段集、可观察失败和人工复核逐渐长出来的流程。

Q：要求只输出 JSON 后，还需要校验吗？ A：需要。模型输出可能缺字段、类型不对或内容不可信；校验和回退是下游流程的职责。
Q：所有结果都应该自动写入数据库吗？ A：不应该。先按风险划分，涉及金额、身份、期限、合同或用户权益的字段，应设计人工确认或更严格的验证。