为什么需要结构化输出
当大模型输出用于驱动下游系统（计费、工单、审批、自动化脚本）时，「自然语言」不够可靠。结构化输出（常见为 JSON）让你能用 schema 校验字段类型、必填项与枚举，从而在入队前拦截错误，而不是等到下游爆炸。
模型侧：提示与约束
常见做法包括：在提示里给出 JSON 示例、字段说明、以及「只输出 JSON，不要解释」的约束。但提示不能替代校验：模型仍可能输出多余文本、注释、尾随逗号或与 schema 不一致的字段。
后端侧：解析与修复策略
推荐流程：
- 尝试从输出中提取 JSON（有时模型会包裹在代码块中）。
- 用严格解析器解析；失败则进入失败分支。
- 可选：一次「修复」尝试（更小模型或规则）——但要记录失败率，避免无限循环。
Schema 设计：少而精
字段越多，越难稳定。优先把关键字段设计得可验证：例如 confidence 用 0-1 浮点，或 risk_level 用枚举。避免让模型输出长字符串承载结构化信息。
版本与兼容
当你升级 schema，要考虑旧数据与回放任务。为每条输出记录 schema_version，并在消费端做兼容处理或迁移。
常见失败模式与应对
结构化输出最常见的失败并不是“完全不返回”，而是“字段名相近但不一致”“类型错误（字符串替代数字）”“多了注释或解释文本”。针对这些失败，建议在服务端区分可自动修复和不可自动修复两类。可修复的进入一次修复流程，不可修复的直接失败并返回明确错误码，避免黑盒重试导致成本失控。
质量门槛建议
你可以为不同业务场景设置不同门槛：例如工单自动分类要求 99% 解析成功率，财务相关流程要求 100% schema 通过率且必须人工复核。把质量门槛写进发布规范，能避免团队在压力下临时降低标准。
观测建议：把错误可视化
建议在监控面板中单独展示结构化输出错误分布，例如“缺少必填字段”“类型不匹配”“JSON 解析失败”。当你能看到错误分布趋势时，优化动作会更有针对性，也更容易评估修复是否有效。
结语
结构化输出的目标是让系统可测试、可监控、可回滚。把校验放在工程里，而不是放在模型里。