自由文本会毁掉流程
当 AI 结果要进入数据库、触发下一步动作或驱动界面时，必须是结构化数据。让模型直接输出自由文本再靠正则解析，是错误率的主要来源。
正确做法是从第一版就要求模型输出 JSON，并在应用层做严格校验。
约束输出的四层防线
第一层，在提示词里给出明确的 JSON 结构和示例。第二层，使用模型的 JSON 模式或函数调用能力。第三层，应用层解析并校验字段。第四层，校验失败时自动重试或降级。
四层都做，结构化输出的成功率可以稳定在 99% 以上。
- 示例先行：给一个完整 JSON 示例，而不是只描述字段
- 字段约束：说明每个字段的类型、枚举和可选性
- 解析兜底：解析失败时自动修复常见错误
- 降级策略：重试两次仍失败时返回安全默认值
设计 schema 的注意事项
字段名用稳定的英文标识，展示层再映射中文。枚举值要覆盖「未知」和「其他」。数值字段要定义单位，否则模型可能在百分比和绝对值之间摇摆。
Schema 本身也要版本化，方便模型升级后回滚对比。
把校验结果反馈给评测
每次结构化解析失败的样本都应该进入评测集，成为下一次提示词或模型升级的回归用例。
可靠的结构化输出，是 AI 从演示走向生产的第一步。
从 JSON 到业务对象
拿到合法 JSON 只是开始，还要把它映射成业务对象：枚举映射、日期解析、数值单位、缺失字段默认值，都要在应用层完成。
映射逻辑要独立于提示词，这样模型升级或提示词调整时，业务代码不需要跟着改。
模型突然改格式怎么办
即使开启了 JSON 模式，模型升级后仍可能出现字段名变化、多余字段、类型漂移。应用层要把「解析失败」当成一等事件处理，而不是默默吞掉。
做法是：解析失败时先尝试一次自动修复，仍失败就降级返回默认值，并记录样本供评测。连续失败率超过阈值时自动告警，而不是等用户投诉。
把格式变化当成常态设计，模型升级就不会变成线上事故。
schema 评审
结构化输出前，先和业务方一起评审字段：每个字段的含义、枚举值、必填性、兼容策略。业务方确认过的 schema，比工程师单方面定义更不容易返工。
schema 变化要遵循兼容规则：只加字段不删字段，枚举只加不减，废弃字段保留一段时间再移除。
把 schema 当成接口来管理，模型输出才能像普通 API 一样稳定演进。