Figma变量不是设计细节，而是AI产品规模化的隐形底座

大多数人把Figma变量当成“省点时间的小技巧”，但这支Config视频透露了一个更狠的事实：变量真正改变的，是设计系统如何被规模化、被自动化、被AI接管。从颜色到布尔值，从夜间模式到语义命名，这是一套为未来产品而生的设计语言。

最反直觉的一点：变量不是为了“复用”，而是为了“切换现实”

视频一上来就做了一件很反直觉的事：讲了半天变量，却一句代码都没写。原因很简单——在Figma里，变量首先不是工程概念，而是“状态建模”。

当作者创建第一个Color Collection时，他没有急着填值，而是先做了两件事：一是重命名集合（比如直接叫“Color”），二是强调“先在画布上把变量关系想清楚”。这背后的逻辑很重要：变量不是用来存颜色的，而是用来描述世界会如何变化的。

最典型的例子是Day / Night模式。通过给同一组颜色加上不同Mode，设计稿本身就具备了“环境感知能力”。你不是在画两个界面，而是在定义一个系统在不同现实下的表现方式。这对AI产品尤其关键——当界面需要根据上下文、偏好、甚至模型状态自动切换时，变量就是接口。

语义命名这件小事，决定了系统能不能被AI理解

视频里有一段很容易被忽略，但信息密度极高：颜色命名的分裂——Semantic vs Decorative。

一边是“background-page”“text-secondary”这种完全不描述颜色长相、只描述用途的语义变量；另一边是“decorative-yellow”“decorative-purple”这种明确告诉你它长什么样的装饰变量。作者非常明确地说：这是一种你必须适应的分裂。

这对AI从业者来说是个重要信号。语义变量，本质上是给机器看的。它们让系统知道：这个颜色为什么存在，而不是它是什么值。未来不管是Design Token自动生成、还是让模型根据上下文替换主题，语义命名都是前提条件。

反过来，装饰性变量是给人看的，是探索和表达用的。把这两类混在一起，短期看省事，长期一定翻车。视频没有说“最佳实践”，但通过示例已经把坑摆在你面前了。

真正拉开差距的，是Boolean和Number变量

如果说颜色变量解决的是“看起来对不对”，那Boolean和Number变量解决的就是“系统能不能自己动起来”。

作者用Boolean变量做了两件事：Show Image、Show Description。这看起来像是组件显隐控制，但关键在于——它们被放进了一个独立的Collection，并且天然支持Mode。这意味着什么？意味着同一个组件，可以在不同场景下自动呈现不同信息密度。

再往后，Number变量接管了圆角、间距、Auto Layout gap。配合语义命名（tight / default / spacious），你已经不是在调UI，而是在定义产品的空间策略。当作者切换Mode，按钮和卡片同步变化的那一刻，其实已经非常接近“参数化界面生成”。

这一步，对AI产品尤其致命——因为一旦界面是参数化的，就有可能被模型驱动，而不是人手改稿。

总结

这支视频表面上教你“创建第一个变量”，实际上在示范一件更重要的事：如何把设计从“静态结果”，升级为“可被系统理解的规则集”。

如果你在做AI产品，今天就值得回去检查三件事：你的设计命名是否语义化？你的界面是否能用布尔和数值描述状态？你的设计系统，是否已经为“自动切换”而不是“人工维护”做好准备？

一个值得思考的问题是：当模型开始直接生成或修改界面时，它会更偏爱哪种设计系统——堆满颜色值的，还是充满语义变量的？答案，可能决定你产品的下一个三年。

关键词： Figma变量， 设计系统， 语义化设计， AI产品设计， Design Tokens

事实核查备注： 需要核查：视频发布时间为2024-02-05；视频标题与频道名称；Figma变量支持的四种类型（Color、Boolean、Number、String）；Day/Night模式示例是否均来自视频原示范