核心要点
优先用平台原生的结构化能力：Function Calling / Tool Use、JSON mode、Structured Outputs（带 JSON Schema）。
底层用约束解码（constrained decoding / grammar）从根本上保证输出符合语法。
应用层必做：用 schema 做校验 + 失败时重试/修复（validation + retry），形成闭环兜底。
标准回答
仅在 prompt 里写「请输出 JSON」并不可靠，应分层加约束：
1. 模型/接口层（最有效）
- Structured Outputs / JSON Schema：传入目标 schema，平台保证返回严格合法且字段匹配的 JSON。
- Function Calling / Tool Use：把目标结构定义成工具参数，让模型「调用工具」，天然产出结构化参数（详见 Function Calling 实战）。
- 约束解码（constrained/grammar-based decoding）：在采样阶段用语法（如 GBNF）屏蔽不合法 token，从根本上杜绝语法错误。
2. Prompt 层（辅助）
- 给出明确 schema/字段说明，用 few-shot 示例固定格式；要求「只输出 JSON、不要额外文字」；降低 temperature 提升稳定性。
3. 应用层（必备兜底）
- 校验 + 重试/修复：用 Pydantic / JSON Schema 校验，失败则带错误信息让模型修正，或做容错解析（剥离 markdown 代码块、补全括号）。这是生产级 Guardrails。
工程上常用 LangChain 的 structured output / output parser 封装上述流程。优先级：原生结构化 > 约束解码 > prompt 约束 + 校验重试。
常见误区
⚠️ 常见踩坑
只靠 prompt 文案「请严格输出 JSON」无法保证稳定——模型仍可能加前后缀、用 markdown 包裹或截断。务必加 schema 约束并在应用层做校验与重试，不要把唯一防线放在提示词上。
追问
追问 1：Function Calling 和 JSON mode 有什么区别？
JSON mode/Structured Outputs 直接让模型把「回答」输出成符合 schema 的 JSON；Function Calling 是让模型决定「是否调用某工具及传什么参数」，参数本身是结构化的。前者面向数据抽取/格式化，后者面向工具编排与 Agent，但两者底层都依赖 schema 约束输出结构。
追问 2：约束解码（constrained decoding）是怎么保证合法的？
在采样每一步，根据目标语法（如 JSON grammar/正则）计算当前合法的 token 集合，对非法 token 的 logits 置为负无穷再采样，使生成路径始终落在语法允许的范围内，从而保证 100% 语法合法。代价是需要语法引擎支持，且可能轻微影响内容质量。
追问 3：输出 JSON 合法但字段语义错误怎么办？
语法合法不等于语义正确。需在校验层加业务规则（枚举范围、数值边界、必填项、跨字段一致性），不通过则带具体错误反馈重试；必要时用 LLM-as-judge 或规则二次校验，并对反复失败的请求降级/告警。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。
📚 知识库
🛠️ AI 工具
- LangChain
最流行的 LLM 应用开发框架，137K+ stars。提供链式编排、RAG 检索增强生成、Agent 构建等核心能力，覆盖 Python 和 JavaScript 双语言生态，是构建 LLM 应用的基础设施