ChatGPT 输出 JSON 能直接用吗?解析、结构和业务规则分开检查
返回 JSON 只是输出要求,不是内容正确性的证明。接收 AI 结果时,先确认完整文本可解析,再验证字段和类型,最后对照原始记录与业务规则。即使结构合法,编造的编号、错的数字或未经授权的动作也不能自动进入后续流程。本文用合成任务记录演示三层验收,没有调用模型。
先看结论
接收 AI JSON 的 5 个验收步骤
保留原始文本和来源
设定输入大小与失败通道,不先删除围栏或截取看起来像 JSON 的片段。本文练习最多接受 4096 个 UTF-8 字节;命令行入口仍会先读完输入,不是面向任意攻击输入的流式限制器。
使用标准解析器
解析失败就报告失败,不用 eval 执行文本。完整 JSON 文本与一段 JavaScript 不是同一要求;截断、尾部说明或无效语法不能被包装成成功。
用成熟库验证结构
明确必须字段、类型、枚举、范围及额外属性策略。本文用 Zod 严格对象,拒绝额外字段和数字字符串,不把未经约定的清洗或类型转换藏进验收。
独立核对业务依据
对照原始记录检查编号和数值。即使字段符合 Schema,不存在的任务或错误耗时也要拒绝;缺少原文依据则保留待核对,不自动补造。
失败不触发下游操作
失败结果只进入可审阅的异常流程,不能继续写入、付费或发送。JSON 中的命令或 action 字段不是授权;页面显示需按目标上下文安全转义,结构校验不是通用安全沙箱。
合法 JSON,也可能记录了不存在的任务
AIXiamo(AI夏末)于 2026 年 10 月 12 日整理,本文由 AI 辅助起草与核对。所有样例是专门设计的任务记录,不是客户数据;测试只在本地运行,不调用模型或外部接口,不执行生成文本里的命令。
本例已知来源仅有 T01:done、45 分钟;T02:todo、0 分钟。约定输出一个对象,字段只有 task_id、status、minutes;状态仅 todo/done,分钟为 0 到 240 的整数,拒绝额外属性。下面对象能解析且结构合规,但 T99 不在来源中,业务层必须拒绝。T01 若输出 46 分钟,也与已知原文不符。
{"task_id":"T99","status":"done","minutes":45}下载一个离线三层校验器
运行需要 Node.js 和 Zod;本文实际验证使用 Zod 4.4.3,无 API 请求或 Key。下载两份源码到独立练习目录,先阅读后安装练习依赖。task.json 使用已知的 T01/done/45;接受结果为 valid:true、stage:accepted,失败区分 input、parse、schema、business 并退出码 2。stage 是本文脚本标记,不是 OpenAI 接口字段。
配套 20 项离线测试覆盖截断、尾部说明、额外字段、错误类型以及合法结构中的虚构数据。通过的是本例的规则,不是任意模型或真实文件测试。完整脚本还包含来源编号和值的核对;只调用 safeParse 不完成业务验收。
npm install zod@4.4.3
node --test test-verify-json.cjs
node verify-json.cjs < task.json
# task.json 内容:
# {"task_id":"T01","status":"done","minutes":45}结构检查之后,仍要核对原始记录
下面是完整脚本的结构校验部分,raw 表示待检查的原始文本。safeParse 成功之后仍要核对 sourceRecords;否则合法的 T99 和编造的耗时也会被当成有效数据。本文不编写自己的通用 Schema 引擎。
const { z } = require("zod");
const taskSchema = z.object({
task_id: z.string().regex(/^T[0-9]{2}$/),
status: z.enum(["todo", "done"]),
minutes: z.number().int().min(0).max(240),
}).strict();
const parsed = JSON.parse(raw);
const checked = taskSchema.safeParse(parsed);
// checked.success 之后仍要核对来源编号和数值。这个小例子没有拒绝所有重复键
一份文本先写 task_id 为 T99,又写 task_id 为 T01,本次实际 Node JSON.parse 得到最后的 T01;之后结构和来源检查仍可能通过。配套测试明确保留了这个边界,不把它写成重复键已严格拒绝。
RFC 8259 说明对象成员名称应唯一,重复名称的处理存在实现差异。应用若必须拒绝重复名称,应在解析阶段使用经核验、能报告重复成员的方案;已经被覆盖的成员通常不能靠解析后的对象结构找回。不要用正则扫描任意 JSON 来伪装完整解析器。
本例不验证深层任意 JSON、通用权限或来源记录的真实性与完整性。即使是通过校验的字符串,显示到页面或用于操作时也仍需对应的安全处理和授权。
{"task_id":"T99","task_id":"T01","status":"done","minutes":45}网页提示词与 API Structured Outputs 不一样
在 ChatGPT 对话里要求只返回 JSON,不能据此宣称启用了 API 严格结构输出。API 的 JSON mode 与 Structured Outputs 是需要明确配置的不同能力;后者遵循支持的 Schema 范围,但仍需处理拒绝、不完整响应和内容错误。具体能力以官方文档为准。
本文没有执行 API 请求,不能证明某个模型、当前账号或任意 Schema 一定可用。业务校验和来源核对仍由应用负责;不能把结构遵循写成事实准确保证。
可复制的提取要求
这是一条操作建议,不是合法 JSON 或正确内容的保证。信息缺失时,应用应定义独立失败通道,不在正常对象里临时混入未约定的错误字段。
仅依据给出的任务原文提取,不新增任务。
输出一个 JSON 对象:task_id、status、minutes。
status 仅允许 todo 或 done;minutes 必须为整数。
不要把未知值猜成 0,不用中文解释替代字段值。
原文信息缺失时,先说明缺项,不给出伪装完整的对象。
后续分别进行解析、结构与来源核验。安全与事实检查
- 标准解析、结构验证、来源与业务核验分别进行。
- 额外字段和类型转换策略明确,缺项不自动补造。
- 拒绝和不完整响应没有伪装成正常数据。
- 重复成员名的解析器边界已记录,不宣称全面拦截。
- 结构校验不是事实保证或执行授权,测试使用合成数据。
常见问题
JSON 能解析,为什么还会失败?
解析只确认文本符合格式。字段类型、必须项、枚举和范围仍需结构检查;编号和数值是否有原文依据,还要单独核对。
数字字符串和数字能自动互换吗?
只有规则明确允许转换时才可。本文拒绝数字字符串,不把未经确认的清洗操作藏进结构验收。
Structured Outputs 能保证内容真实吗?
不能把结构遵循理解为事实保证。仍要处理拒绝、不完整响应,并核对业务依据;ChatGPT 对话提示词也不能视为 API 严格配置。
JSON 里有 action 字段就可以执行吗?
不可以。动作字段不是授权,必须依据真实用户授权和应用权限独立处理;结构校验不是通用安全沙箱。
官方参考
产品功能、方案名称、用量与地区可用性以 OpenAI 当前官方页面为准。
AIXiamo 购买、交付与售后条件以对应实时商品页和原订单为准,不是上述官方文档的服务承诺。内容维护与纠错