你问四位工程师“禁用文字该用什么灰”，可能得到四个答案。有人翻旧页面吸取颜色，有人凭经验选一个，还有人直接在代码里写下新的色值。页面看起来只差一点，积累久了，设计师却要逐页检查、反复返工。设计负责人 Suresh Kumar Veeramachaneni 做的事，是把这些零散决定收进一套设计系统，再为它接上 MCP server，让工程师、设计师和 AI 代理都有机会直接查询同一套规则。
设计系统（Design system）是一套可复用组件、视觉规则和使用原则。组件库负责提供按钮、表格等现成实现，设计系统还应回答“什么情况下该怎么用”。MCP（Model Context Protocol）则是一种让 AI 应用以统一方式连接外部工具和数据源的开放协议。在这里，它相当于给设计系统增加一个机器可查询的入口。
不过，现有供稿在介绍 MCP 的具体实现前就截断了。以下架构、问题与效果均来自作者发表于 Muzli／Medium 的经验文章，尚无代码仓库、团队数据或第三方材料交叉验证。
先让规则只有一个答案
作者负责的是一个数据密集型 B2B SaaS 产品。多个工程团队同时开发，界面里充满表格、指标、图表和密集控件。按他的描述，过去没有集中式设计系统：同一种颜色曾在代码库里出现六七种定义；部分“fit-and-finish”检查，也就是上线前逐项核对视觉细节，会持续数天。这些数字没有样本量和前后对照，只能视为作者对团队经历的描述。
他的第一步不是 MCP，而是先整理规则。颜色、间距、字体、圆角和阴影都被编码成带命名空间前缀的 CSS custom properties——可以理解为代码里的可复用变量——并集中在一个文件中，作为 single source of truth，即唯一权威来源。
这里用到的核心概念是 Design token。它不直接写“这个灰色的十六进制值是多少”，而是给设计决定起一个有含义的名字，例如“disabled-text”。主题可以换，具体色值可以变，但组件仍引用同一个名字。
作者还写了 audit script，也就是自动检查脚本。它扫描组件，标记直接写死的十六进制颜色和未经封装的 utility class。这样，规范不再只是一份提醒人们自觉遵守的文档，而成为代码能执行的检查关卡。
组件不是黑盒，也不一次推倒重来
这套组件库没有打包成 npm package。它采用类似 shadcn/ui 的 registry model：使用方从登记库拉取组件源文件，再直接引用 token CSS。工程师能阅读和扩展组件，而不是只面对一个看不见内部结构的黑盒。
Registry 又按 atoms、molecules、organisms、layouts 分层。可以把它理解为从零件、小组件、完整功能区到页面布局逐级组合。依赖只能向下流动，atom 也不能导入另一个 atom。作者认为，这能避免系统扩张后出现纠缠不清的依赖；但“多数设计系统到第二年会被这种问题拖垮”属于他的判断，不是本文验证出的普遍规律。
它也不只提供 Button、Input、Card 这类通用组件。作者为业务场景制作了专用组件：metric display 能处理货币、百分比、ROAS 和小数；trend indicator 用 higherIsBetter 属性决定上涨或下跌应显示哪种语义颜色。换句话说，工程师展示 CPC 等指标时，不必每次重新决定格式和颜色，业务规则已经写进组件。
同一套变量，承接多套界面
产品已有一套运行多年的 legacy theme，同时还要容纳新的品牌配色、字号和视觉密度。作者把品牌与明暗模式拆成两条独立轴线，通过 HTML 的 data attribute 组合。组件只读取 token 名称，不需要知道自己处于哪个品牌；上层属性会决定这些名称最终解析成什么值。
作者还同时维护 MUI 与 Tailwind + Radix 两条组件轨道，两者消费相同的 design tokens。旧页面继续使用 MUI，新功能可以逐个组件迁移，不必一次性重写整个产品。组件生命周期则分为 experimental、beta、stable 和 deprecated，用状态提示成熟度与退出过程。
真正值得看的，是“规范开始回答问题”
前面的 token、registry、自动审计和组件分层，先把设计决定整理成结构化、可执行的基础。MCP 的意义在于，进一步把这套基础暴露成知识接口。过去，人要打开文档、搜索组件或询问设计师；接入之后，软件与 AI 理论上也能查询同一来源。设计系统由“供人阅读的规范库”，向“人和机器都能提问的规则入口”移动。
这也是标题里“开始回答设计问题”的含义：重点不只是 AI 会生成一个按钮，而是它能否先知道该找哪个组件、该引用哪个 token，以及现有实现是否违反规范。作者称这种连接改变了工程师、设计师与 AI 代理使用设计决策的方式。这个方向值得关注，但供稿没有给出效率、质量或采用率的量化结果，因此还不能把“改变”写成已经证实的成效。
局限与未知
- 原文在 MCP 介绍处截断，未披露 server 提供哪些工具、如何实现协议，也无法确认是否已用于生产环境。
- 所有材料均来自作者本人；历史问题、系统实现和使用效果没有独立证据交叉验证。
- 现有材料无法区分收益究竟来自 MCP，还是主要来自更早完成的 token、registry、组件分层与自动审计。