LLM 输出格式约束JSON 模式不是万能保险一、结构化输出仍会失败很多大模型应用要求输出 JSON于是以为加一句“请严格输出 JSON”就安全了。实际生产里模型仍可能输出注释、Markdown、缺字段、字段类型错误、枚举越界或内容截断。某个日志分析系统用 LLM 提取时间范围和关键词线上出现过 JSON 被截断只剩前半段、字段值超界等多次故障导致后端解析失败、告警漏报。JSON 模式能降低风险但不是万能保险。后端必须做校验和恢复。二、先定义 Schemaflowchart TD A[模型输出] -- B[JSON 解析] B -- C[Schema 校验] C -- D[业务校验] D -- E[入库或执行]Schema 要定义字段类型、必填项、枚举值和长度限制。不要只在自然语言里描述。{ type: object, required: [title, tags], properties: { title: { type: string, maxLength: 80 }, tags: { type: array, items: { type: string } } } }结构清楚程序才好验证。三、解析失败要可恢复解析失败时可以重试、让模型修复 JSON、降级为人工处理或者返回可读错误。不要把坏输出直接传给业务。parse_recovery: retry_once: true repair_json: optional fallback_manual: high_risk重试也要有限制。JSON 解析错误通常不是随机波动——如果第一遍就错了大概率是 Prompt 或截断问题只重试一次足够多轮重试只会白花 token 成本。无限重试只会增加成本。四、业务校验比格式更重要JSON 合法不代表业务合法。价格不能为负日期不能早于当前时间操作类型不能越权工具参数不能指向危险路径。if amount 0: raise ValueError(amount must be positive)模型输出进入工具调用前必须经过业务规则校验。最后要统计格式失败率。某个 Prompt 或模型版本导致解析失败升高就不能上线。结构化输出是工程接口不是聊天结果。输出约束还要考虑截断。模型回答超过 token 限制时JSON 可能只生成一半。解析失败日志里要区分语法错误、字段缺失、截断、业务校验失败这些问题的修复方向不同。format_error_types: invalid_json: syntax missing_field: schema enum_out_of_range: schema truncated_output: length business_invalid: rule对于高风险动作不建议自动修复后直接执行。比如模型生成支付参数、删除路径、权限变更即使 JSON 修复成功也应该重新校验并要求确认。还可以采用“先生成草稿再由程序组装最终结构”的方式。模型负责自然语言内容程序负责固定字段和枚举这比让模型自由生成完整 JSON 更稳。最后结构化输出的 Prompt 示例要覆盖错误场景。只给一个完美示例模型遇到缺数据时可能硬编字段。还要考虑流式输出。前端边收边展示时JSON 只有在结束后才完整。不要在流式中途就解析并执行业务动作除非协议明确支持增量事件。streaming_structured_output: parse_only_when_done: true buffer_with_size_limit: true reject_incomplete_payload: true如果使用函数调用或工具调用也不能跳过校验。模型生成的参数仍然可能越界、缺字段或包含危险路径。工具层永远要把模型当作不可信输入。最后格式约束失败的样本要进入回归集。每一次解析事故都是下一版 Prompt 和 Schema 的测试资产。五、总结LLM 输出格式约束要依靠 Schema、解析校验、业务校验、有限重试和失败率监控。JSON 模式不是万能保险。模型输出只要进入系统就必须按接口治理。