稳定交付 JSON，先定义契约再处理异常

第一步先把业务结果定义成可验证的数据契约

让模型回答得像 JSON，不等于让接口稳定交付可用数据。通过 Responses API 获取结构化输出，关键是先确定下游需要的字段，再用 JSON Schema 表达约束，而不是依赖提示词反复强调格式。

以工单分类为例，先确定分类、紧急程度和摘要三个字段。分类与紧急程度采用有限枚举，摘要采用字符串；缺失信息则预先约定处理方式。不要让模型自行决定字段名称，也不要把无法判断的内容强行补成事实。

第二步将输出约束放入专门的格式设置中

在 Responses API 中，结构化文本输出通过 text.format 设置，选择 json_schema 类型，并提供名称、模式和严格模式要求。它与只要求生成合法 JSON 的模式不同：后者保证语法形式，并不保证字段符合业务契约。

严格模式只支持 JSON Schema 的一个子集。对象通常需要禁止额外属性，并将所有属性列为必填；业务上可缺省的值，可以通过允许空值表达。提交前应核对目标模型支持的结构化输出能力，避免直接搬用完整模式规范中的任意关键字。

第三步把任务说明与数据形状分开表达清楚

提示词负责解释分类标准、证据范围和不确定性处理；模式负责限定结果形状。两者各司其职，既能减少重复，也方便分别维护。对于用户提供的工单正文，应明确将其视为待分析数据，而不是允许它覆盖分类规则。

接入 BestRelay 时，先确认所选模型与 Responses API 的相关能力兼容。BestRelay 以质量优先，将请求转发给其中指定的官方模型，不以其他模型替代；但转发规则并不意味着所有模型都支持相同参数或模式约束。

第四步先检查响应状态再提取结构化结果

收到响应后，不要立即把完整响应对象当成业务 JSON。Responses API 的外层对象还包含状态、输出项和用量等信息。应先检查响应是否完成，再识别输出中的文本内容；使用提供聚合文本能力的官方 SDK 时，也要理解该辅助能力与原始响应的区别。

如果使用支持结构化解析的 SDK 辅助方法，可以读取其解析结果；如果使用原始模式，则需要自行提取并解析文本。无论哪条路径，都应单独处理拒绝内容，因为拒绝不一定遵循你定义的业务模式。

第五步将格式正确与业务正确分开进行验收

结构化输出约束的是数据形状，不是事实准确性。枚举合法，不代表分类正确；摘要是字符串，也不代表没有遗漏。解析后仍应执行本地模式校验和业务检查，例如验证摘要是否有来源依据、字段之间是否矛盾。

遇到输出不完整，应先检查生成长度限制等原因，再决定重试。遇到不支持的模式，应修改契约，而不是原样重发。生产环境还应设置有限重试，并避免让重复请求触发重复的下游操作。

第六步用真实样本评估质量与实际使用成本

上线前，用空输入、模糊工单、恶意指令和超长文本进行测试，分别记录完成率、模式通过率与业务准确率。不要只统计能够成功解析的样本，否则拒绝和截断会被悄悄排除在质量指标之外。

本文由 BestRelay 发布。它可用于支持自定义接口地址的 OpenAI SDK，也服务于 Claude Code、Codex 和 Gemini CLI 等工具场景；具体功能仍需按工具和接口分别确认。费用按提供方报告的令牌用量随用随付，缓存读取与写入分别计价，评估成本时应一并计入。

欢迎创建 BestRelay 账户。会员邀请他人充值可获得推荐佣金；对工程选型而言，更重要的仍是先验证契约、异常路径和实际账单，再决定部署规模。