只要下游是代码，就不会满足于“一段好看的文字”。你需要的是能被程序解析的结构。而模型天然是概率生成器，让它每次都输出合法 JSON，是要专门做工程的。
一、为什么“提示词里写一句请输出 JSON”不够
这句话确实能提高概率，但它不是保证：模型可能加一句解释、可能用单引号、可能少一个括号、可能在字符串里塞了未转义的引号。一次失败就可能让整条流水线崩掉。
二、从弱到强的几种手段
- 提示词约束：明确字段名、类型、是否必填，给一个示例。成本最低，可靠性也最低。
- Few-shot：给一两个“输入 → 正确 JSON”的样例，模型更可能照样式输出。
- 接口级结构约束：让 API 直接接收 JSON Schema（各家叫法不同，如 response_format / 结构化输出），从采样层面约束成合法结构。
- 约束解码：在生成时限制每一步只能选构成合法结构的 token，理论上能保证语法正确。
层级越往下，可靠性越高，代价是灵活性下降、可能不支持所有字段形态。
三、拿到之后必须校验
即使开了结构约束，也不要跳过校验。服务端至少要做：
- 结构校验：字段是否齐全、类型对不对。
- 取值校验：枚举是否越界、数值范围是否合理。
- 业务校验：这个值在当前上下文里是否说得通。
校验失败的常见处理是带错误信息重试一次：把“哪里不符合”告诉模型，比让它盲目重来有效得多。
四、容错与降级
- 解析时容忍常见的“近似合法”（多余的解释文字、markdown 代码块包裹），先剥壳再解析。
- 设重试上限，避免在死循环里烧钱。
- 准备好降级路径：几次失败后返回默认值或转人工，而不是让请求一直挂着。
五、统一约束的一层
如果多个业务都要结构化输出，把模型调用收敛到一层网关会更省心：在网关侧统一配置结构约束、重试策略与校验规则，业务侧只面对一个稳定的契约。长亭百智云的大模型 API 管理网关就属于这一类形态——把模型调用与额度、审计、统一策略收在一起，结构化输出的约定也就能在一个地方维护，而不用每个项目各写一套。
小结
让模型稳定输出 JSON，靠的不是一句提示词，而是三层配合：接口级约束压低出错概率、服务端校验兜住漏网的、重试与降级保证失败也可控。把它当成接口契约来设计，而不是当成一次对话。
