AI 时代设计系统的变革：从组件生产转向治理与代码源真相

三位设计专家向我讲述了 AI 如何改变我们构建和维护设计系统的方式。这也让我认为，“未来”其实已经正在发生。

你可能读过，甚至写过这样的 LinkedIn 帖子：有人用 Claude 在 20 分钟内构建了一个完整的设计系统。或者用 Gemini 在 15 分钟内完成。或者……你懂的。

这些帖子让我很好奇。我从未构建过完整的设计系统，尽管在我深入钻研 AI 之前，我曾搭建过一些基本元素，那过程既有趣又痛苦。因此，几分钟内就能构建一个完整系统的承诺颇具吸引力。

我的错误在于？混淆了 UI 套件与设计系统，并相信整个过程真的可以在 几分钟内完成。

去年五月在 UXDX 柏林大会上，两场关于设计系统的演讲让我想要更深入地了解 AI 如何在产品团队的日常工作中改变了它们。这种好奇心促使我采访了三位设计专家，并触及了设计系统真正核心所在：Marianne Ashton-Booth，ITV 产品设计负责人；David Sward，西门子首席设计官；以及 Nicolas Chatelain，自由职业高级设计师，专长于设计系统与 Ops。

三位专家，三种不同的方法。Nicolas Chatelain 押注于一种柔韧而不折断的框架，对团队灵活且为 AI 做好准备。David Sward 押注于带有护栏的速度，将 AI 作为工具并保持人在回路中。Marianne Ashton-Booth 押注于人和流程，将设计系统视为一个 产品。

后两位在我与他们交谈时刚刚在 UXDX 做过 演讲，因此以下内容借鉴了他们两个不同时刻的观点：他们在舞台上的发言，以及随后与我一对一交流时告诉我的话。

1. AI 自动化了简单的部分，但困难的部分仍然属于 人类

在她演讲结束后的一对一交流中，Marianne Ashton-Booth 说了一些我觉得特别切中要害的话：“任何人都能在几分钟内生成原型，这很棒。但是，实际可行的东西、接近品牌的东西，或接近我们现有组件的东西，与生成的结果之间可能存在相当大的差距。”

我在七月采访的 Nicolas Chatelain 用另一种方式表达了同样的观点：UI 是设计系统中容易的部分。“最难的部分，决定 DS 能否成功的关键，是治理和采用率。”

他们都不认为组件是问题所在；Nicolas 甚至说，在我们交谈期间，任何人确实都能构建一个套件。重要的是跨团队、跨整个公司的一致性，而这正是设计系统中属于人类的部分。一份发布于 2026 年初的关于设计系统现状的 Zeroheight 报告也指出了同样的方向：59% 的从业者将沟通和社区归功于其系统的采用率。

在台上，Marianne Ashton-Booth 已经指出了真正出问题的地方。她说，当设计系统失效时，“这几乎从来不只是 [设计系统的核心操作] 的问题。组件通常没问题。”出问题的是其下看不见的层面：信任、沟通、优先级排序、关系以及共同的 信念。

2. 瓶颈已从生产速度转移到 审查

“我最大的问题是试图用 AI 来放慢人们的速度，”David Sward 告诉我。确实，AI 加速了许多流程，一直加速到交付环节。

在这里，他指的并不是为了让他们习惯 AI 而故意让团队慢下来，而是将他们限制在大型企业的安保和合规规则之内。有数百个产品依赖他的系统，一个错误可能需要数亿欧元才能修复。他的运营原则是：“不要搞砸事情。”

但事实依然存在：生产力提高了。而且 一旦有了速度，瓶颈就从生产转移到了那些负责审查、验证并保持一切连贯性的人身上。Nicolas Chatelain 和 Marianne Ashton-Booth 也遇到了这种情况。

例如，在 Nicolas Chatelain 为一个国际集团执行任务期间，由 AI 赋能的产品团队开始超越中央设计系统团队，而后者的原始策略是将一切都锁定起来。他的结论是：

“有了 AI，这就是一次彻底的倒退。我们必须变得更加灵活，因为明天人们可能在五分钟内创建一个套件。如果我们变得毫无用处，他们会找到更简单的方法来绕过 我们。”

Figma 的插槽（slots）允许团队将自定义内容放入标准化组件中，这是放宽框架的一种方式。

