GPTs 怎么开启 JSON 结构化输出，构建器里没有 JSON 开关时该靠指令、Actions 还是接口层 response_format？

GPTs 里没有名为 JSON 模式的开关，结构化输出只能靠三条路径组合实现：Instructions 里写死字段契约做软约束、用 Actions 或函数参数把输出变成必填参数做接口层约束、在自建服务调用模型时用 response_format 的 json_schema 严格模式做硬约束；只靠指令约束 GPTs 的对话回答，属于概率约束，不能保证每次都返回合法 JSON。 Instructions 是成本最低的起点，但它只提高合规概率，不提供任何保证。做法是把输出契约写在指令的最后一段并重复一次：说明只允许返回一个 JSON 对象、列出全部字段名与类型、规定缺失值用 null、禁止任何解释性前后缀、附一条完整示例；模型对指令末尾和示例的遵循度明显高于散落在段落中间的描述。 在 Instructions 里用 JSON Schema 片段描述结构，比用自然语言描述字段更稳。例如直接写出对象类型、字段清单、每个字段的类型，以及 additionalProperties 为 false 这一约束，再补一句“不符合该结构的输出视为错误”；自然语言描述容易出现字段名漂移，比如同一含义在不同轮次里被写成 order_id 和 orderId。 Actions 是把软约束变成硬约束的关键位置，因为 OpenAPI 描述本身不接受随意结构。把“请输出结果”改造成“请调用 save_result 动作”，让每个业务字段成为动作的必填参数，模型必须先满足参数结构才能发起调用；接口内部再调用模型时使用 json_schema 严格模式，返回体由接口负责整形，GPTs 只承担参数映射与展示。 函数调用与工具参数的 schema 是另一种硬约束，机制与 Actions 相同：参数不符合 schema 就无法完成调用。适合把“抽取订单信息”“生成工单字段”这类任务改造成一次工具调用，让字段成为必填参数项；缺点是模型在参数之外仍会输出自然语言说明，展示层需要只取结构化结果而非整段文本。 API 侧的严格结构化输出有明确适用边界，它并不能接受任意合法的 JSON Schema。对象层级需要声明 additionalProperties 为 false、所有字段必须列入 required，可选字段通常用类型联合 null 表达，部分校验类关键字不被支持，具体支持清单以官方文档为准；schema 写得过于复杂时，模型并不会因为开了严格模式就自动理解业务含义。 GPTs 的对话界面不承诺严格 JSON，这决定了它不适合作为唯一的生产出口。多轮追问、附件解析、代码解释器输出、引用标注都可能把非 JSON 文本混入回答；凡是结果要入数据库、要触发对账或进入下游系统，都必须把 GPTs 视为草稿生成端，在服务端再执行一次结构校验。 校验与重试是必需的兜底环节，而不是可选项。服务端用 JSON Schema 校验器检查返回体，字段缺失、类型错误、多出未定义字段都判为失败；失败时把具体错误路径回传给模型，只允许它修正格式并重试一次，仍失败则降级到模板填充或转人工，避免无限重试放大调用成本与延迟。 提示词里必须显式给出“无法回答”的出口，否则模型倾向于用编造内容补齐必填字段。做法是预留一个状态字段与一个错误说明字段，约定信息不足时状态取固定值、其余业务字段全部返回 null，并在指令中说明该情况不得猜测；这一条对金额、日期、编号这类字段尤其重要。 输出稳定性还取决于任务拆分粒度，一次让模型同时完成抽取、计算和解释，格式错误率会明显上升。把流程拆成抽取原文、按规则计算、按固定模板格式化三段，每段只保留一个输出契约，中间结果落在服务端而不是对话上下文里；拆分后每段的字段数变少，校验失败也更容易定位到具体环节。 调试时应当看接口的原始返回，而不是看界面渲染后的效果。GPTs 的展示层会做换行与美化处理，多余的前后缀文本、被自动补全的引号往往在界面上看不出来，只有在 Actions 侧记录请求体与响应原文，才能判断问题出在指令遵循、schema 定义还是展示层截断。 选择路径可以按用途区分：只给人阅读的临时结果，用 Instructions 加示例约束即可；要进入系统流转的结果，应走 Actions 或函数参数，并在自建接口层启用严格模式与 Schema 校验。严格模式与重试都会增加调用次数，按量计费场景需要为重试预留比例，并把重试率作为上线后的观测指标之一。