设计系统里有个概念，这几年被反复提起，但误解也深——设计令牌（Design Tokens）。很多人以为它就是“把颜色值存成变量”，或者“设计师给开发的一组命名参数”。这理解不能说错，但只触及了表皮。真要解释清楚它是什么，得先放下那些工具思维，回到一个更根本的问题：一个设计决策，如何跨越工具、平台、代码库，始终保持同一副面孔？

不是变量，是“设计决策的最小原子”

变量是工程概念，令牌是设计概念。区别在于，变量关心的是“值是什么”，令牌关心的是“这个值意味着什么”。比如 #1A1A1A 是一个值，但 color.surface.primary 是一个令牌——它告诉你，这是主表面色，用于承载主要内容的背景。它背后绑定的可能是一个色值，也可能是一套深浅模式下的映射规则，甚至包含透明度、混合模式等额外约束。

这就是为什么令牌系统往往不是扁平键值对，而是一个有层级的命名空间。颜色、间距、字号、阴影、圆角……每一项都被拆解成“类别-语义-状态”的树状结构。比如 spacing.layout.gap.large 和 spacing.component.button.padding-x，前者定义页面级栅格间距，后者定义按钮内边距。它们可能指向同一个 16px，但语义绝不重叠。一旦设计需要将页面级间距从 16px 调整为 20px，按钮内边距纹丝不动——因为令牌的语义边界保护了这种变更的独立性。

平台无关，但约束明确

真正成熟的令牌体系，不会直接输出 CSS 变量或 SwiftUI 的 Color Set。它在中间层定义了一套与平台无关的抽象语法，再由转换工具（如 Style Dictionary）生成各平台的特定格式。这层抽象的价值，在于让设计决策的“意图”不被实现细节污染。

举个例子：一个名为 color.border.focus 的令牌，在 Web 端可能输出为 #3B82F6 的实色边框，在 iOS 端可能需要同时映射为 tintColor 和 borderColor，而在暗色模式下甚至要切为半透明的高亮描边。如果没有令牌层，这些差异会散落在代码各处，靠人工记忆对齐。有了令牌，设计师只需要维护一套源数据，平台差异被封装在转换逻辑里，而不是人的脑子里。

真正难的不是定义，是治理

很多团队兴冲冲搭建了一套令牌，三个月后就成了无人维护的“设计废稿”。问题出在哪儿？不是技术，是治理模型没跟上。

令牌不是一成不变的。产品迭代中，新的组件出现，旧的语义过时，命名冲突开始滋生。如果没有明确的增删改规则、所有权划分和变更传播机制，令牌系统会迅速熵增。有经验的团队会引入“令牌层级”的概念：基础令牌（如色板原始值）、语义令牌（如 color.text.primary）、组件令牌（如 button.background.default）。基础令牌极少变动，语义令牌随品牌调整，组件令牌随组件库迭代。每一层都有不同的变更频率和负责人，这才让系统可维护。

说到底，它是一份契约

设计令牌的本质，不是工具，不是规范文档，而是一份跨职能契约。它让设计师的语言（“主色再暖一点”）和工程师的语言（“hex 值从 #1E40AF 改成 #1E3A8A”）之间，有了一个精确的、可验证的翻译层。这份契约的效力，不取决于它写得多漂亮，而取决于它是否被纳入 CI/CD 流程、是否与组件库自动同步、是否在代码评审中被严肃对待。

没有这份契约，设计系统不过是一堆截图和 Sketch 文件。有了它，设计才真正成为可执行、可追溯、可进化的工程资产。