很多大模型应用都会要求模型返回 JSON：生成面试题、抽取简历信息、判断用户意图、规划 Agent 步骤。演示时它经常表现不错，但上线后很快会遇到问题：少字段、多字段、类型错、混入解释文本、数组长度不符合预期，甚至返回了看似合法但业务上危险的参数。
所以结构化输出不是一句“请严格返回 JSON”。它是一个后端可靠性问题，需要提示词、模型能力、解析器、业务校验、重试和兜底一起设计。
语法正确不代表业务正确
模型返回合法 JSON，只说明它能被解析，不说明内容可执行。比如 Agent 生成工具参数时，日期范围可能过大，用户 ID 可能为空，金额可能超出权限，操作类型可能和当前状态不匹配。这些都不是 JSON Schema 能完全解决的。
后端至少要做两层校验：第一层是结构校验，字段是否存在、类型是否正确、枚举是否合法；第二层是业务校验，用户是否有权限，状态是否允许变更，参数范围是否合理，是否需要二次确认。
字段缺失：只靠模型的风险是默认猜测参数，后端要做的事是返回追问或补充提示。类型错误：只靠模型的风险是解析失败，后端要做的事是严格 schema 校验。
- 参数越权：只靠模型的风险是执行危险动作，后端要做的事是权限和状态检查。
- 低置信度意图：只靠模型的风险是调错工具，后端要做的事是让用户确认或转人工。
重试不能无限做
解析失败后重试是常见策略，但不能无限重试。一次失败可能是模型偶发格式漂移，两三次仍失败就可能是输入不清楚、提示词不适合或任务本身不可结构化。继续重试只会增加延迟和成本。
更好的处理是按错误类型分流：格式错误可以带着错误信息让模型修正；字段缺失可以追问用户；业务校验失败不能让模型自己绕过，而要直接拒绝或要求确认；高风险操作即使结构正确，也应该进入确认流程。
结构化输出要保留可复盘信息
上线后最怕用户说“系统执行错了”，但你只能看到最终结果。每次结构化输出都应该记录模型输入摘要、输出内容、解析结果、校验错误、重试次数和最终执行动作。这样排查时才能知道问题在模型理解、提示词约束、解析器还是业务校验。
这里要注意隐私和成本，日志不一定保存完整用户内容，但必须保存足够复盘的信息。尤其是 Agent 工具调用和自动化任务，没有审计链就很难安全上线。
面试里的高分表达
可以这样讲：我会把模型结构化输出当成不可信输入处理。模型负责给建议，后端负责解析、schema 校验、业务校验和权限判断；失败时按类型决定修正重试、追问、降级或人工确认；高风险动作不能因为 JSON 合法就直接执行。这个回答能把大模型项目从“调接口”讲到生产工程。