一次结构化输出失败复盘

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-03 11:40。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

这次失败并不复杂，但特别典型。模型表面上已经按 JSON 返回了结果，接口也没有报错，前端甚至还能正常展示。但真正把结果往下游流程里送时，系统才发现有一个关键字段类型不稳定，有时候是字符串，有时候是数组。

这种问题最麻烦的地方就在于，它不像完全报错那样容易被发现，而是会先以“偶发脏数据”的形式悄悄混进链路。

现象

最早暴露问题的，不是模型调用层，而是后面的业务解析层。平时测试样本都过了，线上少量真实请求一进来，就开始出现解析分支越来越多、补丁越来越多的情况。

判断

这次复盘让我更确定一点：结构化输出的问题，很多时候不是“模型会不会返回 JSON”，而是“Schema 是否真的被定义清楚、校验是否真的执行到位”。

如果没有强校验，系统会默认把“差不多对”当成“可以接收”，后面就会越来越难收拾。

处理

这次之后，我会优先做两件事：

• 模型返回后立刻做严格校验
• 校验失败就 fallback 或重试，不让脏结果继续往后流

把问题卡在入口处，比在下游到处补救省心得多。

结论

一次结构化输出失败最值钱的教训通常不是“换个模型”，而是提醒我们：只要结果要进入系统流程，就必须把契约和校验当成第一优先级。

• 读者：关注 AI 应用落地、全栈工程化、工作流自动化和技术内容系统的开发者。
• 场景：补充 2025 年到 2026 年初这段时间里缺失的技术观察和工程复盘。
• 目标：不写成新闻转述，而是写成可以复用到项目里的判断框架。