设计 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。语义层的三个价值意图表达color-danger比color-red-500传达更多信息——它表达了这个颜色用于危险/错误场景而不仅仅是这是一种红色。变更隔离品牌色从蓝变绿时改变color-primary的引用即可所有组件自动更新。如果有 50 个组件直接引用了color-blue-500逐个修改是噩梦。上下文约束spacing-card-padding限制了只能在卡片组件中使用防止有人在按钮中误用了卡片的间距值。语义层的建立也让设计变更的成本可控。当设计系统从 v1 升级到 v2 时原子层的值可能全部调整#1677FF改为#0066FF但语义层的引用名不变color-primary仍然是color-primary组件代码零修改。这种接口稳定、实现可变的设计模式和软件工程中的依赖反转原则一脉相承——组件依赖抽象语义 Token而非具体原子 Token。语义层的实现方式是别名映射color-danger指向color-red-500color-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 Mapstring, 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, }; }五、总结Token 数量超过 200 时边际收益急剧下降超过 500 时成为负担语义层的价值在于意图表达、变更隔离和上下文约束而非数量Token 引用的语义别名color-danger→color-red-500比新增原子 Token 更重要引用次数 3 的 Token 是噪音应该删除或合并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 资料来源索引并在发布前将具体来源贴到对应断言之后。