刚刚阅读时长 11 分钟

结构化输出不等于可靠输出：2026 年 JSON、schema 与你真正需要的可靠性栈指南

你打开了 JSON 模式，你的 LLM 现在返回有效 JSON。问题在于：符合 schema 的有效 JSON 仍可能在语义上是错的，而生产可靠性不是你启用一个功能——它是你构建的一栈层。本文是经过来源核查的 2026 年生产结构化输出指南：JSON 模式 vs schema 强制结构化输出 vs 函数调用、何时用哪个、为何 Pydantic 和 Zod 不是可选的，以及为何『JSON 解析成功』是可靠性的起点，而非终点。

人工智能 developer-tools 模型新闻

LLM 结构化输出生产 2026 封面

本文是提示工程集群的第三篇，完成技术 → 安全 → 可靠性闭环。别再 cargo-cult 提示词技巧讲了何时用哪种提示技术。提示注入是 OWASP 头号威胁讲了安全维度。本文讲输出维度：当你的 LLM 必须产出机器可读的结构化数据时，如何让它在生产里足够可靠？

我通读了结构化输出文献后的结论很直接：大多数团队把『JSON 解析成功』等同于『输出正确』，这是两件非常不同的事。JSON 模式保证前者；它对后者毫无作用。一个响应可以是完全有效的 JSON、符合你的 schema、却仍在语义上错了——错的值、错的实体、对的形状填了错的内容。2026 年能上线可靠结构化输出功能的团队，不是打开 JSON 模式就停的那些。而是建了可靠性栈——schema 校验、重试逻辑、语义检查、输出审计——的那些，因为他们理解结构是可靠性的地板，不是天花板。

三种方法，各自实际保证什么

2026 的结构化输出格局有三种不同机制，各自带不同保证级别。Vellum 和 Towards Data Science 的决策指南把它们框定得很清楚。

1. JSON 模式（地板）

厂商保证响应是有效 JSON——语法上可解析、没有尾逗号、括号平衡。这就是它保证的全部。JSON 可以有任何键、任何值、任何结构。JSON 模式防止"模型在我要 JSON 时返回散文"；它不防止"模型返回了字段错误的 JSON"。

何时用： 你需要任何有效 JSON，且你的下游代码对结构变化宽容。
不要用： 当你有一个输出必须遵循的特定 schema。用结构化输出代替。

2. 结构化输出 / schema 强制（中间）

厂商保证响应遵循你定义的特定 JSON Schema——对的字段、对的类型、对的约束（枚举、范围、必填 vs 可选）。OpenAI 的结构化输出、Anthropic 的工具使用 schema、Google 的受控生成都提供这个。这比 JSON 模式强得多：它保证形状是对的。

何时用： 你有定义好的 schema，且你要厂商在生成时强制它，而不只是解析时。
局限： 它保证形状，不保证内容。一个 schema 合规的 {"sentiment": "positive"} 仍可能错——文本是负面的，模型误分类了。结构不是语义。

3. 函数调用 / 工具使用（完整机制）

模型被给定一组带类型参数的工具（函数），它决定是否调用、调哪个、用什么参数。这是最结构化的机制：厂商管理 schema 强制和路由，模型的输出是一个结构化函数调用，而不是自由 JSON。

何时用： 你的 LLM 需要用结构化参数采取行动（调 API、查数据库、触发工具），而不只是返回数据。
局限： 同样的内容可靠性鸿沟适用。模型可以用错误的参数调对的函数——完美结构化、语义不正确。

为什么"结构化"不等于"可靠"

这是本文最重要的一点，也是大多数团队错过的。Rotascale 的分析尖锐地命名了它：结构化输出不等于可靠输出。 Schema 合规覆盖的是多行可靠性栈中的一行。一个通过 schema 校验的响应仍可能在这些方式的任何一种中失败：

错的值。 Schema 说 {"score": number}，模型对一个正确分数是 3 的输入返回 {"score": 7}。有效 JSON、有效 schema、错答案。
幻觉内容。 Schema 说 {"entities": string[]}，模型返回源文本里不出现的实体。结构化幻觉仍是幻觉。
类型意图不一致。 Schema 说 {"date": string}，模型把"上周二"作为字符串返回。对 schema 有效，作为日期无用。
丢失细微差别。 Schema 有一个类别枚举，模型选了一个技术上有效、但错过了人类会捕获的细微差别的类别。

