美团 UI-B 设计系统

我在 2024 年开始接手这个“规划宏大但落地糟糕”的设计系统，最终砍掉 80% 的无效功能，聚焦于组件分发这一核心，6 个月后，让 1000+ 设计师真正用起来。

核心洞察

设计系统的价值不在于它「有什么」，而在于「有多少人真正在用」。

MTD 3.0 的规划看起来很完整：规范库、组件库、模板库、交互模式库、图标库、动效库、数据可视化、前端技术栈、主题定制工具、低代码平台、业务最佳实践... 但当我接手时，发现设计师和前端都在「骂」——组件调用困难、还原度差、更新不同步。

规范组管着团队库，但业务侧调不动。组件质量差、技术栈 Bug 多，设计稿随意改，分发靠人盯，反馈传不回来。源头没建好，链路就是断的。

在设计系统最核心的团队库和前端技术栈的建设上，都没有做到十分完善，导致业务的设计师和研发在调用过程当中，链路中断。

更深层的问题是：团队沉迷于「建设」，忽略了「交付」。主题定制工具、低代码平台这些高级功能，ROI 极低，却占用了大量资源。而最核心的「让设计师方便地调用组件」这件事，反而没人做好。

设计决策

1. 暂时砍掉 80% 高级功能，聚焦核心

和上级沟通后，决定暂停主题定制工具、低代码平台等「高级功能」，把缩减后的有限资源全部投入到设计组件库和代码化组件的绑定建设上。原因很简单：设计师连基础组件都用不顺，主题定制无从谈起。

回过头看，主题定制、低代码这些被砍掉功能，在 AI 时代反而变得不那么重要了。

2. 用开发思维做设计组件

在上一版的前端组件库开发中，之所以还原度低、Bug 率高，是因为在设计组件的过程中，并没有考虑过开发过程中以何种方式去实现这种样式。

而本次设计，我们将所有的设计组件以开发思维进行重新审视，将设计系统中的原子、分子等概念，一一对应到技术栈中的 Design Token、API Props 以及相对应的参数。

Design Token

每一个前端 token 都对应一个 MasterGo 中的基础样式。

Props

每一个前端 props 都对应一个 MasterGo 中的设计变体。

在 MasterGo 中变体将 props 实现了可视化。设计师在 MasterGo 里切换变体，就是在「调用 API」。这样保证了设计和代码的 1:1 对应，还原度从 60% 提升到 96%。

3. 引入 Variant + Auto Layout

2024 年公司全面切换到 MasterGo，但推广并不顺利，很大一部分原因是没有好用的团队库，设计师宁愿留在 Sketch。借着重构组件库的机会，我引入 Variant（变体）和 Auto Layout（自动布局）重构了组件库。三个月后，设计团队 100% 迁移，年度调用次数超过 1000 万。

4. 最后一公里：让设计系统被用起来

组件库建好了，但设计师不会用变体和自动布局，技术栈的使用者（设计、前端、甚至产品）不知道 props 对应什么效果——工具链再完善，最后一公里没打通等于零。

我们做了三件事：

带有练习场的可交互教程

针对美团设计师的 Sketch 习惯，写了一套变体和自动布局的入门指南，不是讲概念，直接教操作。

技术栈 Props 预览

可交互的 props 调试器，调参数实时看效果，设计、前端、产品都能一眼明白。

运营手册

将反馈机制、评审流程、迭代流程固化，形成运营手册。把反馈闭环跑起来，让组件持续进化。

我的视角

这个项目让我意识到，设计系统的本质不是「完备」，而是「可用」。设计师愿不愿意用？前端能不能还原？更新能不能同步？这些基础问题比规划多少功能更重要。设计系统不是设计团队的事，也不是前端团队的事，是「设计+前端」一起做的事。

后记：2026 补充

时间来到 2026 年，AI 正在改变设计工具。Tailwind + shadcn 在 AI 生成领域大杀四方，如何把 MTD 的代码资产转化为 AI 友好的格式，是下一个值得探索的方向。这也将在我未来的项目中进行探讨。