你并不需要设计系统

你大概并不需要一套设计系统。你需要的是几个设计 token、一个小型组件库,以及团队里一个有品味的人。你最爱的设计推特账号总在晒的那个东西,那个有 400 个已发布组件和 12 套主题的 Figma 文件,其实是一个全职产品,而你八个人的创业公司正在为它付费,却从没收回过一分钱。

这是行业里人人都知道是真的、却没人敢大声说出来的观点。维护账单是真实的。回报大多是想象出来的。AI 生成更是让两者之间的差距进一步拉大。

95% 发布设计系统的团队,都是在 cosplay 成熟度。真正需要设计系统的那 5%,通常恰恰不是在问这个问题的团队。

设计系统是一个产品,不是一个支线任务

真正的设计系统有自己的路线图、自己的更新日志和自己的客户。 这些客户就是交付实际产品的工程师和设计师。如果没有人被安排来维护它,那它就不是系统,只是一张快照。

看看谁把设计系统做得好。Stripe 有专门的设计基建团队。Shopify Polaris 有自己的组织。GitHub Primer 有带版本发布的公开仓库。

Atlassian 多年投入,打造出的系统在规模上是大多数团队永远无法企及的。每一个都是产品团队,为数以千计的内部客户群构建工具。

再看看典型的版本。一位资深设计师在 Figma 里花了六周,发布了 80 个组件,写了一篇没有工程师会读的 Notion 页面,上线了两套主题。六个月后,一半组件已经过时,token 与代码库漂移脱节,团队又回到了复制 Tailwind class 的老路。系统没有失败,是团队没有为它配备人手。

没人会放进演示文稿的维护账单

回报的推销话术是:构建一次,永久复用。实际的算术是:构建一次,然后永远维护,偶尔复用其中一部分。

每一个存在的设计 token 都必须在 Figma 和代码之间保持同步。每一个组件变体在框架升级时都要重新测试。Radix、React 或 Tailwind 的每一次破坏性变更,都会波及每一个依赖它的产品。文档在一个季度内就会腐烂。

Storybook 实例在一次依赖升级后挂了,三周都没人发现。已发布的 Figma 库比代码库落后一个版本。主题各自分叉。系统里的组件,不是产品里的组件。

诚实的核算是这样的。一个六组件的“系统”可以真正节省时间。一个 12 人公司里的 200 组件系统则是一种税。回报的工时是线性的,维护的工时是复利的,到某个时刻两条线就会交叉。大多数团队在不知不觉中越过了交叉点,因为维护成本体现为周五下午的 Slack 消息,而不是损益表上的一行。

AI 生成刚刚让这笔账崩塌了

设计系统的全部理由都建立在一个数字上:产出一个样式精良的新组件的成本。这个数字如今已经成了舍入误差。

一位初级工程师可以敲下“给我一个设置页面,带侧边栏、三个分区,以及一个遵循加载状态模式的保存栏”,然后在二十分钟内交付一个可用的组件。v0 默认生成 Shadcn 风格的输出。Cursor 和 Claude 可以基于现有 primitives 重构整个流程。设计系统过去提供的回报,也就是快速生成风格一致的 UI,如今成了市面上每个 IDE 附赠的免费服务。

系统税没有变,回报却暴跌。故事就是这么简单。2022 年为了更快产出而构建设计系统的团队,如今比那些直接用 Shadcn 加 Tailwind 加一句提示词的团队更慢,因为每个 AI 工具都是基于后者训练的,对前者视而不见。

真正需要设计系统的那 5%

只有当一组特定条件全部成立时,真正的设计系统才值回票价。缺一条,这笔账就算不过来。

1. 多个产品共享同一套识别。 Atlassian 有 Jira、Confluence、Trello 和另外十几个产品。一套识别,多个界面。系统就是统一层。
2. 人数以百计,而不是几十。 产品工程师少于 50 人时,每个组件都只差一条 Slack 消息就能修好。超过 200 人,这套办法就撑不住了,系统成为唯一出路。
3. 有专职的 design ops 或设计基建团队。 没有负责人的设计系统就是坟场。负责人必须是一个真正的岗位,而不是占 20% 时间的项目。
4. 有外部使用者。 像 GitHub Primer 或 Shopify Polaris 这样的开源设计系统,同时也是面向开发者的产品。外部采用让维护成本变得合理。
5. 受监管或对无障碍要求很高的领域。 医疗、金融、政府。系统把合规和审计就绪编码了进去,这是任何单个团队都无法复制的回报。

