模型返回 JSON 就够了吗？结构化输出还需要哪些校验
三种正确不是一回事
一段文本能解析为 JSON，只说明语法合法；符合 schema，说明字段、类型和部分约束满足定义；业务正确则还需要检查事实、权限和状态。例如金额是合法数字，不代表它与订单总额一致；项目 ID 是字符串，也不代表当前用户有权操作。
结构化输出降低了解析难度，但不替代业务逻辑。应用应把模型结果视为待验证输入，而不是已经授权的指令。
Schema 怎样写得有用
先定义最小字段集，明确必填项、枚举、数组上限和允许的附加字段。金额、时间和标识符要有一致表示，避免模型在字符串与数字间随意切换。对未知信息允许明确的空值或状态，比强迫模型填满所有字段更可靠。
不同模型服务支持的 JSON Schema 子集可能不同，复杂约束不能假设都由服务端保证。接入时应确认支持范围，并在应用端使用同一份契约再次校验。
分层处理返回结果
第一步检查请求是否成功，以及是否发生拒绝、截断或不完整响应。第二步解析并验证结构。第三步执行业务校验，例如关联资源存在、日期范围合理、当前状态允许变化。最后才进入实际写入或工具调用。
生成订单摘要时，还可以把每个字段与原始证据关联，检查金额或名称是否有来源。不能因为字段看起来合理，就默认模型已经核实。
校验失败如何修复
对缺少字段、枚举错误等可修复问题，可以把具体错误反馈给模型，进行有限次数的修正。修正请求仍要遵守原权限与任务范围，不能顺便补造没有依据的事实。
权限不足、资源不存在或业务状态冲突通常应停止，而不是让模型不断更换 ID 试到成功。重试达到预算后，向用户展示哪些信息需要补充，并保留已验证部分。错误日志避免记录完整敏感材料。
最小验证清单
准备正常输出、缺失字段、额外字段、错误类型、超长数组、无权资源以及响应截断样本。确认每一类都落到预期处理分支，写操作只接收通过全部校验的数据。若使用流式输出，必须等完整对象通过校验后才能执行副作用，不能看到半段 JSON 就创建记录。
本文未绑定某个模型服务，也未声称执行上述测试。面试时可以用“语法、契约、业务”三层组织回答，再解释哪类错误可重试、哪类必须停止。真正的收益是把不确定生成结果关在明确接口内，而不是仅让输出变得整齐。