三五个人时设计系统就是个规范文档的事，但到了百人规模，核心已经变成了协作问题。关键看做完大家用不用得起来、愿不愿意跟，以及用着用着会不会又跑偏。
不少团队一开始就先整理UI规范、抽基础组件、写设计原则。
但业务线一多、人员一动、项目并行
，同一个按钮在不同产品里就又各长各的了。同样的交互在不同端，实现逻辑也完全对不上。
所以百人团队的问题不在于"有没有设计系统"，而在于
有没有统一的使用方式，并且能持续运转下去
。
很多设计系统翻车的起点其实很简单：顺序搞反了。一上来就开干组件，规范后面再补。百人团队这么做基本必返工，因为没有统一标准，组件库越做越多，反而成了新的混乱源头。
我们的经验是，起点的核心其实是
三个问题
：设计语言有没有对齐，边界有没有划清楚，资产结构管不管得住。
设计语言统一
，不等于所有产品长一模一样，而是要在“默认长什么样”上达成共识。比如颜色是不是只保留一套主色体系，字号有没有固定梯度而不是随手拉，间距按8还是10走，按钮层级有没有明确区分。这些基础问题没定死，后面组件一定稳不住。
再说边界
。设计系统没必要铺到所有页面，它的边界就是把高频、稳定的那部分标准定死。像按钮、表单、弹窗、列表这些基础控件是必须收住的。但强业务属性的页面，比如活动页、营销页，硬套规范反而会把系统拖垮。
最后是资产结构
。组件不能往一个库里随便一丢就完了，得在一开始就想好分层：基础层放颜色字体间距，组件层放Button、Input这类，模式层放Form、Table，模板层放页面级结构。这样后面才好检索、好维护。这个阶段可以借助设计协作工具来把标准落地，我们用的是Pixso，把颜色、字体、组件结构先搭成可用的资产。
标准定好之后，还有一个问题：
怎么把这些东西快速搭起来
，而不是让设计师从头一个一个建。我们试过纯手工搭，效率实在太低，后来直接用了Pixso的AI生成能力。输入主色和主题方向，AI就能把颜色、字体、组件、阴影这些全吐出来，虽然生成的细节需要人再调一遍，但最耗时的骨架搭建被压缩到了一两天。而且生成的东西可以直接转成全局样式，不用再手动同步到设计稿里，团队内部复用起来也方便。
标准定完之后，才是组件体系的搭建。但这里很容易走偏：越做越全。按钮做一套，输入框做一套，弹窗做一套，然后开始搞复杂组件，最后系统越来越重，实际项目翻来覆去还是用那几个基础款。
到了百人这个规模，设计系统的核心指标不是覆盖率，是稳定性。
1. 基础组件这块
，有几个关键点必须定死。按钮不能只定样式，Default、Hover、Disabled、Loading这些状态必须统一，不能含糊。输入框也是，错误状态、提示信息、聚焦状态要有一套固定规则，否则开发自己补的规则各不一样。
2. 比基础组件更关键的一层是
模式组件
。很多团队一开始不会做这个，但做对了效率提升非常明显。比如标准表单页、列表页、筛选区、分页区，把这些结构固定下来，后台类系统基本就是拼积木。
3. 再往上就是
变量体系
。这个容易被低估，但在多产品线里极其重要。颜色、字号、间距不再是写死的固定值，而是一套变量。不同产品线换个主题就行，组件不用重做。很多系统做到后期崩掉，就是因为没做变量层，只能靠复制组件来解决，越走越重。
设计系统搭起来只是第一步，能持续用下去才是真本事。
百人团队里设计系统最大的问题通常不是技术，而是失控
。最典型的情况就是这几个：
组件改了，旧项目还在用旧的，新项目又用新的，最后一套系统里跑着好几套逻辑；
产品线各自扩展，各产品线自己搞分支组件，都说我这个按钮特殊；
还有就是压根没人维护，设计系统变成设计组的私活儿，不是团队资产。
解决起来不复杂，但得有人管、有规则。我们分了三层：设计系统负责人管标准，前端核心管实现，业务代表管需求反馈。任何新增组件必须经过评审才能进系统，不然很快就会被各业务线的需求冲散。
还有个容易被忽略的点是
反馈机制
。系统做完了得能接收使用反馈，定期优化。某个组件在多个项目里被反复魔改，说明它本身设计得不对，需要调整，而不是让业务去适应它。
百人团队从0到1搞设计系统，是建立一套长期运转的协作方式。其实就是让设计、开发、产品能在同一个语言体系里对话，别再各说各话。
等这套机制跑顺了，团队的变化会很明显：新项目不用从零对齐视觉，设计稿不会被反复推翻，开发也不用再为几像素的间距反复确认。
