JSON Mode 90% → Function Calling 95% → Structured Output 99.9% → Instructor 99.9%+校验重试
① 问题：LLM 默认输出自由文本
自由文本 → 下游程序解析 = 脆弱。我们需要机器可读的输出。
用户：「帮我查一下上海的天气」
LLM 自由文本：「根据我的分析，上海今天气温 28 度，多云。」
程序要的是：{ "city": "上海", "temp": 28, "weather": "多云" }
→ 解析自由文本 = 脆弱的正则地狱，随便一个标点变化就崩
核心认知：结构化输出不是「让模型输出 JSON」，而是「让模型输出符合 Schema 的 JSON」——需要的是约束，不是技巧。
② 四层次台阶（自动播放逐层点亮）
从「靠自觉」到「硬约束」，可靠性逐级上升。
L1JSON Mode提示词要求「只输出 JSON」90%
L2Function Calling模型调函数=固定 JSON 槽位95%
L3Structured Output解码时约束 JSON Schema99.9%
L4Instructor生成后校验 + 自动重试99.9%+
一句话：JSON Mode 靠自觉 / FC 靠协议槽位 / Structured Output 靠解码约束 / Instructor 靠校验重试。
③ 每层机制拆解
| 层次 | 机制 | 可靠性 | 适用 |
|---|
| L1 JSON Mode | Prompt 要求 JSON，模型「尽力而为」 | 90% | 容错场景，结构不关键 |
| L2 Function Calling | 模型调函数，参数天然是 JSON | 95% | 工具调用场景 |
| L3 Structured Output | 解码器约束（JSON Schema 前缀树） | 99.9% | 需要保证结构的核心链路 |
| L4 Instructor | 生成后校验（Pydantic）+ 自动重试 | 99.9%+ | 严格模式，错误零容忍 |
为什么 FC 是「协议槽位」：模型 API 规定 tool_calls 参数必须是合法 JSON——不是模型自觉，是 API 协议强制。所以可靠性 95%。
为什么 Structured Output 到 99.9%：解码阶段直接用 Schema 引导采样（constrained decoding / 前缀树），非法 token 直接被屏蔽——不是事后补救，是「不可能出错」。
④ 选型决策
决策金字塔：能用 L3 就用 L3（Structured Output 已是主流模型标配）；要结合 Pydantic 校验自动重试就上 L4；工具调用场景天然走 L2；只有兼容旧模型才退到 L1 JSON Mode。
推荐- 新模型：L3 Structured Output
- 严格场景：L4 Instructor
- 工具调用：L2 Function Calling
慎用- L1 JSON Mode（靠自觉，易翻车）
- 手写正则解析自由文本
- 生成后不做任何校验
⑤ 与生态联动收束
与工具层：Structured Output 是让「LLM 与程序」无缝对接的最后一公里——工具调用参数、Agent 间消息、任务输出全走结构化，可靠性才撑得住生产。
与评测：结构化输出是评测可自动化的前提——没有稳定结构，LLM-as-Judge 无法批量打分。
一句话：四层次 = 从「请输出 JSON」到「解码器强制 + 校验重试」的可靠性升级阶梯——生产环境默认 L3，严格场景 L4。