GPTs 怎么开启 JSON 结构化输出，在 Instructions 里写死 schema 和用 Actions 约束参数哪个更可靠？

GPTs 本身没有“开启 JSON 结构化输出”的开关；可行做法只有三条：在 Instructions 里写死字段与类型，用 Actions 的 OpenAPI 参数结构反向约束字段，再让 Code Interpreter 在生成后做一次解析校验；如果下游系统要求 100% 合法 JSON，自定义 GPT 不是合适载体，应改用接口层的严格 schema 模式。自定义 GPT 的构建器只暴露 Instructions、Knowledge、Capabilities、Actions 四类配置，接口层那个专门约束输出格式的参数不在其中，所以所谓“开启”本质是用提示词和动作参数模拟约束，而不是打开一个开关。 GPTs 是 ChatGPT 的产品化封装，输出格式属于“软约束”，靠的是模型对自然语言指令的遵循程度。接口层的结构化输出由服务端在解码阶段校验，而 GPTs 里的格式要求只是系统提示的一部分，模型仍可能附加解释、包一层代码块，或在长 schema 后半段丢字段。理解这个层级差异，才能判断哪些场景能接受 GPTs，哪些必须换通道。 在 Instructions 里必须给出可直接照抄的完整模板，只写“请输出 JSON”几乎无效。写法上要逐条列出字段名、类型、是否必填、缺省值，并明确三件事：只输出 JSON 本体，不要任何解释文字，不要代码块围栏。比较稳的写法是给一段样例对象，例如“order_id”为字符串、“amount”为数字、“remark”缺失时写 null，再补一句“不得新增模板之外的字段”。样例越贴近真实数据结构，输出漂移越少。 用 Actions 约束字段比纯提示词更硬，因为 OpenAPI 里的 parameters 本身就是结构定义，模型调用动作时必须按字段填参。把需要结构化产出的环节设计成一个动作，让 GPT 把结果作为参数传出去，字段名和类型就由 schema 兜住。要注意它只约束“调用动作的那一次”，对话里的普通回答仍受 Instructions 支配，所以两者需要同时配置，而不是二选一。 Code Interpreter 能把“生成”和“校验”拆成两步，显著降低非法 JSON 的流出概率。具体做法是在 Instructions 里要求：先产出 JSON 字符串，再执行一次解析，若抛异常则根据错误信息修正后重新输出，最多重试一次，仍失败就返回一个约定的错误对象而不是半成品。这条路径适合低频、有人在环确认的场景，不适合要求亚秒级响应的高并发接口。 失败类型是可以枚举的，提前在 Instructions 里逐条禁止比事后修补更省事。最常见的是包一层代码块标记、使用中文全角引号、尾随逗号、在 JSON 里写注释、字段名从下划线改成驼峰、可选字段被直接省略而不是置 null、以及 schema 过长时后半段字段被遗忘。把这些反例写成否定清单放在指令末尾，通常能挡掉大部分低级错误。 指令里必须出现“JSON”这个词，并声明只输出 JSON，这是很多格式约束生效的前提条件。同时要给兜底路径：当输入信息不足以填满必填字段时，返回带错误码和缺失字段列表的对象，而不是自行编造内容或退化成一段散文。没有兜底规则的 GPTs，在遇到边界输入时会直接放弃格式要求。 需要严格保证合法 JSON 时应走接口层，使用 json_schema 模式并开启 strict 校验。这类模式对 schema 有硬性写法要求：对象必须声明 additionalProperties 为 false，所有字段都要列进 required，可选字段用“类型 + null”的联合来表达，部分校验类关键字不被支持需要移除。满足这些条件后，服务端会约束解码过程，产出的内容天然符合结构，而不是靠模型自觉。 GPTs 的输出行为会随底层模型更新而变化，不能当作对外契约使用。同一个 GPT 在不同时间对同一输入的格式遵循度可能不同，因此面向外部系统的集成不应直接依赖它的原始输出。可行的缓解方式是在 Instructions 顶部固定一个 schema 版本号字段，把 schema 文档放进 Knowledge 便于检索引用，并在解析端保留字段校验与版本兼容分支。 验证效果不要靠单次试跑，准备一组覆盖边界情况的输入做回归更可靠。建议至少覆盖：字段全部可填、必填缺失、超长文本、含引号与换行的内容、多语言混排、以及明显超出范围的输入。每次修改 Instructions 后重跑同一组用例，统计一次通过率并按失败类型归类，才能看出改动是真的有效还是碰巧通过。 结论边界很清楚：低频、有人工复核、产出后还要人看一眼的场合，用 GPTs 加 Instructions 加 Code Interpreter 校验完全够用；高频批量、下游强校验、需要把输出直接写库或喂给程序的场合，应当走接口层的严格结构化输出。把这两条路径混用，是格式问题反复出现的根源。 还有一条容易被忽略的实践：让 GPT 在 JSON 里自带一个自检字段，记录本次输出使用的 schema 版本和是否经过解析校验。这个字段本身不参与业务逻辑，但在排查“为什么昨天能跑今天报错”时，能快速区分是模型行为变化、指令被改动，还是输入触发了未覆盖的分支。