AI 实操与核验 · 发布于 2026-10-12 · 更新于 2026-10-12

ChatGPT 输出 JSON 能直接用吗?解析、结构和业务规则分开检查

返回 JSON 只是输出要求,不是内容正确性的证明。接收 AI 结果时,先确认完整文本可解析,再验证字段和类型,最后对照原始记录与业务规则。即使结构合法,编造的编号、错的数字或未经授权的动作也不能自动进入后续流程。本文用合成任务记录演示三层验收,没有调用模型。

本文目录

先看结论

解析层完整 JSON 文本截断、围栏、尾部解释不静默删掉
结构层字段与类型符合约定明确额外属性和类型转换策略
业务层来源编号和值能核对合法结构不证明事实正确
动作权限独立核对授权数据字段不是执行许可

接收 AI JSON 的 5 个验收步骤

  1. 保留原始文本和来源

    设定输入大小与失败通道,不先删除围栏或截取看起来像 JSON 的片段。本文练习最多接受 4096 个 UTF-8 字节;命令行入口仍会先读完输入,不是面向任意攻击输入的流式限制器。

  2. 使用标准解析器

    解析失败就报告失败,不用 eval 执行文本。完整 JSON 文本与一段 JavaScript 不是同一要求;截断、尾部说明或无效语法不能被包装成成功。

  3. 用成熟库验证结构

    明确必须字段、类型、枚举、范围及额外属性策略。本文用 Zod 严格对象,拒绝额外字段和数字字符串,不把未经约定的清洗或类型转换藏进验收。

  4. 独立核对业务依据

    对照原始记录检查编号和数值。即使字段符合 Schema,不存在的任务或错误耗时也要拒绝;缺少原文依据则保留待核对,不自动补造。

  5. 失败不触发下游操作

    失败结果只进入可审阅的异常流程,不能继续写入、付费或发送。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 购买、交付与售后条件以对应实时商品页和原订单为准,不是上述官方文档的服务承诺。内容维护与纠错