企业官网建设流程全解析

最近中文技术社区里冒出一个很火的论题：“JSON 在 AI 时代正走向消亡”。做后端的人看到这句话容易坐不住，毕竟手上的接口还在用 JSON 和前端联调；搞 AI 的人倒是频频点头，因为他们在微调、训练、Agent 调用里已经踩过太多 JSON 的坑。这个标题确实有点标题党的味道，但背后的问题是真真切切的：AI 时代的数�据交换方式，到底还在多大程度上依赖 JSON？JSON 会不会被某种新格式取代？

我自己的看法是：JSON 不会这么快“死”，但它的角色正在发生剧烈的迁移。以前它是数据交换的绝对中心，现在它退到了三层位置——AI 内部计算不吃 JSON，AI 训练数据不用 JSON，Agent 之间的信息传递也开始绕开 JSON。但与此同时，JSON 在另一些地方反而更牢固了，比如大模型的 Function Calling 结构化输出、RAG 知识库的元数据管理、AI 工具的配置体系。这篇文章我想把这个话题拆开揉碎，结合我这两年做 AI 应用开发的实际经验，聊聊 JSON 在 AI 时代究竟遭遇了什么，哪些地方它真的不行了，哪些地方它依然是刚需，以及我们这些做工程的到底该怎么选型。

1. 这个标题是怎么来的——从“JSON 已死”到“JSON 还活着”

1.1 论题的来源：JSON 与现代 AI 格格不入的三个信号

任何一个耸动的标题背后，一定有真实痛点在支撑。“JSON 在 AI 时代正走向消亡”这个说法，最早是从大模型应用开发者的吐槽里发酵出来的。第一批给 GPT 类模型写代码的人发现，让模型输出一段严格合法的 JSON 是一件既费 token 又容易翻车的事。模型经常给你多一个逗号、少一个引号，或者把一个字符串意外截断，直接导致json.loads抛异常。如果你在大规模流水线里跑几百个结构化抽取任务，你就会对“JSON parse error”产生生理厌恶。

第二个信号来自模型推理的“注意力分布”。Transformer 架构对 token 的处理逻辑，决定了它会花大量计算在结构符号上。一个包含大量引号、冒号、花括号的 JSON 文本，在模型眼里就是大段的“结构性噪音”。同样一段业务信息，写成 JSON 消耗的 token 往往是纯文本的两三倍。在按 token 计费、按上下文窗口算容量的时代，这就是真金白银的成本浪费。

第三个信号出现在模型训练阶段。现在大模型的训练数据主要来自网页、论文、代码仓库、对话记录，几乎没有人会把海量 JSON 文档直接喂给模型做预训练。JSON 是为机器间通信设计的，它的可读性远不如 Markdown、自然语言或者表格，模型学习起来非常低效。所以你会发现，ChatGPT 这类产品的接口文档里有 JSON Schema 定义，但模型内部对“JSON 格式”的理解，其实远没有对“自然语言指令”理解得深。

1.2 先别急着唱衰：JSON 在 AI 生态中的真实位置

上面这些信号都是真实的，但“消亡”这个词用得过于浪漫主义了。AI 应用不是凭空长出来的，它长在互联网的根基上。而互联网过去二十年最成功的通用数据协议，就是 JSON。你要让 AI Agent 去调用一个搜索 API、查一个天气接口、写一条数据库记录，这些接口背后全是 JSON。除非我们把整个 Web 基础设施推倒重来，否则 JSON 在可预见的未来都会是 AI 与外部世界打交道时的事实标准。

我的判断是：JSON 没有在消亡，它是在“降权”。以前它是数据的唯一主角，现在它更像是一个“边界协议”——只在系统边缘、工具调用、人机交互的接口处出现，而数据在 AI 内部流转时，已经被换成向量、token 序列、二进制张量这些更底层的表达。这个转变对后端工程师的冲击不小，因为大家的思维还停留在“一切皆 JSON”的阶段，但 AI 原生应用的设计者已经开始把 JSON 当作最外层的一层壳。

