★ FEATURED ARTICLE 这两天在几个技术社区里刷帖总能看到一个扎眼的论断JSON 在 AI 时代正走向消亡。我第一次看到这句话时是有点懵的——一个被 REST API、云原生、数据管道用了十多年的交换格式怎么说没就没了后来把这句话拆开细想了一下我反而觉得它真正的意思是JSON 作为人写人读的交接格式确实正在被 AI 重构但这个重构并不是把 JSON 扔掉而是让它从一个需要你手动维护的文本格式变成一套由模型和工具链自动生成、自动校验、自动压缩的底层协议。作为长期和数据格式打交道的开发者我在这篇文章里结合最近社区里大家讨论最热的几个方向——json转换、AI编程、AI Agent、结构化输出、大数据解析——聊聊 JSON 为什么会被唱衰、它的真实处境如何、在 AI 时代它到底变成了什么样子以及我们在实际项目里应该怎么应对这个变化。顺便把这两年踩过的和 JSON 有关的坑也一并整理出来。1. 消亡论不是空穴来风AI给JSON带来的三个冲击1.1 冲击一AI接管了手动拼结构的整个环节先说一个最直观的感受十年前我入行那会儿写接口、调接口、改配置手写 JSON 是基本功。一个联调现场前后端为某个字段到底是user_name还是username能吵一下午。那时候的 JSON 是给人看的也是给人拼的。现在完全变了。你在 Cursor 或者 Copilot 里说一句给我生成一个符合下单接口规范的 JSON 请求体20 秒内它就能给你吐出来字段名、嵌套结构、类型全都规整。你甚至可以反过来用根据这个 JSON 帮我反推接口文档。日常开发里手写 JSON这个动作正在快速消失——不是 JSON 消失了是写 JSON 的人从你变成了模型。更要命的是读 JSON这个环节也在被替代。以前你得一行行看日志、查字段、对照文档确认每个值的意思现在 AI 可以直接把一段 Json 日志丢给你告诉你这里异常因为order_id为空且status字段出现了非法值。自然语言直接给你结果。从写到读中间那个夹着文本格式的人肉环节确实在被 AI 一点点抽空。但注意这些场景里 JSON 本身仍然是绝对的主角。AI 产出的是 JSONAI 消费的也是 JSON只是人不直接上手了。这就像流水线自动化之后螺丝钉还在但装配工人从车间里走出来了。1.2 冲击二AI Agent更偏爱程序化数据协议第二个变化来自 AI Agent。这两年 Agent 概念特别火从 AutoGPT 到各类 Agent 框架你让一个 Agent 去查询天气、调用工具、规划步骤背后跑的是什么是大量的结构化数据传输。我在实际搭建 Agent 工作流时发现了一件很扎心的事LLM 上下文里塞 JSON是真的费 token。举个例子。我之前参与过一个内部 Agent 项目它需要把多轮对话的状态、意图、候选工具列表全部塞进上下文一开始用的是很规范、很好看的 JSON字段名全拼写、嵌套层四级、还有大量冗余信息。结果一个状态快照大概 4KB单次请求 token 成本高得吓人。后来我们把键名缩短、打平嵌套结构、删掉默认值字段压到 800 字节左右单次调用成本直接降了接近八成。这件事的影响很大。如果你经常设计 Prompt 或者调 LLM 接口你会慢慢形成一种LLM 友好的 JSON 风格短键名、单层结构、避免大数组嵌套、字段顺序稳定。这在很多团队里已经成了一项新的规范。与此同时Agent 与 Agent 之间的通信开始越来越多地走向 gRPC Protobuf、MessagePack、甚至直接传二进制序列化结果。这些格式更紧凑、解析更快在长链路调用里优势明显。但这也不是 JSON 的末日。它只是说明在给 LLM 看和给后端程序看这两个不同场景里JSON 不再是最好的答案了。它从万金油退回到了它真正擅长的地方。1.3 冲击三新格式与新工具抢占认知心智第三重冲击来自各种新面孔。开发圈里大家默认的数据格式鄙视链这几年一直在动。配置文件的场景YAML 吃掉了一大块份额——Docker Compose、Kubernetes、GitHub Actions 全是 YAML言简意赅还支持注释。TOML 也在 Cargo、Pip 这些包管理器里站稳了脚。数据科学的场景Parquet 和 Arrow 坐上牌桌尤其在 AI 训练数据管道里列式格式的读取速度比 JSON 快几个数量级。这些新格式确实抢走了很多 JSON 的传统阵地。就说 Arrow在做大模型数据预处理的时候一条记录几十个字段几百万条数据你用 JSON 反复序列化反序列化光infer_schema那个阶段就能把人等疯。换成 Arrow 的列式内存表示内存占用和 CPU 开销都降下来了。但请注意一个事实这些格式没有一个能够全面取代 JSON。YAML 表达嵌套数据很灵活但类型解析有各种坑安全性和性能都不如 JSONTOML 适合扁平配置一旦数据结构复杂就写得很难看Parquet/Arrow 是列式格式适合批量分析但没办法直接当接口协议用。它们的胜利都是局部的JSON 退出的也都是局部战场。2. 数据交换领域的现状JSON远未退出历史舞台2.1 数据说话JSON仍然是API世界里的事实标准说一千道一万我们看真实世界。这几年我做过大约三十多个包括 Web 后端、移动端接口、数据中台、AI 应用在内的项目新老系统几乎没有一个能绕开 JSON。稍微看一下几个宏观指标也能印证Postman 历年 API 报告里JSON 在接口响应格式中的占比常年保持在九成上下XML 基本退到存量系统里。GitHub 上 JSON 相关仓库、工具和库的数量依然在快速增长json、json-schema、jsonpath、jq 相关的开源项目活跃度非常高。npm 生态里res.json()、JSON.parse这些基础操作每天的调用量是以亿为单位的。云厂商、大厂开放平台的公共 API绝大多数仍把 JSON 作为唯一交换格式。说实话一个格式能连续红十几年在技术领域是很罕见的事。当年 XML 是王者后来被 JSON 掀翻现在大家都在讨论后 JSON 时代但仔细看真正扛起数据交换大旗的还是 JSON。只不过大家用得更聪明了不再手写而是用模型生成、用 schema 约束、用 jq 查询。2.2 格式横向对比到底输给了谁又赢了谁很多刚接触这块的读者朋友会问既然这么多格式我到底该用哪个我自己的选型逻辑很直白看场景不要看热度。把主流格式放在一张表里对比就很清楚格式强项弱项最合适场景JSON通用性最强、语言支持最全、人类可读冗长、无二进制、类型弱API 交互、配置、日志、LLM 结构化输出XML强约束、可加命名空间、文档规范成熟啰嗦、解析慢、心智负担重金融报文、遗留系统、可扩展性要求极高的文档YAML可读性好、支持注释缩进、类型隐式转换容易出幺蛾子配置文件、CI/CD、K8s 清单TOML简洁、适合扁平键值嵌套复杂结构表达吃力包管理配置、现代工具的配置文件Protobuf/MessagePack压缩率高、性能好、有强类型 schema不可读、需要编译步骤微服务内部 RPC、高性能通信、Agent 工具调用Parquet/Arrow列式存储、批量分析极快不适合单条读写、不直观数据湖、AI 训练集、分析型管道这张表我建议收藏。以后做技术选型的时候不要问谁更先进应该问我的数据形态和传输频率更匹配哪一列。比如你只是写个内部工具脚本用 JSON 就很好你要是做大规模数据分析管道直接上 Parquet你要是做低延迟内部服务Protobuf 无可替代。每种格式都有自己的一亩三分地不存在一个格式干掉另一个格式的情况。2.3 生态护城河JSON Schema、JSONPath与查询工具链真正让 JSON 在 AI 时代还能稳住基本盘的不是格式本身而是围绕它长出的那棵巨大的生态树。我重点说三样JSON Schema、JSONPath、jq。JSON Schema 是 JSON 的契约语言。你可以用它描述一个 JSON 长什么样哪些字段必填、字段类型是什么、值域范围、嵌套层级、枚举值。一旦有了 schema你就可以做自动化校验放在 CI 里拦截数据结构的非法变更也可以生成 Mock 数据甚至直接根据 schema 生成 API 文档。这跟强类型语言里的类型系统是一个作用。JSONPath 则是 JSON 世界的 XPath。你写$.store.book[?(.price 10)].title就能从一棵巨大的 JSON 树里抽出符合条件的书名。在排查问题、数据抽取、接口断言这些场景里JSONPath 是杀手级工具。再说 jq它是命令行处理 JSON 的神器。我平时在服务器上查日志、分析接口返回、清洗数据十次有八次是cat data.json | jq .items[] | {id: .id, name: .name, price: .price}一条命令干完原本要写几十行 Python 的事情。更关键的是这套生态和 AI 工具可以无缝结合——你在 Cursor 里让它生成一条 jq 指令它生成后你直接跑整个处理链路的效率是之前没法比的。另外数据库领域的底层支持也很能说明问题PostgreSQL 的 JSONB 支持复杂嵌套查询和索引MongoDB 的 BSON 本身就是 JSON 的二进制形式Spark、Kettle 这类大数据工具对 JSON 的读取解析支持都非常完善。社区里的高频问题——spark 中怎么读 jsonkettle 能解析 json 吗pg 的 json 函数有哪些技巧——全都在证明一件事实际工作中JSON 非但没死反而是大家每天都在打交道的东西只是没人再像十年前那样纯靠手写和肉眼硬扛了。3. AI时代JSON不再是你手写的JSON角色转型与真实走向3.1 从人机交换格式到模型结构化语言我一直觉得JSON 在 AI 时代的最大变化不是用得少了而是角色变了。以前JSON 的主要服务对象是人——程序员读、程序员写、程序员调试。它是人的接口语言。现在JSON 的主要服务对象变成了模型。什么意思呢你让 AI 画画、写文案、做 PPT、生成分镜这些工作流内部其实全在传 JSON。比如现在很火的 AI 短剧制作过程一个完整管线里剧本拆解、角色设定、分镜脚本、素材调用每一层之间交换的都是 JSON。再比如 AI 辅助写技术交底书、写专利底稿你会发现中间产物仍然是结构化 JSON——模型先生成一个包含背景、创新点、技术方案的 JSON 对象再由后续工具渲染成最终文档。在这个模式下JSON 变成了一种模型之间的通用语。它不需要人来读也不需要人来改它只需要足够规范、足够稳定、能直接被程序消费。你会发现 JSON 里开始出现大量system_prompt、agent_state、tool_call这样的字段它不再是给人看的数据快照而是 AI 运行时的内骨骼。前两天我也看到有人讨论ai辅助做专利和写作这个话题其实背后是一个更大的趋势一切内容生产都正在被拆成结构化流水线。流水线上流动的东西几乎全是 JSON。所以我的判断是在 AI 内容生产链路里JSON 的用量不降反升只是它变得看不见了。3.2 Function Calling与JSON ModeLLM如何吃下结构化的需求如果你是做 LLM 应用开发的一定感受过 Function Calling 带来的质变。所谓 Function Calling本质上是让 LLM 输出一个特殊的 JSON告诉你我要调用哪个函数参数值分别是什么。然后程序拿到这个 JSON 去执行对应函数再把结果回传。这就是 Agent 能自主调用工具的核心机制。比如你告诉模型查一下北京的天气并告诉我明天适不适合爬山模型内部几乎一定会输出这样的 JSON{ function: get_weather, parameters: { city: 北京, date: 2026-05-20 } }没有 JSON这套机制根本无法运作。所以你不妨说JSON 是 LLM 对外伸出手的语法。与此同时OpenAI、Claude、DeepSeek 等主流模型服务商都推出了JSON Mode或结构化输出能力你在请求参数里声明response_format: {type: json_object}模型就会把回复强制包装成合法 JSON绝对不会输出 Markdown 或自然语言。我在实际项目中测过很多次加了 JSON Mode 之后解析错误率直线下降。但这里有一个经验JSON Mode 不等于内容一定正确它只是保证一定是合法 JSON。你仍然需要在提示词里明确给字段说明、给示例最好再给 JSON Schema。我个人的实测结论是在提示词里放一个两行左右的示例 JSON比写一大段请严格按照以下字段返回的说明有效得多。这个细节很多新手不知道值得记下来。3.3 强约束与弱约束给JSON加上契约在 AI 时代真正取代手写 JSON的不是某个替代格式而是模型 Schema的组合拳。这里我要重点聊聊强约束结构化输出。以前你要一个符合规范的 JSON靠的是什么靠人眼检查。现在你可以直接定义一个 JSON Schema然后用 Pydantic、TypeBox、Zod 这类库把 schema 变成强类型模型。以 Python 生态为例from pydantic import BaseModel class Order(BaseModel): order_id: str user_name: str | None None items: list[str] total_price: float status: str pending你定义好模型让 LLM 的输出反序列化成这个对象字段缺失、类型不对会立刻校验失败完全不用手写检查逻辑。往底层看它生成、校验、流转的仍然是 JSON但你已经不需要知道 JSON 长什么样了。这就是我说的高级生存——JSON 还在只是藏到了框架和你之间。现在很多团队做 LLM Structured Output 的标配已经是JSON Schema 定义结构 大模型 JSON Mode 生成 Pydantic/Zod 校验 jq 或 JSONPath 做过滤。整套链路里手写的 JSON 几乎为零但处处都是 JSON。这才是 AI 时代数据交换的真实走向。4. 实操实录LLM与JSON协作中的关键细节和常见坑4.1 结构化输出的落地配置JSON Schema约束与校验这里给出一套可以直接抄作业的组合拳演示。假设你要用某个 GPT 风格的大模型接口从一段用户评论里抽取情感标签和关键词要求模型只返回 JSONimport json from openai import OpenAI client OpenAI( api_keyyour_api_key, base_urlhttps://api.example.com/v1 ) prompt 请从以下用户评论中抽取情感倾向和关键词。 严格按照如下 JSON 格式返回 {sentiment: positive/neutral/negative, keywords: [词1, 词2]} 用户评论这个快递速度太慢了包装倒是结实。 resp client.chat.completions.create( modelgpt-4o-mini, response_format{type: json_object}, messages[{role: user, content: prompt}], temperature0 ) content resp.choices[0].message.content data json.loads(content) print(data[sentiment], data[keywords])有几点实操提醒开了response_format{type: json_object}提示词里必须包含JSONjson字样和具体示例否则部分模型会报错。temperature建议设成 0 或接近 0结构化提取场景里要的是稳定不是发散。如果接口返回内容包含多余解释文字不要把json.loads直接丢上去而是先做一次提取 JSON的预处理或者用json.loads(content[content.index({):content.rindex(})1])这种方式截取最外层的 JSON 块。4.2 高频报错排查清单date反序列化、大小写、尾逗号……说到踩坑我这两年处理过太多和 JSON 相关的线上事故。很多报错看着是 JSON 的问题实际上是对 JSON 理解不够造成的。我把高频坑整理成一个速查清单报错/问题现象根因解决方案Java 报cannot deserialize value of type java.util.Date from StringJSON 里没有日期类型只能传字符串但字符串格式和 Java 侧期望不匹配统一用 ISO8601 格式2026-05-20T10:30:00Z服务端用JsonFormat或Instant类型接收Pythonjson.loads报Expecting property name enclosed in double quotes有人手写了单引号 JSON{a: 1}JSON 标准只认双引号用json.dumps的ensure_asciiFalse输出时也要注意转义尾逗号报错[1,2,3,]JSON 不允许结尾逗号写生成代码时不要拼字符串用语言内置的序列化方法整数变成字符串100被当成 100类型映射漂移引入 JSON Schema 或 Pydantic 做运行时校验中文显示成\uXXXX默认 ASCII 转义Python 里json.dumps(data, ensure_asciiFalse)NaN/Infinity无法解析JSON 标准不支持非数值量入库前做数值清洗或使用容忍这些值的扩展解析器特别是那个 Java Date 的报错我在联调时遇到不下五次。它本质上不是 JSON 的坑而是JSON 无日期类型这个特性带来的跨语言映射问题。解决的办法没有捷径就是约定前端序列化时用dayjs统一格式化为 ISO8601后端接收时用Instant、LocalDateTime配合JsonFormat(pattern yyyy-MM-ddTHH:mm:ss.SSSZ)。把日期格式放进团队的接口契约文档里比啥都强。4.3 大数据与数据工程里JSON的使用技巧在数据工程场景里JSON 是绕不开的。我见过很多人问Spark 能不能读 JSON能而且非常成熟。spark.read.json(path)会自动推断 schema几千个字段也能处理。Kettle 解析 JSON 也简单用 JSON input 插件配好路径就行。PostgreSQL 里 JSONB 函数更是日常操作比如SELECT>
阅读完成 · 觉得有帮助？
