Figma 在东京抛出一个狠判断：设计系统不再只是给设计师用的

在东京这场 Schema 回顾里，Figma 做了一件反直觉的事：几乎没把重心放在“设计更好看”，而是反复谈“规模、机器学习、非设计师”。这不是一场功能发布会，而是一次对设计系统未来的摊牌。

最反直觉的开场：设计系统的最大敌人不是混乱，而是规模

如果你以为设计系统的核心问题是“不统一”，那这场 Schema Tokyo 回顾一上来就会打脸你。Figma 的判断很直接：当设计系统真的跑在几十、上百个业务上时，最大的敌人不是规范没写清楚，而是规模本身。

谷在回顾 Schema 历史时反复强调一个背景变化：2022 年东京那场 Schema，大家还在讨论“要不要做设计系统”；到了 2025 年旧金山，讨论已经变成“一个巨大到无法完全理解的系统，怎么还能继续演进”。这不是态度转变，而是现实逼出来的。

真正的矛盾在于：一边是 scale——统一、复用、效率；另一边是 craft——细节、语境、设计判断。Figma 罕见地承认：如果你只追求 scale，设计系统会迅速变成僵硬的模板库；但如果你死守 craft，系统根本活不过第二个业务线。Schema 的主题，本质就是如何在这条钢丝上走下去。

来自一线的真实样本：当一个设计系统要服务所有业务

这也是为什么他们请来了 CyberAgent 的 UI 设计负责人本田。原因很简单：Ameba 的设计系统「Spindle」不是实验品，而是一个被多个业务长期“消耗”的系统。

本田讲到一个细节很关键：Spindle 不是给某个产品服务，而是横跨多个事业部、不同节奏、不同成熟度的团队。这意味着组件、变量、指南都必须在“共通性”和“可变性”之间不断妥协。

听起来很抽象，但你只要想象一个场景就懂了：同一个按钮组件，在 A 业务是强品牌色，在 B 业务却必须弱化；今天是暗色模式优先，明天又要支持临时活动主题。过去的做法，往往是复制、分叉、再也合不回来。本田的分享，其实是在回答一个所有大厂都会遇到的问题：当设计系统被真正用起来，它一定会被‘滥用’，你准备好了吗？

Variables 和 Extended Collections：第一次正面承认“继承关系”

Schema Tokyo 最有信息量的部分，毫无疑问是 Variables 和 Extended Collections。

Figma 很坦诚地回顾了痛点：在多品牌、多模式场景下，变量数量会爆炸；而一旦爆炸，维护成本就会反过来拖垮系统。Extended Collections 的思路，其实非常工程化——明确“父子关系”。

通过父集合定义基础主题，子集合继承大部分变量，只在必要时 override。这个机制看似简单，但意义非常大：它第一次在工具层面承认了“设计系统不是平铺的，而是有层级、有继承的”。

更重要的是，这不是理论。现场 Demo 展示了在真实项目中如何只改动少量变量，就完成品牌差异化。本田在对话中点出一个现实好处：以前不敢改的东西，现在敢改了，因为影响范围是可控的。这种“心理安全感”，对长期维护系统的人来说，价值不亚于任何效率提升。

Slot 的真正野心：让组件不再被 Detach 破坏

另一个被低估的新功能是 Slot。表面看，它解决的是一个老问题：不 Detach，也能替换组件内部内容。

但如果你把它放进设计系统的语境里，就会发现这是一次理念升级。过去，组件一旦需要灵活，就只能 Detach；而 Detach 的代价，是你彻底脱离了系统的演进。这是一个设计师和系统之间的零和博弈。

Slot 提供的是第三条路：在不破坏结构的前提下，开放“可替换位”。这让组件第一次具备了类似“布局组件”的潜力，而不是静态 UI 零件。对大规模系统来说，这意味着什么？意味着你终于可以在保证一致性的同时，允许变化存在。Schema 把这个功能放在核心位置，本身就说明 Figma 已经不再把‘完全控制’当成目标。

机器学习真正落地的地方：设计检查而不是生成

如果你是 AI 从业者，最值得反复咀嚼的，其实是 Design Check。

它并不炫技：不生成 UI，不帮你“设计更好”。它做的是检测——变量是否正确使用、对比度是否合规，并给出建议。但背后用的是学习型模型，而不是写死的规则。

这透露出一个非常清醒的判断：在高复杂度的设计系统里，AI 最先发挥价值的地方不是创造，而是守门。它像一个永远不疲劳的系统维护者，持续发现人类在规模下必然犯的错误。

这和当前很多 AI 产品形成鲜明对比。Figma 选择把机器学习用在“减少系统熵增”上，而不是追求表面惊艳。这可能不性感，但对真实世界的团队来说，这是最有用的落点。

总结

Schema Tokyo 传递的核心信号很明确：设计系统已经进入“规模化维护”的时代。工具的价值，不再是让设计更快，而是让系统在复杂环境中不崩塌。

对 AI 和设计系统从业者来说，这里有三个直接 takeaway：第一，优先用 AI 降低维护成本，而不是追求生成；第二，承认继承、层级和例外是系统的一部分；第三，真正成熟的系统，一定是为非设计师、为长期演进而设计的。

如果你正在构建或维护一个设计系统，也许该问的不是“我们要不要加更多规范”，而是：当规模再翻一倍，这套系统还能活下来吗？

关键词： Figma， 设计系统， Schema， 机器学习， Variables

事实核查备注： 需要核查：Schema Tokyo 举办年份（2022）、Schema San Francisco 举办年份（2025）、Figma 内部性能改进的具体数值、Design Check 是否明确使用学习型模型、Extended Collections 与 Variables 的正式功能名称