结构化输出不是 JSON 能解析就够了：用 JSON Schema 把 AI 接进业务系统

结构化输出不是 JSON 能解析就够了：用 JSON Schema 把 AI 接进业务系统

让模型返回一段 JSON，看起来只是把提示词改成“请按格式输出”；真正进入订单、工单、内容审核或数据分析流程后，团队很快会发现：能被 JSON 解析，不等于字段完整、类型正确，更不等于业务含义可靠。JSON Schema 是描述 JSON 结构与约束的声明式语言，可定义对象属性、必填字段、数组、枚举、长度、数值范围和条件规则。它适合充当模型输出与业务系统之间的机器可验证边界。

从“像 JSON”到可执行契约

最基础的 Schema 会声明对象类型、properties 和 required。对于工单分类，可以要求 category 只能来自固定枚举，priority 是限定范围的整数，summary 有最大长度，evidence 是字符串数组，并禁止未声明字段。验证器负责检查模型返回实例是否符合规则，业务代码不必在多个入口重复手写判断。

三层验证缺一不可

第一层是语法：文本能否解析为 JSON。第二层是结构：是否通过 JSON Schema，包括类型、必填、枚举和范围。第三层是业务语义：订单号是否存在、金额是否与币种匹配、操作者是否有权限、引用证据是否真的支持结论。前两层可以自动化，第三层仍需要调用可信数据源和业务规则。

因此，不要因为模型通过了 Schema 就直接执行退款、发信或删除数据。高影响动作应先展示待执行计划，校验权限与幂等键，必要时要求人工确认。对于分类、摘要等低风险结果，也要保留原始输入、模型代码、Schema 版本与验证错误，便于回放和改进。

失败时修复还是重试

当结果不符合 Schema，可以将精简的验证错误反馈给模型进行一次受控修复，但要限制次数。无限重试会放大成本，并可能在边界输入上循环。若同一字段持续失败，应把问题标记为不可自动处理，进入降级或人工队列。

重试时不要把完整内部异常、密钥或数据库结构放进 Prompt。只返回必要的信息，例如缺少哪个字段、哪个枚举不合法。记录首次输出与修复输出，才能判断是模型不稳定、Schema 设计不清，还是输入本身无法提供答案。

Schema 也需要版本治理

业务字段会变化。新增可选字段通常较安全，删除字段、改名或收紧枚举可能让旧消费者失败。可以给 Schema 独立版本，在一段时间内同时接受旧版和新版，并在消费端明确选择。发布前用固定样本做回归测试，覆盖正常、缺失、额外字段、极端长度和恶意输入。

当多个模型提供结构化输出时，不要假定它们对复杂 Schema 的遵循能力相同。使用同一评测集比较一次通过率、修复成功率、Token、时延和语义正确率。涉及模型选择时，可让另一套独立模型检查失败样本的归因，再由规则验证和人工标注确认。

让能力发现驱动模型选择

AnyAIS 的公开模型目录包含是否支持 JSON、函数调用、流式、视觉、思考模式以及上下文和输出上限等字段。应用可以先筛选支持 JSON 的模型，再通过自己的 Schema 评测决定生产候选，而不是仅凭模型名称写死路由。模型能力字段解决“可能支持什么”，回归测试回答“在这个业务 Schema 上是否可靠”。

上线前的最小清单

明确 required、枚举、范围和额外字段策略；为 Schema 分配版本；对模型输出做语法、结构和业务三层验证；限制修复次数；高风险动作加入权限、幂等与确认；持续统计各模型的一次通过率和失败类型。做到这些，结构化输出才从提示词技巧变成可运营的工程能力。

参考资料

• [JSON Schema 官方概览](https://json-schema.org/overview/what-is-jsonschema)
• [JSON Schema 对象参考](https://json-schema.org/understanding-json-schema/reference/object)
• [AnyAIS 公开模型 API](https://www.anyais.com/api/dev/models)

你可以在 AnyAIS 模型目录筛选支持 JSON 与函数调用的模型，再用自己的 Schema 样本进行小规模交叉评测。