先给结论：建立组件和设计系统，不是先画一套漂亮的按钮，而是把团队反复做的界面决策变成可复用、可解释、可维护的规则。推荐从一条高频业务流程开始，依次建立设计变量、基础组件、业务模式和治理机制，再用真实页面验证复用效果。
一套能落地的设计系统至少要回答四个问题：组件由哪些部分组成？有哪些状态和变体？什么情况下应该复用或拆分？设计、产品、研发如何知道它正在使用哪一版？如果只做素材收集，没有这些规则，组件库很快会变成“看起来很多、真正不敢用”。
组件库和设计系统有什么区别
组件库是可复用的界面单元，例如按钮、输入框、表格、弹窗和导航；设计系统则包含组件库，以及设计变量、内容规则、交互模式、无障碍要求、代码映射、文档和维护流程。组件库解决“怎么快速搭”，设计系统还要解决“为什么这样搭、怎样持续一致”。
| 层级 | 主要内容 | 团队获得的结果 |
|---|---|---|
| 设计变量 | 颜色、字体、字号、间距、圆角、阴影、层级 | 修改主题或品牌样式时有统一来源 |
| 基础组件 | 按钮、输入、选择、提示、弹窗、导航、表格 | 常用界面单元拥有清晰状态和复用方式 |
| 业务模式 | 登录、筛选、审批、列表、空状态、错误恢复 | 组件能组合成可执行的任务流程 |
| 治理机制 | 命名、版本、负责人、变更、发布和废弃规则 | 设计、产品和研发知道如何采用、反馈和升级 |
一个实用判断是：如果团队只能复制图层，却说不清组件的禁用、加载和错误状态，它还是素材集合；如果每次改色都要逐页手工调整，它还没有形成变量层。
不要从“全量组件”开始，而要从一条任务链开始
设计系统最容易失败的做法，是先列出几十个组件，再试图为它们寻找业务用途。更稳妥的顺序是先选一条高频任务链，例如“创建订单—填写信息—提交审核—查看结果”，盘点其中重复出现的界面决策，再把这些决策沉淀成系统资产。
- 选定范围：明确端（Web、App 或后台）、目标角色、核心流程和本轮不覆盖的内容。
- 盘点重复：找出不同页面中名称相同但样式、间距或交互不同的元素。
- 确定优先级：优先处理高频、容易出错、会影响多个页面的组件。
- 建立最小版本：先让一条任务链从入口走到结果，再逐步扩展到其他模块。
这样做的价值在于，组件是否值得抽象会由真实任务检验，而不是由组件数量证明。一次性的特殊布局可以留在页面里，不必强行纳入公共库。
建立设计系统的四个层次
第一层：先定义变量，再定义组件
变量是设计系统的“单一来源”。建议先建立语义变量，而不是把颜色直接写成十六进制值。例如不要在按钮里直接使用 #2F6BFF，而是使用 color-action-primary；不要把间距写成“看起来差不多”，而是使用 space-3、space-4 这类有规律的命名。想进一步理解变量的使用方式，可以参考设计变量实操教程。
| 变量类别 | 示例命名 | 使用边界 |
|---|---|---|
| 颜色 | color-text-primary、color-border-default、color-action-primary | 按语义命名，避免把“蓝色”写进变量名 |
| 字体 | font-body-md、font-heading-lg、font-caption | 同时定义字号、字重、行高和使用场景 |
| 尺寸 | space-2、space-4、radius-sm、control-height-md | 保持间距和控件高度的节奏，减少随意取值 |
| 层级 | shadow-card、shadow-popover、z-modal | 说明覆盖关系，避免弹窗和下拉层互相遮挡 |
变量命名的核心不是“看起来专业”，而是让设计师、产品和研发在搜索、替换和评审时使用同一种语言。多主题产品还应把品牌色和语义色分开，切换主题时只替换映射关系。
第二层：把组件写成一份“可执行契约”
组件不是一个静态截图，而是一份包含结构、状态和规则的契约。以按钮为例，至少要定义以下内容：
| 组件维度 | 按钮需要说明什么 | 常见遗漏 |
|---|---|---|
| 结构 | 文字、图标、加载指示器、左右内边距和最小点击区域 | 图标按钮没有替代文本或提示 |
| 变体 | 主要、次要、文字、危险、仅图标 | 用颜色临时表达含义，导致同色不同义 |
| 状态 | 默认、悬停、按下、聚焦、禁用、加载、成功、失败 | 只设计默认态，研发需要自行猜测反馈 |
| 内容 | 动词优先、长度限制、超长换行和多语言扩展 | 中文短文案放到英文或长文案时溢出 |
| 行为 | 触发条件、是否可重复点击、完成后的反馈与撤销方式 | 页面跳转存在，但操作结果没有说明 |
同样的写法可以用于输入框、选择器、表格和弹窗。组件文档至少要有“何时用、怎么配、有哪些状态、什么时候不要用”四段说明，避免只展示一张组件预览图。
第三层：从组件组合成业务模式
组件解决局部一致性，模式解决任务一致性。登录、筛选、审批、批量操作、空状态和错误恢复，通常由多个组件组成，不能靠“把按钮和输入框放在一起”自动得到。
建立模式时，先写清用户目标和决策节点，再确定页面结构。以后台筛选为例，模式应说明筛选条件的默认值、提交和重置行为、无结果反馈、分页与排序之间的关系，以及筛选条件是否写入 URL。这样产品经理能判断任务是否完整，设计师能复用结构，研发也能理解交互边界。
第四层：用治理机制让系统持续可用
设计系统上线后，维护比创建更难。建议为每个公共组件指定负责人，建立轻量的变更流程：
- 提出变更：写清问题、影响页面和期望结果。
- 判断范围：确认是修复组件缺陷、增加变体，还是应该创建业务模式。
- 验证影响：检查已使用页面、原型链接、代码实现和历史版本。
- 发布说明：记录变更原因、版本、迁移方式和废弃时间。
组件只要被多个业务页面使用，就不应直接覆盖旧状态。高风险变化可以新增变体或新版本，给使用方留出迁移时间；只影响局部页面的临时方案，则不必急着升级为公共组件。
一套组件从建立到复用，应该经过哪些检查
下面以“用户管理页”的状态按钮为例。组件通过检查后，再放入公共库；没有通过的内容先留在业务页面中验证。
| 检查阶段 | 需要确认的问题 | 通过标准 |
|---|---|---|
| 需求 | 它解决什么任务？用户在什么条件下使用？ | 有明确角色、目标和触发场景 |
| 结构 | 有哪些元素、尺寸、对齐和内容规则？ | 不同页面组合后仍保持布局稳定 |
| 状态 | 默认、悬停、禁用、加载、失败和成功如何表达？ | 每个状态都有视觉与行为说明 |
| 响应式 | 窄屏、长文案和多语言时如何变化？ | 不遮挡、不溢出，关键操作仍可发现 |
| 交付 | 研发需要哪些标注、变量和代码映射？ | 设计、原型和实现使用同一命名口径 |
| 维护 | 谁负责反馈、版本和废弃？ | 有负责人、变更记录和迁移说明 |
移动端还要额外检查点击区域、键盘/读屏可达性、横向滚动和错误信息位置。设计系统不是把桌面组件缩小，而是为不同容器定义可预期的行为。需要补充视觉、布局和交付规范时，可结合UI设计规范清单逐项核对。
组件命名和目录怎样设计，团队才找得到
目录按“平台—领域—组件—变体”组织，比按设计师姓名或页面名称组织更稳定。例如：
- 基础：Button、Input、Icon、Typography、Divider。
- 导航：Tabs、Breadcrumb、Pagination、SideNav。
- 反馈：Toast、Alert、Modal、Empty、Error。
- 业务：UserStatus、ApprovalStep、FilterBar、DataTable。
基础组件描述通用结构，业务组件描述明确任务。不要把“用户列表页面”直接当作组件，也不要把所有内容都抽象成通用卡片。抽象的最小单位应该是稳定的决策和行为，而不是视觉上相似的矩形。
用墨刀把设计系统放进真实协作流程
如果团队需要把变量、组件、原型和评审放在同一条工作链路中，可以在墨刀设计中先建立变量和组件，再把它们应用到真实页面。官方设计页当前展示了颜色、文字、数字等变量，以及带变体和交互的智能组件、自动布局和主题切换能力。
产品经理可以先用墨刀原型验证任务、页面和状态；设计师再把重复决策沉淀为变量和组件；研发根据标注、组件命名和交互说明确认实现边界。若团队正在搭建后台，可以参考B端后台设计系统与组件库，了解组件、模式和团队治理之间的关系。
组件库不是越大越好。每次复用前都要确认组件的状态、内容长度、权限和响应式行为是否适合当前任务；如果只是为了“看起来统一”而牺牲业务清晰度，应保留页面级方案并记录原因。
建立设计系统时最容易踩的四个坑
- 只做视觉，不做状态：组件看起来统一，但加载、禁用、错误和空状态各自为政。
- 只追求数量，不看复用：目录里有很多组件，实际页面仍然复制粘贴并自行修改。
- 只让设计维护：没有产品规则和研发映射，组件无法覆盖真实业务。
- 一次性大重构：没有迁移计划，旧页面和新组件长期并存，反而增加沟通成本。
发现这些问题时，优先修复最常用的一条任务链。设计系统的成熟度，体现在团队能否少做重复决策，而不是组件目录看起来有多完整。
发布前检查清单
- 是否明确了设计系统服务的产品、平台、角色和核心任务。
- 颜色、字体、间距、圆角和层级是否有统一变量来源。
- 每个公共组件是否定义了变体、状态、内容规则和交互行为。
- 组件是否在真实页面中验证过，而不是只展示静态画板。
- 加载、空、错误、无权限、禁用和长文案是否有明确表现。
- 命名、目录、负责人、版本和变更记录是否能被团队找到。
- 设计标注、原型交互和研发实现是否使用同一套术语。
- 组件升级是否有影响分析、迁移方式和回退路径。
常见问题
组件库和设计系统应该先做哪个
先确定目标和变量，再做一小组能支撑核心任务的组件，最后扩展成业务模式和治理机制。单独做组件库容易缺少使用边界，单独写规范又难以验证。
设计系统是不是要一次覆盖所有页面
不需要。先覆盖高频流程和容易产生差异的模块，再根据复用频率、维护成本和业务风险决定是否扩大范围。
什么时候应该把页面元素抽成组件
当它在多个页面重复出现，结构和行为已经稳定，并且团队可以清楚描述它的变体和状态时，才适合抽成公共组件。只相似一次的视觉区域，先留在页面里更容易维护。
设计变量和组件有什么关系
变量定义颜色、字体、尺寸和层级等基础决策，组件引用这些变量并增加结构、状态和行为。先有变量，组件才能在主题切换和统一调整时保持一致。
设计系统建立后还需要评审吗
需要。每次新增或升级组件，都要用真实页面检查任务、状态、内容长度、响应式和研发实现；设计系统本身也应随着产品和技术变化持续维护。
建立组件和设计系统的关键，不是收集更多素材，而是把高频决策变成团队可以复用、评审和维护的契约。先用真实任务确定范围，再用变量统一基础规则，用组件表达状态，用业务模式连接流程，最后用版本和负责人保证它能持续被使用。