“JSON 在 AI 时代正走向消亡”——我最近刷到这个说法的时候，正好在处理一个线上事故，我们的 AI 编排服务里，模型吐回来的 JSON 字段多了一个换行，导致下游 Java 服务直接json parse error。热搜词里也全是“json parse error: cannot deserialize value of type java.util.date from str”“json查询函数”“json转字符串”。一边是“消亡论”，一边是全网在加班处理 JSON 的报错，这两件事放在一起本身就挺有意思。我在 AI 工程这条线上干了一年多，和 JSON 打交道的时间一点都不比做传统后端时少，唯一的变化是：以前 JSON 是我写的，现在是 AI 写的、我来擦屁股。所以我想把“消亡”这件事拆开聊聊——它到底死的是哪一部分，又在哪里换了件马甲继续发光发热。

如果你正在做 AI Agent、自动化脚本、数据处理管道，或者只是经常调用大模型 API，这篇文章值得看完。它不会给你灌“JSON 将死”的焦虑，反而会告诉你，JSON 在 AI 时代获得了一个新身份：AI 与外部系统之间的翻译官。理解了这层，你手里的 JSON 技能不但没过时，反而更值钱。

1. 热搜词里的反向证据：JSON 没死，只是换了岗位

先别急着聊理论，我们直接看数据。我翻了翻最近围绕这个话题的热搜词，排在前面的不是“JSON 已死”，而是下面这类：

这个表格说明了一件事：JSON 在工程层面不但没有消亡，反而渗透到了更多领域。那为什么“JSON 在 AI 时代正走向消亡”这种说法会有市场？我琢磨了很久，核心原因是：AI 把自然语言变成了“第一接口”。

以前写代码，你从后端拿数据，JSON 结构必须事先约定好，否则前端没法渲染。现在呢？你跟大模型说“帮我查一下北京的天气”，模型自己决定调用哪个工具、返回什么结构，中间那段 JSON 构造与解析被藏起来了。从使用者的视角看，JSON 仿佛是消失了。但这只是感知层面的消失。在系统内部，function calling 的请求体是 JSON，工具参数的 schema 是 JSON Schema，返回结果还是 JSON。自然语言只是门面，JSON 是地基。

用一个不太严谨的类比：你点外卖用 App 下单，不需要看到后厨是怎么炒菜的，但不能说厨师这个职业消亡了。JSON 就是 AI 世界的“后厨”，AI 越智能，后台需要处理的 JSON 反而越多、越复杂。你从热搜词里看不到“消亡”，只能看到“大家都在花式处理 JSON”。

所以第一个结论：消亡的不是 JSON，而是你肉眼可见 JSON 的那部分场景。

2. AI 逼出来的三种新形态：JSONL、Structured Output 与流式残片

如果只是说“JSON 没死”，那这篇文章没多大价值。真正值得关注的是，AI 这波浪潮把 JSON 的使用方式硬生生改写了。我在这段实践里观察到三种最明显的新形态，每一种都对应着新的技术栈和踩坑点。

2.1 JSONL：AI 数据喂养的标准流水线

传统 JSON 是一个完整的树形结构，一个文件代表一份数据。AI 时代的数据集，则普遍采用 JSONL（JSON Lines）格式：每一行独立一个 JSON 对象，行与行之间没有任何分隔符问题。

为什么选 JSONL？因为训练和微调的数据量太大了。一个 10GB 的 JSON 数组文件，你要先整体 parse 才能拿到数据，内存直接爆掉；JSONL 则可以按行读取、增量追加、断点续读，处理到哪一行出错，只丢那一行，不影响整体。

以 Python 生态为例，我现在处理微调数据基本都是这个套路：

import json from datasets import Dataset rows = [] with open("train.jsonl", "r", encoding="utf-8") as f: for line in f: line = line.strip() if line: rows.append(json.loads(line)) dataset = Dataset.from_list(rows)

这不是什么高深技巧，但很能说明趋势：同一个目标数据，现在被你拆成几百万行 JSONL 来喂给模型。最近一些大模型厂商公开的智能体训练新方法里，预处理脚本的核心输出就是排好序、去好重的 JSONL。JSON 非但没死，反而成了 AI 数据管线的默认底座。

2.2 Structured Output：从“数据格式”升级为“接口契约”

传统 JSON 的约定，是前后端开发者在接口文档里口头规定的。但在 AI 场景里，如果让模型自由发挥返回 JSON，你会得到千奇百怪的结果：字段名对不上、值类型不对、多一个少一个字段。这时候需要把 JSON 升级为可校验的“契约”。

主流大模型 API 现在都支持 Structured Output，也就是在请求里显式声明 JSON Schema，强制模型按约束输出。拿 OpenAI 官方的 JSON Schema 写法举例：

from openai import OpenAI client = OpenAI() completion = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": "提取订单信息"}], response_format={ "type": "json_schema", "json_schema": { "name": "order_info", "strict": True, "schema": { "type": "object", "properties": { "order_id": {"type": "string"}, "amount": {"type": "number"}, "items": {"type": "array", "items": {"type": "string"}} }, "required": ["order_id", "amount", "items"] } } } )