这隐含的纪律是：schema 校验是可靠性栈的一层，不是全部。你还需要语义检查（模型真的回答了问题吗，而不只是产出了有效对象）、重试逻辑（当输出未通过校验或语义检查时，带错误反馈重试）、以及输出审计（抽样并评审生产输出的语义正确性，因为 schema 合规不会抓住语义漂移）。

生产可靠性栈

综合 TECHSY 的 Pydantic/Zod 指南、Collin Wilkins 的 schema 校验文章和 Rotascale 的可靠性框架，下面是我会为任何结构化输出功能建的栈：

Schema 定义（Pydantic 或 Zod）。 把输出 schema 定义为代码，不是 prompt 里的注释。Pydantic（Python）和 Zod（TypeScript/JS）是主流库。Schema 是你与模型的契约，也是你输出的校验层。
厂商原生结构化输出。 用厂商的 schema 强制功能（OpenAI 结构化输出、Anthropic 工具使用、Google 受控生成），而不是在 prompt 里要 JSON 并祈祷。原生强制比基于 prompt 的 JSON 请求可靠得多。
接收时校验。 当模型返回时，在你的代码里对照 schema 校验输出。拒绝不合规的输出；不要试图修补它们。这抓住结构性失败。
失败重试。 当校验失败时重试——理想情况下把校验错误反馈给模型让它纠正。设重试上限（两三次）以避免成本螺旋。
语义检查。 对高风险字段，在 schema 之外加语义检查：模型分类对了吗、提取了正确的实体吗、分数合理吗？这是校准过的 LLM 评审或确定性校验器增值的地方。
输出审计。 定期抽样生产输出并评审语义正确性。Schema 合规不会告诉你模型何时开始返回微妙错误的值；审计会。

营销稿不会写的锋利之处

几个值得知道的风险：

复杂嵌套 schema 更不可靠。 Schema 越深越复杂，模型越可能在即使有 schema 强制的情况下产出结构错误。尽量保持 schema 扁平。
结构化输出可能约束模型推理。 强制模型产出特定结构有时会降低答案质量，因为结构约束了模型"思考"的方式。对难推理任务，考虑让模型先用自由文本推理，再结构化最终答案。
流式 + 结构化输出很难。 如果你向用户流式传输部分输出，你无法在流完成前校验，这意味着部分输出在流中途可能在结构上无效。为此设计 UX。
函数调用不免疫提示注入风险。 提示注入可以诱导模型用恶意参数调用函数。函数调用机制结构化了攻击；它不防止攻击。
结构化输出的基准本身不可靠。 Cleanlab 对结构化输出基准的批评值得读：很多基准衡量错了东西，高分不预测你在特定 schema 和领域上的可靠性。在你自己的数据上测。

它如何对接技术栈的其余部分

结构化输出是 LLM 输出与你应用其余部分之间的桥梁，这也是它连接每个前面集群的原因：

它消费提示技术——结构化输出是一个提示决策，系统提示是你定义 schema 契约的地方。
它继承注入风险——函数调用是行动，行动需要沙箱。
它喂给你的评测管线——结构化输出可以确定性评测（schema 校验）和语义评测（评审），是最好评测的输出之一。
它与按任务成本可观测性配对——重试循环增加成本，你需要知道你的可靠性栈值不值它花的钱。

我的看法

2026 的故事是：结构化输出从"要 JSON 并祈祷"成熟为真正的工程纪律，但大多数团队停在第一层——打开 JSON 模式——并把它当作解。它是地板。天花板是一个可靠性栈：schema 定义、原生强制、校验、重试、语义检查、审计。生产里结构化输出功能可靠的团队，是建了完整栈、并接受"JSON 解析成功"是可靠性起点而非终点的那些。

如果你从本文只记一件事：schema 合规保证结构，不保证正确。建检查正确性的层，否则你漂亮的结构化输出会漂亮地错。

本文是提示工程集群的第三篇。从别再 cargo-cult 提示词技巧起步看提示基础，然后提示注入防御看安全，再本篇看输出可靠性。关于如何评测你的结构化输出是否语义正确，见 LLM 评测集群。想找厂商的常驻参考，见我们的 AI 价格数据页。