结构化输出格式有哪些？开发者常用格式与适用场景梳理

你让模型返回 JSON，结果它给你包了一层 markdown 代码块，或者多写了一句解释，解析直接报错。这类问题多半不是模型不行，而是格式本身选错了、约束没给够。这篇把开发者常打交道的几种结构化返回格式摆在一起，说清各自擅长什么、在什么条件下会翻车，以及什么情况下干脆别用结构化输出。

你让模型返回 JSON，它给你包了一层 markdown 代码块，或者前面多写一句「好的，以下是结果」，解析直接报错。这类问题多半不是模型不行，而是格式本身选错了、约束没给够。

这篇把开发者常打交道的几种结构化返回格式摆在一起，说清各自擅长什么、在什么条件下会翻车，以及什么情况下干脆别用结构化输出。读完你至少能拿到一套选型顺序和验证动作，而不是靠反复调提示词碰运气。

先分清：哪些算结构化输出

真正的结构化输出，指的是返回里能被程序直接取值的那部分字段，而不是「看起来像 JSON」的一段文本。判断标准很朴素：能不能一次解析成功，解析失败之后你要花多少成本去救。格式再漂亮，接不进代码就等于没结构化。

• 看用途：给程序消费的优先考虑 schema 约束或工具调用参数
• 看模型支持：不同模型对 schema 约束的完整度不一样，先小样本试
• 看下游：要入库就直接定类型，要给人看就别上严格 schema
• 看变更频率：字段还在天天改的阶段，先别把 schema 写死

几种格式的适用场景与约束

自由 JSON 文本最容易上手，任何模型都能用，代价是容错解析得你自己写。常见翻车点是模型顺手加注释、加解释句、把数字写成带引号的字符串。适合原型阶段和字段不固定的场景。

schema 约束模式把字段名、类型、必填项写在请求里，约束越细模型越难绕过。要注意两点：一是部分服务商或模型对 schema 的支持不完整，二是字段一多，模型漏填、填错的概率会上升，稳定性不是只靠约束就能解决。

什么情况下别硬上结构化

内容本身就是长文、解释或创意文本时，套 schema 会逼着模型削足适履，回答质量先掉一截。这种场景更适合让模型自由写，再由你在代码里做后处理，而不是反过来让格式迁就解析。

字段结构还在频繁改动的早期探索阶段，先跑通业务再定 schema。否则每改一次字段，提示词、校验、测试用例都要跟着重跑一遍，投入产出比很低。

• 要流式输出给用户看的交互场景，严格 schema 往往要等整体生成完才校验，首字体验会变差
• 内容以解释、创意为主，格式约束会压缩表达空间
• 字段还没稳定，业务规则一天一变的阶段
• 模型本身对结构化约束支持较弱，强上不如用半结构化加后处理

判断标准可以简化成一句话：结构化是为了让下游好接，如果下游根本还没定型，先别急着定格式。这条不适用于已经进生产、字段稳定的接口。

选型顺序与验证动作

选型按三步走：先定用途，再定字段，最后做小样本验证。用途决定用哪类格式，字段决定结构复杂度，验证决定这套方案能不能上生产。

1. 先定用途给程序消费的优先 schema 约束或工具调用参数；给人看的可以放宽容错，用键值对或表格。
2. 再定字段只保留下游真正要用的字段，字段越少越容易稳定；能扁平就别嵌套，能枚举就别用自由字符串。
3. 小样本验证同一提示词跑若干次，统计解析成功率和字段缺失情况，别只看跑通一次就下结论。
4. 加校验和降级代码侧保留一层结构校验，校验不过时给出重试或降级路径，不要把稳定性全押在模型身上。

验证这一步最容易被跳过。跑几次正常不代表稳定，尤其是字段多、嵌套深的 schema，失败往往集中在少数几个边界字段上。想对比不同模型在这类任务上的表现，可以到 /tools/speed-test 做延迟和稳定性测试，再到 /models 查模型资料，具体支持能力和当时的表现，以站内页面显示的为准。

如果你正在选接入渠道，可以把结构化输出支持情况当作一项对比维度，结合 /sites 的渠道信息和 /price-watch 的价格追踪一起看，具体数字到对应页面核对当时的版本。

结构化输出的目标不是格式好看，而是下游能稳定接住。