这个东西的价值，对 AI Agent 来说是“安全底线”。Agent 通过 function calling 调工具，工具参数就是 JSON，一旦模型输出不合法，工具调用直接失败，整个链路崩溃。有了 Schema 约束，至少你能确保模型不会把一个字符串塞进数值字段。我在实际项目中的体会是：Schema 设计得好不好，直接决定 AI 应用的上线速度。它不再是后端开发者的私有话题，而是每个做 AI 应用的人必须掌握的技能。

2.3 流式输出把好端端一个 JSON 切成了“半成品”

这是我在 AI 场景里遇到的最大的 JSON 挑战，也最容易被“消亡论”带偏。大模型 API 默认流式返回，你从 SSE 里收到的是一个个 token 碎片。第一帧可能是：

{

第二帧：

"order_id": "A100

第三帧：

86", "amount":

如果你在收到前两帧时就用JSON.parse，必挂。很多新人第一次对接 AI 接口，十个里有九个栽在这里，然后得出一条错误结论：“AI 生成的 JSON 不靠谱”。其实不是不靠谱，是你没理解流式 JSON 的形态。

我的处理思路是：在客户端攒缓冲，等流结束再统一解析。简单实现：

let buffer = ""; stream.on("data", chunk => { buffer += chunk; // 注意：不要在这里 JSON.parse(buffer)，因为 buffer 不完整 }); stream.on("end", () => { const data = JSON.parse(buffer); // 后续逻辑 });

代价是延迟，但换来的是稳定。如果想拿到“半成品”也能解析，就得用增量 JSON 解析器（比如partial-json-parser），它能把残缺的 JSON 尝试解析成可访问的中间对象。这种能力在渲染流式 UI 时非常有用。但请记住：增量解析是锦上添花，攒缓冲整体解析才是兜底方案。别把结果渲染玩出了花，结果下游接口全部 500。

这三种新形态一摆出来，你应该能感受到：JSON 不是死了，而是活得比以前更复杂了。

3. “消亡论”传递的三个真信号，别会错意

虽然我不认同“JSON 消亡”，但这个说法能火，背后确实有值得重视的信号。我把它拆成三点，每一点都指向工作方式和技能结构的真实变化。

3.1 手写 JSON 的岗位在消失，但设计 JSON 的话语权变大了

几年前，写一份 mock 数据、手填配置文件、在接口文档里排版 JSON 示例，是后端工程师的基本功，也是不少初级开发每天的主要工作。现在这些活，丢给 AI 一句话就能完成——甚至会给你生成带注释、带示例、能直接拿去跑通的版本。

这是好事，把我从重复劳动里解放出来了。但我们团队很快就发现：AI 生成的 JSON 质量，取决于你给它定义的 Schema 和约束条件。你给它的 schema 越清晰，它生成的 JSON 越可靠；你给它的 schema 模糊，它就像喝醉了一样自由发挥。

换句话说，初级的“写 JSON”在消失，高级的“定义 JSON 结构”在变成更核心的技能。以前你需要知道怎么写"name": "张三"，现在你需要知道：这个字段是否必填？允许 null 吗？时间戳是秒还是毫秒？数组最多几条？这些决策直接影响下游所有系统，话语权比以前大得多。

3.2 “人类可读性”被重新定义

传统 JSON 设计讲究“可读性”，字段名要见名知义，嵌套不要太深，最好人能直接看懂。但从 AI 场景里我发现，新的优先级变了：可校验性、可约束性、可工具化。

大模型不需要“人读得舒服”，它需要的是结构无歧义。比如你定义日期字段，如果允许“2025-01-01”和“2025/01/01”同时出现，对人来说都能看懂，但对 AI 和下游系统来说就是灾难。所以现在设计 JSON 时，第一个问题不再是“这样读起来顺不顺眼”，而是“这个字段值域是什么，允许哪些格式，能不能被 Schema 强约束”。这不是说可读性不重要了，而是它在 AI 时代的权重被降低了。

3.3 JSON 在垂直领域的地位，比你想的更根深蒂固

说 JSON 会消亡，很多时候是因为大家只盯着聊天机器人看。但你往具体行业里看，JSON 比十年更普及：

• 大数据：Spark 里from_json、to_json是日常函数，半结构化日志几乎全是 JSON。
• 数据库：PostgreSQL 的 jsonb 类型加函数索引，能让查询变得极其灵活，社区里积累了大把 json 查询函数技巧。
• 3D 与 GIS：Blender 导出 JSON 做资产交换，JSON 转 SHP 做地理信息处理，都是标准流程。
• 内容分发：书源、音源、影视源这类配置，至今仍以 JSON 文件方式在社区里分享，一个合集 JSON 就是一套可复用的资源包。

这些行业的共同点是：排错难、追溯难、对结构稳定性要求高。而 JSON 的可读、可校验、跨语言通用特性，恰好满足了这一切。AI 在这个生态里只是又加了一层读写端，根本不可能把它彻底替换。

4. 我的实战建议：AI 场景下把 JSON 用稳的几个硬功夫

聊完宏观趋势，我把自己在 AI 项目里积累的 JSON 实操经验整理成几条，每一条都是从翻车现场爬出来的。

4.1 先定 Schema，再让模型动笔

这是我目前最重要的一条铁律：永远不要在 prompt 里只说“返回 JSON”。你必须给出明确的 Schema 定义，最好附带一个最小示例。模型对示例的模仿能力远超对抽象描述的遵从能力。

我常用的模板是这样：

请提取用户邮件中的订单信息，输出 JSON，必须遵循以下 Schema： { "order_id": "字符串，必填", "date": "日期字符串，格式 YYYY-MM-DD，必填", "amount": "数字，必填", "notes": "字符串，可为空，默认为空字符串" } 输出示例： {"order_id": "A10086", "date": "2025-06-01", "amount": 199.9, "notes": ""}

注意：我不说“notes 可选”，而是直接规定“可为空，默认为空字符串”。AI 对“可选”的理解往往和程序员的默认值不一样。给它一个明确的兜底策略，比你事后做空值判断省一万倍心。

4.2 五个高频翻车现场和处置方案

现场一：类型不匹配，典型报错是cannot deserialize value of type java.util.date from str。热搜词里明晃晃挂着这个。原因是模型把日期输出成了字符串给 Java 后端，Java 的 Jackson 默认又不能把这个字符串自动转成 Date。我踩过一次，后来统一方案是：前端/上游约定日期一律用 ISO 8601 格式字符串（2025-06-01T10:00:00Z），后端用@JsonFormat指定格式，或者写自定义反序列化器。关键是把时间格式写在 Schema 里，别让模型自己猜。

现场二：模型把 JSON 包在代码块里。特别是用开源模型时，它经常输出：

{ "order_id": "A10086" }

前后还可能带着“这是你要的JSON：”这种解释文字。解析前必须先清理：提取第一个{到最后一个}之间的内容，再交给JSON.parse。我写过一个正则清理函数，现在还在用。

现场三：字段缺失。模型常常自信地省略“它觉得没必要”的字段，即使你在 required 里写了。单一靠 Schema 约束不够，下游一定要有默认值机制。Pydantic 里给Field(default=...)，Zod 里给.default()，都是防这个。

现场四：格式漂移。同一个 Schema，不同模型返回的风格不同：有的把数值写成字符串，有的空数组写成 null。这个只能靠运行期校验兜住。我现在所有 AI 返回的 JSON 都会过一道 Pydantic 或 Zod 校验，不合格就重试。宁可多跑一轮模型，不可带着脏数据入库。

现场五：流式切片。前面提过，SSE 流式输出时 JSON 被切得七零八落。处理优先级应该是：先保证整体能解析，再考虑增量渲染。很多人上来就折腾流式渲染，结果项目交付时连解析都还没跑通。

4.3 工具链升级建议

针对上面的坑，我把工具链也升级过一轮，现在这些是我的标配：

• Pydantic（Python）/ Zod（TypeScript）：运行时数据校验，比手写JSON.parse+if判断强太多。
• jq：命令行处理 JSON 依然高效，特别是调试阶段想看某个字段，一行搞定。
• jsonlines 工具 / jl：处理 JSONL 数据集的利器。
• JSON Schema Validator：无论是 Python 的jsonschema还是前端 ajv，都建议接进 CI，Schema 变更时自动回归。

这套组合让我在项目里几乎不用再手工比对 JSON 的字段。

4.4 什么时候可以真的不用 JSON？

我也得说句公道话，有些场景确实可以淡化 JSON：

• 纯聊天、纯问答、不需要结构化落地的场景，JSON 对使用者无感。
• 模型直接调工具、参数完全由模型内部生成，你看不见 JSON，这其实是“JSON 内化”而非“JSON 消亡”。
• 向量检索、语义记忆这类以 embedding 为核心的功能，向量和分数才是主角，JSON 只是外壳。

但只要你涉及持久化、跨系统通信、审计日志、权限控制，JSON 就绕不开。它不会变成历史的尘埃，只会在系统深处继续老黄牛一样干活。

5. 最后分享一点个人感触

我做 AI 编排平台时，跟同事争论过要不要“抛弃 JSON，全部用自然语言传参”。当时我觉得，AI 都这么强了，为什么还让我写这些繁琐的括号和引号？结果上线第二周就被打脸：Agent 之间拿自然语言传上下文，一段对话里层层嵌套，既不能校验，也不能回溯，只能靠模型自己“理解”。后来我们还是老老实实引入了 structured output + JSON Schema，把关键参数全部结构化，系统才算稳定下来。

这件事给我的教训是：越智能的系统，越需要明确的边界和契约。JSON 在 AI 时代并没有消亡，它只是从“给人看的配置文件”变成了“AI 世界的接口文档”。那些跟你大喊 JSON 已死的人，要么不做工程，要么还没被模型五花八门的输出毒打过。而你只要把 Schema 设计、流式处理、校验兜底这几件事做扎实，手里的饭碗反而比传统后端时期更稳。