很多人第一次接 OpenAI API，会把重点放在“模型回答得好不好”。真正进入业务系统后，你会发现另一个问题更要命：回答如果不是稳定的 JSON，后面的表单、CRM、数据库、n8n 工作流、Dify 节点就很难可靠处理。
这也是 OpenAI API 结构化输出的价值。它不是单纯让模型“尽量按 JSON 回答”，而是把你需要的字段、类型、枚举、必填项写成 JSON Schema，让模型输出更接近可被程序直接解析的数据。对做 AI编程工具专题、OpenAI专题 和自动化应用的人来说，这是从“能聊”走向“能接系统”的关键一步。
先说结论：不要只靠提示词约束格式
以前很多教程会这样写提示词：
请只返回JSON，不要解释，不要使用Markdown。
字段包括 name、phone、intent、budget。
这种写法能用，但不够稳。模型可能多输出一句解释，可能把数字写成字符串，可能漏字段，也可能在复杂输入里改变字段名。只要下游程序严格解析，就容易报错。
更稳的思路是：提示词负责说明任务，JSON Schema 负责约束结构，程序负责校验和兜底。OpenAI 官方 Structured Outputs 文档也明确把它用于确保模型输出符合开发者提供的 JSON Schema。简单说，格式控制不应该只靠一句“请按 JSON 输出”。
适合结构化输出的5类场景
不是所有 AI 回答都需要结构化输出。写一篇文章、总结一段资料、做头脑风暴，普通文本就够了。下面这些场景更适合用 OpenAI API 结构化输出：
- 线索识别：从客户咨询里抽取姓名、联系方式、需求类型、预算、紧急程度。
- 内容审核：判断文章是否包含标题、摘要、内链、敏感词、风险项。
- 工单分类：把客服消息分成售前、售后、退款、技术故障、投诉建议。
- 数据清洗：把杂乱文本整理成统一字段，写入表格或数据库。
- Agent步骤结果：让每一步返回状态、证据、下一步动作和是否需要人工确认。
比如站内之前写过 OpenAI Agents SDK实战 和 ChatGPT Agent实用工作流，那类多步骤任务如果要进入生产流程，就不能只看自然语言结果，最好让关键节点返回结构化数据。
一个最小可用的JSON Schema应该怎么设计
先用一个客户线索识别例子。假设你要从用户留言里抽取销售线索，可以设计成这样：
{
"type": "object",
"additionalProperties": false,
"properties": {
"customer_name": { "type": "string" },
"contact": { "type": "string" },
"intent": {
"type": "string",
"enum": ["咨询价格", "预约演示", "售后问题", "资料索取", "其他"]
},
"urgency": {
"type": "string",
"enum": ["高", "中", "低"]
},
"summary": { "type": "string" },
"needs_human_review": { "type": "boolean" }
},
"required": [
"customer_name",
"contact",
"intent",
"urgency",
"summary",
"needs_human_review"
]
}
这里有几个关键点：
type写清对象、字符串、布尔值等类型。enum用来限制分类字段，避免模型随手创造新分类。required明确哪些字段必须出现。additionalProperties: false避免模型额外塞入下游不认识的字段。
很多 JSON 输出不稳定，根源不是模型“笨”，而是字段设计太松。你让它自由发挥，它当然会按照自然语言习惯补充解释；你把字段边界写清楚，它才更像一个可接入系统的接口。
字段不要贪多：先覆盖下游真正要用的动作
新手很容易一上来设计二三十个字段：情绪、行业、地区、预算、购买阶段、推荐话术、客户画像、风险等级、下一步动作。字段看起来很完整，但越多越难稳定，也越难验收。
我建议先反过来问：下游系统到底要做什么？
- 如果只是分配客服，可能只需要需求类型、紧急程度、是否人工接管。
- 如果要写入 CRM，可能需要联系人、公司、需求摘要、下一次跟进时间。
- 如果要做内容审核，可能需要是否通过、问题列表、修改建议、风险等级。
- 如果要驱动 n8n 或 Dify，可能需要状态码、下一节点、失败原因。
字段越贴近下游动作，结构化输出越有价值。字段只是“看起来高级”，但没有人消费，就会变成维护负担。
strict模式解决什么问题
OpenAI Structured Outputs 里常见的一个关键词是 strict。你可以把它理解成更严格地让模型遵守 schema。它解决的不是“模型会不会理解业务”，而是“模型输出能不能按你定义的结构返回”。
在实际应用里，strict 模式最有用的地方有三个：
- 减少漏字段、错字段、额外字段。
- 让枚举、数组、对象层级更稳定。
- 降低下游解析失败和手写清洗逻辑的概率。
但 strict 不是万能保险。schema 本身设计错了，模型仍然会在错误结构里给你“正确格式的错误结果”。所以业务判断、样本测试和失败兜底仍然要做。
不要把JSON Schema当成业务判断
JSON Schema 能约束字段类型和结构，但不能替你判断业务真伪。比如客户留言里说“预算 10 万”，schema 可以让 budget 是数字，却不能保证客户真的有 10 万预算。
所以建议把字段分成三类：
- 事实字段：从原文直接抽取，例如手机号、邮箱、公司名。
- 判断字段：模型基于内容推断，例如意向强弱、需求类别。
- 动作字段：系统下一步怎么做，例如转人工、加入待跟进、暂不处理。
事实字段要尽量可追溯；判断字段要给枚举和置信度；动作字段最好加人工确认边界。这个原则和 MCP权限安全检查清单 类似：能自动做分类，不代表能自动做高风险决策。
落地流程：从提示词到生产可用
一个比较稳的 OpenAI API 结构化输出流程，可以按下面 6 步走：
- 定义下游动作：先确认 JSON 输出要写入哪里、触发什么、谁来复核。
- 设计最小 schema：只保留必需字段，分类字段优先用枚举。
- 准备真实样本：至少包含正常、模糊、缺字段、恶意输入、超长输入。
- 跑批量测试：看解析成功率、字段准确率、误分类情况。
- 加入校验重试：解析失败、字段异常、置信度低时重新请求或转人工。
- 记录审计日志：保留原文、模型输出、校验结果和人工修改记录。
如果你已经在做 AI智能体与自动化专题 里的工作流，这套流程可以直接放到 Agent 每个关键节点后面。每一步不只返回“我完成了”，而是返回可验收的结构化状态。
常见错误一：把所有异常都交给模型解释
有些人会在解析失败后继续问模型：“你刚才输出的 JSON 有问题，请修复。”这可以作为兜底，但不能是唯一机制。
程序层面至少要做三件事：
- 解析 JSON，失败就记录错误。
- 用 schema 校验字段类型、必填项、枚举值。
- 对关键字段做业务校验，例如手机号格式、金额范围、日期是否在未来。
模型负责生成，程序负责验证。不要让模型既当运动员又当裁判。
常见错误二：没有“不确定”字段
结构化输出最怕强行分类。用户原文里没有预算，你却要求模型必须输出预算等级；客户意图很模糊，你却要求它必须选“高意向”。这会制造看似整齐、实际误导的数据。
比较好的做法是给不确定性留出口：
- 允许
unknown或 “未确认” 作为枚举值。 - 增加
confidence字段，但不要迷信小数点精度。 - 增加
needs_human_review，把模糊样本交给人。 - 要求输出
evidence，引用原文中支持判断的短句。
这和 MCP工具调用日志 的思路一致：自动化越多，越要给复核和追踪留位置。
一个可复用的提示词模板
下面这个模板适合线索抽取、客服分类、内容审核等场景：
你是一个信息抽取助手。
任务：根据用户输入，抽取结构化字段，用于写入业务系统。
要求：
1. 只根据原文判断，不要补编不存在的信息。
2. 如果信息缺失，使用“未确认”或空字符串。
3. 如果判断不确定，needs_human_review 设为 true。
4. evidence 字段只写支持判断的原文短句。
5. 不要输出 schema 之外的字段。
用户输入：
{{user_message}}
提示词的重点不是重复 schema，而是说明业务边界：不补编、不越界、不确定就转人工。结构交给 schema，行为交给提示词，两者配合才稳定。
什么时候不用结构化输出
如果任务本身就是开放文本，结构化输出反而会束缚模型。比如：
- 写长文、写脚本、写评论。
- 做开放式创意方案。
- 总结一份报告给人阅读。
- 用户体验优先于机器解析的对话。
这类任务可以用普通文本输出，再在关键节点补一个结构化摘要。不要为了“技术感”把所有内容都塞进 JSON。
老达建议：把结构化输出当成接口设计
OpenAI API 结构化输出最适合解决的，不是“让模型回答更漂亮”，而是“让模型回答能被系统稳定消费”。一旦你的 AI 应用要连接表格、数据库、CRM、WordPress、Dify 或 n8n，就应该把它当成接口设计问题。
我的建议是：先从一个小场景开始，比如线索分类或内容审核；只设计 6 到 8 个字段；用真实样本测试 50 次；把解析失败、字段异常和人工复核记录下来。等这套流程稳定了，再扩展到更复杂的 Agent 工作流。
AI 应用不是只靠大模型聪明就能稳定交付。提示词、schema、程序校验、人工边界和日志追踪，才是一整套可落地的工程化能力。
