让 AI 写一段说明，少一个逗号通常没什么。让它把发票信息交给报销系统，字段名写错一个字，后面的程序就可能停住。金额若被写进备注，程序继续运行，麻烦还会藏得更久。
我对照了 OpenAI、Gemini 和 JSON Schema 的公开说明。现在多家模型接口都支持结构化输出，开发者可以预先规定对象有哪些字段、字段是什么类型、哪些必须出现。它解决了一大类格式问题，适合把模型结果交给数据库、表单和下一段程序。
先约定系统能接住什么
拿报销单录入来说，应用可以要求模型返回发票号码、开票日期、含税金额和币种。日期只收字符串，金额只收数字，币种从允许列表里选。required 可以规定缺少哪些字段就算失败，additionalProperties 可以阻止模型临时加出一栏“温馨提示”。
OpenAI 早先提供的 JSON mode 主要保证输出是有效 JSON。Structured Outputs 在支持的模型上进一步按 schema 约束字段。Gemini 也提供相近能力，Python 和 JavaScript 项目还能用 Pydantic 或 Zod 生成 schema。团队已经有接口类型时，可以沿用现有定义，少维护一份只给提示词看的格式说明。
schema 还要保持朴素。各家接口支持的是 JSON Schema 子集，太复杂的条件可能直接报错。OpenAI 说明，新 schema 第一次处理会增加延迟，复杂定义可能更慢。频繁为每一份文件生成全新 schema，会让缓存与排错都变难。稳定业务适合使用少量有版本号的 schema，修改字段时同时更新调用端和测试。
格式正确仍可能填错
JSON Schema 擅长检查形状。它能发现“金额”被填成一段文字，却不知道一百元是否来自这张发票，也不知道报销人选错了成本中心。JSON Schema 官方说明也承认，复杂数据往往需要结构校验和业务语义校验两个阶段。
应用因此要继续核对业务规则。含税金额能否与明细相加，日期是否落在报销周期，供应商编号能否在主数据中找到，这些检查应由确定的代码完成。影响付款和入账的字段还要保留原文位置或截图，让审核人能回到证据。
模型也可能拒绝请求，或者在达到输出长度上限时被截断。OpenAI 的说明要求调用端检查拒绝标记与结束原因。只要状态异常，就不要把半份对象补几个空值后送进业务系统。错误应进入待处理队列，留下输入版本、schema 版本和原始响应，方便重试与追查。
先在低风险流程里试
结构化输出很适合从草稿和辅助录入开始。模型先把一批文件整理成候选记录，程序做类型与业务校验，人确认以后再写入正式系统。连续运行一段时间，可以统计缺字段、填错值、拒绝与人工改动各有多少。
这些数字比一句“能输出 JSON”有用。格式失败变少以后，团队才看得清剩下的问题究竟来自识别、判断还是原始文件。输出字段写清了，AI 才从一段可读文字变成系统能够谨慎接住的数据。