为大语言模型而生的节省成本数据格式 TOON 详解

用过 LLM API 的朋友一定深有体会：Token 就是真金白银。每次把结构化数据塞进 Prompt，看着重复的字段名、冗余的引号和括号占掉大半 Token 额度，心里都在滴血------明明核心内容没多少，却要为格式"买单"。

过去十几年，JSON 凭借其稳定性、跨平台性和可读性，成了互联网数据交换的事实标准。但在 AI 时代，尤其是面对按 Token 计费的大语言模型（LLM），JSON 的"啰嗦"就暴露出来了。

举个简单例子：一个包含两个用户的列表，用 JSON 表示是这样的：

json 复制代码

[{"name":"Alice","age":30,"city":"New York"},{"name":"Bob","age":25,"city":"San Francisco"}]

看起来简洁，但仔细一算，光是重复三次的 "name"、"age"、"city" 字段名，就占了近一半的 Token。对于高频调用或大批量数据场景，这种浪费非常可观。

正是为了解决这个痛点，社区在 2025 年左右推出了一种新格式------TOON （Token-Oriented Object Notation，面向 Token 的对象表示法）。它不是要取代 JSON，而是充当一个"效率翻译官"：平时开发仍用熟悉的 JSON 处理数据，等到要传给 LLM 时，一键转成 TOON 格式，就能节省 30% 到 60% 的 Token，直接降低调用成本和响应延迟。

TOON 的设计思路非常直观：把重复的部分提出来，只声明一次。

还是上面那个用户列表，用 TOON 表示如下：

复制代码

("name","age","city")(("Alice",30,"New York"),("Bob",25,"San Francisco"))

结构一目了然：先定义字段名，再以元组形式列出每条记录。Token 数从约 50 降到 35 左右，节省近 30%。更重要的是，这种紧凑、对齐的格式对 LLM 更友好------模型更容易识别数据边界，解析准确率更高。有实测数据显示，使用 TOON 后，LLM 在结构化数据理解上的错误率可降低约 15%。

除了省 Token，TOON 还有两个实用优势：

语法极简：去掉了 JSON 中的大括号、冒号等冗余符号，靠括号和逗号就能清晰表达层级，有点像 YAML 的简洁 + CSV 的紧凑，但保留了 JSON 的结构化能力。
生态渐成：GitHub 上已有官方仓库，支持 TypeScript、Python、Rust 等主流语言，几行代码就能集成到现有项目中。

当然，TOON 并非万能。它最适合处理同构、扁平化的批量数据，比如用户列表、订单记录、日志条目等。如果是深度嵌套、结构不规则的数据，或者需要对外提供通用 API，JSON 依然是更稳妥的选择。

目前，不少企业已经开始落地实践：

金融机构用 TOON 传递交易流水给 LLM 做风险分析；
电商平台将商品目录转为 TOON 格式，交给 AI 自动生成营销文案；
甚至一些云服务商已在工具链中内置 TOON 转换功能，进一步降低使用门槛。

说到底，TOON 的出现是 AI 时代的必然产物------当 Token 成为核心成本，数据格式就必须为场景而优化。它没有颠覆现有体系，而是在 JSON 和 LLM 之间架起了一座高效、轻量的桥梁。

如果你的工作经常需要向大模型输入结构化数据，不妨试试 TOON。说不定你会发现：省 Token，原来可以这么简单。