如果一个团队五条全中,设计系统就是正确的选择。如果一个团队只中一两条,只做一个有 40 名工程师的产品,那设计系统就是 cosplay。关于反仪表盘的那篇文章讲了一个相关的模式:为你还没达到的组织规模去搭建基础设施。

最小可行视觉系统

对于那 95% 的团队,答案是一个三层堆栈,维护成本几乎为零,产出却几乎一样。

这就是整个堆栈。Tokens 给你一致性。Primitives 给你无障碍和行为。品味给你任何系统都无法编码的那一层,也就是判断规则何时该弯曲的能力。

2026 年交付最干净产品的团队,用的都是这套的某种版本。Linear 靠一小套 token、定制 primitives 和近乎偏执的品味运转。Vercel 发布了庞大的 Tailwind 配置,加上自家的 primitives。

Cal.com 公开发布了它的 primitives。Resend 和 Loops 交付的是 Shadcn 风格的 UI,上面叠加自家的 token。

Notion 靠一小套 token 和刻意收紧的组件词汇运转。它们都没有 Atlassian 意义上的“设计系统”。但它们的营销站点技术栈看起来都比体量大十倍的公司更连贯。

为什么 Shadcn 正在吞噬设计系统这个品类

Shadcn 不是组件库。它是新默认标准的交付机制。Primitives 被直接引入代码库,用 Tailwind 设置样式,而且因为底层由 Radix 扛起重活,所以具备无障碍能力。用户拥有这些组件,可以随意编辑,永远不会被上游发布卡住。

这对大多数内部设计系统来说是致命一击。团队过去自建的原因是掌控权。Shadcn 免费给了你掌控权。团队过去搭 Storybook 的原因是可发现性。

Shadcn 公开发布文档,AI 工具会索引它们。团队过去发布 Figma 库的原因是一致性。Shadcn primitives 足够一致,任何针对它们的提示词产出的结果,团队都已经知道如何评估。

Shadcn 加 Tailwind 加一套 token,就是 2026 年的默认视觉技术栈。它是每个现代 AI 代码生成工具的默认产出。它是每个新产品团队最先交付的东西。它就是primitives 加品味的模式,浓缩在两个仓库和一个配置文件里。设计系统作为一个独立的产物,拥有自己的发布流水线和自己的团队,如今才是特例。

真正的系统何时终于值回票价

“我们需要设计系统吗?”这个问题的诚实版本是:“我们越过维护门槛了吗?”

如果一个团队命中三条或更多信号,真正的系统就是合理的。如果只命中一条,一个 token 文件就够了。同样的逻辑也出现在定价页问题和无需引导的引导中,它们在界面层面而不是系统层面解决协作问题。

先说规律,再抖包袱

成熟度的炫耀是颠倒的。2026 年交付最连贯产品的团队,并不是拥有最大设计系统的团队。他们是视觉债务最小的团队。紧凑的 token 集、薄薄的 primitives 层,以及一位经常说不的有品味的设计师。

真正的设计系统,是为那些已经超出替代方案承载能力的组织准备的基础设施。它不是每个团队都该达成的里程碑。它不是身份象征。它也不是“我们想看起来更专业”的答案。

一个在还没挣到维护预算之前就构建设计系统的团队,是用更慢的节奏、更重的文件交付同样的产品。而交付 tokens 加 Shadcn 加品味的团队,用更快的节奏交付同样的产品,并把省下的时间拿去修设置页问题。

问题不是“我们有设计系统吗?”而是“我们是不是在正确的抽象层级上支付维护成本?”

FAQ

设计系统和组件库有什么区别?

组件库是一组可复用的 UI 零件。设计系统则是组件库,加上 token,加上文档,加上治理,加上负责人,加上发布节奏。大多数团队交付的是组件库,却称之为系统。两者并不相同,后者有前者没有的维护成本。

Shadcn 是设计系统吗?

不是。Shadcn 是 primitives 的交付机制。组件被直接引入代码库,归团队所有。没有中央库,没有上游发布计划,也没有治理。

这正是重点。它让团队获得系统的回报,却不用付维护账单。

创业公司什么时候该投资设计系统?

当以下条件至少有三条成立时:多个产品共享识别、五十名以上工程师交付 UI、有专职的 design ops 岗位、组件有外部使用者,或身处受监管领域。低于这条线,就交付 tokens 加 primitives 加品味,把省下的时间投入真正的产品。

CTA

想要一个视觉系统与团队规模相匹配的产品吗?Brainy 为那 95% 交付 tokens 加 primitives 的技术栈,为那 5% 交付完整的设计系统,并按实际维护预算进行校准。雇用 Brainy。在你把一个季度浪费在错误的产物上之前,我们会告诉你你站在线的哪一边。