设计系统团队成熟度
Design system 已经从早期的静态样式指南和松散的 UI kit 走了很远。现在一个成熟的 design system 就是一个内部产品：有自己的发布周期、专门的团队、带版本的 package，以及固定的支持渠道。
做和维护这套系统的团队不会一开始就很成熟。它的成长通常会经历三个阶段，而且这种演进既在技术上，也在组织关系上。每个阶段里，团队怎么和 product team 合作、有多少信任、能在技术栈里产生多大的影响力，都在变化。
第一阶段是提供组件。你交付一套共享组件库，让设计师和工程师对齐语言，在产品快速扩张的同时尽量保持一致。第二阶段是规范与治理（enforcement）。团队不再只是发组件，而是开始管理组件怎么被使用：收紧 API，用 linter 拦住 slop，自己扛起 migration 而不是把活甩给业务团队，同时建立起单一 product team 很难具备的跨产品视野。第三阶段是成为底层基础设施。团队开始解决那些能一次性提升全局体验的问题。因为 design system 已经铺在技术栈最底层，核心处的一次改动会立刻反映到整个产品里。
第一阶段：提供组件
第一阶段很直接：把东西做出来，让人用起来。这通常发生在产品快速增长的时期：需求不断涌进来，好几个团队并行开发，但没人统筹 UI。Design system 团队的任务，是在界面碎片化和技术债失控之前，交付一套经过测试、视觉一致的组件库。
一致性
这个阶段最核心的技术工作是把 UI 的复杂度封装起来，让业务团队不用重复造轮子。Uber 的 Base design system 是一个很好的例子：接入它的团队交付速度快了 3 倍，视觉一致性 bug 少了 4 倍，写的 UI 代码少了一半。一个新的 design system 团队在内部建立信任，靠的就是这样的数字。没有这些，你只是又一个要求别人改变工作习惯的项目。
设计师和工程师的共同语言
第一阶段没那么显眼、但影响更久远的作用，是给设计师和工程师一套共同的词汇。没有系统的时候，设计师交付静态稿，工程师靠猜补全细节：阴影深度不对，动画缓动曲线对不上。都是小事，但时间一长就会积累成很大的摩擦。
Design system 把这种映射明确了下来。设计师在 Figma 里标一个 bg-primary，工程师在代码里用同一个 token。不用猜，也不用争论那个灰色到底该是哪一个色号。
起步方式很关键
系统的起点对第一阶段的影响比很多人想的更大。Design system 通常有两种起步方式：
| 起源 | 是什么样子 | 难点 | 怎么推进 |
|---|---|---|---|
| 自上而下 | 有管理层 sponsor、专门的 headcount、正式预算和明确目标。 | 需要尽快找到合适的合作团队，用真实数据证明效率提升。 | 不要强推到让业务团队反感。靠好用和省事吸引他们，而不是靠行政命令。 |
| 自下而上 | 没有 sponsor，没有资源，往往是工程师或设计师自己先做起来的。试错压力小，但阻力大。 | 没有正式排期，只能挤时间做，推动其他团队 adoption 很费劲。 | 先找最痛的团队帮他们解决问题，剩下的靠口碑传播。 |
无论哪种起步方式，第一阶段结束时的状态都是一样的：design system 团队必须开始把自己当成产品团队来运作。你需要文档、onboarding，甚至一点内部宣传。一旦这套系统变成各个团队默认使用的开发方式，就算度过了婴儿期。
第二阶段：规范与治理
当系统在多条产品线真正铺开之后，就会进入一个尴尬的阶段。问题不再是没有人用，而是规模化之后的混乱：业务团队用各种你没想过的方式使用组件，feature request 积压的速度超过团队的消化能力，高强度的使用也把小规模时没暴露的 bug 和架构问题全都翻了出来。
为了不让系统散架，团队必须从单纯提供组件转向规范和治理：重新设计 API、把规范自动化、自己承担 migration，并在不失去控制权的前提下理清共同维护的边界。
收紧 API
在第一阶段，为了推动 adoption，你会把组件做得很灵活，允许业务团队传自定义样式、覆盖内部结构，需要什么就开什么口子。但在规模化之后，这种灵活性会变成负担。有人改了 button 的 padding，有人往 input 里塞了奇怪的交互逻辑，结果你改任何一个组件都会把别人的页面搞坏。
解法是在不牺牲易用性的前提下约束 API。成熟的团队通常会提供多层抽象，让使用者根据场景自己权衡。Spotify 的 Encore 系统用三层结构很好地解决了这个问题：
| 层级 | 运作方式 | 适用场景 |
|---|---|---|
| Config（高抽象） | 组件只接受预设选项，完全掌控内部渲染。 | 标准场景，使用最广。系统升级会自动生效，业务团队不需要做任何改动。 |
| Slots（中等抽象） | 组件暴露特定区域，允许业务团队传入子组件。 | 需要局部定制（比如在标题前加个图标），但整体布局和交互仍由系统控制。避免组件为了堆功能而塞满 props。 |
| Custom（低抽象） | 无样式的 headless primitives，只提供无障碍逻辑和键盘导航，不包含视觉样式。 | 边界场景和复杂的定制需求。业务团队可以自己写 UI，同时直接复用标准化的 a11y 和交互行为。 |
用工具拦住 slop
到了这个规模，光靠文档已经守不住规范了。人工 code review 又慢又不稳定，还容易伤和气。更好的做法是把规范直接写进工具链里。
也就是配好严格的 lint 规则、build-time 检查和 runtime 校验。比如一个本该渲染子元素的容器组件没有收到 children，编辑器就会直接标红，build 会失败，PR 也会被拦下。违规在进代码库之前就被截住了。这还有一个很好的副作用：工程师在平时改 lint 报错的过程中，自然就学会了系统的用法和规范。
自己扛起 migration
Design system 一定会演进：视觉语言会更新，组件会重写，旧的 API 会被废弃。Breaking changes 是避免不了的。
不要把迁移的活甩给业务团队。这种事我见过太多次了：你发了一个 breaking change，群发一条消息让大家升级，然后眼看着迁移排期一拖就是好几个月。业务团队觉得烦，公司一半在用 v2，另一半卡在 v1，谁都不痛快。
迁移应该由 design system 团队自己来做。直接进业务代码库把 UI 改好，请对方做 code review；能用 codemod 的地方就用 codemod。Sourcegraph 的团队就曾用 codemod 自动完成了某次迁移 95% 的工作量。
所有权的拉扯
随着系统变大，design system 团队和业务团队之间的张力是免不了的。你想要一致性和严谨，他们想要快点上线和做实验。如果你抓得太死，需求越积越多、交付周期拉长，最后他们干脆自己写一套组件绕开你。
这个问题靠画组织架构图是解决不了的。归根结底还是要和业务团队更紧密地配合，把测试覆盖率做好，让他们放心升级你的新版本，并在他们需要的时候及时出现。
跨产品的全局视野
信任建立起来之后，design system 团队会慢慢变成内部顾问。因为跟足够多的团队打交道，你能看到别人看不到的规律：组织两头的两个团队卡在同一个问题上，但彼此不知道对方的存在；一个看起来像局部特殊需求的痛点，其实是个系统性问题。
业务团队感受到自己的声音被听见之后，也会开始像共建者一样参与进来，提更有价值的 bug、给切实的改进建议、做有建设性的讨论。而 design system 团队也在合作中攒出了单一业务团队不可能有的全局视野：发现重复造轮子的地方，把一次性的解法提炼成通用方案，或者把遇到同样问题的团队撮合到一起。
第三阶段：底层基础设施
理顺了所有权的拉扯、搭好了自动化检查、也和业务团队建立了真正顺畅的合作关系之后，系统就走到了第三个阶段。它不再只是一个帮开发者提速的组件库，而是整个产品生态运行的底层基础设施。
这个阶段的标志是触达范围。团队在日常维护之外有了足够的空间，去攻克那些能一次性提升全局体验的问题。因为系统处在依赖树的最底层，核心处的一次改动会立刻反映到所有产品界面上。
拿无障碍（a11y）来说。在一个同时有亮色和暗色主题的大型产品里，颜色和对比度的改动会影响整个产品的可用性。GitHub 的 Primer 团队在一次大规模系统升级中重做了对比度策略，新的 token 一次性修掉了平台上 1000 多处、好几百个无障碍对比度问题。不需要跨季度的迁移，只靠底层 token 的更新就同步到了所有地方。Atlassian 在品牌重塑时也做过类似的事，靠 design system 把新的定制字体铺到了 18 个以上的产品里，而没有演变成持续好几个月的跨团队协调噩梦。