三层防线，缺一不可
第一层：约束输出形态
- 明确给出 schema（字段名、类型、取值范围、必填项），而不是说「给我 JSON」；
- 给出一个完整示例与一个边界示例（例如字段为空时怎么写）；
- 说明「不要输出解释、不要用 Markdown 代码块包裹」——这两条是最高频的格式污染源。
第二层：程序校验
解析后立刻校验，不要相信提示词：
- 能否解析（去掉可能的代码块围栏后重试解析）；
- 必填字段是否都在；
- 类型是否对（字符串写成数字、数组写成字符串都很常见）；
- 取值是否在允许集合内（枚举、区间）；
- 业务校验（日期先后、金额非负、ID 是否存在）。
第三层：失败重试
- 第一次失败：把校验错误原文回给模型，让它只修错误处（比整段重写好得多）；
- 第二次失败：把温度降到 0 或换更稳的模型；
- 第三次失败：降级到规则兜底或转人工，并记录这类样本——它们是最有价值的评测素材。
三个常见坑
- 把原始输出直接落库：一旦格式漂了，脏数据会污染下游与统计；
- 只校验最外层：嵌套对象里的字段类型必须逐层校验；
- 重试时把上下文全丢掉：模型看不到刚才错在哪，只会再错一次。
一个可执行的检查清单
- schema 写清楚（含空值与边界示例）；
- 解析 → 校验 → 归一化（例如统一时间格式、去掉多余空白）；
- 失败时带错误信息重试，最多 2 次；
- 仍失败则降级，并把该样本加入评测集；
- 记录格式失败率这个指标：它比「感觉还行」靠谱得多。