TOON 格式：结构化上下文的 Token 优化与边界
介绍 TOON 的表格化编码与 Node.js 转换，区分字符长度、Token 数和模型准确率，说明适用数据形状。
直接回答：TOON 是为模型上下文设计的紧凑结构化表示。规则表格可减少重复键名，但节省比例取决于数据形状、分词器与完整提示，必须按实际输入统计。
JSON 为什么在 LLM 场景浪费钱
JSON 是好格式——为 Web API 和人类阅读设计。但 LLM 按 Token 计费时，它的设计就成了负担：
- 符号可能单独或与相邻字符合并编码，不能按一个符号一个 Token 估算
- 数组里 100 条记录，键名就重复 100 次
- 这些 Token 对模型理解内容包含结构信息，部分重复可以换一种表达方式减少
TOON 怎么省
核心思路：键名只说一次，数据按行排列——类似把 JSON 数组转成 CSV/表格：
// JSON：每行重复键名
[{"name":"张三","age":28,"city":"杭州"},{"name":"李四","age":35,"city":"北京"}]
// TOON：键名声明一次
[2]{name,age,city}:
张三,28,杭州
李四,35,北京
重复键较多的规则表格有优化空间；比较时应保留原始数据、序列化方式和分词器记录。
转换示例（Node.js）
npm init -y && npm install @toon-format/toon
import { encode } from '@toon-format/toon';
import fs from 'fs';
const data = JSON.parse(fs.readFileSync('data.json', 'utf8'));
const toon = encode(data);
fs.writeFileSync('data.toon', toon);
// 这里只比较 UTF-16 字符长度，不是 Token 数
console.log('JSON 长度:', JSON.stringify(data).length);
console.log('TOON 长度:', toon.length);
将脚本保存为 .mjs 或在项目启用 ESM。Token 对比另用目标模型支持的分词器，并把格式说明和输出校验开销一起计入；本文未运行示例。
什么时候值得用
适合：
- 向 LLM 喂大量结构化数据（表格、日志、订单记录、查询结果集）
- RAG/分析类应用，上下文里数据占比高
- 高频调用，省下的 Token 聚沙成塔
不适合：
- 深度嵌套、结构不规则的数据（TOON 最擅长扁平表格状数据）
- 模型输出侧——让模型生成严格 TOON 的可靠性不如 JSON，输出仍建议 JSON
- 数据量小的场景，省几个 Token 不值得增加复杂度
集成建议
把 TOON 当成"上下文压缩层"：入库存储仍用 JSON，组装 Prompt 时转换为 TOON，模型回答要求 JSON 输出再解析回来。需要增加编码、提示与回归验证，不是零改动。
常见问题（FAQ）
Q：模型一定能正确读取吗？
A：不保证，需测试字段错位、嵌套、转义及缺失值。
Q：转换无损等于准确率不变吗？
A：不是。数据表示可逆不保证模型理解无误。
Q：与 JSON minify 怎么比较？
A：用同一数据和分词器比较；不要机械删除 TOON 的结构性缩进和换行。
参考资料
资料核对日期：2026 年 9 月 29 日。本文基于公开文档整理，代码片段和评估方案未作独立运行或性能验证；厂商测试结果已注明来源。
