设计系统（Design System）完整指南：从三层架构到 AI 时代的实践
本文最后更新于 2026 年 4 月 20 日
TL;DR
设计系统不是"画规范"，而是把设计从个人手艺升级为可复用的资产。
它的骨架由三层构成：Foundation（基础）、Component（组件）、Pattern（模式）。
本文基于我从 Yahoo DPL 到阿里 Fusion Design 的十多年设计系统建设经验，带你从定义到落地、从传统实践到 AI 时代的新范式，完整走一遍设计系统这件事。
设计系统（Design System）是什么？
设计系统是一套可复用的设计资产、使用约束和决策规则的集合，目的是让一个产品或一家公司的所有界面设计保持一致、可规模化生产。
它很容易被混淆成 UI Kit、Style Guide 或 Figma / React 组件库，但这些其实只是设计系统的一部分。真正的设计系统在"有什么素材"之上，还要回答"在什么场景下该用哪个、为什么这么用、什么时候不该用"——这层决策约束才是它和普通组件库的本质区别。
简单地说：设计系统是把"设计的知识"从人的头脑里提炼出来，变成团队（未来还有 AI）可消费的资产。它由三部分组成：Foundation（基础规则，如色彩、排版）、Component（可复用的组件，如按钮、输入框）、Pattern（场景化的模式，如删除确认流、批量操作）。其中 Pattern 是最容易被忽略也最关键的一层，它定义了"在具体业务场景下该怎么组合这些组件"，是 AI 时代设计系统真正的价值所在。
为什么要做设计系统：五个核心价值
2022 年我做过一次设计系统调研，90% 的设计师所在公司都期望用设计系统来提升设计研发效能。这个诉求背后，其实是五件事：
- 业务效率：把重复性的界面设计沉淀到系统里，让设计师专注业务逻辑而不是画组件
- 体验一致性：多团队协作不可避免会产生差异，设计系统通过强约束对齐输出
- 业务语言统一：设计师、产品经理、研发工程师共享同一套术语和模块，沟通成本明显下降
- 团队协作升级：设计系统把"走流程"升级为"按标准组装"，把设计从交付环节拉回到决策环节
- 人才培养：新人快速融入、外部合作伙伴快速对接，组织能力沉淀到系统里
这五条在 我们为什么要做 Design System 这篇里有详细案例。如果你需要向你的老板证明设计系统的投入合理性，可以参考 如何向你的主管和团队介绍 Design System 的重要性 。
设计系统的三个层级：系统级 / 领域级 / 业务级
设计系统不是铁板一块。从抽象到具象，通常分三个层级：
1. 系统级（Platform Level）
操作系统或浏览器级别的设计系统，提供最底层的设计及研发指引。代表作：Apple Human Interface Guidelines、Google Material Design、Microsoft Fluent Design。
这些系统为用户建立基础认知，确保一个应用在基础交互层面的体验基线。
2. 领域级（Domain Level）
聚焦于某一类通用场景（当前最成熟的是企业级 / B 端）的设计及研发指引。代表作：Ant Design（阿里）、Fusion Design（阿里）、Semi Design（字节）、Arco Design（字节）、TDesign（腾讯）、IBM Carbon、Salesforce Lightning、AWS CloudScape。
领域级系统的目标是帮助业务在同类场景下快速完成 0 到 1。
3. 业务级（Product Level）
在系统级 / 领域级基础上，为具体产品或业务做二次定义。这是绝大多数设计师日常工作的层级，基于通用设计系统做行业化、业务化的特定方案。
完整的层级对比与代表案例分析：设计系统学习指南 - 国内外 Design System 案例解析 。
核心构成：Foundation、Component、Pattern 三层架构
抛开层级，任何一套设计系统从技术构成上都可以拆成三层：
Foundation（基础层）
风格定调：色彩、排版、栅格、间距、圆角、阴影、动效。
这层解决的是"长什么样“的问题，决定了整个产品的视觉气质。
布局框架是 Foundation 里经常被低估的部分，它决定了所有界面怎么组织。详见 设计系统核心理论篇 – 布局框架 。
Component（组件层）
基础积木：Button、Input、Card、Tooltip 等。
Component 解决的是”单点操作怎么做“的问题。但很多团队在这层就以为自己做完了设计系统，这是一个常见误区。
Pattern（模式层）
场景化的组件组合：删除确认流、批量操作、表格筛选、空状态、错误处理等。
打个比方：Component 像做菜的单个步骤（切菜、焯水、炒制），Pattern 则是把这些步骤组合起来完成”做一道小龙虾“的完整方案。
Pattern 层是绝大多数团队真正的瓶颈，也是 AI 时代最重要的资产。详见 设计模式库与设计组件库到底有什么区别？ 。
决策树：让三层真正可用
光有三层定义还不够，还需要决策树帮设计师（以及 AI）做选择：遇到这个场景，该用哪个组件、配哪个 Pattern。
决策树是让设计系统"真正能用"的关键机制。它把分散的组件规范变成可执行的选择路径，既帮设计师做对选择，也为 AI 在界面生成时提供稳定逻辑。详见 设计系统中的决策树：让设计决策更简单 。
国内外代表性设计系统
讲完理论，看几个值得研究的实战案例：
AWS CloudScape Design System （B 端深度范本）
2016 年启动，2022 年开源。包含 66 个组件 + 5 大类 35 个 Pattern，是目前我见过的 B 端领域级设计系统里最务实、最有领域专业度的一套。强约束 + 明确的 Do / Don’t，几乎每个 Pattern 都有在线配置示例。完整拆解：如何规划 B端 设计系统？深度解析 AWS CloudScape 。
IBM Carbon Design System （企业级开源老牌）
IBM 十多年沉淀的企业级设计系统，覆盖设计原则、组件库、数据可视化、多品牌主题等完整体系。是全球最成熟的 B 端设计系统之一，文档结构化程度极高，适合作为学习样本。
Salesforce Lightning Design System （B 端 SaaS 标杆）
Salesforce 为其 CRM 生态打造的设计系统，是 SaaS 产品设计系统的典型代表。强调产品生态内的一致性和可扩展性，适合参考多产品矩阵场景下的设计治理思路。
Ant Design （领域级开源标杆）
国内 B 端设计系统的"事实标准”。2016 年发展至今，为无数企业的 0 到 1 产品建设提供了底层能力。
Fusion Design （内聚型设计系统）
我在阿里主导建设的设计中台产品。与 Ant Design 面向开源生态不同，Fusion Design 后来聚焦为内部服务，支撑集团内（阿里、菜鸟、蚂蚁）数百条业务线。它的特色是强在线搭建能力，设计师在平台上配置，研发直接用，省掉中间翻译。在一些重点合作业务里实现了设计师提效 50%、研发提效 30% 的成果。
Ant Design X （会话式 AI 产品扩展）
Ant Design 针对会话式 AI 产品推出的扩展（extension），不是独立的设计系统，而是在 Ant Design 基础组件之上，补充了 AI 对话、消息流、机器人头像、Prompt 输入等场景化组件与 Pattern。适合做类 ChatGPT / Copilot 形态产品时参考。详见 从 Ant Design X 探索 AI 产品领域设计系统 。
Material Design / Human Interface Guidelines
系统级设计系统的典范，适合作为底层认知基础来读。
AI 时代的新范式：设计系统变成 AI 的上下文
2026 年的 AI Coding 时代，设计系统的消费者正在发生根本变化：从"人类设计师 + 研发"，到"AI Agent"。
Google 提出的 DESIGN.md 是这个变化里最值得关注的一个轻量方案。它把设计系统的核心约束（色彩、排版、组件规则、Do’s and Don’ts）写成 Markdown 放进代码仓库，让 AI 编码助手（Claude Code、Cursor、Codex）在每次 Coding 前读取。
这个思路的核心不在 Markdown 这个载体，而在"设计约束变成 AI 可消费的上下文“这个本质。完整实践：Google DESIGN.md 实践：把设计系统写成 AI 能读的 Markdown 。
不过 AI 真要自己完整生成产品界面还很远，从概念到落地还有大量障碍。背景阅读：
谁来建设设计系统：架构型设计师的崛起
设计系统的卡点很多时候不在工作本身，而在”谁来负责"。
从我过去十几年的观察来看，设计系统不适合分派给全员，它需要由有抽象能力、有业务经验的设计师来牵头。这个角色我在 2020 年就提出了一个名字：架构型设计师。
架构型设计师不直接画界面，而是通过构建设计系统、管理设计资产、推动设计运营，让整个团队的输出标准化、规模化。深度展开：成为架构型设计师 。
这几年随着设计系统的成熟，体验设计师的角色正在分化为两类：
- 一类继续深入构建系统、制定规则：架构型设计师
- 另一类深入业务一线，把 Pattern 和组件当成"标准件"拼装：业务型设计师
继续做通用 UX 是最危险的位置，它正是最容易被 AI 和产品经理上下夹击的中间层。详见 设计师的下一站，成为架构师，还是走向业务？ 。
关于谁主导、产品经理要不要参与、前端工程师在里面扮演什么角色，见 设计系统究竟应该由谁来负责？ 。
场景化延展：从 PPT 到表单
设计系统不只属于 B 端中后台：
- PPT 工具：iA Presenter、Paste 这类新工具正在把设计系统理念引入 PPT 领域，让 PPT 从画图变成组织信息。详见 设计系统在 PPT 领域的应用 。
- 表单设计：表单是所有数字产品的基础动作。设计系统的底层逻辑在表单上有最高的复用率。详见 表单设计的基础设计逻辑 。
常见问题（FAQ）
什么时候该开始做设计系统？
产品进入稳定期、有 3 个以上并行的功能模块或业务线、或你发现设计师每天都在重复画同样的组件时，就该开始了。不建议在 0 到 1 阶段投入，那时候业务还没摸清，过早抽象只会造成浪费。
个人或小团队也能做设计系统吗？
能。以前这是大团队才干的事，但在 AI 时代不同了。借助 Shadcn/ui 这类开源组件库 + Claude Code 等 AI 工具 + DESIGN.md 规范，一个人也能搭起一套足以约束 AI 生成的设计系统。
设计系统和 UI Kit、Style Guide 有什么区别？
UI Kit 只是静态元素集合，Style Guide 提供视觉规则，而设计系统在两者之上增加了决策约束（什么时候用、不用、为什么）。一句话：UI Kit 回答"有什么"，设计系统还回答"怎么选"。
怎么度量设计系统的价值？
常见三个维度：生产效率（单页面交付时长）、一致性（视觉审查通过率）、协作质量（设计还原度、跨团队对齐速度）。在阿里我们用「单页面成本 = 平均工时工资 × 单页面交付时长」来直观核算。
AI 时代设计系统会消失吗？
恰恰相反，会更重要。AI 不会消灭设计系统，它会消费设计系统。AI 越强，越需要一套清晰、结构化的设计约束来指导它的生成。没有设计系统的 AI Coding 就是不受控的猜测。
设计系统和 Figma 组件库是一回事吗？
不是。Figma 组件库只是设计系统在 Figma 里的呈现形式（或一部分），真正的设计系统还应该包括：研发实现（React / Vue 组件库）、使用文档、决策规则、Do / Don’t。光有 Figma 组件库，设计师手里的组件到研发那里可能完全变形。
设计系统做起来要多少人？
取决于规模。业务级设计系统 1-2 个架构型设计师 + 1-2 个前端工程师就能启动。领域级需要 5-10 人的稳定小组。系统级则至少 30 人以上的专职团队。
完整文章索引（延伸阅读）
按主题分组的 17 篇深度文章：
入门与价值
- 我们为什么要做 Design System
- Design System 应该做到什么程度才够？
- 如何向你的主管和团队介绍 Design System 的重要性
- 2022 Design System 调研总结
理论基础
实战案例
AI 时代
- Google DESIGN.md 实践：把设计系统写成 AI 能读的 Markdown
- 从概念到落地，产品界面的 AI 生成究竟卡在哪儿了？
- Salesforce 的生成式画布，证明了 AI 在产品界面设计中的可行性？