--- title: 设计系统（Design System）完整指南：从三层架构到 AI 时代的实践 date: 2026-04-20 description: 设计系统到底是什么、为什么要做、怎么做？本文基于二十年互联网产品设计经验（从 Yahoo DPL 到阿里 Fusion Design 设计中台），系统讲解设计系统的三层架构（Foundation / Component / Pattern）、国内外代表案例（Ant Design / CloudScape / Material）、AI 时代的 DESIGN.md 新范式，以及谁来负责、如何推动的组织议题。收录 17 篇深度文章的完整学习路径。 author: 5key source: https://www.thefivekey.com/design-system/ --- # 设计系统（Design System）完整指南：从三层架构到 AI 时代的实践 > 设计系统到底是什么、为什么要做、怎么做？本文基于二十年互联网产品设计经验（从 Yahoo DPL 到阿里 Fusion Design 设计中台），系统讲解设计系统的三层架构（Foundation / Component / Pattern）、国内外代表案例（Ant Design / CloudScape / Material）、AI 时代的 DESIGN.md 新范式，以及谁来负责、如何推动的组织议题。收录 17 篇深度文章的完整学习路径。 **作者**：5key　·　**发布于**：2026-04-20　·　**原文链接**：https://www.thefivekey.com/design-system/ --- ![设计系统完整指南封面：从三层架构到 AI 时代的实践](https://cdn.thefivekey.com/designsystem.webp) *本文最后更新于 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% 的设计师所在公司都期望用设计系统来提升设计研发效能。这个诉求背后，其实是五件事： 1. **业务效率**：把重复性的界面设计沉淀到系统里，让设计师专注业务逻辑而不是画组件 2. **体验一致性**：多团队协作不可避免会产生差异，设计系统通过强约束对齐输出 3. **业务语言统一**：设计师、产品经理、研发工程师共享同一套术语和模块，沟通成本明显下降 4. **团队协作升级**：设计系统把"走流程"升级为"按标准组装"，把设计从交付环节拉回到决策环节 5. **人才培养**：新人快速融入、外部合作伙伴快速对接，组织能力沉淀到系统里 这五条在 [我们为什么要做 Design System](/why-we-need-design-system/) 这篇里有详细案例。如果你需要向你的老板证明设计系统的投入合理性，可以参考 [如何向你的主管和团队介绍 Design System 的重要性](/how-to-prove-the-value-of-design-system-to-your-boss/)。 ## 设计系统的三个层级：系统级 / 领域级 / 业务级 设计系统不是铁板一块。从抽象到具象，通常分三个层级： **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 案例解析](/how-to-learn-from-other-design-systems/)。 ## 核心构成：Foundation、Component、Pattern 三层架构 抛开层级，任何一套设计系统从技术构成上都可以拆成三层： ### Foundation（基础层） 风格定调：色彩、排版、栅格、间距、圆角、阴影、动效。 这层解决的是"**长什么样**"的问题，决定了整个产品的视觉气质。 布局框架是 Foundation 里经常被低估的部分，它决定了所有界面怎么组织。详见 [设计系统核心理论篇 – 布局框架](/design-system-layout-framework/)。 ### Component（组件层） 基础积木：Button、Input、Card、Tooltip 等。 Component 解决的是"**单点操作怎么做**"的问题。但很多团队在这层就以为自己做完了设计系统，这是一个常见误区。 ### Pattern（模式层） 场景化的组件组合：删除确认流、批量操作、表格筛选、空状态、错误处理等。 打个比方：Component 像做菜的单个步骤（切菜、焯水、炒制），Pattern 则是把这些步骤组合起来完成"**做一道小龙虾**"的完整方案。 Pattern 层是绝大多数团队真正的瓶颈，也是 **AI 时代最重要的资产**。详见 [设计模式库与设计组件库到底有什么区别？](/difference-between-design-pattern-and-design-component/)。 ### 决策树：让三层真正可用 光有三层定义还不够，还需要**决策树**帮设计师（以及 AI）做选择：遇到这个场景，该用哪个组件、配哪个 Pattern。 决策树是让设计系统"真正能用"的关键机制。它把分散的组件规范变成可执行的选择路径，既帮设计师做对选择，也为 AI 在界面生成时提供稳定逻辑。详见 [设计系统中的决策树：让设计决策更简单](/design-system-decision-tree/)。 ## 国内外代表性设计系统 讲完理论，看几个值得研究的实战案例： **[AWS CloudScape Design System](https://cloudscape.design/)**（B 端深度范本） 2016 年启动，2022 年开源。包含 66 个组件 + 5 大类 35 个 Pattern，是目前我见过的 B 端领域级设计系统里最务实、最有领域专业度的一套。强约束 + 明确的 Do / Don't，几乎每个 Pattern 都有在线配置示例。完整拆解：[如何规划 B端 设计系统？深度解析 AWS CloudScape](/b-end-design-system-deep-dive-aws-cloudscape/)。 **[IBM Carbon Design System](https://carbondesignsystem.com/)**（企业级开源老牌） IBM 十多年沉淀的企业级设计系统，覆盖设计原则、组件库、数据可视化、多品牌主题等完整体系。是全球最成熟的 B 端设计系统之一，文档结构化程度极高，适合作为学习样本。 **[Salesforce Lightning Design System](https://www.lightningdesignsystem.com/)**（B 端 SaaS 标杆） Salesforce 为其 CRM 生态打造的设计系统，是 SaaS 产品设计系统的典型代表。强调产品生态内的一致性和可扩展性，适合参考多产品矩阵场景下的设计治理思路。 **[Ant Design](https://ant.design/)**（领域级开源标杆） 国内 B 端设计系统的"事实标准"。2016 年发展至今，为无数企业的 0 到 1 产品建设提供了底层能力。 **[Fusion Design](https://fusion.design/)**（内聚型设计系统） 我在阿里主导建设的设计中台产品。与 Ant Design 面向开源生态不同，Fusion Design 后来聚焦为内部服务，支撑集团内（阿里、菜鸟、蚂蚁）数百条业务线。它的特色是强在线搭建能力，设计师在平台上配置，研发直接用，省掉中间翻译。在一些重点合作业务里实现了设计师提效 50%、研发提效 30% 的成果。 **[Ant Design X](https://x.ant.design/)**（会话式 AI 产品扩展） Ant Design 针对**会话式 AI 产品**推出的扩展（extension），不是独立的设计系统，而是在 Ant Design 基础组件之上，补充了 AI 对话、消息流、机器人头像、Prompt 输入等场景化组件与 Pattern。适合做类 ChatGPT / Copilot 形态产品时参考。详见 [从 Ant Design X 探索 AI 产品领域设计系统](/ant-design-x-ai-product-design-system/)。 **[Material Design](https://m3.material.io/) / [Human Interface Guidelines](https://developer.apple.com/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](/design-system-as-markdown/)。 不过 AI 真要自己完整生成产品界面还很远，从概念到落地还有大量障碍。背景阅读： - [从概念到落地，产品界面的 AI 生成究竟卡在哪儿了？](/ai-generated-ui-not-work/) - [Salesforce 的生成式画布，证明了 AI 在产品界面设计中的可行性？](/salesforce-generative-canvas-proves-ai-ui-design-feasibility/) ## 谁来建设设计系统：架构型设计师的崛起 设计系统的卡点很多时候不在工作本身，而在"**谁来负责**"。 从我过去十几年的观察来看，设计系统不适合分派给全员，它需要由有抽象能力、有业务经验的设计师来牵头。这个角色我在 2020 年就提出了一个名字：**架构型设计师**。 架构型设计师不直接画界面，而是通过构建设计系统、管理设计资产、推动设计运营，让整个团队的输出标准化、规模化。深度展开：[成为架构型设计师](/become-an-architectural-designer/)。 这几年随着设计系统的成熟，体验设计师的角色正在分化为两类： - 一类继续深入构建系统、制定规则：**架构型设计师** - 另一类深入业务一线，把 Pattern 和组件当成"标准件"拼装：**业务型设计师** 继续做通用 UX 是最危险的位置，它正是最容易被 AI 和产品经理上下夹击的中间层。详见 [设计师的下一站，成为架构师，还是走向业务？](/designer-architect-or-business/)。 关于谁主导、产品经理要不要参与、前端工程师在里面扮演什么角色，见 [设计系统究竟应该由谁来负责？](/who-should-own-design-system/)。 ## 场景化延展：从 PPT 到表单 设计系统不只属于 B 端中后台： - **PPT 工具**：iA Presenter、Paste 这类新工具正在把设计系统理念引入 PPT 领域，让 PPT 从画图变成组织信息。详见 [设计系统在 PPT 领域的应用](/design-system-in-ppt/)。 - **表单设计**：表单是所有数字产品的基础动作。设计系统的底层逻辑在表单上有最高的复用率。详见 [表单设计的基础设计逻辑](/design-strategies-for-form-design/)。 ## 常见问题（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](/why-we-need-design-system/) - [Design System 应该做到什么程度才够？](/what-should-a-design-system-look-like/) - [如何向你的主管和团队介绍 Design System 的重要性](/how-to-prove-the-value-of-design-system-to-your-boss/) - [2022 Design System 调研总结](/design-system-survey-2022/) ### 理论基础 - [设计系统学习指南 - 国内外 Design System 案例解析](/how-to-learn-from-other-design-systems/) - [设计系统核心理论篇 – 布局框架](/design-system-layout-framework/) - [设计模式库与设计组件库到底有什么区别？](/difference-between-design-pattern-and-design-component/) - [设计系统中的决策树：让设计决策更简单](/design-system-decision-tree/) ### 实战案例 - [如何规划 B端 设计系统？深度解析 AWS CloudScape](/b-end-design-system-deep-dive-aws-cloudscape/) - [从 Ant Design X 探索 AI 产品领域设计系统](/ant-design-x-ai-product-design-system/) ### AI 时代 - [Google DESIGN.md 实践：把设计系统写成 AI 能读的 Markdown](/design-system-as-markdown/) - [从概念到落地，产品界面的 AI 生成究竟卡在哪儿了？](/ai-generated-ui-not-work/) - [Salesforce 的生成式画布，证明了 AI 在产品界面设计中的可行性？](/salesforce-generative-canvas-proves-ai-ui-design-feasibility/) ### 组织与职业 - [设计系统究竟应该由谁来负责？](/who-should-own-design-system/) - [成为架构型设计师](/become-an-architectural-designer/) - [设计师的下一站，成为架构师，还是走向业务？](/designer-architect-or-business/) ### 场景应用 - [设计系统在 PPT 领域的应用](/design-system-in-ppt/) - [表单设计的基础设计逻辑](/design-strategies-for-form-design/) --- _本文由 [5key](https://www.thefivekey.com/) 创作，原文发布于 [https://www.thefivekey.com/design-system/](https://www.thefivekey.com/design-system/)。欢迎引用，请注明出处。_ _订阅付费专栏「OFF DESIGN」：https://www.thefivekey.com/premium-design-subscription/_