[控场AI]
· 5 分钟阅读· 2,867 字

Supernova MCP:让每个AI智能体读懂你的设计系统

Supernova MCP:让每个AI智能体读懂你的设计系统

Supernova通过MCP协议将设计系统转化为AI智能体可读的结构化上下文,解决AI工具不了解团队规范的根本问题。

产品团队在日常使用Cursor、Claude、ChatGPT等AI工具时面临一个隐性痛点:这些智能体不了解团队的设计系统,往往硬编码颜色或从零重建已有组件。Supernova的MCP方案通过标准化的Model Context Protocol协议,构建了「编辑/消费」双层架构——面向设计团队的Editor MCP支持写入操作,面向其他团队的只读MCP Server则按团队过滤数据,确保每个智能体只接收与自己相关的精准上下文。连接后,AI工具会直接调用现成的Token和组件,并在发布前征求人类确认。配套的可观测面板还能追踪每次工具调用与各团队的使用情况,将设计系统从一份给人看的文档升级为给智能体喂养的结构化上下文层。

当AI智能体遇上设计系统:一个被忽视的断点

如今的产品团队已经离不开各类AI助手——Figma里的智能体、Cursor、Claude、ChatGPT,开发和设计流程中它们无处不在。但有一个尴尬的现实:这些智能体根本不了解你的设计系统。于是它们只能靠猜,然后把事情做错——硬编码的颜色、从零手搓的按钮组件,完全脱离团队既定的规范。

Supernova 推出的 MCP(Model Context Protocol)方案正是针对这个痛点。它的核心思路是打通设计系统与AI智能体之间的双向通道:智能体既能在 Supernova 中替你干活,也能读取你的设计系统来进行构建。这意味着AI不再是脱缰的野马,而是一个被喂饱了规范上下文的协作者。

MCP(Model Context Protocol)是由 Anthropic 于2024年底提出并开源的一套标准协议,旨在解决AI大模型与外部工具、数据源之间的集成问题。在此之前,每个AI应用若要接入外部系统,都需要编写定制化的连接代码,碎片化严重。MCP 提供了一套统一的「客户端-服务器」通信规范:AI应用(客户端)可以通过标准化接口发现并调用任意 MCP Server 暴露的工具和资源,而无需关心底层实现细节。这一协议已被 Cursor、Claude、Windsurf 等主流AI开发工具迅速采纳,正在成为AI工具链互联互通的事实标准。Supernova 将设计系统包装为 MCP Server,正是借助了这一协议的生态红利——任何支持 MCP 的AI客户端都能直接接入,无需为每个工具单独开发集成。

两种MCP:编辑与消费的分工

Supernova 的 MCP 架构分成两层,逻辑清晰。

Editor MCP 面向设计系统团队。 智能体几乎可以执行你在 Supernova 里能做的所有操作——更新组件文档、创建 token、撰写页面等。它是写入侧的入口,权限更高。

MCP Server 面向其他所有人。 每一个 server 都是设计系统的只读切片,针对某一个团队做了过滤。换句话说,React 团队看到的和设计团队看到的内容各不相同,各取所需。

这种「编辑/消费」分离的设计很关键:它避免了把整个系统一股脑塞给每个智能体,既保证了安全边界,也降低了噪音。

在侧边栏打开概览,在MCP卡片上点击连接

第一步与第二步:连接智能体,让它干活

连接过程被设计得相当轻量。在侧边栏打开 overview,找到 MCP 卡片点击 connect,就能把它安装到 Cursor、复制给 Claude Code,或者把 MCP URL 复制给 Codex、ChatGPT、Figma。几乎覆盖了当前主流的AI工具链。

连接之后,智能体就能真正参与工作流。视频给出了两个具体场景:

  • 设计师在 Figma 里为按钮新增了一个关键变体,直接在画框旁打开智能体并提及 Supernova,智能体便通过 Editor MCP 更新了按钮的文档。
  • 工程师让 Claude Code 添加一个间距 token 并记录下来,智能体创建了 token、撰写了对应页面,并在任何内容发布前先征求确认。

「发布前先询问」这个细节值得点名——它把人类留在了关键决策的闭环里,而不是让AI直接改动生产内容。

第三步:按团队过滤,创建专属MCP Server

所有设计系统数据都汇入 Supernova,再由此派生出各个 MCP Server。创建流程是:在侧边栏打开 MCP servers 点击加号,从设计系统出发,命名为比如「React Team」,然后对数据做过滤。

创建MCP服务器,为每个团队定制

过滤的粒度可以很细。以文档页面为例,可以切换到 manual 模式,只保留 React 团队真正需要的页面。这样做的直接收益是:智能体接收到的噪音更少,给出的答案更准。这其实暗合了当下大模型应用的一条经验——上下文不是越多越好,精准、相关的上下文才能换来高质量的输出。

在文档页面切换到手动模式,只保留React团队需要的页面

第四步与第五步:分发连接与使用可见

Server 创建好后,分发方式也很灵活。既可以从 distribution 分享专属链接,也可以给所有人同一个地址 mcp.supernova.io/mcp,让大家自己挑选对应的 server。当有人用这个地址连接时,Supernova 会询问要共享什么,用户选择 Consumer MCP、挑选 React Team server 并批准即可,无需任何特殊链接。

无需特殊链接,团队成员自行选择对应的MCP服务器

效果对比相当直观:没有 MCP 时,智能体只能硬猜颜色、从头造一个按钮;接入 MCP 后,智能体会直接使用 color primary、导入你现成的按钮组件。设计系统的一致性由此得到保障。

最后是可观测性。在侧边栏打开 MCP 的监控面板,可以看到每一次工具调用、调用者是谁,以及哪些 MCP Server 被团队使用得最频繁。这为设计系统团队提供了宝贵的使用数据,帮助判断哪些资源真正被需要。

小结:设计系统正在成为AI的上下文层

Supernova MCP 的价值不在于某个炫酷功能,而在于它重新定义了设计系统在AI时代的角色——从一份给人看的规范文档,升级为给智能体喂养的结构化上下文层。编辑/消费双层架构、按团队过滤、发布前确认、使用可观测,这几个设计组合在一起,构成了一套务实的落地方案。

对于已经被各类AI工具包围的产品团队来说,这解决的是一个真实的协作摩擦:让AI理解「我们的规范」,而不是「某种通用做法」。随着 MCP 协议在各类工具中普及,设计系统与AI智能体的这种绑定方式,很可能成为团队标配。

「上下文层(Context Layer)」这一概念在大模型应用架构中正变得日益重要。大语言模型本身并不存储组织特有的知识,它们依赖运行时注入的上下文来理解「当前这个团队是谁、遵循什么规范」。设计系统天然是这类结构化私有知识的载体——它包含了命名规范、Token 体系、组件用法和设计决策背后的逻辑。将其转化为机器可读的上下文,与RAG(检索增强生成)技术在企业知识库领域的应用逻辑一脉相承:与其依赖模型的泛化能力猜测正确做法,不如在推理时精准注入相关规范。这也解释了为何「按团队过滤」如此关键——向模型输入冗余上下文不仅增加推理成本,还会稀释相关信号、降低输出质量。

分享:

相关推荐