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