为什么我强烈推荐 TOON（Token-Oriented Object Notation）——以及 .NET 版 Toon.NET

为什么我强烈推荐 TOON（Token-Oriented Object Notation）——以及 .NET 版 Toon.NET

给 LLM 喂结构化数据，别再硬塞 JSON 了。在很多真实场景里，TOON 同时做到更省 Token、更稳的解析/检索、更易于写提示词。

（上图：TOON 官方逻辑图，来源 toon-format/toon 仓库。 ）
TOON 是什么？

TOON 是一种为 LLM 输入而生的紧凑序列化格式。它把 YAML 的缩进层级和 CSV 的表格行融合起来，用极少的符号把结构表达清楚，特别擅长“字段一致的对象数组”（如表格数据）。官方定位很明确：只用作模型输入的中间层——应用里照常用 JSON，喂给模型前再转成 TOON。(GitHub)
核心特性（官方）：

• 更省 Token：通常比 JSON 少 30–60%。
  
• 更稳健：用显式长度 [N] 和字段头 {a,b,c} 做“护栏”，便于校验与约束。
  
• 语法极简：去掉大括号/引号等重复符号，缩进表达层级，表头只写一次、数据连行输出。(GitHub)
  

为什么不是 JSON（以及“压缩 JSON”）？

• 结构信息的冗余：JSON 的每一行都重复键名，合并空格/去换行后虽然“压缩”了字符，但并没有减少模型看见的关键 Token 数，甚至可能降低模型对结构的把握（你给出的实验里就体现为识别率下降）。
  
• TOON 的思路：一次声明、按行铺开。对于多行同构数据，去掉重复键名就是“白捡”的 Token 节省，同时字段头与行数构成了显式约束，更利于模型“对齐”结构。官方基准在多组数据上都显示对 JSON 有明显节省，且对 “紧凑 JSON”（minified/compact）依旧有可观优势。(GitHub)
  

一句话：当你的数据像表格那样“多行同字段”时，TOON 的收益随规模复利增长。(GitHub)
官方基准与节省幅度

在官方基准里（GitHub 热门仓库、日常分析、电商订单三类数据），TOON 相对 JSON 平均节省 ~49% Token，相对紧凑 JSON 也节省 ~28%；不同数据结构会有差异，但总体趋势稳定。(GitHub)

官方图例也给出一个直观口径：≈ 40–60% 节省，并显示在检索类任务上的准确率提升示意。

你提供的模型对比数据同样有参考意义：

• gpt-5-nano：TOON 96.1%（148/154），优于 CSV / YAML / 紧凑 JSON / XML / JSON。
  
• gemini-2.5-flash：TOON 86.4%，与 CSV/XML 相近，显著高于 JSON。
  
• haiku / grok 等轻量或非推理模型：TOON 仍具竞争力，但不同模型差异更大。
  

这些是你给出的内部评测结果，用的数据集与提示模板会影响分数，但方向与官方结论一致。

什么时候用 / 不用？

强烈推荐用在：

• 大量同构记录（表格、日志、指标、清单、订单等）
  
• 检索/比对/校验型任务（显式行数与字段让模型少犯错）
  
• 上下文成本敏感、批量调用频繁的 Agent/Workflow
  

谨慎使用或继续用 JSON：

• 深层嵌套、字段形态差异大的对象（此时 JSON 可能更高效）
  
• 需要对外暴露 API / 存储：TOON 是输入层而非通用交换格式。(GitHub)
  

JSON → TOON：一眼看懂

同一份数据：

1. {
2.   "users": [
3.     { "id": 1, "name": "Alice", "role": "admin" },
4.     { "id": 2, "name": "Bob",   "role": "user"  }
5.   ]
6. }

复制代码

转为 TOON：

1. users[2]{id,name,role}:
2.   1,Alice,admin
3.   2,Bob,user

复制代码

头部一次性给出行数和字段次序，后面只写值行。(GitHub)

Prompt 最佳实践（官方建议）

• 当作输入喂给模型时，直接展示格式而不是解释格式；用 ```toon 代码块包起来即可。
  
• 让模型产出 TOON 时，务必在提示里给出期望的表头、两空格缩进、行数 [N] 与实际行数一致等约束。(GitHub)
  

.NET 实现：AIDotNet/Toon.NET

我们开源了 Toon.NET，对齐官方规范（当前 v1.3），并尽量提供与 System.Text.Json 一致的 API 与选项模型，方便 .NET 开发者“无缝上手”。(GitHub)
亮点

• 高性能编码：对象、原子数组（行内）、对象数组（表格）路径已实现
  
• 解码管线在推进中（扫描/解析/验证），当前已支持原子值回读
  
• 选项包括 Indent / Delimiter(Comma|Tab|Pipe) / Strict / LengthMarker 等
  
• 目标框架：.NET 8/9/10；许可：MIT。(GitHub)
  

快速开始（C#）

1. using Toon;
3. var options = new ToonSerializerOptions
4. {
5.     Indent = 2,
6.     Delimiter = ToonDelimiter.Comma,
7.     Strict = true,
8.     LengthMarker = null
9. };
11. var data = new
12. {
13.     users = new[]
14.     {
15.         new { name = "alice", age = 30 },
16.         new { name = "bob",   age = 25 }
17.     },
18.     tags = new[] { "a", "b", "c" },
19.     numbers = new[] { 1, 2, 3 }
20. };
22. string toonText = ToonSerializer.Serialize(data, options);
23. // users[2]{name,age}:
24. //   1,alice
25. //   2,bob
26. // tags[3]: a,b,c
27. // numbers[3]: 1,2,3

复制代码

以上示例与官方格式对齐；更多 API、选项与路线图详见仓库 README。(GitHub)

仓库地址

• TOON 官方：toon-format/toon（规范、TS 实现、基准与图示）。(GitHub)
  
• .NET 实现：AIDotNet/Toon.NET（欢迎 Star、Issue、PR）。(GitHub)
  

落地清单（给工程团队）

• 识别数据形态：优先挑选“多行同字段”的提示数据（表格类）。(GitHub)
  
• 引入编码步骤：应用层仍用 JSON，在入模前 encode(JSON) → TOON。(GitHub)
  
• 模板化约束：在系统提示中固定 TOON 表头、缩进、[N] 规则，并做长度/字段校验。(GitHub)
  
• 测量而非臆测：不同 tokenizer/模型会带来差异，基于你的真实数据做一次 A/B（Token/费用/准确率）。(GitHub)
  
• 回退策略：当数据深嵌套/非同构时，保留 JSON 路径；TOON 不是通用存储/对外 API。(GitHub)
  

常见坑与注意

• 混合或复杂数组：TOON 会回退为列表项写法，不再是表格行，收益会变小。(GitHub)
  
• 空格/缩进/行数要严格匹配；建议在服务端做一次轻量校验再送模型。(GitHub)
  
• Tokenizer 不同会带来节省幅度波动（官方基准用 GPT 系列的 cl100k/o200k）。(GitHub)
  

结语

如果你的 LLM 应用经常把成百上千行的表格/对象数组塞给模型，TOON 是一个立竿见影的“省钱+增稳”方案。现在就试试：

• 规范与图示、基准：toon-format/toon。(GitHub)
  
• .NET 实现：AIDotNet/Toon.NET（与 System.Text.Json 一样顺手）。(GitHub)
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！