设计系统的本质：如何从零构建可扩展的组件库
设计系统不是 Figma 中的组件库文件。它是一套决策机制——当新需求出现时，团队知道从哪开始、遵循什么、在哪结束。
2017 年，我在一家有七个产品线的公司担任设计负责人。每个产品都有自己的一套按钮样式、自己的颜色变量命名、自己的间距规则。当我们要给所有产品新增深色模式时，工作量是 7×N——七个团队各自发明自己的深色方案。
那一年我们启动了设计系统项目。以下是我们在接下来的两年里学到的东西——不是理论，是经过验证的实践。
Section 01设计系统到底解决什么问题
很多人把设计系统理解成“组件复用”，但这只是表层。设计系统真正解决的是三个问题：
- 一致性：不同页面是否像同一个产品
- 效率：重复需求是否能快速实现
- 演进性：当需求变化时，系统能否稳定扩展
如果只为复用而建系统，很容易做成一堆僵硬的零件；如果只为统一而建系统，又很容易阻碍产品迭代。真正成熟的设计系统，是在一致与灵活之间找到平衡。
Section 02设计系统的五层模型
第一层：设计原则
原则是高于任何具体实现的决策规则。每条原则在冲突出现时可以裁决。
有效的设计原则满足三个条件：
- 它能告诉你什么该做、什么不该做
- 它在两个互相冲突的需求之间强制做出取舍
- 它适用时你能立刻识别
例如：
- 「清晰优先于简洁」——当一个界面可以做得更简单但牺牲了可理解性，选择清晰
- 「可访问的是好的」——当设计选择与 WCAG AA 冲突时，AA 优先
第二层：设计令牌
令牌是平台无关的设计变量——颜色、字体、间距、圆角、阴影——以名称而非值来引用：
| 1 | { |
| 2 | "color": { |
| 3 | "accent": { "value": "#c45c3e" }, |
| 4 | "surface": { |
| 5 | "0": { "value": "#0a0a0a" }, |
| 6 | "1": { "value": "#1a1a1a" }, |
| 7 | "2": { "value": "#242424" } |
| 8 | } |
| 9 | }, |
| 10 | "spacing": { |
| 11 | "1": { "value": "8px" }, |
| 12 | "2": { "value": "16px" }, |
| 13 | "3": { "value": "24px" }, |
| 14 | "4": { "value": "32px" }, |
| 15 | "6": { "value": "48px" } |
| 16 | } |
| 17 | } |
这些令牌通过工具链（如 Style Dictionary）转换为：
- CSS 自定义属性
- JavaScript/TypeScript 常量
- Figma 变量
- iOS/Android 资源文件
以本博客为例——globals.css 中的 @theme 指令实质上就是 Tailwind 风格的设计令牌：
| 1 | @theme { |
| 2 | --color-accent: #c45c3e; |
| 3 | --color-background: #0a0a0a; |
| 4 | --color-surface: #1a1a1a; |
| 5 | --color-border: #333333; |
| 6 | --color-primary: #e0e0e0; |
| 7 | --color-secondary: #888888; |
| 8 | } |
第三层：原子组件
原子组件是单个不可再分的 UI 单元。它们应该：
- 只做一件事
- 有清晰的状态枚举（default / hover / active / disabled / focus）
- 对外界完全无知——不关心自己在哪里被使用
以 Button 为例，一个好的原子组件 API：
| 1 | interface ButtonProps { |
| 2 | variant: 'primary' | 'secondary' | 'ghost'; |
| 3 | size: 'sm' | 'md' | 'lg'; |
| 4 | disabled?: boolean; |
| 5 | loading?: boolean; |
| 6 | children: React.ReactNode; |
| 7 | } |
而不是：
| 1 | interface ButtonProps { |
| 2 | color: string; |
| 3 | width: number; |
| 4 | height: number; |
| 5 | style: 'shiny' | 'flat'; |
| 6 | } |
第二种 API 将实现细节暴露给了消费者，使系统难以演进。
第四层：模式（Patterns）
模式是多个原子组件的可复用组合方式。例如：
- 搜索模式：Input + Button + Dropdown
- 确认模式：Modal + Header + Body + Footer + Button × 2
- 数据表格：Table + Pagination + Filter + Search
模式的价值在于——新功能可以从已有的模式开始搭建，而不是每次从零拼凑原子组件。
第五层：文档
再好的系统没有文档也会消亡。文档不必是一本完整的书——但必须覆盖以下最小集：
- 每个组件的用途和使用方法
- 适用场景与不适用场景
- 可访问性考虑
- 代码示例（复制即可运行的）
Section 03从零构建：四阶段路线图
阶段一：审计（2-4 周）
- 收集所有产品中现有的 UI 截图
- 识别重复的组件（一个应用中可能有 7 种不同的按钮）
- 选择最常见的变体作为初始目标
- 找出现有设计中最不一致的地方
| 1 | # 自动化审计命令示例 |
| 2 | find src -name "*.tsx" -o -name "*.css" | xargs grep -oh 'color: #[0-9a-fA-F]\{3,6\}' | sort | uniq -c | sort -rn | head -20 |
阶段二：令牌定义（1-2 周）
从最小令牌集开始——你不需要覆盖全部场景。优先级顺序：颜色 > 间距 > 字体 > 圆角 > 阴影。
阶段三：组件构建（持续）
永远从最常用的组件开始：Button → Input → Badge → Card → Modal。每个组件构建后立即集成回一个真实页面中测试，而不依赖 Storybook 作为唯一验证方式。
阶段四：文档与推广（持续）
在组件稳定后立即记录。推广设计系统的最佳方式不是行政命令，而是让第一个使用它的团队获得可测量的好处——更快、更一致、更少 bug——让其他团队自然效仿。
Section 04常见失败模式
1. 过度抽象
看到两个组件的相似性就立刻提取成一个抽象组件。但在提取前问：在未来三个月内，这两个组件的演进方向是否一致？如果不确定——先复制，后提取。过早抽象比重复代码更难修复。
2. 从最难的部分开始
每个设计系统都有一个最难统一的部分——通常是表格、日期选择器或图表。不要从它们开始。从按钮、输入框、颜色令牌开始。让系统先在简单处取得信任，再挑战复杂处。
3. 文档部门化
文档不是「文档团队」写完就完成的。文档需要嵌入开发流程——组件更新时，文档必须与代码一起更新。理想情况下，文档从 JSDoc/TSDoc 注释自动生成 API 参考。
Section 05维护设计系统
设计系统不是一次性项目。它是一个产品——它的用户是内部开发者。
- 设立组件贡献流程：提案 → 评审 → 实现 → 文档 → 发布
- 版本化管理：使用语义版本号（semver）——major 版本意味着破坏性变更
- 向后兼容是企业级系统的生命线：如果一个团队升级了设计系统版本，所有页面仍然正常工作
Section 06结语
设计系统不是关于统一性。它是关于可预测性。
当你的团队有十个开发者和三个设计师时，你需要的不再是每个人都在 Figma 中「对齐共识」。你需要一个机制——这个机制让每一次设计决策都能稳定地转化为代码、并在变更时通知到每一个消费者。
设计系统就是那个机制。