完整题目
在大模型应用中，如何设计提示词或后处理机制以确保模型稳定地输出符合JSON格式的结构化内容？
本文目录
核心原则
稳定 JSON 输出依赖协议约束、解析、Schema 校验和有限重试的闭环。提示词只能降低格式错误，普通 Function Calling 也不天然保证参数满足全部 Schema；只有提供方明确支持并启用严格结构化输出时，才能依其文档讨论约束强度，服务端仍应校验。
1. 优先使用结构化协议
- 为输出定义 JSON Schema，包括字段类型、必填项、枚举、数值范围和是否允许额外字段。
- 模型支持 strict structured output 时优先启用；工具调用场景仍要解析 arguments，并在服务端验证。
- 模型不支持原生约束时，在系统指令中给出 Schema、一个最小示例，并明确只返回 JSON。
2. 解析与校验
先用标准 JSON 解析器解析，再用 JSON Schema、Pydantic 或等价工具做字段级验证。不要用简单正则或全局替换单引号、尾随逗号来“修复”任意文本，因为这可能改变字符串内容或掩盖真实错误。若需要修复，应使用受限解析器并保留原始输出与修复记录。
3. 有限重试与降级
- 把具体校验错误回灌给模型，例如缺少字段或枚举非法，而不是只说“格式不对”。
- 设置最大重试次数、超时和幂等键，避免循环调用和重复副作用。
- 重试仍失败时返回显式错误、进入人工审核或使用安全默认值；不能静默伪造必填数据。
4. 监控
分别记录 JSON 解析成功率、Schema 合规率、字段级错误分布、重试次数、降级率和模型版本。对高风险字段还要做业务规则校验与权限检查。
结论：可靠性来自严格协议、服务端校验和有界失败处理，而不是单靠 prompt 或“看起来像 JSON”的文本。
图解
换一种问法，检查是否真正理解
场景切入
假设你在做一个订单查询的客服机器人，用户输入“帮我查一下最近订单”，你需要把模型输出解析成固定的JSON结构。但是模型偶尔会多一个逗号或者用单引号，你一般怎么保证它每次都输出合法的JSON？
层层追问
模型生成文本时怎么让它输出结构化数据？……如果提示词写了格式但模型还是偶尔出错，你有什么后处理手段？……那如果后处理修不好呢，你会怎么兜底？
直球架构
设计一个方案，要求模型稳定输出符合JSON Schema的结构化内容，从提示词设计到后处理容错，把完整的工程链路说一遍，包括重试和降级策略。
练习口述回答 · 约4分钟
- 核心思路：预防 + 容错
- 提示工程做预防
- Function Calling 是首选
- 后处理做容错兜底
- 收口与可延伸点
这个问题我会按可靠性从高到低来设计：能用模型原生的结构化输出就优先用；不能用时，再靠 prompt 约束；最后一定要有解析、校验、重试和降级兜底。不要指望一句“只输出 JSON”就能在生产里稳定运行。
最优先的是 [[Function Calling]]、Tool Use 或 JSON Schema 这类原生机制。我们把字段名、类型、必填项、枚举值、取值范围都定义清楚，让模型输出结构化参数。这样比自由文本再解析稳定得多。但即便用了原生能力，后端也不能直接相信结果，还是要做 schema 校验和业务校验。
如果模型不支持原生结构化输出，prompt 层要尽量减少自由度。我会在 system prompt 里明确要求只输出 JSON，不要 markdown，不要解释文字；然后给出完整 schema 或示例，复杂格式再加 few-shot。比如抽取用户信息时，不只写“输出姓名和年龄”，而是写清楚字段类型、空值怎么表示、数组怎么处理、日期格式是什么。
后处理层我一般分三步。第一步是清洗，比如去掉 markdown 代码块、前后多余解释。第二步是解析和轻量修复，处理尾随逗号、转义错误这类常见问题。第三步是校验，这里至少有两层：JSON 语法合法是一层，字段业务合法是另一层。比如 age 是整数只能说明格式对了，但如果输出 300，业务上仍然要拦。
如果解析或校验失败，我会触发重试。重试时要把错误原因反馈给模型，比如“字段 age 超出 0 到 150 范围，请只修复 JSON，不要改变其他字段”，同时降低 temperature，避免它生成另一套随机结果。重试次数也要有限制，超过阈值就降级为空结构、规则抽取或人工审核。
线上还要监控几个指标：JSON 合法率、schema 合规率、字段缺失率、平均重试次数、最终降级率。因为结构化输出的问题经常不是一次性解决的，要靠失败样本持续优化 prompt、schema 和模型选择。
我会特别强调，JSON 合法不等于结果可信。比如模型输出了一个合法 JSON，但把订单号抽错了，这比格式错更危险。所以高价值场景里，结构化输出后还要做源文本对齐、置信度判断，必要时要求模型给出字段来源。