结构化输出是什么：字段符合 Schema 不代表事实全对
解释固定字段与类型约束，区分合法 JSON、结构符合和内容正确，并说明缺失值及请求失败怎样处理。
先理解这个概念
结构化输出是在模型接口支持范围内，让返回内容遵循指定字段、类型或其他结构约束的方式。它帮助程序读取结果，却不能保证字段内容来自真实资料。合法 JSON 与符合目标 Schema 也不同，缺少日期时仍需允许未知。验收应分别检查请求状态、结构和事实，不能因为解析成功就把数据直接视为已核实。
类型约束不负责证明字段来源
OpenAI 和 Anthropic 都提供结构化能力，但支持的 Schema 特性应分别核对。一个字段被限制为字符串，仍可能装入错误姓名；金额是数字，也可能与原文不同。约束解决可读取格式，事实需要资料支持，业务规则还可能要求字段之间一致。不要为了让所有项非空而要求模型猜值，应设计清楚缺失状态。服务拒绝或中断也不能当作普通对象直接解析，必须先处理实际状态，避免一串看似结构完整的默认值掩盖失败。
同一资料核对结构和缺失事实
例如从公开报名表提取姓名和日期，先验证字段类型，再逐项对照原文，随后删除日期信息重试。检查输出是否按预定方式保留未知，而不是生成一个合理日期。加入请求失败场景，确认下游不会误存默认对象。本文没有调用模型或运行解析器，例子只说明验收。流式返回时等待必要结构完成，再检查最终状态，不能把中途分片不完整直接判成最终错误，也不能自行补齐未返回字段。
Schema 更新要同步下游使用者
字段改名或枚举变化后，旧代码可能仍按过去规则读取，应保存结构版本并重跑原样本。更新模型也需要检查支持范围，不能把某平台全部 JSON Schema 特性套到另一个接口。成本包括兼容和人工事实核对，不只减少解析报错。可以将确定字段交给程序规则，开放解释交给模型，再统一验收。最终报告应分开记录格式错误与事实错误，让修复真正对应原因，不把结构化输出宣传成永远不会出错的答案机制。
核对来源
以下资料用于核对概念和方法。文中的示例与测试范围分别注明，实际使用时请核对所用工具的版本。