Figma Token 入门：别再把变量当颜色库了
上海/UI设计师/114天前/448浏览
版权
Figma Token 入门：别再把变量当颜色库了
写在前面
这篇文章不是 Figma 官方教程，也不是某个项目的完整复盘。
它来自我读研期间，跟随导师田飞老师参与真实设计系统项目时的一次学习整理。为了保护项目信息，文中不会出现真实项目名称，也不会展示具体业务截图。我会统一用“某工业运维平台”“旧模板”“业务系统”等说法代替。
以前我也以为 Figma Token 只是“给颜色起名字”。后来在真实项目里才发现，Token 真正解决的不是颜色命名，而是多人协作、主题切换、明暗模式、组件复用和开发交付中的一致性问题。
如果你做过多人协作的 Figma 项目，大概率会遇到这些崩溃瞬间：
- 明明大家用的是同一套组件，最后页面颜色却不一样；
- 明明变量名字看起来一样，组件上还是显示问号；
- 明明只是想把主色从蓝色换成绿色，结果发现每个页面都要手动改一遍；
- 明明设计稿看起来还行，一切到暗色模式，文字、按钮、背景全都不对劲；
- 明明用了组件库，最后却发现组件来自不同模板，母组件也找不到了。
这些问题表面看像是“颜色没设好”，但真正的问题通常是：
团队没有理解 Token 到底在设计系统里扮演什么角色。
01｜Token 不是颜色库，而是设计系统的调用规则
很多人刚接触 Figma 变量时，会把它理解成“颜色库”。
比如：
blue-500 gray-100 green-600 primary-500
看起来确实像是在给颜色起名字。
但如果只停留在这个层面，Token 很快就会失去意义。因为真实项目里，设计师关心的不是“这个颜色叫什么”，而是：
- 这个颜色能不能被统一维护；
- 这个颜色能不能适配 light / dark；
- 这个颜色能不能跟组件库对应；
- 这个颜色能不能交给开发；
- 以后换主题时，它会不会自动变化。
所以我现在更愿意把 Token 理解成：
Token 不是一张颜色表，而是一套设计系统的调用规则。
它规定了团队成员在页面里应该使用什么、不应该使用什么，也规定了设计稿和代码之间如何保持一致。
02｜一个更好理解的模型：三层颜色体系
在真实项目中，我学到最有用的一个理解方式，是把颜色体系拆成三层：
第一层：原料色 第二层：语义色 第三层：UI Token
这三层解决的问题完全不一样。
第一层：原料色，像一个“颜料盒”
原料色就是最底层的颜色仓库。
例如：
slate-50 slate-100 slate-200 green-50 green-100 green-200 energy-50 energy-100 energy-200
它们的作用是定义“这个系统里有哪些颜料”。
你可以把它理解成画画前准备好的颜料盒：红色有哪些深浅，绿色有哪些深浅，灰色有哪些深浅。
但注意：
原料色不应该直接拿来画页面。
因为它只是原料，不知道自己要用在什么地方。它不知道自己是按钮、背景、文字，还是边框；也不知道当前页面是亮色模式还是暗色模式。
如果页面里直接使用原料色，后面一旦做主题切换，就会非常难维护。
第二层：语义色，表达“角色”
语义色不是具体颜色，而是角色。
比如：
primary secondary success warning error neutral
很多人容易误解 primary。
以前我也会下意识觉得 primary 就是蓝色。
但实际上 primary 不是蓝色，也不是绿色。
primary 的意思是：
这个地方承担的是系统里的主要强调角色。
所以今天 primary 可以映射蓝色，明天可以映射绿色，另一个主题里也可以映射成紫色。
真正重要的不是它最后是什么颜色，而是它在系统里的角色没有变。
这也是为什么在 B 端、多主题、多客户系统中，不能把颜色写死。
第三层：UI Token，才是页面真正应该调用的颜色
到了第三层，才是真正给页面和组件使用的颜色。
例如：
ui-bg ui-text ui-border ui-primary ui-warning ui-success
UI Token 关心的是具体使用场景。
它回答的是：
- 这个页面背景应该用什么；
- 正文文字应该用什么；
- 主按钮应该用什么；
- 边框应该用什么；
- 警告状态应该用什么；
- 暗色模式下应该怎么变。
所以在设计稿里，真正应该直接使用的是第三层 UI Token，而不是第一层原料色，也不是第二层语义色。
可以简单理解成：
原料色：系统有哪些颜色 语义色：这些颜色分别承担什么角色 UI Token：页面和组件最终调用什么
03｜为什么不要直接用 primary？
很多人会觉得：既然 primary 是主色，那我直接用 primary 不就好了？
问题在于：primary 仍然只是语义层，它不一定知道具体场景。
比如：primary-600
在亮色背景上可能很清楚。
但如果页面切到暗色模式，它还是 primary-600，就可能显得太暗，按钮不够亮，文字不够清楚。
所以真正应该使用的是：ui-primary
因为 ui-primary 可以在不同模式下映射到不同色阶。
例如：
light 模式： ui-primary = primary-600
dark 模式： ui-primary = primary-300
页面不需要知道最后是 600 还是 300。页面只需要知道：
这里应该使用主强调色。
具体亮一点还是暗一点，应该交给 Token 映射关系来处理。
这就是 Token 的价值：它把“视觉判断”提前沉淀进系统里，而不是让每个设计师在每个页面里重新判断一次。
04｜Light / Dark 不是简单反色
暗色模式最容易被误解成“把颜色反过来”。
但真实项目里，暗色模式不是反色，而是重新映射。
比如同一个文字 Token：
light 模式： ui-text = neutral-900 dark 模式： ui-text = neutral-100
它表达的不是“900 变成 100”这么简单，而是：
在当前背景下，这段文字应该保持足够清晰。
所以 light / dark 的核心不是颜色值对调，而是视觉关系保持稳定。
背景变了，文字要重新映射；
背景变了，边框要重新映射；
背景变了，主按钮也要重新映射。
如果页面里直接写死某个颜色，暗色模式就很容易崩。
05｜变量命名不要绑死当前色阶
真实维护设计系统时，还有一个很容易踩坑的点：变量名不要和当前色阶绑得太死。
比如你有一个文字变量：
text-900-100
它的意思可能是：
亮色模式用 900 暗色模式用 100
这听起来很直观，但问题是：如果后面你发现亮色模式用 800 更舒服，暗色模式用 200 更清楚，怎么办？
变量值可以改，但变量名也要改吗？
如果变量名一改，组件、规范、开发文档都会受到影响。
所以更好的命名方式是表达“强度”，而不是表达“具体色阶”。
例如：
ui-text-degree90 = 强强调文字 ui-text-degree60 = 普通正文文字 ui-bg-degree10 = 很轻的背景 ui-bg-degree40 = 更明显的背景层级
这样做的好处是，即使未来具体映射从 900 改成 800，这个 Token 的含义仍然成立。
因为它表达的是“强调程度”，而不是永远绑定某一个色阶。
06｜为什么“同名变量”也会失效？
真实项目里还遇到过一个很反直觉的问题：
明明变量名字还在，为什么组件上仍然显示问号？
后来才意识到：Figma 变量绑定看的不是名字，而是变量 ID。
也就是说：
同名变量 ≠ 同一个变量 同值变量 ≠ 同一个变量 同层级变量 ≠ 同一个变量
如果一个变量被删除了，再创建一个名字完全一样的新变量，Figma 也不会自动把旧组件重新接回来。
因为旧组件绑定的是原来的变量 ID。
新变量虽然名字一样，但它是一个新的对象。
这对组件库治理非常重要。
所以变量管理不能只看命名表，还要关注：
- 这个变量是否被删除过；
- 这个变量是否跨文件复制过；
- 这个变量是否来自旧模板；
- 这个变量是否仍然保持原来的引用关系；
- 组件是否真的绑定到了当前库里的变量。
设计系统里的变量不是普通文字标签，而是一套对象关系。
07｜组件库也不是素材库
Token 的问题经常和组件库问题一起出现。
很多人会把组件库理解成“方便复制东西的素材库”。
但在真实项目里，组件库更像是设计和开发之间的协议。
比如：
弹窗不是一个矩形加遮罩，而是 Dialog 按钮不是圆角矩形加文字，而是 Button 侧栏不是几个标签拼起来，而是 Navigation 复选框不是一个小方块，而是 Checkbox 标签不是一个色块，而是 Badge
如果设计师随手画一个“看起来像弹窗”的东西，开发并不知道它应该对应哪个代码组件。
但如果设计稿里使用的是标准 Dialog 组件，开发就能理解它应该调用什么。
所以组件库的价值不是“少画几步”，而是让设计稿和代码之间少一层翻译成本。
08｜多人协作时，最危险的是“看起来差不多”
在多人协作中，最麻烦的不是完全错误，而是“看起来差不多”。
比如：
- 有人用原料色；
- 有人用语义色；
- 有人用 UI Token；
- 有人从旧模板复制组件；
- 有人自己手动画一个类似组件；
- 有人把组件分离实例后又重新组合；
- 有人修改了底层变量但没意识到会影响全局。
最后页面看起来可能都差不多，但底层完全不可控。
一旦统一换色、切暗色模式、整理组件库、交付开发，这些问题都会爆出来。
所以设计系统真正要解决的，不只是“统一视觉”，而是：
统一团队的使用规则。
哪些东西可以用，哪些东西不该暴露；
哪些组件可以改，哪些组件不能随便动；
哪些变量可以发布，哪些变量应该隐藏；
哪些颜色是原料，哪些颜色才是页面调用入口。
这些才是设计系统治理的核心。
09｜不该用的变量，要隐藏，不要全暴露
还有一个非常容易被忽略的点：
设计系统不是把所有变量都展示给团队，而是只把该用的变量展示出来。
如果你把所有层级都暴露在颜色面板里，团队成员打开 Figma 时会看到一大堆选择：
原料色 语义色 UI Token 旧模板色 临时颜色 历史遗留变量
这时候大家就很容易凭感觉选色。
有人会选 green-500；
有人会选 primary-500；
有人会选 ui-primary；
有人甚至会选到旧模板里的同名颜色。
页面看起来可能差不多，但底层引用已经乱了。
所以更合理的做法是：
第一层：原料色 保留给设计系统维护者使用，普通页面设计时不要直接选。 第二层：语义色 用于主题映射和系统配置，不建议直接暴露给所有协作者。 第三层：UI Token 才是页面和组件真正应该使用的颜色。
也就是说，发布组件库或变量库时，可以把不该直接使用的变量隐藏起来，让协作者打开颜色面板时，优先看到：
ui-bg ui-text ui-border ui-primary ui-success ui-warning ui-error
而不是一整套底层颜料盒。
这件事听起来像是“小操作”，但在多人协作里非常关键。
因为设计系统治理的第一步，不是让大家知道所有东西在哪里，而是让大家
少看到不该用的东西
。
好的变量系统，不是选项越多越专业，而是让正确选项更容易被选到。
这里要注意：隐藏不等于删除。
如果变量已经被组件引用，不要随便删。删除变量可能导致历史组件引用断裂，之后即使新建一个同名变量，也不一定能自动恢复。更安全的做法是：保留变量对象，但通过发布范围、可见性、命名和说明，把它从普通协作者的日常选择里收起来。
10｜我的使用建议
如果你刚开始整理 Figma Token，可以先记住这几条：
1. 不要在页面里直接用 HEX
HEX 是最难维护的。
一旦页面多了，就无法统一换肤和批量修改。
2. 不要直接用原料色
例如：
green-500 blue-600 gray-100
这些颜色只适合待在底层颜料盒里，不适合直接进入页面。
3. 不要以为 primary 就是最终答案
primary 是角色，不是最终调用层。
页面更应该使用 ui-primary。
4. UI Token 才是页面和组件真正该调用的入口
例如：
ui-bg ui-text ui-primary ui-border ui-success ui-warning
5. 命名尽量表达语义，而不是绑定死色阶
不要只写：
900-100
可以考虑写成：
degree90 degree60 degree10
让它保留未来调整空间。
6. 删除变量要非常谨慎
如果变量已经被组件引用，不要随手删除。
删除后再建同名变量，不一定能恢复旧绑定。
7. 组件库不要当素材库用
先判断它对应哪个标准组件，再决定是否复制、分离或二次封装。
11｜总结：Token 是协作契约，不是颜色名称
以前我会觉得，Figma Token 是一个偏工具层的小知识点。
但真实项目做下来才发现，Token 背后其实是一种设计系统思维：
- 不要一个一个改对象，要改对象背后的定义；
- 不要让每个人凭感觉选颜色，要让团队共享同一套调用规则；
- 不要只追求页面好看，要保证后续能维护、能换肤、能交付；
- 不要把组件库当素材库，而要把它当成设计与代码之间的协议。
所以我现在对 Token 的理解是：
Token 是设计系统里的协作契约。
它不是为了让颜色名字更好看，而是为了让设计在多人协作、主题切换、暗色模式和开发交付中不崩。
写在最后
这篇是我的研究生 UI 学习笔记之一。
读研期间，我跟随导师田飞老师参与真实设计系统项目，也在一次次项目问题里重新理解 Figma、B 端设计、组件库和设计系统。
后续我会继续把这些学习内容整理出来：不写成很玄的理论，也不写成只适合项目内部看的复盘，而是尽量整理成设计同学也能看懂、能复用、能迁移到自己项目里的经验笔记。
如果你也在学 Figma、B 端设计、组件库或设计系统，希望这篇文章能帮你少踩一点坑。
4
举报
声明
收藏
分享
相关推荐
评论你的想法~
表情
喜欢TA的作品吗？喜欢就快来夸夸TA吧！
推荐素材
你可能喜欢
相关收藏夹
登录注册
4登录即可同步推荐记录哦
收藏登录即可加入我的收藏
评论登录即可评论想法
分享分享