在 ITV，Marianne Ashton-Booth 的团队采取了另一条路径，依靠设计和工程领域的“设计系统代表”：“他们往往是那些在最终决策等事务中具有更高知名度和参与度的人，也就是大家首选的咨询对象。这意味着事情可以持续推进，而不是仅仅成为一点瓶颈。”她在台上补充说，ITV 并没有把 AI 当作一个独立的话题来处理，而是提出了正确的问题：“这对设计系统意味着什么？我们的流程应该如何演变？”

这三种方法表明，处理瓶颈没有单一的方法：这取决于背景、风险水平，以及 AI 在组织中的发展和接受程度。这正是人类仍然有用的地方：理解拥有设计系统决策权的每个人应在何时、以何种程度介入，以及何时应该放手。

3. 设计系统正在变成某种供 AI 阅读的东西

这部分听起来最像“未来”，但实际上已经是现在：使系统对机器可读。

Nicolas Chatelain 的团队从 2025 年下半年开始关注 V0 和 Lovable 等工具，并得出结论认为采用它们为时尚早。他们选择转而准备系统本身：令牌迁移至 DTCG（Design Tokens Community Group）标准，这是一种用于系统值（如颜色、间距或排版）的共享格式，以便每个工具和每个 AI 代理都能以相同的 方式读取它们。

MCP 服务器（模型上下文协议）让 AI 智能体能够直接查询设计系统，例如查找正确的组件或令牌，而不是靠猜测。在 2026 年 7 月发表的一项实地研究中，Kaelig Deloumeau-Prigent 调查了 21 个开源设计系统：其中 20 个提供了 MCP 服务器（官方或社区构建），但只有 3 个设置了 Figma Code Connect，该功能将 Figma 组件与其实际代码对应物绑定。许多系统允许 AI 读取它们，但将组件与设计重新关联的系统要少得多。

David Sward 的团队在流程的另一端使用 AI：大语言模型 (LLM) 比较团队已实现的内容与设计系统应有的内容，用他的话说，“系统地告诉你需要修复什么。”在他自己的设计系统中，AI 仍然是“一个像其他工具一样的工具”（例如，一个引擎协调数千个图标），而他的更广泛原则依然成立：“你不能把人从循环中移除，然后指望他们在不理解系统状态的情况下退回来操作系统。”

另一方面，Marianne Ashton-Booth 态度坚决：“[设计系统] 的某些部分可能会变得更依赖 AI 生成或自动化。但设计系统不仅仅是那部分，你知道，它还包括人和流程。我认为我们将保留的就是这部分。”

我认为我们正走向的方向：代码作为事实来源

这些见解让我相信这是设计系统的发展方向：代码而非设计文件正在成为其事实来源。我们可能已经处于这个阶段。使用 AI 的设计师似乎越来越少打开 Figma（我就是这种情况），而在那些交付和迭代胜过完善细节的团队中，角色界限的模糊（我在这里讨论过这一点）并没有帮助。

Nicolas Chatelain 说得很清楚：“如今，事实来源必须是代码。绝对如此。”在代码中工作消除了 AI 与生产之间的一层抽象，并且“明天，当这些文档直接存在于代码中时，我们将不再需要 Figma。”他承认自己可能“完全错了”，但仍然发现 Figma 对于探索和微调很有用。我也同意他的观点，即 Figma 并未消亡。但对我来说，它在流程中的地位确实发生了变化。

具体来说，这意味着合并到代码中的任何内容都成为标准，设计文件、文档和 AI 智能体都从中读取信息。因此，每次审查都成为一项治理决策。但正如 Tony Ward 在他最近的文章“代码作为事实来源”中所写，关键在于在每一步都保持“领域专家在循环中。”这留下了真正的问题：在这个新流程中，谁有权决定什么进入事实？

至于我，与这三位专家的会面表明，这个问题没有单一的答案。每个人都根据自己的环境建立了自己的答案，在这种丰富性中，我找到了应对自身挑战的关键。希望你也一样。

感谢 UXDX 提供活动访问权限，并感谢 David Sward、Marianne Ashton-Booth 和 Nicolas Chatelain 抽出时间。

Nicolas Chatelain 的所有引语均译自法语。