TOON 評測：把 JSON 壓成 LLM 讀得懂的表格
🎒 Token-Oriented Object Notation (TOON) – compact, human-readable serialization of JSON data for LLM prompts. TypeScript SDK, CLI, benchmarks.
秒懂
- 它是什麼？
- TOON 是針對大型語言模型提示詞設計的 JSON 編碼格式，用縮排與表格化把結構開銷壓下來。它的適用範圍比宣傳語窄得多：均勻物件陣列是主場，深層巢狀資料反而該留在 JSON。
- 適合誰用？
- 如果你手上有大量同欄位的物件陣列，例如排程表、感測器讀數、以 ID 為鍵的設定記錄，而且這些資料要進 LLM 提示詞，TOON 值得先做一次實測。做法很直接：把真實資料餵給 npx @toon-format/cli --stats，看它回報的節省比例，同時確認你的資料有多少比例落在 tabular form。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 13 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
TOON 想解的不是序列化，是提示詞的帳單
JSON 是程式之間交換資料的格式，它的括號、引號與重複鍵名對機器幾乎不花成本。但當同一份 JSON 被塞進 LLM 提示詞，這些結構字元全部要按 token 計價，而且會在輸入與輸出兩端各付一次。TOON 的定位就是這個落差：程式內部照舊用 JSON，只在送進模型前編碼成 TOON。README 把它講得很清楚，這是一層翻譯，是既有 JSON 的無損表示。
目標讀者是誰？是那些提示詞裡要塞結構化資料的人。工具呼叫的參數、資料庫查詢結果、設定檔、逐日預報這類內容，只要欄位重複度高，結構開銷就佔掉可觀比例。反過來說，如果你的提示詞主要是自然語言、結構化資料只佔一小塊，TOON 能省的絕對值很小，導入成本卻一樣要付。
這裡有個容易被忽略的前提：TOON 假設你控制提示詞的組裝。若你的資料是透過某個框架或供應商的結構化輸出功能送進去的，中間沒有插入編碼步驟的位置，那 TOON 對你就不成立。
四種形式：資料形狀決定渲染方式
TOON 不是一套固定語法，而是依資料形狀自動挑選渲染方式。README 列出四種。
inline form 處理純量陣列，直接寫在標頭行：alerts[2]: frost,wind。tabular form 處理均勻物件陣列，欄位清單在標頭宣告一次，之後每行一筆資料：forecast[3]{day,temp{min,max},condition,rainChance}: 底下接三行逗號分隔的值。keyed tabular 處理值為均勻物件的物件，靠長度後面的冒號標記，每行自帶鍵名，適合設定映射與以 ID 索引的記錄。剩下無法歸類的，包括混合型別與非均勻物件，退回 list form，每個元素一行，空物件寫成單獨一個減號。
標頭裡的 [N] 與 {fields} 不只是語法裝飾。README 稱之為 LLM 護欄：長度宣告讓截斷或格式錯誤的輸出難以蒙混過關，因為模型若少寫一行，數量對不上就是明顯的破綻。這是 TOON 相對純 CSV 的主要賣點，代價是那 5% 到 10% 的額外開銷。
巢狀欄位群 temp{min,max} 值得單獨看。它把均勻的巢狀物件折進標頭，資料列維持扁平，等於用宣告換取行內空間。這個設計只在巢狀結構本身均勻時成立，一旦某些項目的 temp 缺少 max，整個 tabular form 就失去資格。
裝起來跑一次：CLI 與 TypeScript SDK
最快的驗證路徑不需要安裝。README 給的例子是把 JSON 從標準輸入餵進去：cat data.json | npx @toon-format/cli --stats。輸出會同時印出 TOON 內容與轉換省下的量，格式類似「Token estimates: ~117 (JSON) → ~66 (TOON)」加上節省比例。這個指令適合拿真實資料先試水溫，因為它會直接告訴你節省幅度，不必先讀完整份規格。
套件本身是 TypeScript SDK，發佈在 npm 的 @toon-format/toon，另有 CLI 套件 @toon-format/cli。README 沒有在可見段落給出 SDK 的匯入與呼叫範例，只說明它對 JSON 資料模型提供確定性、無損的往返。實際的函式名稱與參數請以官方文件為準，本文不代為推測。
規格版本是 v4.1，與套件版號分開演進，README 的徽章把兩者並列。這代表讀文件時要留意規格與實作可能不同步。生態面，README 提到官方實作之外還有數十個社群移植版本，全部對準同一份規格與共用的一致性測試套件，這是多語言支援的實際運作方式。
檔案層面，README 標示了專屬的 media type 與副檔名，但可見段落未列出字串內容，需要時請查官方文件。
官方自己劃的紅線：什麼時候別用
多數格式的 README 只講適用場景，TOON 罕見地列了一節 When Not to Use TOON，而且內容具體。這節值得當成選型的第一道篩子。
第一，結構深層巢狀或非均勻，tabular eligibility 接近 0% 時，緊湊 JSON 往往直接勝出。原因不難理解：TOON 的壓縮來自欄位清單只宣告一次，若每個物件的欄位都不同，這個前提消失，剩下的是縮排與標頭帶來的額外字元。
第二，陣列半均勻、落在 40% 到 60% 之間時，節省幅度縮水。文件建議若你的管線本來就講 JSON，這種情況下留在 JSON。
第三，資料本來就是純表格時，CSV 更小。TOON 那 5% 到 10% 的開銷買的是長度宣告、欄位清單與分隔符號作用域，文件明講這是可靠性交易，不是體積交易。這個定性很重要：如果你的問題只是檔案大小，CSV 或壓縮是更直接的答案。
第四，延遲主導的場景。文件指出部分部署，特別是本地或量化模型，處理緊湊 JSON 反而更快，儘管 token 數更多。文件也直說延遲是唯一必須自己量的項目。這等於承認 token 數不是延遲的代理指標，兩者可能反向。
和 CSV、緊湊 JSON 的實際差別
TOON 最接近的替代品是 CSV。兩者都用列來承載均勻資料，差別在於 CSV 沒有型別、沒有巢狀、沒有長度宣告。TOON 的巢狀欄位群讓 temp{min,max} 這種結構留在單一列裡，CSV 得攤平成 temp_min 與 temp_max 兩欄，攤平會丟掉原始結構，回程要重建就得靠外部約定。所以 TOON 對 CSV 的優勢不在體積，在於它保留了 JSON 資料模型的形狀，往返不需要額外規則。
另一個替代品是緊湊 JSON，也就是拿掉空白與換行的 JSON。它的優點是零轉換成本，管線不必多一層。TOON 對它的優勢只在均勻度高的資料上成立，一旦結構不規則，兩者差距迅速收斂，而 TOON 還多付了編碼與解碼的程式碼。
YAML 是第三個參照點。TOON 借用了 YAML 的縮排結構，但 YAML 的規格龐大、邊界案例多，TOON 選擇縮小語法面並加上表格形式。代價是 TOON 的表現力比 YAML 窄，換來的是更容易預測的輸出。
官方 benchmark 分成兩條賽道，這種做法本身值得肯定：Mixed-Structure Track 比 TOON 與 JSON、YAML、XML，排除 CSV，因為 CSV 無法在不失真的前提下表示這些結構；Flat-Only Track 才納入 CSV。可見的 README 段落只描述賽道設計與檢索準確度的標題，沒有給出完整數字表，因此本文不引用任何具體準確率數字。
維護成本與授權的實際盤算
授權是 MIT，對商業使用與修改都沒有額外限制。這裡只描述授權條款本身，不構成法律意見；若你要把格式嵌入產品或對外承諾相容性，實際條文仍應自行確認。
維護面上，有幾件事會直接影響你的持有成本。第一，格式仍在演進。README 自己說格式穩定但仍是進行中的想法，沒有什麼是不可變的，並邀請使用者到規格倉庫參與。v4.0.0 到 v4.1.1 之間的三次發佈集中在 2026 年 7 月下旬到 8 月上旬，節奏不慢。若你的系統把 TOON 字串持久化到資料庫或快取，規格變動就意味著遷移工作，這是把序列化格式當儲存格式的典型風險。
第二，規格與實作分離成兩個倉庫，版本各自推進。這對多語言生態是好事，但也意味著升級時要同時確認規格版本與套件版本是否對齊，以及你依賴的其他語言移植版是否跟上。
第三，README 提到共用的一致性測試套件。對自行實作或選用社群移植版的人來說，這是驗證相容性的現成工具，比逐條比對規格文件可靠。
降低風險的做法很單純：把 TOON 限制在提示詞組裝這一層，不要讓它成為儲存或跨服務傳輸的格式。JSON 留在系統邊界內，TOON 只出現在送給模型的那一段。
導入前該驗的三件事
第一，量你的均勻度。跑 npx @toon-format/cli --stats 對真實資料集，看節省比例，而不是看範例。README 的天氣預報範例是精心挑選的均勻資料，約 117 token 降到約 66 token。你的資料若均勻度只有一半，這個數字會明顯縮水。
第二，確認往返無損。文件宣稱對 JSON 資料模型是確定性、無損的往返，但你的資料可能含有大量需要引號的字串、空物件或混合型別陣列，這些正好落在 list form 與引號規則的邊界上。用實際資料跑一次編碼再解碼，與原物件逐欄比對，比讀規格快。
第三，量延遲而非只量 token。文件明講部分部署處理緊湊 JSON 更快。若你的模型是本地部署或量化版本，token 數下降不代表回應變快。TTFT 與總時間要在你自己的環境量，這一項沒有替代方案。
這三件事都做完，你手上會有一組針對自己資料的數字，足以判斷 TOON 是省錢工具還是多一層轉換。
編輯結論
如果你手上有大量同欄位的物件陣列，例如排程表、感測器讀數、以 ID 為鍵的設定記錄，而且這些資料要進 LLM 提示詞，TOON 值得先做一次實測。做法很直接：把真實資料餵給 npx @toon-format/cli --stats，看它回報的節省比例，同時確認你的資料有多少比例落在 tabular form。若你的資料是深層巢狀、非均勻，或半均勻程度落在 40% 到 60% 之間，轉換的收益會被抵銷，留在 JSON 更省事。若你的瓶頸是延遲而非 token 成本，官方文件明講部分部署（尤其是本地或量化模型）處理緊湊 JSON 反而更快，這一項必須自己量測 TTFT 與總時間，不能靠 token 數字推論。最後要驗的是往返正確性：TOON 宣稱對 JSON 資料模型是無損的，但你的資料若含有大量需要引號的字串、空物件或混合型別陣列，請先跑一輪 decode(encode(x)) 與原物件比對，再決定要不要接進正式管線。
社群筆記