Figma 里一个被低估的功能，正在重塑设计系统的“可扩展性思维”

很多人以为 Variants 只是“更高级的组件管理”，但在 Figma Config 的这支视频里，它被揭示成一种更接近工程和 AI 思维的设计方式：减少组合爆炸、提高可发现性、把复杂度前移。这不只是设计技巧，而是一种系统能力。

最反直觉的一点：Variants 不是为了“好看”，而是为了“不崩”

视频一开场，作者几乎带着偏执地说：Variants 是她最喜欢的功能。原因并不是它让画布更整洁，而是它解决了一个设计系统迟早会遇到的灾难性问题——组合爆炸。

想象一个按钮：primary / secondary / tertiary，default / hover / disabled，small / large。如果你用“普通组件”来做，这不是 1 个按钮，而是 18 个组件。更致命的是：使用者并不知道“我还能选什么”。

Variants 的反直觉之处在于：它牺牲了命名的“显性可见”，换来了状态的“即时可发现”。在普通组件里，你必须先知道答案，才能搜到组件；在 Variants 里，答案直接暴露在右侧属性面板。

这点对 AI 从业者其实非常熟悉——这就像 prompt engineering 里，显式参数 vs 隐式上下文的区别。一个系统是否“好用”，不取决于你能做多少事，而取决于使用者能不能一眼看出还能怎么做。

Slash 命名法，其实是一种“低配版 Schema 设计”

视频中花了大量时间讲 slash 命名：Button / Primary / Default / Small。很多设计师把它当成“历史包袱”，但作者点出一个关键事实：slash 的每一段，本质上就是一个属性维度。

当你把这些组件一键 Combine as Variants，Figma 会自动把 slash 拆解成属性：type、state、size。换句话说，你不是在“整理组件”，而是在定义一个 schema。

这件事和 AI 系统设计高度同构：
- Prompt 里混在一起的描述，一定会在后期被拆成结构化参数
- 早期偷懒不建 schema，后期一定靠人肉兜底

作者甚至演示了一个非常工程化的技巧：先复制、再批量 Command + R 重命名，用查找替换来保证所有维度对齐。这不是设计技巧，这是在避免“数据脏”。

如果你做过模型评测或特征工程，你会立刻意识到：Variants 成功的前提，不是 UI，而是命名纪律。

最后那个提醒，像极了对 AI 产品的忠告

视频结尾看似轻描淡写，但其实是全片最重要的一句话：不要把所有 boolean 状态都做成 variants。

比如“是否显示 icon”。理论上你可以做成两个 variants，但作者明确说：不建议。原因只有一个词——膨胀。

一旦 boolean 进入 variants，组合数量会指数级上升。Figma 给出的解决方案是 Component Properties，用属性开关来处理 on/off。

这句话如果翻译成 AI 世界，就是：
- 不是所有变量都该进入模型结构
- 有些东西，应该留给配置层，而不是状态空间

Variants 适合多值、核心维度；Properties 适合开关、附加能力。这是一种成熟系统才会有的分层意识。

总结

这支看似“讲 Figma 按钮”的视频，本质上在教一种复杂系统的构建方法：先定义维度，再控制组合，再把可变性暴露给使用者。对 AI 从业者来说，这不是设计细节，而是每天都会踩的坑。

你的模型接口、你的 prompt 模板、你的工具参数，是否也存在“普通组件式”的混乱？是否只有你自己知道还能怎么改？

一个好的系统，不是功能多，而是让人一眼就知道还能怎么用。下次你觉得某个设计或 AI 工具“用起来不顺”，不妨问一句：它是不是缺了一套像 Variants 这样的结构化表达？

关键词： Figma Variants， 设计系统， 组件化思维， 可扩展性， 系统设计

事实核查备注： 视频来源：Figma Config；发布时间：2023-05-05；作者观点包括：Variants 提高可发现性、slash 命名自动转属性、boolean 状态更适合 Component Properties。