结构化输出与 JSON：让模型「说机器话」才接得住流水线
一、背景
聊天框里 自然语言 很好读，但 下游系统（数据库、工作流、前端表单）往往要 JSON、XML、固定字段。让 LLM 稳定吐出可解析结构，是 Agent、RAG、表单自动填充的 刚需。只靠提示写「请输出 JSON」有时 括号不全、字段胡编、类型乱飘——于是有了 JSON Schema 约束、约束解码、工具模式 等工程手段。
做过 对接 ERP、自动建单、函数参数填充 的同学，基本都踩过 解析失败重试 的坑。本文用口语把 为什么要结构化、常见坑、和 Function Calling 分工 说清楚。
二、核心概念和核心原理（详细解答+通俗解释）
（一）核心概念（先通俗，再详细）
1. 结构化输出——机器可解析、可校验通俗解释：字段名、类型、嵌套 固定，程序
JSON.parse后能走业务逻辑。详细解答：和自由文本比，降低正则抽取；和 Function Calling 比：后者是 调工具，前者是 答内容，但都可能用 Schema。2. JSON Schema通俗解释：用一份 声明 规定有哪些 key、类型是 string 还是 number、哪些必填。详细解答：部分 API 原生支持
response_format: json_schema；没有时靠 提示 + 后处理。**3. 约束解码（Constrained Decoding）**通俗解释：解码每一步 只允许合法 token，从根上 消灭非法 JSON。详细解答：实现复杂，多在 专用推理栈；效果 稳，但 灵活性 略受限。
（二）核心原理（通俗拆解，一步一步讲清楚）
第一步：提示工程打底通俗解释：示例 + 字段说明 + 禁止多余废话；要求 只输出 JSON 无 Markdown。详细解答：仍可能偶发格式错，要 容错解析或重试。
第二步：两阶段通俗解释：先让模型列提纲/字段，再填值；或 先 XML 再转 JSON。详细解答：步骤多 latency 涨，换 稳定性。
第三步：与工具调用协同通俗解释：Function Calling 返回的结构化参数 直接给 API；普通 JSON答案 给业务层。详细解答：MCP 文章里的 tool schema 是 另一类结构化。
三、补充进阶知识点（易懂不晦涩，适配新手进阶）
1. 部分 API 的
strict模式通俗解释：严格按 schema 出参，适合 生产。简单补充：字段别 过度复杂，schema 越大越容易失败。2. 后处理通俗解释：从回复里 抠出 JSON 段落（如 Markdown 代码块）、修尾逗号、用 json5 等库容错。简单补充：别信模型给的假 URL，要业务校验。
3. 和之前知识点的关联（重点） 提示工程 定格式；幻觉 表现为 编字段值；评测 可算 JSON 合法率；流式 下边解析边展示要 增量状态机。
四、文章知识总结
- 背景：下游要机器可读；纯提示 JSON 不稳。
- 核心概念：Schema、约束解码、两阶段生成。
- 核心原理：提示 +平台能力 + 容错；与工具参数分工。
- 进阶：strict 模式；后处理；防假数据。
- 核心逻辑：「能解析」比「读起来像 JSON」难一个数量级。
总结：结构化输出是 LLM 进业务系统的桥；和 Function Calling 一起，构成 自动化的输入输出闭环。