“请严格返回 JSON不要输出其他内容。”这句话很多开发者都写过但程序照样可能遇到多余说明、字段缺失、类型错误甚至结构完全正确、内容却不符合业务要求的结果。本文以订单查询助手为例讲清合法 JSON、符合 Schema 和业务正确三个层次以及提示词约束、原生结构化输出、工具调用和应用端校验分别承担什么职责。一、模型觉得自己答得很好程序却直接报错你想让模型把用户需求转成一个对象结果它返回好的以下是你需要的 JSON{order_id: A1023, intent: query_shipping}人一眼就能看懂但如果程序把整段文本交给 JSON 解析器前面那句“好的”就可能导致解析失败。你继续强调“不要解释”模型终于只返回对象了却把字段名改成了orderId。程序仍然拿不到预期的order_id。好不容易字段名也对了模型又填了一个用户根本没提供过的订单号。这就像收集报名表有人交作文有人把年龄写进姓名栏还有人每个格子都填满了但内容是编的。让结果能被程序使用需要同时解决格式、结构和内容问题。二、三个层次一定要分清层次检查什么典型问题JSON 语法能不能解析成合法 JSON多余说明、引号错误、内容截断Schema 结构字段、类型、枚举是否符合约定缺字段、类型错误、出现未知状态业务语义内容是否符合用户输入和业务规则编造订单号、查错订单、权限不符下面这段数据可能是合法 JSON{ order_id: 1023, intent: 随便查一下 }但如果接口约定订单号是字符串意图只能取固定枚举它就不符合结构要求。再看这一段{ order_id: A9999, intent: query_shipping }字段和类型都可能正确。但用户说的是 A1023它仍然是错误结果。JSON 能解析不等于字段符合要求字段符合要求也不等于业务正确。三、什么是结构化输出把“自由作文”变成“按表填报”结构化输出是让模型按预先约定的数据结构返回结果使程序能够稳定地读取字段并继续处理。这个约定常用 JSON Schema、类型定义或数据模型表达。例如订单查询助手可以设计一份表格字段类型用途status枚举字符串可继续处理、需澄清或不支持intent枚举字符串查询物流、查询退款或未知order_id字符串或 null从用户提供的信息中提取订单号missing_fields字符串数组还缺少哪些必要信息其中status的“可继续处理”只表示提取阶段的信息条件满足不表示已经查到订单更不表示已经通过权限校验。LangChain 的官方文档将结构化输出描述为返回可预测格式的数据并提供模型提供方原生策略与工具调用策略等实现方式。四、四种常见做法区别在哪里做法主要机制能解决什么仍需处理什么提示词要求返回 JSON用文字与示例约束模型快速约定输出风格模型仍可能偏离格式JSON 模式在支持的平台上约束 JSON 输出提高 JSON 格式可靠性不一定严格符合业务 Schema原生结构化输出按接口支持的 Schema 约束生成提高字段与结构一致性支持范围、异常结束、语义错误工具调用形式用工具参数承载结果与工具接口或框架流程衔接严格程度取决于接口与配置这些名称的具体行为与模型、平台和版本有关不能只看到“JSON”或“strict”就认为所有要求都得到了保证。原生结构化输出为什么更稳定可以用填表来理解提示词约束像在纸上写“请按格式填写”约束生成则像给输入过程设置了格式限制某些不符合结构的内容无法按普通自由输出的方式产生。例如Claude 官方文档介绍了把 Schema 编译为语法约束的方式。这种机制主要帮助控制结构。它不会因为订单号字段必须是字符串就自动知道用户真正要查的是哪个订单。工具调用是不是等于执行了业务操作也不是。模型输出一组工具参数首先只是形成了调用请求或结构化数据。是否实际执行查询、写库、退款等操作由应用的后续逻辑决定。有些框架借用工具调用机制收集结构化结果这个“输出工具”本身不需要产生业务副作用。五、完整案例把用户的话转换成可处理的请求用户说帮我查一下订单 A1023 的物流到哪了。在下面这个示例设计中期望输出为{ status: ready, intent: query_shipping, order_id: A1023, missing_fields: [] }应用可以按以下顺序处理确认模型响应是否正常、完整结束。解析结果并校验结构。检查ready状态下是否真的存在订单号和受支持的意图。根据登录身份查询订单归属与访问权限。在校验通过后调用物流查询接口。这里的用户身份、租户和实际权限应来自可信的会话与服务端系统不能让模型随意填写一个authorized: true就算通过。用户没给订单号怎么办用户只说查一下我的物流。如果上下文和已授权数据中也没有足够信息可以返回{ status: needs_clarification, intent: query_shipping, order_id: null, missing_fields: [order_id] }这样前端可以明确地请求用户补充订单而不是拿一个编造的订单号继续查询。好的输出结构会给“信息不足”留位置。如果 Schema 强迫模型必须填写所有具体值却没有表达未知的方式就容易把模型推向猜测。六、Schema 怎么设计才能既好用又不添乱1. 用明确类型代替模糊描述“数量”是整数还是字符串“金额”是元还是分“时间”采用什么时区这些需要提前约定。在程序接口中可以把金额设计成整数分并明确币种时间明确采用带时区的格式。具体选型按业务要求决定但不能让不同环节各自猜测单位。2. 固定状态使用枚举如果后端只识别ready、needs_clarification、unsupported就不要让模型自由创造“基本可以”“有点不确定”等状态名。面向用户的解释可以自由一些供程序分支判断的字段应尽量明确。3. 区分字段缺失、null 和空字符串表达可以约定的含义字段缺失当前结构允许不提供该字段null字段存在但当前没有可用值一个长度为零的字符串[]一个没有元素的数组这些值不会天然表达完全相同的业务含义。例如missing_fields: []表示没有待补充字段而order_id: 未必是有效订单号。4. 限制不需要的额外字段可以在适用的 Schema 中限制未知字段避免模型额外生成一个后端没有定义的execute_now或is_admin。但关闭额外字段仍然只是结构控制不会替代权限校验。5. 跨字段规则放在哪里例如status为ready时order_id必须有可用值missing_fields必须为空。这属于字段之间的联合约束。部分规则可以通过支持的 Schema 表达其他规则由应用校验器完成。不要默认模型接口支持 JSON Schema 的全部功能。以 Claude 文档为例原生结构化输出存在 Schema 支持范围限制。应根据实际接口能力生成约束并在应用端补足验证。七、返回 JSON 失败了是不是让模型重试就行先区分失败原因再选择处理方式。失败类型更合理的处理多余文本或格式不符优先改用更可靠的输出方式必要时有限修复字段类型或枚举错误提供明确校验错误进行有预算的重试输出被长度上限截断调整输出规模或预算获取完整结果用户信息不足澄清或使用设计好的未知状态模型拒答进入对应响应分支订单不存在或无权限按业务结果处理不要求模型“修好”原生结构化输出也需要识别异常结束。Claude 文档明确列出了拒答、达到输出长度上限等情况下的特殊处理需求。尤其不能把“订单不存在”当成模型输出错误让模型换一个订单号试到成功为止。修复格式与修改事实是两件完全不同的事。能不能直接用正则截出大括号里面的内容对于边界明确的简单包装应用可以进行严格、有限的预处理。但“找到第一个左大括号和最后一个右大括号”无法可靠处理多个对象、嵌套文本、字符串中的括号等情况也不能证明提取出来的对象就是预期结果。即使成功解析后面的结构和业务检查仍然需要完成。八、流式 JSON能不能边收到边执行通常应该把展示和执行分开。一个尚未接收完整的 JSON 片段可能缺少后续字段也可能最终因为截断而失败。前端可以使用适当的增量解析方式做预览但订单查询、写库等后续操作应等待约定的完整结果通过校验。如果业务采用明确的分块协议可以逐块验证和处理那需要提前定义每块的边界和语义不是对任意半截 JSON 直接执行。看起来像一个字段值不代表它已经成为经过验证的业务输入。九、怎样验证输出方案真的可靠不要只测试一句“帮我查订单 A1023”。可以增加这些样本输入情况希望看到的行为订单号和意图都明确正确提取进入后续校验缺少订单号标记需澄清不编造同时出现两个订单号按任务语义处理必要时澄清用户纠正先前订单号使用有效的最新要求请求不在支持范围内返回明确的不支持状态很长的文本输入保持字段提取与输出边界正确输出截断、拒答或接口异常正确进入相应错误分支评测时至少区分JSON 解析成功率。Schema 校验通过率。字段提取正确率。端到端任务成功率。同时记录拒答、截断和接口异常的比例说明统计分母避免只挑正常完成的响应来展示一个漂亮的格式通过率。十、面试精简总结我会把输出可靠性分成三层合法 JSON、符合 Schema、满足业务语义。提示词可以帮助模型理解要求但正式接口优先使用可用的原生结构化输出或适当的工具调用机制再进行应用端校验。Schema 需要定义类型、枚举、未知值和状态避免为了填满字段而编造内容。拿到结果后先检查完成状态再解析和校验结构最后检查跨字段规则、资源归属及权限。对格式错误可以有限修复但信息不足应澄清业务失败按真实结果处理拒答和截断单独分支。结构化输出让数据更容易被程序处理并不保证内容真实或操作已经获准。一句话记忆模型负责按表填写程序负责验表业务系统负责决定能不能办。