2. JSON 和 AI 的相爱相杀：为什么模型“看不上”JSON

2.1 Token 浪费：JSON 的结构化语法在模型眼里是“噪音”

用生活里的例子来类比可能更直观。你去听一场讲座，讲师讲了一个小时，但真正有用的信息其实只有三句话。这三句话如果提炼出来，可能就 50 个字；但讲师为了组织表达，用了大量连接词、铺垫、重复强调。JSON 的结构化语法，在模型眼里就扮演了“废话连接词”的角色。比如{"user_id": 123, "user_name": "张三", "user_age": 28}这段数据，真正有价值的信息是“123、张三、28”这三个值，而{"user_id":,:,,这些东西对模型理解语义几乎没有任何帮助。

在 Transformer 的注意力机制里，这些符号虽然不是完全无用（它们帮助模型定位字段边界），但相比自然语言令牌，它们携带的语义信息密度低很多。更麻烦的是，大模型的 Tokenizer 通常会把:、"等符号切分成独立的 token，原本一个单词能表达的信息，现在要拆成多个 token。我在实际项目里统计过，同一份销售数据，用 JSON 表达大约 1200 个 token，用纯文本表格表达只要 600 个左右，用自然语言描述只要 400 个。在批量处理场景下，这是成倍的成本差异。

2.2 解析地狱：AI 生成 JSON 时的格式不稳定

做过 AI 结构化抽取的人，大概率遇到过“模型输出的 JSON 差一个引号”的玄学问题。你让模型按指定格式抽取合同里的关键字段，它偏偏给你输出一段带解释性前缀的文本。你做了 few-shot 示例，它却用错注释符号。你锁死了 JSON Schema，结果它在花括号里嵌套了一段啰嗦的自白。这些问题的根源在于，大模型本质上是“概率化的语言生成器”，而不是“格式化的序列化器”。它生成“看起来像 JSON 的文本”，而不是严格符合规范的 JSON 值。

为了对付这种不确定性，工程上出现了大量的 JSON 修复工具、容错解析库、重试策略。OpenAI 等厂商也推出了json_mode、结构化输出、Function Calling 等功能，本质上不是让模型更懂 JSON，而是把 JSON 生成过程变成了“受限解码”或“Schema 约束下的标记生成”。这相当于我们用外部规则强行纠正模型的自由主义输出倾向。虽然可靠度大幅提升了，但这也说明了一个尴尬的事实：JSON 格式对模型而言不是天然友好的母语，而是需要“看着说明书手写”的外语。

2.3 嵌套地狱：复杂 JSON 让模型上下文窗口雪上加霜

另一个容易被忽视的问题是嵌套复杂度。业务系统里那种五六层嵌套的 JSON，交给人类后端开发者阅读都有压力，更别提让模型在有限的上下文窗口里去理解并操作了。上下文窗口就像一个人的工作记忆，你往里塞的无效结构越多，模型能记住的有效业务信息就越少。为了让模型在长文档上保持高质量表现，我现在做提示词工程时，都会刻意把输入数据先“拍平”——把多层嵌套 JSON 转成扁平的表格、键值列表或者 JSONL 格式，再喂给模型。

举个例子，一个包含订单、商品、物流、售后四层嵌套的 JSON 对象，如果直接塞给模型分析，它很容易在第三层就“失忆”。但如果你把它转成行式 JSONL，每行一条完整记录，或者拍平成多张关系表，模型的处理质量会明显上升。这就逼着我们在 AI 工作流里做大量的 json转换和预处理，而不是原样把混论结构丢给模型。

3. 时代替代品：AI 原生数据格式正在崛起

既然 JSON 在 AI 内部场景有这么多的不适应，那么替代品自然会出现。我这里说的“替代”，不是指一夜之间替换，而是在 AI 原生链路里，越来越多的团队开始选用新的数据表达方式。

3.1 JSONL：AI 训练和日志领域新的事实标准

JSONL 的全称是 JSON Lines，说白了就是每一行一个完整的 JSON 对象。它看起来从 JSON 派生而来，但在 AI 数据工程里，它的地位已经完全独立于 JSON。大模型微调的数据集格式，几乎清一色是 JSONL：{"instruction": "...", "input": "...", "output": "..."}，一行一个样本。RAG 向量库的元数据导入、海量日志的采集、批量流水线的输入输出，也都在用 JSONL。

为什么 JSONL 这么吃香？因为它天然适配“逐行处理”的管道模式。你可以用for line in file一条条读取，不必把整个文件加载到内存再整体解析。对于动辄几个 GB 的训练集，这是最重要的工程优势。而且 JSONL 的每一行是独立的，如果中间有一行数据坏了，你只需要跳过这一行，不会像解析一个大 JSON 文件那样“一损俱损”。在处理大规模数据时，这种容错能力是非常现实的考量。

3.2 向量存储与嵌入：取代“结构”的不是新格式，而是新常态

AI 时代最深刻的变化，其实是数据表达的根本性转移。以前我们关注“字段和类型”，现在越来越关注“语义向量和相关性”。一篇文档、一段对话、一张图片，在模型内部都会被转换成一串高维向量（Embedding）。这些向量代表的不是结构化的字段值，而是语义空间里的坐标。搜索、推荐、问答，全都变成向量之间的相似度计算。

这意味着，在很多 AI 应用里，JSON 里的字段信息反而不重要了，重要的是这个对象对应的向量。你在做语义检索时，先通过向量召回一批候选结果，再把它对应的原始文档（很可能是一段文本，不是 JSON）拿回来交给大模型做分析。数据从“可解析的结构化对象”变成了“不可直接阅读的数值矩阵”。这是对 JSON 统治地位最釜底抽薪的打击。

3.3 二进制时代回归：Protocol Buffers、FlatBuffers 与 MessagePack

如果说 JSONL 和向量改变了数据存储的方式，那么序列化协议的变化，则直接发生在数据交换的层面。我用过 JSON 做内部服务之间的通信，最早图省事、调试方便，后来流量上来后开始纠结 JSON 的序列化性能和体积。JSON 的文本格式天生就比二进制格式冗余。后来我换成 Protocol Buffers，序列化后的体积只有 JSON 的五分之一左右，解析速度提升了近一个量级。

在 AI 推理服务里，这种体积和性能差异更加致命。推理引擎需要在高并发下快速读写海量的中间数据、特征向量、模型输出。如果每一路调用都走 JSON，带宽和 CPU 都会被无谓占用。因此你会看到，很多 AI 推理框架的底层数据传输都采用了二进制协议，JSON 仅仅保留在对外 HTTP 接口那一层。这也是“JSON 在 AI 时代走向消亡”论调的另一个现实支撑——在最内层、最核心的数据通路上，JSON 已经边缘化了。

3.4 YAML/TOML 的逆袭：配置场景中的“人机友好”偏好

还有一个有趣的趋势是，在 AI 应用的配置管理里，YAML 和 TOML 正在挤占 JSON 的位置。原因很简单：人类写 prompt、配模型参数、定义 Agent 行为时，需要更贴近自然语言的表达方式。JSON 的每个 key 都要加双引号、每个对象要写大括号，在写复杂配置时非常痛苦。YAML 靠缩进表达层级，写了就让人眼明心亮；TOML 的[section]结构在管理扁平配置时格外清晰。

比如我维护一个多 Agent 协作系统，里面需要定义每个 Agent 的 system prompt、模型参数、工具列表、温度系数。早期用 JSON 写配置，维护成本很高；后来改成 YAML，不仅可读性好，并且可以直接在文件里写注释解释每个参数的含义。对 AI 工程师而言，配置文件的“可编辑性”和“可读性”比“严格可序列化”更重要，这是从前端 API 时代延续下来的思维惯性所不能理解的。

4. JSON 从未离开：AI 时代的三大不可替代场景

看到这里，你可能觉得 JSON 真的不行了。别急，接下来我要说它的“护城河”。在 AI 应用中，有三个场景不仅离不开 JSON，反而因为 AI 的发展变得更加依赖它。

4.1 结构化输出：大模型 Function Calling 的接口协议

Function Calling 是现在 AI Agent 的核心能力之一。模型理解用户的自然语言请求后，决定要调用哪个工具、传入什么参数，然后以结构化格式输出调用指令。而这个结构化格式，目前的标准就是 JSON。比如模型决定查询天气，它需要输出{"function_name": "get_weather", "parameters": {"city": "北京"}}这样的结构，才能被 Agent 框架解析并执行。

OpenAI 的 API 文档里，工具函数的参数定义用的是 JSON Schema，模型返回的也是 JSON 格式的函数调用参数。Anthropic 的 tool use 机制大同小异，Google Gemini 的 function declaration 同样依赖 JSON Schema。这说明什么？说明在未来相当长的时间里，AI 与外部工具之间的“接口层”始终要有一种稳定的、类型明确的、机器可读的格式，而 JSON 是目前综合成本最低的选择。你可以说这不是 JSON 的胜利，而是 JSON 的“偏安一隅”，但在 Agent 生态真正成熟之前，这“一隅”的含金量极高。

4.2 RAG 与知识库：元数据管理仍然依赖 JSON

RAG（检索增强生成）是现在企业落地大模型最主流的方式。它的核心是用私域知识库做向量化检索，把相关片段取出来作为上下文，交给大模型回答。在这个流程中，知识片段的主体内容会被切成 chunk，做向量化处理；但每个 chunk 的元数据——来源文档、标题、章节、作者、时间戳、权限标签——通常就是 JSON 格式。为什么？因为元数据需要灵活的支持各种自定义字段，而 JSON 恰好提供了这种灵活性。

比如我用向量数据库存内部规章制度时，会在每条 chunk 的 metadata 里塞{"doc_name": "考勤制度", "department": "HR", "version": "v2.1", "effective_date": "2025-01-01"}。检索完之后，我会先看这些 metadata，决定要不要把这条结果呈现给用户。如果某个文档已过期，我可以直接根据 metadata 里的版本字段把它过滤掉。这种灵活的字段扩展能力，用 SQL 表结构不一定做不到，但开发效率上确实 JSON 最顺手。

4.3 API 与 Agent 生态：JSON 仍是“工具链的通用语”

最后是我开头提到的那个观点：AI 不是生活在真空里，它必须调用真实的工具、访问真实的 API。而几乎所有公共 API 的默认数据格式都是 JSON。GitHub API 返回 JSON，Stripe 支付接口用 JSON，微信小程序后端用 JSON，数据库查询的 HTTP 接口返回 JSON。AI Agent 作为这一代应用的新交互入口，本质上是在替你把这些 API 串起来。如果这个世界的 API 不用 JSON 了，Agent 的生存基础反而会受到威胁。

我在做一个研究助手型 Agent 的时候，需要在一次任务里调用搜索、资讯抓取、表格生成、图表渲染四种工具。这些工具的输入输出参数，无一例外都通过 JSON 传递。Agent 的规划器在决定调用顺序时，也要把中间结果封装成 JSON 缓存，传给下一步的处理器。没有 JSON，这个轻量级的 Agent 编排流程会变得极其笨拙。这正是 JSON 的生命力所在——它也许不是效率最高的格式，却是互操作成本最低的格式。

5. 趋势观察与实操建议：AI 时代的数据格式选型策略

5.1 我的选型经验：什么场景坚持 JSON，什么场景果断换掉

踩过不少坑之后，我总结了一套自己的选型原则。这个原则不复杂，核心是看数据要经过哪些“域”。

第一，数据只在 API 边界、用户终端、工具调用之间流转，坚持用 JSON，不要换。这是它的主场，维护成本最低，生态支持最好。第二，数据要灌给模型做推理或微调，尽量转成 JSONL，尤其是在处理大批量样本时。第三，数据要在服务间高并发、低延迟传输，果断考虑 Protocol Buffers 或其他二进制方案。第四，数据用于配置文件、提示词模板、Agent 行为定义，优先 YAML 或 TOML。

用这个原则去审视现有系统，你会发现很多“JSON 性能瓶颈”其实是用错了场景。你拿着 JSON 当高并发内部协议用，自然痛不欲生；但如果你退回到 API 边界场景，它依然是最舒服的选择。这和“消亡”无关，只是“用对位置”。

5.2 给开发者的实操建议与避坑指南

第一，不要迷信模型的 JSON 输出能力。即使你开了结构化输出模式，也一定要在代码侧做二次校验。我见过太多生产事故，源于模型返回的 JSON 里多了一个未知字段，解析库直接报错。处理方法是：用宽容的解析策略，比如 Python 里先尝试json.loads，失败后用json5库兜底，再不行就触发一次重试。

第二，在提示词里明确“只输出 JSON，不要解释”。这是我反复踩坑后总结的经验。模型经常会仁慈悲悯地在 JSON 前后加一段话，比如“好的，这是你要的结果”。这句话一旦混进输出，你的解析器就会崩溃。现在我都会在 system prompt 里严格要求Return ONLY valid JSON, no markdown, no comments, no explanation，并在代码里用正则把可能包裹的json代码块剥掉，再做解析。

第三，小心 json parse error 的时间陷阱。有一个经典报错：cannot deserialize value of type java.util.Date from String。这不是 JSON 本身的错，而是 JSON 没有内置日期类型，时间到底存成字符串还是时间戳，完全靠约定。Java 这边用 Jackson 解析时，如果反序列化配置没指定格式，就会炸。AI 时代这个坑更多了，因为模型可能用各种格式输出日期字符串。我的建议是：在 Schema 里显式定义日期格式正则，并且在后端统一做一层日期解析适配器。

第四，关注 json序列化工具的选择。同样是序列化，Python 的orjson比标准json库快数倍，Java 的Jackson/fastjson各有取舍，Go 的encoding/json标准库在性能上已经越来越跟不上jsoniter的节奏。做 AI 数据管道时，我建议能用 C 扩展实现的高性能序列化库，就不要用纯 Python 标准库。有时候几十 GB 数据转下来，差别是小时级的。

5.3 未来推演：JSON 的演变而非消亡

最后聊聊未来。我个人的判断是，JSON 不会消亡，但也不会继续保持在“唯一中心”的位置，它会回归到“网页和 API 的基础格式”这一本色。AI 内部会有更多自己的原生格式：也许是更高效的二进制协议、也许是更语义化的结构化标记、也许是一种全新的数据容器。但这些格式大概率不会直接出现在公共接口层，因为公共接口层需要的是“通用性”和“最小摩擦”，JSON 依然是现在最优解。

一个更现实的演化方向是“JSON 和 AI 互相适应”。当前的大模型正在通过 Function Calling 学习如何输出合法 JSON，这是模型向 JSON 的妥协；同时工程师也在研究更省 token 的结构化表达方法，比如让模型只输出键值对列表而不是嵌套对象、使用短键名、提前拍平数据结构，这是工程向 AI 的妥协。两股力量的拉扯，会把 JSON 的使用方式推向一个更成熟、更多元的状态。

有一点可以确定：作为一名从业者，你不需要“站队”去拥护或者批判 JSON。真正有用的能力是，在合适的场景下选择合适的数据格式，并理解每一种格式背后的成本和收益。这比追逐概念、抢着宣布“旧技术已死”，要务实得多。