让模型稳定输出 JSON：约束、校验与重试的工程做法

结构化输出不稳定，多半不是模型问题，而是缺少约束与校验。本文给出三层做法：形态约束、程序校验、失败重试，并说明为什么不该把模型的原始输出直接喂给下游。

三层防线，缺一不可

**第一层：约束输出形态**

明确给出 schema（字段名、类型、取值范围、必填项），而不是说「给我 JSON」；

给出**一个完整示例**与**一个边界示例**（例如字段为空时怎么写）；

说明「不要输出解释、不要用 Markdown 代码块包裹」——这两条是最高频的格式污染源。

**第二层：程序校验**

解析后立刻校验，不要相信提示词：

1. 能否解析（去掉可能的代码块围栏后重试解析）；

2. 必填字段是否都在；

3. 类型是否对（字符串写成数字、数组写成字符串都很常见）；

4. 取值是否在允许集合内（枚举、区间）；

5. 业务校验（日期先后、金额非负、ID 是否存在）。

**第三层：失败重试**

第一次失败：把**校验错误原文**回给模型，让它只修错误处（比整段重写好得多）；

第二次失败：把温度降到 0 或换更稳的模型；

第三次失败：**降级到规则兜底或转人工**，并记录这类样本——它们是最有价值的评测素材。

**把原始输出直接落库**：一旦格式漂了，脏数据会污染下游与统计；

**只校验最外层**：嵌套对象里的字段类型必须逐层校验；

**重试时把上下文全丢掉**：模型看不到刚才错在哪，只会再错一次。

1. schema 写清楚（含空值与边界示例）；

2. 解析 → 校验 → 归一化（例如统一时间格式、去掉多余空白）；

3. 失败时带错误信息重试，最多 2 次；

4. 仍失败则降级，并把该样本加入评测集；

5. 记录**格式失败率**这个指标：它比「感觉还行」靠谱得多。