token 到底长什么样。
这个问题我被问过几次，每次只能回一句，它不是字，也不是词，是模型自己切出来的块。说完自己都觉得等于没说。
现在有人做了个东西，能让你直接看见。
简单说，这是一个跑在浏览器里的字体编译器。把一个 tokenizer 和一款字体丢进去，它吐出一个新的 TTF。装上之后，你打的字会按那个 tokenizer 的切法显示，要么每个 token 等宽排开，要么用颜色区分。
关键是最后的字体里没有脚本。分词逻辑被烤进了字体的字形排布规则。你把它发给别人，对方什么都不用装，看到的还是切好的样子。
为什么这条值得收
我们这几年的账基本都按 token 算。接口按 token 计费，context window 按 token 卡，模型答得慢也是因为 token 一个一个吐。但 token 一直看不见。看不见就只能凭感觉估，估完账单出来对不上。
这个字体不解决账单。它解决的是你一直估的那个东西到底长什么样。
支持哪些 tokenizer
列出来挺宽。DeepSeek、OpenAI 那几个 base（o200k、cl100k、p50k、r50k）、Kimi、Qwen、GLM、Llama 3、Gemma、Gemini，都在。ctok 那几版走的是另一条路。
也能上传自己的 tokenizer.json，或者贴一个 Hugging Face 仓库链接。字体文件不上传，留在你本机，只下 tokenizer。
但"支持"这两个字的含金量不一样
DeepSeek、OpenAI、Kimi、Qwen、GLM、Llama 3 走的是各自的专门编译路径，作者做过定向测试。Gemma 和 Gemini 是另一套，测的是空格标记和字节回退。
上传的 tokenizer 就不好说了。接受文件不等于兼容，任意的 normalizer、WordPiece、Unigram 一般都不支持。页面自己写得很直白，任意上传没有 preset 级别的测试。
别把"它收了我的文件"当成"它算得对"。
ctok 是近似，不是复刻
这条得单独标出来。ctok 用的是字体里做最小代价分词，配一个近似的 Unicode 归一化器。
页面原文的意思是，这是对 Claude 的一版近似，不是确认过的复刻。审计全程没调用过任何 Claude 接口。
我看到每版 785 个定向用例里，v3 有 29 个计数或宽度失败、45 个语义失败，v4.7 是 25 和 49，v4.8 是 16 和 8。都还没修。
作者自己说他不怎么懂字体
这可能是整条里我最想收的一句。作者明说自己在字体上没有很深的功底，欢迎更懂行的人做一个更正经的版本。
一个工具把自己的边界写得这么清楚，比它多支持五个 tokenizer 难得。
颜色模式有个坑
用颜色标 token 视觉上最直观。颜色数 2 到 16 可调，挑色时会按你填的背景色保证对比度不低于 4.5:1。
但页面也承认，颜色差异本身对一部分人来说不构成可用的边界。颜色开得越多，撞色的概率是低了，颜色之间却越来越像，字体体积也会涨，有的字体直接撞上字形数量上限。
还有，它没法知道你实际用在什么背景上。你填的那个色值，只是它猜的。
真正能落地的地方是聊天软件
编译出来的字体配个主题，可以塞进 Discord，也能用 userscript 用在网页版 Slack 里。可以只对某一个人的消息生效，填 ID 或显示名，不填就是全部消息都变。
Discord 那个是主题，不用自己编译客户端。代码块还是原来的等宽字体，不受影响。
这个用法挺实在。你想看某个 agent 到底把你那句话切成了几块，开一下就行。
限制比功能多
字体分不了跨 shaping run 的词。前导空格自己会成一个 run。零宽空格、word joiner、BOM、软连字符都能把词边界吞掉。Qwen 的 NFC 最多扛八个连续非起始字符，超了显示 [NFC limit]。GLM 和 Llama 的某些片段超过限制显示 [BPE limit]。区域超容量显示 [limit]。
这些方括号不是 bug，是这套东西老实承认自己算不完的地方。
浏览器归一化会在字体看到文字之前就改变 token 边界。同一段文本在不同浏览器、不同应用里，切法可能不一样。页面最后还有一句，这是拿来看普通文本的，不是拿来当精确计费数的。
我自己的用法很简单。把一段常写的提示词丢进去，看一眼它被切成什么样，就知道该在哪儿断句、哪儿别塞没用的空格。
这条我其实只看懂了一半，尤其是 ctok 那套最小代价分词的部分。先放在这里，等我弄明白再补。
本周就这些。上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。
下周见。