设计 Token 的极限：当原子化走到尽头——语义层的真正价值

设计 Token 的极限：当原子化走到尽头——语义层的真正价值

一、引子：1000 个 Token 还是不够用

团队的设计 Token 文件从最初的 30 个增长到 1000 个。每一个新的视觉需求都被加到 Token 定义中——"这个背景色比 bg-secondary 浅一点但比 bg-tertiary 深一点，就叫 bg-secondary-light 吧。" 原子化走到极致的表现是 Token 数量爆炸，而 Token 应该解决的问题——一致性——反而被稀释了。

美院学色彩的时候，老师给了一套 12 色相环，让我们只用这 12 个颜色完成所有作业。当时觉得受限，后来才理解：限制即风格。当 Token 从 30 个膨胀到 1000 个时，团队中没有人能记住全部 Token 的用途——设计师不确定该用bg-gray-50还是bg-gray-100，开发者随手var(--color-bg-secondary-light)打错了也没人发现。Token 文件变成了一本没人读完的字典，每个人只在其中查自己认识的那几页。一致性的前提是"可记忆"，1000 个 Token 已经超出了人的记忆带宽。Token 的价值不在于"覆盖了每一种视觉变体"，而在于"让团队在同一个词汇表里对话"。

二、Token 原子化的边际收益递减

三、语义层的真正价值

当 Token 数量超过 200 时，问题不再是"不够用"，而是"找不到"。语义层解决的不是"有多少 Token"，而是"在什么场景下用哪个 Token"。

语义层的三个价值：

1. 意图表达：color-danger比color-red-500传达更多信息——它表达了"这个颜色用于危险/错误场景"，而不仅仅是"这是一种红色"。

2. 变更隔离：品牌色从蓝变绿时，改变color-primary的引用即可，所有组件自动更新。如果有 50 个组件直接引用了color-blue-500，逐个修改是噩梦。

3. 上下文约束：spacing-card-padding限制了只能在卡片组件中使用，防止有人在按钮中误用了卡片的间距值。

语义层的建立也让设计变更的成本可控。当设计系统从 v1 升级到 v2 时，原子层的值可能全部调整（#1677FF改为#0066FF），但语义层的引用名不变（color-primary仍然是color-primary），组件代码零修改。这种"接口稳定、实现可变"的设计模式，和软件工程中的依赖反转原则一脉相承——组件依赖抽象（语义 Token），而非具体（原子 Token）。

语义层的实现方式是"别名映射"：color-danger指向color-red-500，color-red-500指向#EF4444。两层间接引用让原子层可以自由变更（把红色从#EF4444改成#DC2626），而语义层保持稳定（color-danger的引用不变）。这就像美院的色彩训练——你先调出"朱砂红"（原子层），再决定"警示色用朱砂红"（语义层），最后在画面上画"危险区域用警示色"（组件层）。三层各司其职，互不干扰。

四、Token 体系的止盈点

当遇到以下信号时，说明 Token 体系需要收敛而非继续扩展：

- Token 命名中出现数字后缀（bg-gray-100 到 bg-gray-900 是合理的，bg-gray-950 是过度扩展） - Token 被 < 3 个组件引用（没有复用价值的 Token 是噪音） - Token 的修改频率 > 每月 5 次（说明粒度不对）

收敛策略：

// Token 审计：删除 < 3 次引用的 Token function auditTokenUsage(tokenFile: TokensDefinition, codebase: string[]): TokenAudit { // 美院学色彩时老师给了一套12色相环，限制即风格。 // Token 从30膨胀到1000时，没人能记住全部用途。 // 一致性的前提是可记忆，1000个Token已超出人的记忆带宽。 const usageCounts = new Map<string, number>(); for (const tokenName of getAllTokenNames(tokenFile)) { const regex = new RegExp(`var\\(--${tokenName}\\)|--${tokenName}`, 'g'); let count = 0; for (const file of codebase) { const matches = file.match(regex); if (matches) count += matches.length; } usageCounts.set(tokenName, count); } return { unused: [...usageCounts.entries()].filter(([_, c]) => c === 0), lowUsage: [...usageCounts.entries()].filter(([_, c]) => c > 0 && c < 3), suggestion: '删除使用次数 < 3 的 Token', }; }

五、总结

1. Token 数量超过 200 时边际收益急剧下降，超过 500 时成为负担
2. 语义层的价值在于意图表达、变更隔离和上下文约束，而非数量
3. Token 引用的语义别名（color-danger→color-red-500）比新增原子 Token 更重要
4. 引用次数 < 3 的 Token 是噪音，应该删除或合并
5. Token 体系的健康指标：Token 数量稳定在 100-200，语义别名占比 > 60%

最终，Token 体系的健康不在于"有多少 Token"，而在于"团队能否在 3 秒内找到需要的 Token"。美院教版式设计时老师说："一套好的字体系统，不是有 100 种字体，而是让你在任何场景下都不犹豫该用哪个。"Token 系统同理——最好的 Token 文件不是最全的，而是让设计师和开发者在面对任何 UI 需求时，都能毫不犹豫地选出正确的那个。止盈，比扩张更难，也更重要。

在实际操作中，我们团队用了半年时间将 Token 从 1000 个收敛到 180 个。方法是：先跑一轮auditTokenUsage找出引用次数为 0 的 Token 直接删除（约 400 个），再将引用次数 1-2 次的 Token 合并到语义别名中（约 300 个），最后将数字后缀的 Token（如bg-gray-50到bg-gray-900）收拢为 3 档（bg-light/bg-normal/bg-dark）。收敛后的 Token 文件从 2000 行缩减到 350 行，新成员 onboarding 时间从 3 天缩短到半天——因为只需要记住 180 个 Token 的语义，而不是在 1000 个 Token 中搜索。这就是"少即是多"在设计系统中的真实写照。

资料说明

本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论，不应视为行业事实。可参考 0730 资料来源索引，并在发布前将具体来源贴到对应断言之后。