大模型输出能解析成 JSON，就能直接入库吗？

不能只凭解析成功就入库。结构化输出有助于约束格式，但还要核对字段含义、来源证据和业务规则，并处理拒绝或截断等异常。建议把“格式通过”和“业务可用”分开记录，不让缺失信息变成看似完整的错误数据。本文为文档分析，未做产品实测。

结构化输出约束格式，业务仍要验证内容

Gemini 官方文档说明结构化输出支持 JSON Schema 的一个子集，同时要求应用校验字段值，并处理格式符合要求但语义不正确的结果。[1] 因而，“返回的是 JSON”不足以证明结果适合直接进入业务系统。

举一个假设的资料录入场景：模型把联系人姓名、公司名称和联系电话都放进了正确字段，但把另一家公司的电话填了进来。即使字段类型都是字符串，仍需回到原始资料核对。这是用于说明检查方法的假设，不是本文记录的真实错误率或测试结果。

先约定未知值，不要求模型把空格填满

JSON Schema 官方说明，默认情况下，对象可以省略属性，也可以带有额外属性；是否必填、是否允许额外字段需要相应规则。字段值为 null 与字段不存在并不等同。[2] 设计输出结构时，需要把“必须出现这个键”和“这个值已经确定”分开考虑。

编辑建议：为每个业务字段记录名称、类型、允许值、未知时的表达、来源位置和后续处理。原始资料没有电话号码时，不要用虚构数字或无意义的零占位。可以按目标接口允许的方式使用明确的 null 值（不是空字符串），并配套“待核对”状态；如果接口不允许空值，就把记录送入待处理队列。

额外字段也应有明确处理方式。不要让模型新增的“已审批”或“可付款”等字段自动改变业务状态；这类状态应由实际业务规则及有权限的操作决定。上述流程属于编辑建议，需要应用自行实现。

先判断输出是否完成，再做字段和来源核对

Claude 官方文档列出结构化输出的例外：拒绝请求或达到输出 token 上限时，返回内容可能不符合原定结构；拒绝响应仍可能是 HTTP 200。[3] 因此建议接收端先看完成状态，再进入解析和校验，而不是把网络请求成功当成业务成功。

编辑建议把接收流程分为几步：检查结束原因和错误；验证结构；核对关键字段与原文是否一致；检查跨字段关系；通过后写入目标系统。跨字段关系例如开始时间不得晚于结束时间，或某个内部客户编号必须能在本公司的客户表中找到。这里是待实现的检查规则，不是宣称厂商默认执行这些验证。

用异常样本验收，留下可回查的结果

编辑建议建立一组经过授权或脱敏的样本，分别覆盖信息完整、缺字段、信息互相冲突、无关资料和输出不完整。为每组写下预期动作：正常入库、保留待核对、退回补充或停止处理。不要只统计能否解析成功，还要检查关键字段正确性和错误记录是否被拦住。

保存模型配置、结构规则版本、输入资料标识、校验结论及处理人，便于规则更新后回查。记录中只保留排查必需的信息，敏感原文按权限管理。试用阶段先以人工确认过的结果作对照；达到什么条件才允许自动入库，由业务负责人和技术负责人共同确定。 原文自身存在冲突或错误时，也应标记待核对，不能把“与原文一致”直接当作事实已经正确。

适用条件与限制

资料核对日期为2026年10月21日。模型、接口和支持的结构规则可能变化，接入时应核对具体版本；JSON Schema规范的全部能力不等于每家模型API都支持。本文没有比较厂商准确率，也没有提供可直接用于生产的完整实现。