设计系统已死。设计系统万岁。

每隔十八个月，几乎像气象规律一样准时，就会出现一篇权威文章宣告设计系统的死亡。我读过 Sketch 版本，然后是 Figma 版本，然后是 AI 生成组件库版本，然后是零配置 CSS 框架版本。每一次葬礼都举行得太早。每一次，所指出的问题中都确实有新东西，而诊断中也都有错误。

我构建企业设计系统已有十年。为 Exein 打造的 Tarvos——一个用于物联网安全基础设施的设计系统，它必须让固件工程师读得懂、让董事会理解得了。Vodafone Italia 的组件系统。面向法律、医疗和金融产品的框架。我见过什么能存活下来，什么不能。我要说的是：致悼词的人对病人的判断总是错的，但对病症的诊断几乎总是对的。

不断重复的模式：新工具，老指责

反复出现的指责是：设计系统太僵化、太缓慢、与日常开发的现实脱节。产品团队绕开它们，而不是使用它们。Figma 组件库总是比代码落后三个版本。当一个组件需要更新时，没人知道谁负责它。Notion 文档在写下的那一天是准确的，六个月后就毫无用处了。

全都没错。但这些不是设计系统的问题——它们是治理问题。而治理不会因为换了工具就得到改善。从 Sketch 换到 Figma 并没有解决文档过时的问题。换到 Storybook 也没有解决当产品与设计系统相互矛盾时由谁拍板的问题。换到设计令牌也没有解决品牌变化时由谁更新令牌的问题。

周期性死去的并不是设计系统。而是那种“构建一次就意味着问题已经解决”的幻觉。

周期性死去的并不是设计系统。而是那种“构建一次就意味着问题已经解决”的幻觉。

真正死去的：单体模型

有一样东西确实已经死了，至少对中大型企业团队而言如此。那就是我称之为“至尊魔戒”的模型——一个声称要覆盖整个组织中每一个产品、每一个界面、每一个用例的集中式系统。

问题不是概念上的，而是运营上的。一个集中式团队不可能对每个产品都足够了解，从而为所有产品做出合理的设计系统决策。一个足够通用、能在任何地方使用的系统，最终也通用到在任何地方都不是最优。产品团队提出的每一个例外，都变成了排在队列中的工单，引发挫败感，以及没人记录的非官方分支。

过去三年里我见过效果最好的模型是联邦式的：一小组共享决策构成的核心——字体排印、语义色彩、间距尺度、强制性无障碍模式——再加上一套有文档记录的扩展体系，允许产品团队在遵守核心约定的前提下构建各自的特定组件。不是完全自由。也不是完全控制。而是一个清晰的边界，边界内拥有自主权。

生成式 AI 实际上改变了什么

当初的承诺是：有了 AI，生成组件变得即时，设计系统变得多余。我观察到的现实更有意思，也没那么戏剧化。

生成式 AI 让创建组件变体和原型变得更快。但它没有解决——也不可能解决——上游的问题：决定哪些组件存在、它们做什么、它们推广哪些模式而排除哪些、出错时如何表现、满足哪些无障碍要求。这些是治理决策，需要生成式模型所不具备的组织背景。

我所看到的在没有设计系统的情况下采用生成式 AI 的团队：组件产出速度提高了，但分化也加剧了。每个工程师都生成了自己略有不同的模态框组件。视觉一致性下降。技术债务悄然增长。六个月后，就需要像我这样的人来做一次审计以恢复秩序。

矛盾的是，生成式 AI 让设计系统变得更加必要，而不是更不必要。因为没有一份权威的参考规范，快速生成会迅速产生分化。

2025 年的设计系统：更小的覆盖面，更强的令牌

我今天构建的企业设计系统，在结构上与我在 2018 年构建的不同。不是因为理念变了，而是因为我学会了应该把投入集中在哪里以获得最大回报。

系统的覆盖面更小了。组件更少，但文档更完善、更稳定。我使用的规则是：一个组件只有在至少三个不同的产品或情境中出现时才进入系统。在此之前，它作为本地解决方案存在。这大大减轻了维护负担，并提高了系统中组件的平均质量。

语义令牌是核心。不是 color-blue-500，而是 color-action-primary、color-feedback-error、color-surface-elevated。这些令牌编码的是语义决策，而不是视觉值。当品牌发生变化时——它总是会变——更新的是底层的值，而不是重写系统。我在 Tarvos 中采用了这种方法，深色主题迁移只用了两天的工作量，而不是三周。

文档存在于代码中，而不是 Notion 中。不是因为 Notion 是错误的工具，而是因为与唯一可信来源分离的文档总会过时。组件通过 Storybook 进行文档化，包含参数、用例和无障碍行为。如果组件改变了，文档也随之改变——因为它们是同一个文件。

一个组件只有在至少三个不同的产品中出现时才进入系统。在此之前，它作为本地解决方案存在。

治理：唯一真正重要的事

我把最重要的事留到了最后，因为它读起来最枯燥，而做对它又最关键。设计系统治理要回答四个问题，如果你在开始构建之前没有回答全部四个问题，无论系统的技术质量如何，它都会失败。

谁拥有这个系统？不是一个泛泛的团队——而是一个具体的人，当某个组件在周四晚上 11 点出现严重缺陷时，由他来响应。在我见过设计系统存活最久的组织中，总有一个人拥有明确的所有权，即使工作是分布式的。

当系统与产品需求发生冲突时，如何做决策？你需要一个有文档记录的流程，而不是逐案讨论。答案可以是一个委员会、一个在 GitHub 上进行的异步流程，或者一条简单的规则（“在布局和字体排印上系统总是优先，在特定流程上产品优先”）。行不通的是没有答案。

如何衡量采用情况？如果你不衡量，就不知道系统是在被使用还是被绕过。我使用的指标：组件覆盖率（有多少界面使用系统组件，而非自定义组件），新功能的平均实现时间与系统引入前的基准对比，设计评审中被标记出的视觉分歧数量。这些指标并不完美，但总比没有好。

如何在不破坏产品的情况下更新系统？将语义化版本控制应用于组件库不仅仅是一个技术细节——它是对产品团队的一个承诺：他们可以以受控的方式升级。如果每次更新都有可能在毫无预警的情况下破坏某些东西，系统就会因恐惧而被冻结，然后被抛弃。

未来的方向

我看到即将到来的下一个变化，是使用 AI 进行自动一致性检查：分析生产环境截图并识别组件在哪些地方偏离了设计系统的工具，无需人工审查。技术上这已经可行——一些团队正在试验基于视觉模型的方法和自动化视觉测试。它还不是行业标准，但终将成为标准。

我看到的另一个趋势，是将设计决策直接编码进令牌，而不仅仅是值。携带使用情境、对比度要求、无障碍约束等元数据的令牌。一个令牌不只是一种颜色——它是带着自身规则的一种颜色。这让系统更智能，也更难因疏忽而被误用。

设计系统没有死。它在进化，一如既往。而那些过早宣布葬礼的人，如今发现自己正与一些团队共事——这些团队丢失了三年的视觉一致性，被迫从零开始重建他们为追逐潮流而拆除的东西。