让模型输出 JSON：从可读文本到可校验数据
什么是 JSON？
JSON（JavaScript Object Notation）是一种常用的数据交换格式。它使用键值对组织数据，便于人阅读，也便于程序解析。
{
"product": "保温杯",
"quantity": 1,
"damaged": true,
"requested_action": "换货",
"photos": []
}JSON 的值可以是字符串、数字、布尔值、null、数组或对象。合法 JSON 有一些基本要求：
- key 和字符串使用双引号；
- 不能有多余的尾逗号；
- 不能包含注释；
- 布尔值写作
true或false； - 缺失值可以按照事先约定使用
null，不要随意编造。
什么时候需要 JSON？
如果结果只给人阅读，Markdown 或普通文本通常更自然。如果结果要由程序继续处理，例如录入工单、批量分类或调用另一个接口，JSON 会更合适。
JSON 的优势不是“看起来整齐”，而是字段有明确名称和层级。程序可以按字段读取数据，不必猜某一行文字代表什么。
JSON 不是所有任务的必选格式。先判断下游怎样使用结果，再决定使用文本、表格、JSON 或其他格式。
一个安全的信息提取案例
下面的客户反馈是完全虚构的：
包裹今天送到，外箱破了，里面的杯子也裂了。我已经申请换货，但还没有上传照片。我们希望提取问题类型、用户诉求和缺少的材料。
请从 <feedback></feedback> 中提取售后信息，并只输出一个合法 JSON 对象。
字段定义：
- issue_type：字符串，问题类型；
- requested_action：字符串或 null，用户明确提出的处理方式；
- missing_information：字符串数组，继续处理所缺少的信息；
- evidence：字符串数组，支持上述判断的原文片段。
规则：
- 只使用原文信息；
- 原文没有说明的内容不要推断；
- 不要使用 Markdown 代码围栏；
- 输出前检查 JSON 是否可以解析。
<feedback>
包裹今天送到，外箱破了，里面的杯子也裂了。我已经申请换货，但还没有上传照片。
</feedback>可能得到：
{
"issue_type": "商品破损",
"requested_action": "换货",
"missing_information": ["破损照片"],
"evidence": ["外箱破了", "杯子也裂了", "已经申请换货", "还没有上传照片"]
}evidence 字段不是所有场景都需要，但它能帮助人快速检查模型是否根据原文提取，而不是自行补充。
明确怎样处理未知信息
信息提取中最危险的错误之一，是把合理猜测写成事实。
例如，“家长每天在抓坏人”不能可靠证明职业是警察；“在家照顾孩子”也不能可靠证明职业是家庭主妇。正确做法是保留原始描述，或者按约定输出 null / “未提供”。
{
"father_job": null,
"mother_job": null
}如果确实需要推断，应把“事实”和“推断”分成不同字段，并标注依据与不确定性，不能把推断伪装成用户提供的信息。
只在 Prompt 里写“返回 JSON”够吗？
不够。
普通对话中，模型可能输出解释文字、缺少字段、使用错误类型，或者生成语法不合法的 JSON。即使语法正确，字段内容也可能不符合业务规则。
生产系统至少应执行两层检查：
- 语法检查： 输出能否被 JSON parser 解析；
- Schema 与业务检查： 字段是否齐全、类型是否正确、枚举和数值是否在允许范围内。
支持 Structured Outputs 或 JSON Schema 的模型接口，可以让调用方提供结构约束。具体写法、支持的 Schema 子集和可用模型会变化，应查阅所用接口的当前官方文档，不要把某个示例参数当成所有模型的通用能力。
下面是一个简化的 JSON Schema 示例：
{
"type": "object",
"properties": {
"issue_type": { "type": "string" },
"requested_action": { "type": ["string", "null"] },
"missing_information": {
"type": "array",
"items": { "type": "string" }
}
},
"required": ["issue_type", "requested_action", "missing_information"],
"additionalProperties": false
}不要为了演示信息提取，把真实儿童住址、身份证、健康信息或其他不必要的个人数据提交给模型。案例应使用虚构、匿名或经过授权的数据。
本章检查清单
- 下游是否真的需要 JSON；
- 字段名称、类型和允许值是否明确；
- 是否规定未知信息使用
null、空数组或其他约定； - 是否禁止模型补全原文没有的事实；
- 是否保留必要的证据字段；
- 程序是否执行解析、Schema 和业务校验；
- 出错时是否有重试、拒绝或人工处理流程。
JSON 让结果更容易进入程序，但可靠性来自“明确字段 + Schema + 程序校验 + 人工处理例外”，而不是一句“必须返回 JSON”。
