TOON：为 LLM 提示词设计的紧凑序列化格式，值得替换 JSON 吗
🎒 Token-Oriented Object Notation (TOON) – compact, human-readable serialization of JSON data for LLM prompts. TypeScript SDK, CLI, benchmarks.
秒懂
- 它是什么？
- TOON 是一种面向 LLM 提示词的 JSON 数据序列化格式，宣称可减少约四成 token 且保持检索精度。本文基于其 README 与仓库信息，分析其语法机制、适用边界、上手方式与真实限制。
- 适合谁用？
- 如果你的数据以数组或键控对象的均匀结构为主，且你正在为 LLM 输入支付 token 费用，TOON 值得一试。先用自己的数据跑一遍 `cat data.json | npx @toon-format/cli --stats`，确认节省比例是否达到预期，再检查你的模型对 TOON 文本的检索准确率是否与 JSON 相当。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 13 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，为谁设计
LLM 的输入输出按 token 计费，而 JSON 的括号、引号、逗号占据了大量 token。TOON 的目标是提供一种 JSON 数据模型的替代编码，让结构更紧凑，同时让模型更容易遵循格式。它面向的是那些需要把结构化数据塞进提示词的开发者，例如生成天气预报、配置列表、记录数组等场景。TOON 不是要取代 JSON 作为程序间交换格式，而是作为一层翻译：程序内部仍然用 JSON，只在送入 LLM 之前转换为 TOON。它的核心承诺是 lossless，即任何 JSON 值都能无损地表示为 TOON，并能确定性地往返。
四种表格形式如何压缩结构
TOON 的压缩思路来自对数据形状的自动分类。它定义了四种形式：inline form 用于原始类型数组，把元素直接写在头部行，例如 `alerts[2]: frost,wind`。tabular form 用于均匀对象数组，字段列表在头部声明一次，后续每行只写值，例如 `forecast[3]{day,temp{min,max},condition,rainChance}:` 之后每行是 `Mon,-2,4,snow,80`。keyed tabular form 用于键控对象，冒号加长度标记 `[2:]`，每行自带键。list form 是兜底方案，用于混合类型或非均匀结构，每项一行 `- `。这种设计把重复的结构声明压缩到一次，行内只保留数据本身。注意，nested field group 允许在头部声明嵌套的均匀对象，比如 `temp{min,max}`，这让行保持扁平，但深层嵌套时这种折叠会失效。
从 JSON 到 TOON：实际命令与输出
安装和试用不需要先写代码。README 给出的快速体验命令是 `cat data.json | npx @toon-format/cli --stats`，它会输出 TOON 编码以及 token 节省估算。以天气预报为例，输出显示 `Token estimates: ~117 (JSON) → ~66 (TOON)`，并打印 `Saved ~51 tokens (-43.6%)`。项目提供 TypeScript SDK，包名为 `@toon-format/toon`，另有 CLI 包 `@toon-format/cli`。官方文档站点是 toonformat.dev，其中包含 Format Overview 指南。要实际集成，你需要调用 SDK 的编码函数，但 README 没有给出具体的 API 调用示例，因此编码函数名和选项需要查阅仓库的源码或文档。CLI 的 `--stats` 参数是唯一明确的命令选项。
token 节省的边界在哪里
TOON 的节省不是普适的。README 明确列出不适合的场景：结构深度嵌套或非均匀时，tabular 的适用率接近 0%，紧凑 JSON 可能更高效。半均匀数组（适用率约 40% 到 60%）时节省缩水，如果现有管线已经用 JSON，可能不值得切换。纯表格数据用 CSV 更小，TOON 的 5% 到 10% 开销换来的是声明长度和字段列表，这是可靠性上的权衡。更关键的是延迟：某些部署，特别是本地或量化模型，处理紧凑 JSON 反而更快，尽管 token 更多。README 建议自己测量 TTFT 和总时间，因为它无法替你的硬件和模型做这个判断。这意味着 token 节省并不自动等于成本节省，如果延迟是瓶颈，TOON 可能帮倒忙。
检索准确率：基准测试说了什么
README 声称 TOON 匹配 JSON 的检索准确率，同时使用 42.6% 更少的 token。这个数字来自项目自己的基准测试，分为两个轨道：混合结构轨道对比 JSON、YAML、XML，排除 CSV，因为 CSV 无法无损表示嵌套结构；纯扁平轨道则允许 CSV 参与。检索准确率的具体测试方法、数据集和结果表格在 README 中被截断，因此无法验证这一声称的严谨性。项目没有提供第三方独立基准。你需要自行用你的数据和模型复现准确率对比，尤其是当你的任务要求模型从 TOON 文本中提取字段时，格式变化可能影响模型的遵循能力。
限制与失败模式：何时不该用
除了结构复杂度，TOON 的另一个限制是格式仍在演进。README 的提示框说格式稳定，但也是进行中的想法，没有什么是定死的，并邀请贡献者参与 spec。这意味着如果你在生产环境采用，未来 spec 更新可能带来破坏性变化。另一个失败模式是截断或格式错误的输出。TOON 的 `[N]` 声明行数、`{fields}` 声明宽度，本意是防止模型输出被截断时悄悄出错，但这依赖于模型严格遵循头部声明。如果模型生成的行数与声明不符，解析器需要决定是报错还是容错，README 没有说明这种行为。此外，TOON 的媒体类型和文件扩展名在 README 中提及但未给出具体值，说明标准化程度还不足。
替代方案：JSON、CSV 与 YAML 的取舍
TOON 的直接替代是 JSON，因为它是 LLM 提示词中最常见的格式。JSON 的优点是通用、模型训练数据多、解析器无处不在，缺点是 token 开销大。YAML 是另一个选择，缩进结构比 JSON 紧凑，但 YAML 的语法复杂，容易产生歧义，模型生成时出错率可能更高。CSV 在纯表格数据上比 TOON 更小，但它无法表达嵌套结构，且缺乏字段类型声明。TOON 的定位是介于 CSV 的紧凑和 JSON 的表达力之间，用头部声明弥补 CSV 的结构缺失。如果你的数据已经以 CSV 形式存在且无需嵌套，直接使用 CSV 可能更省 token。如果你的数据深层嵌套，JSON 可能反而更高效，因为 TOON 的表格形式无法应用，而 list form 的缩进并不比 JSON 的括号更省。
维护成本与许可证
项目使用 MIT 许可证，这对商业使用友好，没有 copyleft 义务。仓库最后推送时间是 2026 年 9 月，最近的发布是 v4.1.1（2026 年 8 月），v4.0.0 在 7 月发布，说明迭代频繁。频繁的版本更新意味着你需要跟踪变更日志，特别是 spec 版本标记为 v4.1，格式本身也在演进。维护成本包括：一是学习 TOON 语法，虽然最小，但头部声明的嵌套字段组需要理解；二是转换层，你需要在 JSON 和 TOON 之间加一个编码步骤，这可能影响现有管线的错误处理；三是 conformance test suite 的存在，说明不同语言实现需要保持一致，但如果你只用 TypeScript SDK，这个风险较低。整体上，MIT 许可证和活跃维护降低了采用的法律和社区风险，但格式未冻结是长期维护的主要不确定性。
编辑结论
如果你的数据以数组或键控对象的均匀结构为主，且你正在为 LLM 输入支付 token 费用，TOON 值得一试。先用自己的数据跑一遍 `cat data.json | npx @toon-format/cli --stats`，确认节省比例是否达到预期，再检查你的模型对 TOON 文本的检索准确率是否与 JSON 相当。若你的数据结构高度嵌套或非均匀，或你的部署是本地量化模型且延迟敏感，JSON 可能仍然更合适。TOON 的规范仍在演进，生产环境采用前应锁定 spec 版本，并关注其 conformance test suite 的更新。
社区笔记