Figma 为什么把设计规则做成变量？它替你卸载了哪一层脑力
从 Figma Variables 的真实界面出发，拆解变量模式、作用域约束与别名链如何实现设计规则的认知卸载，并转成五个设计评审问题。
在搭建和维护一套复杂的数字产品时，几乎所有设计与研发团队都会面临同一种协作梦魇：当产品需要同时支持浅色与深色模式、适配多个子品牌，或者统一调整整套界面的圆角规范时，设计师往往需要在大画布上反复复制成百上千个页面，并在无数图层中人脑检索色值与像素间距。稍微遗漏一个十六进制代码，就会在交付代码时演变成视觉错位与设计走样。
很多人习惯把这种困境归结为「设计师缺乏自律」或「设计系统文档不够健全」。然而在认知科学看来，这本质上是一场人类工作记忆（Working Memory）的系统性过载。要求团队成员在日常设计与评审中，时刻在大脑里维持成百上千条「哪个数值对应哪种状态」的映射规则，不仅违背了人类有限的认知带宽，而且注定会在繁重的业务交付中频频失效。
Figma 在其设计系统工具链中引入的 Variables（变量） 体系，并非只是给图层增加了一层「换色滤镜」。相反，它通过 Collections（变量集合）、Modes（变量模式）、Scope（作用域约束） 与 Aliases（别名链），将设计规则从人类脆弱的工作记忆中彻底剥离出来，构建成一套具备确定性逻辑的外部表征系统。12
这项设计不仅改变了数字界面的搭建方式，更为我们提供了一个绝佳的样本，观察人机交互如何借助系统机制实现「认知卸载」。
模式与集合：把多重情境的映射关系锁在表格里
在传统的设计工具中，如果要表达「同一个页面在白天与黑夜下的不同状态」，设计师唯一的办法就是在画布上平铺两份完全相同的画板，然后手动把右侧画板里的每个图层逐一换成暗色。
这种做法在认知上极其昂贵。首先，设计师需要同时维护两套几何结构完全相同但属性不同的图层树，这导致注意力资源在两个平行空间中不断撕裂；其次，任何关于交互逻辑或文案排版的微调，都必须在两块画板上重复操作两次，极易出现「浅色版改了、深色版遗漏」的状态脱节。
Figma 的
Modes for variables（变量模式）将这种多维度的状态空间压缩进了一个离散的二维表格中。1在变量管理面板中，每一行代表一个抽象的语义决策（例如
surface/primary），而表格的每一列则代表一种运行环境或模式（如 Light 与 Dark）。设计师在画板上搭建界面时，不需要关心具体的 Hex 色值到底是 #FFFFFF 还是 #000000，只需为背景图层绑定 surface/primary 这个语义。当需要预览暗色模式时，用户只需在右侧属性面板或图层容器上一键切换模式，整个界面中的所有子图层便会依据预设表格自动完成全量重绘。1在 Schema 2025 大会上，Figma 进一步将专业版与组织版的模式上限扩展到 10 至 20 个模式，并推出了
Extended collections（继承扩展集合）。3 这意味着大型跨国产品团队可以将核心设计规范（如间距、字号比例）作为父级集合集中发布，而各业务线或独立子品牌只需在下游继承该集合并覆盖自身特定的主题变量。状态矩阵由系统引擎统一托管，人脑不再需要充当搬运色值的临时中继站。
作用域约束：用界面过滤器阻断选项过载与误用
如果系统仅仅允许用户创建变量，随之而来的很可能是灾难性的「选择瘫痪」。一个成熟的设计系统往往拥有数百甚至数千个数值定义：按钮圆角可能是 4px、8px、16px；卡片间距可能是 12px、16px、24px；字号阶梯可能是 14px、16px、20px。如果系统在每个输入框都向用户展示一个包含所有数字变量的全局下拉列表，设计师每一次调整属性都需要在长长的列表中展开视觉搜索，认知负荷将不降反升。
更严重的风险在于语义污染。在界面中，虽然卡片的外边距是
16px，大按钮的圆角恰好也是 16px，但它们属于完全不同的设计语义。如果设计师因为数值相同，误将 spacing/16 绑定到了按钮圆角上，未来当设计系统团队想要收紧全站间距规范时，全站的按钮圆角便会遭遇荒唐的连带变形。Figma 在变量底层植入了
Scope（作用域约束）机制。1在变量编辑面板的 Scope 选项卡中，设计系统的构建者可以精细化地声明某个变量能够出现在哪些属性选择器中。对于颜色变量，可以单独限制其仅能用于 Frame fill（容器填充）、Shape fill（形状填充）、Stroke（描边）或 Text fill（文字填充）；对于数字变量，则可以精确指定其只能应用于 Corner radius（圆角）、Gap（布局间隙）、Padding（内边距）或 Typography（排版属性）。1
作用域约束本质上是一种主动的认知负向约束（Negative Constraint）。它并不依赖设计师在每一次操作时「打起精神仔细辨别」，而是在界面交互层面直接切断了错误联结的发生路径。当你在设置圆角时，所有关于外边距与行高的变量都被直接过滤；出现在眼前候选框中的，只有真正被允许用于圆角的极少数合法选项。
别名链与代码对齐：搭建可追溯的因果树
设计系统领域常说的一句名言是：「变量的价值不仅在于存储数值，更在于命名意图。」
在 Figma 变量体系中，变量之间可以通过
Create alias（创建别名）建立层级引用，形成清晰的因果链条：1- 基础层（Primitive Tokens）：直接存储物理世界中的具体取值，如颜色值
Green/500 = #14AE5C、空间尺寸Space/16 = 16px； - 语义层（Semantic Tokens）：不直接存储数值，而是通过别名指向基础层，表达明确的业务角色，例如
Background/Positive/Default链接到Green/500； - 组件层（Component Tokens）：进一步将语义变量绑定到具体组件实例（如通知横条或警示标签的填充底色）。
通过这种别名链路，系统实现了物理属性与设计意图的分离。设计师在业务画布上只需理解「这里需要一个表达成功或积极反馈的背景」，而无需去记忆调色板里具体用的是哪一种明度的绿。当品牌色发生调整时，团队只需要修改底层基础色，整个设计系统便会沿别名树向下级联更新。
然而，高度抽象的层级往往会带来「黑盒化」的副作用：如果开发者在检查面板里只能看到一个抽象的变量名，却无法得知其最终计算出来的物理像素或色值，调试与联调将变得无从下手。
为了解决这个问题，Figma 在 Dev Mode 中提供了
Variable details（变量详情）功能。开发者点击任何一个变量，系统都会弹出一个完整的链路面板，清清楚楚地展示该变量所在的 Collection、当前 Mode、别名指向的每一步跳转（如 Background/Positive/Default → Green/500 → #14AE5C），以及在 Web/iOS/Android 对应平台的代码语法（Code syntax）。2 这种透明可溯的因果展示，有效弥合了设计抽象与工程实现之间的理解鸿沟。它借用的认知科学原理：认知卸载的效率增益与记忆权衡
Figma 变量之所以能够让设计团队在处理复杂多状态界面时显得游刃有余，其深层依据正是认知心理学对于外部表征（External Representations）与认知卸载（Cognitive Offloading）的规律揭示。
认知卸载是指人类通过物理动作改变任务的信息加工要求，从而降低内部认知负担的行为。例如，我们在做多步心算时拿出纸笔列竖式，或者去超市购物前在手机上写下清单，都属于典型的认知卸载。通过将工作记忆中的临时信息转移到可靠的外部介质中，人类得以腾出珍贵的中央执行资源去从事更高级的推演与规划。
2021 年，认知科学家 Sandra Grinschgl、Hartmut S. Meyerhoff 与 Frank Papenmeier 在《Quarterly Journal of Experimental Psychology》上发表了一项题为《Consequences of cognitive offloading: Boosting performance but diminishing memory》的严谨实验研究。研究者通过三个受控实验（每个实验包含 172 名被试），使用图形图案复制任务（Pattern Copy Task）精确检验了将记忆任务外部化到数字工具后的真实效应。4
实验得出了两项极具启发性的结论：
首先，外部认知卸载能够显著提升即时的任务执行效率。在实验 1 中，允许被试自由且低成本地将信息保存在外部设备上（低访问延迟条件）时，被试完成复杂图案拼装的时间仅为 49.33 秒，显著快于必须依赖大脑内部维持记忆的高访问成本条件（55.06 秒，t(170) = −3.31, p = .001）。这直接验证了：将繁复的属性映射交给机器托管，能够立竿见影地提高生产力。4
然而，该研究同时揭示了一个必须引起重视的权衡（Trade-off）机制：更多的认知卸载往往伴随着对细节信息的更差后续记忆。实验发现，外部卸载频率与被试后续对目标身份及其空间位置绑定的记忆准确率呈显著负相关（相关系数均满足 |r| ≥ .51）。当被试确信外部介质中随时存有完整备份时，大脑就会自发减少对这些细节的编码与加固。只有当被试明确具备后继测试意识并主动维持认知投入时，这种记忆衰减才会被有效抵消。4
将这项认知科学的实证结论映射到数字产品设计中，我们能够清晰看懂 Figma 变量机制的双面性：
一方面，变量、模式与作用域极大地解放了设计师的脑力。团队不再需要凭记忆背诵颜色 Hex 代码和组件间距，也不需要在多模式适配中进行繁琐的手工比对；有限的大脑带宽被完整释放给更高价值的用户体验旅程、信息层级与交互微动效设计。
但另一方面，正如 Grinschgl 等人的实验所指出的，高度自动化的外部系统容易让使用者陷入「无意识点选」的认知陷阱。如果设计团队对变量的组织缺乏敬畏，设计师可能只是机械地套用 Token，而对底层的色彩对比度、层级语义或排版节奏失去敏锐的判断力。这正是为什么 Figma 在提供自动化模式切换的同时，必须在 Dev Mode 与检查器中设置直观的
Variable details、Suggested variables 和 Check designs 校验工具——通过在关键节点重新激活人类的主动核验意识，防止系统完全沦为一个无人理解的冷漠黑盒。23一条完整的因果链
问题：海量状态与多主题适配导致工作记忆枯竭与跨端脱节
在现代复杂产品的设计与迭代中，深浅色切换、多端响应、无障碍高对比度以及多品牌定制已成为刚需。若仅依靠设计师人工记忆规范并在画布上手工刷图，极易发生色值不准、间距杂乱和交付口径分裂，人脑认知负荷达到极限。1
约束：既要保证全局设计规则的高度一致性，又要满足业务探索的敏捷度
设计系统若完全依靠刚性文档约束，会严重拖慢业务设计师的探索效率；若完全放开自由绘制，系统一致性会在数周内迅速瓦解。系统必须在不牺牲设计灵活性的前提下，实现规则的底层对齐。3
设计选择：以变量集合、多模式矩阵、作用域约束与别名链重构设计规范
Figma 将设计属性抽象为 Color、Number、String、Boolean 四种基本变量，用 Collections 进行架构解耦，用 Modes 容纳多维状态矩阵，用 Scope 剪除无关属性选项，并通过别名链路建立从基础物理值到业务语义的因果树。1
失败模式：未设作用域导致选择过载，别名链路断裂导致黑盒化
若变量创建时不加 Scope 限制，全局长列表会导致设计师在选择器中迷失方向，甚至将间距误绑到圆角上；若别名层级设计过于晦涩且缺乏检查追溯面板，设计师与开发者将无法理解变量来源，最终退回硬编码原始值的低效状态。12
后果：规则沉淀为外部确定性模型，人机协作效率与工程一致性大幅跃升
五个可用于设计评审的判断
1. 变量是否设置了严格的作用域约束（Scope）
产品选择：在 Figma 变量设置中，利用
Scope 选项卡明确指定每个变量仅能在特定的属性面板中曝光（如仅限 Corner radius 或仅限 Frame fill）。1用户要判断什么：当设计师选中一个按钮调整圆角时，弹出的下拉菜单里展示的是清晰的几个圆角阶梯，还是充斥着间距、字号和描边粗细的冗长列表。
机制省下的工作：省去了设计师在数百个无关变量中肉眼筛选的耗时，彻底消除了由于手误而将「外边距」误赋给「圆角」的低级系统性污染。
成立条件：变量库作者在搭建初期就清晰规划各物理量（间距、圆角、排版）的专有属性，避免使用通用的模糊数字。
失败信号：所有变量均保持默认的「Show in all supported properties」，导致任何属性输入框点击后都展开数百个全局选项，选错率激增。
2. 语义变量是否建立了清晰且可追溯的别名链（Alias Chain）
用户要判断什么：当前图层绑定的命名是否能够直接解释其设计意图（如「警示文字」），以及当我对底层色调产生疑问时，能否一键追溯到其十六进制原始数值。
机制省下的工作：省去了在全站改版时挨个画板查找替换 Hex 值的体力活，也消除了设计师与工程师关于「为什么这里用这个十六进制」的反复口头确认。
成立条件：语义命名与底层基础调色板严格解耦，且层级控制在 2 至 3 层以内，避免引用链条过于深长导致追溯困难。
失败信号：设计师直接把图层绑定到原始色
Blue/600，一旦暗色模式下需要反转底色，系统无法自动响应；或者别名链条层层嵌套超过 5 层，连作者自己都搞不清底层是谁。3. 多主题与环境差异是否通过模式（Modes）表达
产品选择：利用变量表格中的多列
Modes（如 Light、Dark 或各品牌模式）管理不同环境下的取值映射，画板只需绑定同一套语义变量。1用户要判断什么：评估一个页面在暗色模式或不同品牌下的表现时，是在同一个画板容器上一键切换，还是必须去寻找隔壁那块「拷贝出来的老画板」。
机制省下的工作：省去了在多套平行画板之间手工同步交互与文字修改的双倍工作量，彻底消除了版本分叉（Drift）与遗漏。
成立条件：所有参与多模式渲染的图层均严格使用具备多模式定义的语义变量，不存在私自涂抹的硬编码样式。
失败信号：团队仍然在画布上并排堆放「首页_浅色」与「首页_深色」两套完全相同的画板，一处排版调整导致两边不同步。
4. 变量集合（Collections）是否具备明确的生命周期与访问边界
产品选择：合理划分变量集合，将基础色彩、空间排版与业务专属变量拆分为不同的 Collections，并利用发布权限控制其对外可见性。1
用户要判断什么：新加入团队的设计师打开变量面板时，是否能在 3 秒内识别出该去哪个集合里找常用的颜色或间距。
机制省下的工作：省去了在单一庞大集合中滚动查找的混乱，避免了内部开发中间变量泄漏到业务设计师的常用选择器中。
成立条件：集合按「基础配置」、「主题映射」与「特定业务」清晰分层，临时或内部测试变量及时勾选「Hide from publishing」。
失败信号：把全公司成百上千个变量胡乱堆在一个名为
Collection 1 的大杂烩集合中，既无分组又无说明，最终无人敢动。5. 交付下游时是否提供了原生代码语法与反向建议机制
用户要判断什么：研发工程师在检查面板中查看一个图层时，看到的是标准的代码变量名（如
var(--color-bg-primary)）还是生硬的十六进制散列；若偶发遇到原始值，系统能否反向推荐对应的官方变量。机制省下的工作：省去了研发人员对照设计文档逐个翻译 Token 命名的沟通成本，也省去了设计师因为手误脱离变量后需要人工逐个图层核验的精力。
成立条件：设计团队与前端架构团队提前对齐 Token 命名的命名规范（Naming Convention），确保设计变量与代码库变量名完全一致。
失败信号：Code syntax 为空，研发复制出来的仍是静态颜色值，导致设计系统在落地代码阶段彻底断层。
评审时，把问题落到可观察的行为上
| 评审问题 | 要观察的证据 | 失败信号 |
|---|---|---|
| 变量是否设置了严格的作用域？ | 变量 Scope 面板中仅勾选与该变量语义直接相关的属性（如圆角仅勾选 Corner radius） | 保持默认全选，圆角输入框下拉菜单中赫然出现间距与字号变量 |
| 语义变量是否建立了清晰别名链？ | 业务图层绑定语义名（如 Text/Primary），Variable details 能流畅追溯至底层原始值 | 图层直接硬编码绑定 Neutral/900，或别名嵌套过深导致因果链断裂 |
| 多模式适配是否通过变量模式表达？ | 画板或模块容器上具备 Mode 切换选项，一键完成深浅色或多品牌自动重绘 | 画布上并排复制多个相同结构画板，手工刷色导致两套画板内容经常脱节 |
| 变量集合划分是否有清晰边界？ | Collections 按基础层、语义层与特定业务解耦，临时变量开启 Hide from publishing | 所有变量塞在单个未命名集合中，未发布的试验性变量污染全局选择器 |
| 研发交付是否配置了原生代码语法？ | 变量详情中配置了 Web、iOS、Android 平台的 Code syntax，Dev Mode 正常生成代码令牌 | 代码面板中仅显示 #14AE5C 等静态 Hex 值，设计与代码断开连接 |
在界面设计系统的演进历程中，最值得警惕的误区，就是把「规范的建立」完全押注在「人类的记忆力与自觉性」上。Figma 变量体系的真正价值，在于它践行了一种深刻的认知工程逻辑：它承认人类工作记忆的局限，用模式矩阵锁住多维状态，用作用域过滤决策噪音，用别名链条理顺因果关联。
优秀的设计工具从来不是替人做决定，而是通过高超的选择架构与外部表征，把人脑从机械繁琐的记忆负担中解脱出来，让思考重新回到创造本身的辽阔空间之中。
References
- 1
- 2Variables in Dev Mode - Figma Learn
help.figma.com
- 3
- 4
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.