让 AI 稳定输出 JSON：从提示词到可校验的数据
把 AI 用在聊天里，少一个字段还能追问；接进自动化流程后，同一个问题就可能让整批任务中断。做工单分类、信息提取或表格整理时，先定义数据契约，会比反复补一句“请严格按格式回答”更容易维护。
先分清两层约束
JSON 模式主要约束输出是合法 JSON；结构化输出进一步要求结果符合指定的 JSON Schema，例如字段名称、数据类型和枚举值。OpenAI 官方也提醒，拒绝回答、输出不完整等情况仍需单独处理，格式正确也不保证内容判断正确。具体支持范围应查看所用模型与接口的结构化输出文档。
用一个小任务设计字段
假设输入是一条演示工单：“导出的文件打不开，请帮忙检查。”我们只提取主题、类别和订单号。先写下约定：类别仅允许“导出问题”“登录问题”“其他”；原文没有订单号时填 null；不能根据语气推测订单信息。
{"topic":"导出的文件无法打开","category":"导出问题","order_id":null}这只是期望结果示例，实际接入时还要把字段规则写进 Schema。普通 JSON Schema 中，在 properties 里声明字段，并不自动代表必填；required 控制字段是否必须出现，允许 null 则要在类型中明确声明。这些区别可以对照JSON Schema 对象规范说明。
给缺失信息留一个明确出口
“没有提供”和“确认不存在”是两回事。上面的 null 只表示原文未给出订单号，不能解释为用户没有订单。如果后续流程需要区分“未提供”“无法辨认”“不适用”，可以另设状态字段，并写清每种状态的含义。
字段也不宜越多越好。先保留后续步骤真正使用的内容；对一个含义复杂的自由文本字段，宁可拆成两个简单字段。新增字段时同步更新解析器、示例与测试用例，避免模型输出和程序预期各走各的。
把校验放在真正产生影响之前
AI 模型生成的概念插图：结构化输出仍需格式检查、业务校验与缺失信息处理。
检查请求是否成功，结果是否完整，以及是否出现拒绝回答。
解析 JSON，并检查字段、类型、枚举与额外字段。
核对业务规则，例如订单号能否在授权范围内查到，类别是否与原文相符。
把缺失或冲突的项目送入待核对队列；通过检查后，再交给后续流程。
可以先准备五类测试输入：正常工单、信息缺失、含错别字、同时包含两个问题、夹带与提取任务无关的指令。记录失败原因，再调整字段定义或提示词。不要让系统在校验失败后无限重试，更不要用默认值悄悄掩盖缺失。
如果结果会触发退款、发消息或修改账户，校验通过也不等于获得执行授权。把“提取数据”和“执行操作”分成独立步骤，保留必要的人工确认，才能让这份 JSON 真正成为可靠流程的一部分。
资料核对日期：2026 年 9 月 30 日。示例为教学设计，未宣称实测效果。
