每个前端团队最终都会走上同一条路：建组件库，搞设计系统，画设计规范文档。

然后看着它慢慢死去。

不是夸张。我见过太多团队花大力气搭了一套设计系统，上线时热热闹闹，半年后只剩一个人在维护，一年后连那个人也转岗了。业务线该自己封装的还是自己封装，该重复的还是重复，设计系统变成了一座精美的鬼城。

这个现象太普遍了，普遍到已经不值得用"执行力不够"来解释。问题不在人，在设计系统这个事情本身的逻辑里。

建设者的幻觉

设计系统的出发点通常很理想：统一视觉规范，提高开发效率，减少重复劳动。听起来无懈可击。

但这个逻辑有一个隐含前提——业务足够稳定，需求足够规范，变化足够可控。

现实呢？

金融产品恨不得每周换一轮视觉，大促活动页面跟日常页面完全是两套设计语言，某个业务线因为合规要求必须用特殊样式，另一个业务线因为老板拍板要用新风格。你精心设计的 Button 组件有十二个 variant，但业务要的是第十三个。

设计系统的建设者往往是架构团队或基础设施团队。他们离业务远，有时间做抽象。但离业务远恰恰是问题所在——你抽象出来的东西，天然跟不上业务的节奏。

我见过一个团队花两个月重构了组件库的 Token 体系，上线当天业务侧就提了一堆覆盖样式的需求。不是业务不讲道理，是业务等不了你两个月。

统一的代价

设计系统追求统一，但统一的代价是灵活性丧失。

这个矛盾在组件层面还好解决——你要的 variant 我加一个就行。但在设计语言层面几乎无解。

A 业务要沉重感、专业感，B 业务要轻快、年轻，C 业务要安全感、信任感。同一个 Color Palette 怎么满足三种情绪？同一个 Spacing Scale 怎么适配三种信息密度？

大厂的平台级设计系统（Ant Design、Arco Design）能活下来，是因为它们服务的是海量中小团队，这些团队没有自己的设计语言，拿过来直接用是最优解。但你自己的内部设计系统面对的不是这种场景——你面对的是几个有自己想法的业务线，每个业务线都觉得自己特殊。

"你们用设计系统就行"——这话在架构评审会上说得通，在需求评审会上说不通。

版本号的诅咒

设计系统一旦发布，就背上了一个永远甩不掉的包袱：版本兼容。

v1 的 Button 有 ts 属性，v2 你觉得这个命名不好想改。改了之后呢？所有用到 Button 的业务都得跟着改。你发了一份迁移指南，写了 breaking changes，然后呢？业务团队排期排到下个季度。

于是你开始不敢改。API 设计得不够好的地方，只能 add 不敢 remove。组件的 props 越来越多，默认行为越来越诡异。新来的人看一眼组件文档，满头问号。

开源组件库有社区的力量推动升级，内部设计系统有什么？有业务团队"能用就行"的惰性。

我见过一个内部组件库的 Button 组件，三个月没人敢碰它的 props 定义。不是因为设计得好，是因为改了不知道哪里会炸。一个本该提高效率的工具，变成了效率的枷锁。

谁来维护

这可能是最现实的问题。

设计系统需要持续投入：跟着设计规范走，跟着业务需求长，跟着技术栈升级。这不是一个项目，是一个产品。

但大多数团队把设计系统当成项目来做——立项、排期、开发、上线、结项。然后呢？

没有专人维护，设计系统就开始腐烂。设计规范更新了，组件没跟上。新需求来了，组件不支持。业务团队等不了，就开始绕过设计系统自己搞。越绕越不统一，越不统一设计系统越没用，越没人用越没人维护。

恶性循环。

你可能会说，那就设专职团队维护呗。问题是，设计系统的 ROI 很难量化。老板问你："这个团队一年产出了什么？"你总不能说"产出了统一性"。

在绩效体系里，写业务代码有明确的业务价值，写组件库的代码——尤其是维护型的工作——很难讲清楚价值。聪明人不会主动选择这个方向。

什么情况下设计系统能活

说了这么多，不是说设计系统没有价值。而是在大多数场景下，它的价值实现不了。

但确实有成功的设计系统，它们有几个共同特征。

第一，业务高度同质化。所有业务线的视觉语言、交互模式、信息架构都很接近，设计系统的抽象不需要妥协。这种情况在工具类产品（后台管理、数据看板）中比较常见，在面向 C 端的金融产品中基本不存在。

第二，有强大的设计团队持续驱动。不是开发驱动的组件库，是设计驱动的规范系统。设计师深入业务，理解每个场景的差异，在设计语言层面做出弹性，而不是让开发硬编码二十个 variant。

第三，有明确的治理机制。谁负责升级？谁审批 breaking change？业务线多久必须跟进？这些不搞定，技术再好也白搭。

第四，也是最重要的一点——设计系统的建设者和服务对象是同一拨人。组件库团队既做组件，也用组件做业务。只有这样，他们才能感受到痛点，才能及时响应。脱离业务的纯基础设施团队做设计系统，几乎必败。

退一步

与其追求全公司统一的设计系统，不如降低预期。

做设计 Token 和基础样式变量，不做业务组件。提供设计原则和边界，不规定具体实现。统一色彩、间距、圆角这些最底层的东西，上面的业务组件让各业务线自己搞。

这样的"半设计系统"没那么酷，但能活下来。活下来的东西才有机会迭代，迭代了才有机会统一。一上来就要大统一，结局往往是大家都不用。

还有一种思路更务实：不做设计系统，做设计工具。给业务团队提供 Figma 组件库、设计 Token 导出工具、样式 lint 规则。不强制统一，降低统一的成本。当统一的成本足够低，业务团队自然会统一——因为没人喜欢重复劳动。

很多人不想承认的是，设计系统的问题不是技术问题，是组织问题。当你的组织还没有准备好为统一性付出代价——持续的人力投入、业务妥协、治理成本——就不要硬上设计系统。

先让业务跑起来，先让团队有统一的意愿，再建系统。顺序反了，就是建一座没人住的房子。

设计系统的尽头未必是没人用。但跳过前提条件直接搞建设，尽头大概率就是没人用。