一、引子：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-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',
};
}
五、总结
- 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 资料来源索引，并在发布前将具体来源贴到对应断言之后。
400 186 1886
