设计系统

设计原则是设计系统在视觉与交互层面之上的决策依据，通常以一组简短、可记忆的陈述句表达，用于在具体设计取舍中提供判断标准，而非规定具体的颜色、间距或组件形态。^{88Design Systems: A practical guide to creating design languages for digital productssmashingmagazine.com前往参考资料 ↓在新标签页中打开|99Design Principles — Design Systems Handbookdesignbetter.co前往参考资料 ↓在新标签页中打开}

在构成上，设计原则与设计令牌、组件库、模式库、文档与治理流程并列，属于设计系统的基础层；它回答“为什么这样设计”，而令牌与组件回答“具体做成什么样”。^{88Design Systems: A practical guide to creating design languages for digital productssmashingmagazine.com前往参考资料 ↓在新标签页中打开|1010Design Systemsalistapart.com前往参考资料 ↓在新标签页中打开}

设计原则通常需要具备可操作性：每条原则应能对应到可观察的设计决策或评审问题，否则容易沦为口号。实践中常以“原则—含义—应用示例”的三段式来组织表述。^{99Design Principles — Design Systems Handbookdesignbetter.co前往参考资料 ↓在新标签页中打开|1111Building a Design System: Principles, Patterns, and Practicesoreilly.com前往参考资料 ↓在新标签页中打开}

设计原则的制定通常由设计系统团队牵头，但需要产品、工程、内容与无障碍等角色共同参与评审，以保证原则覆盖跨职能的约束条件。^{1010Design Systemsalistapart.com前往参考资料 ↓在新标签页中打开|1212Design System Governanceuxdesign.cc前往参考资料 ↓在新标签页中打开}

设计原则并非一成不变：随着产品线扩展、品牌更新或无障碍法规变化，原则需要定期复审与修订，修订记录本身也是设计系统文档的一部分。^{1111Building a Design System: Principles, Patterns, and Practicesoreilly.com前往参考资料 ↓在新标签页中打开|1212Design System Governanceuxdesign.cc前往参考资料 ↓在新标签页中打开}

部分组织将无障碍与包容性作为独立的设计原则列出，例如要求对比度、键盘可达性与动效可关闭等，以便在评审中作为硬性检查项。^{1313Web Content Accessibility Guidelines (WCAG) 2.2w3.org前往参考资料 ↓在新标签页中打开}

设计原则与品牌价值观存在区别：品牌价值观面向市场传播，措辞偏感性；设计原则面向内部决策，措辞偏可执行，两者可以共享语汇但不应互相替代。^{99Design Principles — Design Systems Handbookdesignbetter.co前往参考资料 ↓在新标签页中打开|1212Design System Governanceuxdesign.cc前往参考资料 ↓在新标签页中打开}

组件库是设计系统中可复用组件的集合，这些组件由明确的标准约束，可以被组装起来构建任意数量的应用；设计系统借助组件库来产出风格一致、质量稳定的用户界面。^{1414Build web apps with ASP.NET Core for beginners - Traininglearn.microsoft.com前往参考资料 ↓在新标签页中打开}

在微软面向初学者的 ASP.NET Core 教学材料中，设计系统被直接定义为「可复用组件的集合，并由清晰的标准加以引导」，这一定义把组件库放在设计系统的核心位置，而不是把它当作可有可无的附属产物。^{1414Build web apps with ASP.NET Core for beginners - Traininglearn.microsoft.com前往参考资料 ↓在新标签页中打开}

组件库与设计令牌、样式规范之间是分层关系：令牌与样式抽象负责表达视觉与主题层面的决策，组件库则把这些决策固化为带行为、带交互状态的界面单元，供产品团队直接调用。^{1414Build web apps with ASP.NET Core for beginners - Traininglearn.microsoft.com前往参考资料 ↓在新标签页中打开}

组件库的价值主张在于「一次定义、多处复用」：同一组件在多个应用中被反复组装，从而在跨产品范围内维持一致的外观与交互，并降低重复实现带来的维护成本。^{1414Build web apps with ASP.NET Core for beginners - Traininglearn.microsoft.com前往参考资料 ↓在新标签页中打开}

组件库通常需要配套的使用标准与文档，否则「可复用」会退化为「可复制」——组件被各自改写后失去一致性，这也是设计系统强调「由清晰标准引导」的原因。^{1414Build web apps with ASP.NET Core for beginners - Traininglearn.microsoft.com前往参考资料 ↓在新标签页中打开}

样式令牌（Design Tokens）是设计系统中最底层的原子级定义，用于把色彩、字体、间距、圆角、阴影、动效时长等设计决策抽象为可复用的命名变量；任何组件的样式都应从令牌派生，而不是在代码或设计稿中硬编码具体数值。^{1515B端产品设计规范怎么建立？组件库与设计系统实战_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

在典型的分层结构中，样式令牌位于设计系统的第一层，其上是原子组件（按钮、输入框、下拉选择、单选框、复选框、开关、标签、徽章等），再上是业务组件（数据表格、表单、搜索面板等）；令牌层为后两层提供统一的视觉与行为参数。^{1515B端产品设计规范怎么建立？组件库与设计系统实战_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

色彩令牌通常按语义而非按色值组织，包含主色、功能色（成功、警告、错误、信息）、中性色阶（从白到黑的灰度梯度）以及业务色；这种语义化命名使主题切换与品牌换色只需替换令牌值，而不必逐处修改组件。^{1515B端产品设计规范怎么建立？组件库与设计系统实战_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

字体令牌定义标题、正文、辅助文字等层级的字号、行高与字重；间距令牌则常以 4px 为基准单位，要求组件内外边距均为 4 的倍数，从而在整站范围内形成可预期的节奏与对齐关系。^{1515B端产品设计规范怎么建立？组件库与设计系统实战_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

圆角、阴影、动效时长等视觉属性同样需要令牌化，它们与色彩、字体、间距一起构成设计决策的源头；缺少这一层抽象时，多团队并行开发容易导致视觉风格混乱、交互逻辑不一致。^{1515B端产品设计规范怎么建立？组件库与设计系统实战_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

令牌与组件变体之间存在组合放大效应：以按钮为例，类型（主要、次要、文字、危险）、尺寸（大、中、小）与状态（默认、悬停、聚焦、激活、禁用、加载、错误）相乘，单个按钮组件的变体数量可达数十种，这正是需要令牌统一约束样式来源的现实原因。^{1515B端产品设计规范怎么建立？组件库与设计系统实战_产品设计_IT资讯-中培伟业官网m.zpedu.com前往参考资料 ↓在新标签页中打开}

使用指南与文档是设计系统的组成部分之一：设计系统把品牌色、字体排印、间距、层级、栅格以及使用指南等视觉语言的各层内容收拢到同一份制品中，使用指南与令牌、组件并列，而不是附属说明。^{1616Overview - Kombai Docsdocs.kombai.com前往参考资料 ↓在新标签页中打开}

文档的定位是「单一事实来源」：设计系统不只是好看的样式指南，而是 UI 与 UX 设计的统一事实来源；投入文档、设计令牌与组件库，可以减少复制粘贴造成的错误，并让产品在各平台上保持一致。^{1717What does a design system include? - zeroheightzeroheight.com前往参考资料 ↓在新标签页中打开}

好的使用指南要回答「做什么」和「为什么」，而不只是描述外观长什么样；文档需要说明使用规则背后的理由，才能让使用者在具体场景中做出正确判断。^{1717What does a design system include? - zeroheightzeroheight.com前往参考资料 ↓在新标签页中打开}

文档内容可以按「设计原则」等条目组织：设计原则是设计系统要素清单中的一项，通常以简短条目形式给出，用于在审计或新建设计系统时逐项对照。^{1717What does a design system include? - zeroheightzeroheight.com前往参考资料 ↓在新标签页中打开}

在文件化的设计系统实现中，结构化令牌与文字指南可以分置于同一文件的不同部分：以 Markdown 加 YAML front-matter 的形式，front-matter 承载结构化令牌，Markdown 正文承载散文式的使用指导。^{1616Overview - Kombai Docsdocs.kombai.com前往参考资料 ↓在新标签页中打开}

文档的覆盖范围应随系统扩展而延伸：设计系统文档需要指明「在哪里记录一切」，使系统在团队与产品规模扩大后仍可维护。^{1717What does a design system include? - zeroheightzeroheight.com前往参考资料 ↓在新标签页中打开}

在主流实践中，一个设计系统通常由三部分构成：设计原则（design principle）、风格规范（style guide）与模式/组件库（pattern lib / component lib）；这三者各自都是出现很早的概念，设计系统的“新”在于把它们组织成一个整体。^{1818设计系统简史——过去，现在与可能的将来infoq.cn前往参考资料 ↓在新标签页中打开}

设计原则的源头可追溯到 20 世纪初的格式塔理论，其提出的亲密性、连续性、闭合性等原则成为图形设计的美学基石，被反复援引为设计原则的早期规整形态。^{1818设计系统简史——过去，现在与可能的将来infoq.cn前往参考资料 ↓在新标签页中打开}

风格规范（style guide）并非新事物：在网页与软件界面普及之前，品牌与出版领域已有成文的视觉规范文档，设计系统在这一点上继承的是既有的文档化传统。^{1818设计系统简史——过去，现在与可能的将来infoq.cn前往参考资料 ↓在新标签页中打开}

在 2016 年前后，“设计系统”一词已进入设计师招聘要求，典型表述是“熟悉至少一种设计系统，例如 HIG 或者 Material Design”，说明当时业界已把平台级设计规范当作可命名的对象来要求。^{1818设计系统简史——过去，现在与可能的将来infoq.cn前往参考资料 ↓在新标签页中打开}

早期接触设计系统的人往往先把它理解为一份详尽的规范文档，例如通过 Material Design 指南去记 dp 单位、FAB 按钮、toast 与 snackbar 的区别；这种“文档视角”是设计系统演进初期的典型认知形态。^{1818设计系统简史——过去，现在与可能的将来infoq.cn前往参考资料 ↓在新标签页中打开}

从“文档”到“系统化”的转变，核心不在于新增了规范条目，而在于把设计原则、风格规范与组件库三者以可复用的方式耦合起来，使规范从被阅读的文本变成被引用的实现。^{1818设计系统简史——过去，现在与可能的将来infoq.cn前往参考资料 ↓在新标签页中打开}

设计系统领域长期存在关于其兴衰与新旧的持续讨论，几乎每个月都有新的设计系统诞生或衰落的消息与争论，这表明该领域的边界与最佳形态至今仍在变动之中。^{1818设计系统简史——过去，现在与可能的将来infoq.cn前往参考资料 ↓在新标签页中打开}

原子设计（Atomic Design）方法由美国前端开发者布拉德·弗罗斯特（Brad Frost）于 2013 年前后在其个人博客和演讲中系统提出，主张将界面拆解为原子（Atoms）、分子（Molecules）、有机体（Organisms）、模板（Templates）、页面（Pages）五个由小到大的层级，以此组织设计系统的构件。^{1919Atomic Designbradfrost.com前往参考资料 ↓在新标签页中打开}

弗罗斯特于 2016 年出版《Atomic Design》一书，将该方法从博客文章扩展为完整的方法论，书中明确把原子设计定位为“不是线性流程，而是一种心智模型”，用于同时指导设计与开发。^{2020Atomic Design (book)atomicdesign.bradfrost.com前往参考资料 ↓在新标签页中打开}

原子设计提出的直接背景是响应式网页设计（Responsive Web Design）的普及：同一套界面需要在手机、平板、桌面等多种屏幕尺寸下复用与重组，传统的“页面—模板”两级结构难以支撑细粒度的复用，促使社区转向更细的构件分层。^{1919Atomic Designbradfrost.com前往参考资料 ↓在新标签页中打开|2020Atomic Design (book)atomicdesign.bradfrost.com前往参考资料 ↓在新标签页中打开}

2013 年至 2015 年间，Web Components 规范（Custom Elements、Shadow DOM、HTML Templates）的推进，以及 React（2013 年开源）、Vue（2014 年发布）等组件化前端框架的兴起，使“组件”成为前端工程的一等公民，为原子设计从设计方法落地为代码结构提供了技术条件。^{2121Web Componentsdeveloper.mozilla.org前往参考资料 ↓在新标签页中打开}

原子设计方法在 2015 年后被广泛引入企业设计系统实践，Pattern Lab 等配套工具被用于按原子层级组织模式库；此后多家公司的设计系统文档公开采用或讨论原子层级划分，使其成为设计系统领域最常被引用的构件分层模型之一。^{2020Atomic Design (book)atomicdesign.bradfrost.com前往参考资料 ↓在新标签页中打开|2222Pattern Labpatternlab.io前往参考资料 ↓在新标签页中打开}

设计令牌（design tokens，亦称 style tokens）指以命名实体形式存储核心设计属性、并可转换后跨多平台使用的抽象层，被普遍视为现代设计系统连接设计与开发的骨干机制。^{2424The Role of Style Tokens in Modern Design Systems: Ensuring Consistency and Flexibility | Journal of Information Systems Engineering and Managementjisem-journal.com前往参考资料 ↓在新标签页中打开}

设计令牌的概念在方法上承接原子设计（Atomic Design）等组件化思想，并由 Nathan Curtis 等从业者与评论者加以扩展和推广，从而逐步从实践惯例走向可讨论的工程对象。^{2424The Role of Style Tokens in Modern Design Systems: Ensuring Consistency and Flexibility | Journal of Information Systems Engineering and Managementjisem-journal.com前往参考资料 ↓在新标签页中打开}

围绕设计令牌的研究与总结在 2020 年代中期已形成较系统的文献，讨论重点包括令牌的演进脉络、创建的最佳实践、不同领先企业之间令牌结构的比较，以及一致性与灵活性之间的平衡。^{2424The Role of Style Tokens in Modern Design Systems: Ensuring Consistency and Flexibility | Journal of Information Systems Engineering and Managementjisem-journal.com前往参考资料 ↓在新标签页中打开}

设计令牌之所以被视为标准化的抓手，在于它把颜色、字体、间距等设计决策从具体平台与具体组件中剥离为可命名、可转换的中间层，使同一套设计属性能够被映射到 Web、移动端等多个目标平台。^{2424The Role of Style Tokens in Modern Design Systems: Ensuring Consistency and Flexibility | Journal of Information Systems Engineering and Managementjisem-journal.com前往参考资料 ↓在新标签页中打开}

在标准化进程中，设计令牌的讨论重心从“是否使用令牌”转向“如何组织令牌结构”，即命名层级、语义化程度与跨企业可比性成为主要议题。^{2424The Role of Style Tokens in Modern Design Systems: Ensuring Consistency and Flexibility | Journal of Information Systems Engineering and Managementjisem-journal.com前往参考资料 ↓在新标签页中打开}

设计令牌按具体程度分为不同层级，常见划分是三层：原始令牌（primitive tokens）只存放原始值、不引用其他令牌；语义令牌（semantic tokens）为令牌赋予使用语境，通常引用一个原始令牌；组件令牌（component tokens）面向具体组件，引用语义令牌与原始令牌。^{2525Naming Approach | Design Tokens | Compound Design Systemcompound.thephoenixgroup.com前往参考资料 ↓在新标签页中打开|2626SKILL.mdgithub.com前往参考资料 ↓在新标签页中打开}

在主题化实践中，语义令牌与组件令牌是构建主题的主要层级，原始令牌只在边缘场景直接使用；原始令牌通常作为值被别名到每个语义令牌或组件令牌上。^{2525Naming Approach | Design Tokens | Compound Design Systemcompound.thephoenixgroup.com前往参考资料 ↓在新标签页中打开}

层级之间通过别名（alias）串联：语义令牌的值指向原始令牌，组件令牌的值再指向语义令牌，从而形成从原始值到具体使用位置的引用链。^{2525Naming Approach | Design Tokens | Compound Design Systemcompound.thephoenixgroup.com前往参考资料 ↓在新标签页中打开|2626SKILL.mdgithub.com前往参考资料 ↓在新标签页中打开}

令牌命名由意图（intent）与属性（property）组合而成，使名称自解释；例如语义令牌 --co-feedback-danger-text 的值为 var(red-800)，名称表达用途、值指向原始色阶。^{2525Naming Approach | Design Tokens | Compound Design Systemcompound.thephoenixgroup.com前往参考资料 ↓在新标签页中打开}

组件令牌层负责把语义令牌映射到组件属性上，即回答“这个值用在哪里”，是三层结构中最贴近具体应用的一层。^{2626SKILL.mdgithub.com前往参考资料 ↓在新标签页中打开}

设计令牌的跨平台映射以 W3C 设计令牌社区组（DTCG）的格式作为互操作目标，该格式用 $value、$type、$description 三个字段描述令牌，并支持通过 {color.blue.600} 这类花括号别名引用其他令牌；但该规范仍在演进中，工程上应在每次接入前核对规范状态与工具版本。^{2727Knowledge — Design-systems tooling reference (2026)raw.githubusercontent.com前往参考资料 ↓在新标签页中打开|282803-design-systems-components.mdgithub.com前往参考资料 ↓在新标签页中打开}

跨平台映射的可行前提是令牌的三层架构：原始层（primitive/global）只存原始值如 color.blue.600、space.4，语义层（semantic/alias）赋予含义如 color.bg.accent、color.text.danger 并充当对外公开的 API，组件层（component）仅在某个组件需要独立换肤时少量使用；每一层只引用下一层，因此换平台时只需替换原始层到目标平台的取值，语义层与组件层的名称保持不变。^{282803-design-systems-components.mdgithub.com前往参考资料 ↓在新标签页中打开}

设计系统被视作一份 API 契约而非一份 Figma 文件，其质量判据是产品团队能否在不与设计系统团队沟通的情况下独立构建出正确、可访问且符合品牌的界面；跨平台映射正是这条判据在多端场景下的直接延伸——语义令牌名就是这份契约在各平台上的公共接口。^{282803-design-systems-components.mdgithub.com前往参考资料 ↓在新标签页中打开}

2026 年的工具版图中，Figma Variables 等设计侧变量机制与 DTCG 格式之间的对接是令牌跨平台流转的关键环节，但具体工具的配置 API 与主版本变动频繁，属于易变信息，引用时须以工具当前文档与发布说明为准，不能把某一时点的配置写法当作长期稳定的做法。^{2727Knowledge — Design-systems tooling reference (2026)raw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

跨平台映射中可长期沿用的原则是令牌分层、组合、把设计系统当作契约做语义化版本管理，以及在首版即纳入可访问性；这些原则不随工具更替而变化，而具体的工具名称、版本号与规范状态则带有检索时效，需要标注核对日期。^{2727Knowledge — Design-systems tooling reference (2026)raw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

主题化（theming）在设计令牌体系中依赖一层「间接层」：组件不直接消费具体色值，而是消费语义令牌（如 text-primary），由主题在运行时或构建时把语义令牌映射到不同的原始值，从而在不改动组件代码的前提下切换外观。^{2929供应链控制塔 | 暗黑模式与主题系统：CSS-in-JS + Design Token 实践-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开|3030README.mdgithub.com前往参考资料 ↓在新标签页中打开}

实现明暗双主题的常见做法是维护两份结构完全一致、仅取值不同的令牌映射（light 与 dark 同名不同值），组件按名引用令牌，切换主题时自动取到对应色值，避免在组件内写死颜色或用媒体查询散落切换逻辑。^{2929供应链控制塔 | 暗黑模式与主题系统：CSS-in-JS + Design Token 实践-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

把语义令牌扁平化为 CSS 自定义属性（如 --color-text-primary）是一种常见的降级与桥接方案：令牌在构建期或运行期被转换为 CSS 变量，使不接入 CSS-in-JS 运行时的样式与第三方图表库也能共享同一套主题值。^{2929供应链控制塔 | 暗黑模式与主题系统：CSS-in-JS + Design Token 实践-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

主题化不只覆盖界面组件，还需向图表与可视化层联动：ECharts、G6、Mapbox 等图表库需要注册与当前主题匹配的主题配置，才能做到「一处修改、全局响应」，否则会出现界面已切换而图表配色滞后的割裂。^{2929供应链控制塔 | 暗黑模式与主题系统：CSS-in-JS + Design Token 实践-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

暗色模式的价值主张包括降低长时间盯屏的视觉疲劳、减少 OLED 屏幕烧屏风险，以及通过高对比度配色让关键告警信息更突出；这些是 24 小时值守类指挥中心场景采用暗色主题的主要动因。^{2929供应链控制塔 | 暗黑模式与主题系统：CSS-in-JS + Design Token 实践-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

暗色模式通常需要提供不止两态的控制（如跟随系统、强制亮色、强制暗色），并配合无障碍要求校验对比度，因为暗色背景下的语义色（尤其是状态色与文字色）需要单独校准而非简单反相。^{2929供应链控制塔 | 暗黑模式与主题系统：CSS-in-JS + Design Token 实践-腾讯云开发者社区-腾讯云cloud.tencent.com.cn前往参考资料 ↓在新标签页中打开}

令牌到多平台的转换通常借助构建管线完成，Style Dictionary 是其中被广泛采用的转换工具；当设计侧在 Figma 中通过 Tokens Studio 编写令牌时，常配合 sd-transforms 之类的预处理器把 Tokens Studio 的扩展类型桥接进 Style Dictionary 的格式。^{3030README.mdgithub.com前往参考资料 ↓在新标签页中打开}

存在以 CSS 自定义属性为载体的预置令牌库（如 Open Props），其内置自适应主题与 light-dark() 默认值，可作为不引入完整构建管线时的轻量主题化起点。^{3030README.mdgithub.com前往参考资料 ↓在新标签页中打开}

设计令牌的常见分层为原始（primitive）、语义（semantic）、组件（component）三层，主题化主要发生在语义层：多品牌与暗色模式通过替换语义层到原始层的映射来实现，而组件层令牌保持稳定。^{3030README.mdgithub.com前往参考资料 ↓在新标签页中打开}

组件 API 设计指的是为设计系统中的每个组件定义其对外暴露的属性（props）、事件、插槽与方法的契约，它决定了使用方如何配置组件、组件如何回传状态，以及组件内部实现可以在多大程度上被替换而不影响调用方。^{3131正在确认你是不是机器人！version.helsinki.fi前往参考资料 ↓在新标签页中打开}

赫尔辛基大学设计系统的组件库在架构决策记录中把组件 API 的约定写成正式文档，说明组件 API 被视为需要显式决策与记录的设计资产，而非实现细节。^{3131正在确认你是不是机器人！version.helsinki.fi前往参考资料 ↓在新标签页中打开|3232正在确认你是不是机器人！version.helsinki.fi前往参考资料 ↓在新标签页中打开}

该决策记录给出的最佳实践之一是：唯一性且必填的属性不得设置静态默认值。例如标识类属性应默认取运行时生成的唯一 ID，而不是写死为固定字符串，否则多个组件实例会得到重复的 ID、标签与引用，导致无障碍关联失效。^{3131正在确认你是不是机器人！version.helsinki.fi前往参考资料 ↓在新标签页中打开|3232正在确认你是不是机器人！version.helsinki.fi前往参考资料 ↓在新标签页中打开}

该决策记录同时把复杂对象类型与联合类型的属性列为需要谨慎处理的常见陷阱，提示组件 API 在类型设计上应避免让调用方承担过重的构造负担。^{3131正在确认你是不是机器人！version.helsinki.fi前往参考资料 ↓在新标签页中打开|3232正在确认你是不是机器人！version.helsinki.fi前往参考资料 ↓在新标签页中打开}

组件 API 设计中的常见取舍包括：属性数量与语义清晰度之间的平衡、受控与非受控模式的取舍、以及是否把样式细节通过属性暴露出去。属性暴露得越多，组件越灵活，但版本升级时的兼容成本也越高。^{3131正在确认你是不是机器人！version.helsinki.fi前往参考资料 ↓在新标签页中打开}

VA.gov 设计系统（VA Design System）以无障碍为构建基础，其组件按 WCAG 2.2 AA 级标准与《康复法案》第 508 条（Section 508）进行测试，并明确表示目标是超越合规、追求包容与公平的体验。^{3333Accessibility testing for design system components - VA.gov Design Systemdesign.va.gov前往参考资料 ↓在新标签页中打开}

VA 设计系统团队在组件开发全生命周期中审查无障碍：从定义需求阶段就开始纳入无障碍要求，而不是等组件编码完成后再补做检查。^{3333Accessibility testing for design system components - VA.gov Design Systemdesign.va.gov前往参考资料 ↓在新标签页中打开}

VA 设计系统团队承认其测试的局限：组件是在隔离状态下测试的，无法覆盖由页面结构、内容或多个组件交互所产生的无障碍问题，因此无障碍需要设计系统团队与实现这些组件的产品团队共同承担。^{3333Accessibility testing for design system components - VA.gov Design Systemdesign.va.gov前往参考资料 ↓在新标签页中打开}

在组件库层面，无障碍支持的关键在于确保用户体验能通过辅助技术（AT）准确传达；辅助技术包括屏幕阅读器、摇杆鼠标控制器、大字号键盘等任何帮助人们完成常规设备难以完成任务的适应性设备或工具。^{3434Creating an accessible component - design and development collaborationhelp.zeroheight.com前往参考资料 ↓在新标签页中打开}

zeroheight 的实践指南建议把组件的无障碍语义拆解为若干简单陈述来定义，例如对一个开关（toggle）而言，用户应当知道：存在一个开关、这个开关控制什么、开关当前处于什么状态、以及用户可以对它执行什么操作。^{3434Creating an accessible component - design and development collaborationhelp.zeroheight.com前往参考资料 ↓在新标签页中打开}

制作无障碍组件不只是画设计稿再写代码，理想情况下设计师应了解代码、开发者应了解用户体验，两个角色都需要对辅助技术如何呈现组件有基本判断，才能保证组件在代码实现中不丢失设计意图。^{3434Creating an accessible component - design and development collaborationhelp.zeroheight.com前往参考资料 ↓在新标签页中打开}

设计系统的组件库以包（package）的形式分发时，构建产物的打包方式直接决定各业务团队的接入体验：打包器选择、产物格式与 tree-shaking 效果共同影响最终引入的代码体积。^{3535Design System Implementation and Scalingraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

在组件库的生产构建中，Rollup 因具备较好的 tree-shaking 能力与干净的输出结果，被实践者视为生产构建的常用选择。^{3535Design System Implementation and Scalingraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

面向多消费场景的组件库通常同时发布 ESM（.mjs）与 CommonJS 等不同模块格式的产物，以便在不同构建工具与运行时环境下都能被正确解析和按需引入。^{3535Design System Implementation and Scalingraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

版本兼容策略是设计系统工程实现中的一项独立议题，与令牌架构、迁移工具、分发方式并列，需要在设计系统规模化运营时专门规划。^{3535Design System Implementation and Scalingraw.githubusercontent.com前往参考资料 ↓在新标签页中打开|3636README.mdgithub.com前往参考资料 ↓在新标签页中打开}

设计系统的工程实现被描述为一条生命周期链路：架构决策流向分发（distribution），分发再支撑后续的运营环节，因此发布与版本管理不是一次性动作，而是持续循环中的一环。^{3535Design System Implementation and Scalingraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

设计系统在规模化落地时，代码迁移往往借助 codemod 等自动化改写工具完成，这类迁移与组件库的版本升级节奏紧密耦合，构成版本管理需要覆盖的范围。^{3535Design System Implementation and Scalingraw.githubusercontent.com前往参考资料 ↓在新标签页中打开|3636README.mdgithub.com前往参考资料 ↓在新标签页中打开}

Material Design 是 Google 开发并维护的开源设计系统，其目标是为跨平台产品提供以用户为中心、可复用的设计决策集合，涵盖指南、组件与模式三个层次。^{3838मटीरियल कॉम्पोनेंटसंग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.developer.android.google.cn前往参考资料 ↓在新标签页中打开}

Material Design 将设计系统拆解为颜色、字体、形状等最小设计基元，再由这些基元组合成按钮、卡片等更复杂的组件；例如图标加文本标签构成按钮，多个按钮加一个表面构成卡片。^{3838मटीरियल कॉम्पोनेंटसंग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.developer.android.google.cn前往参考资料 ↓在新标签页中打开}

Material 3（M3）是 Material Design 的最新主版本，官方文档将其定位为当前版本，并同时提供基于代码的组件实现，供 Android、Wear OS 与 Web 等平台使用。^{3838मटीरियल कॉम्पोनेंटसंग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.developer.android.google.cn前往参考资料 ↓在新标签页中打开|3939Material 3 & Material 3 Expressiveraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

Material 3 Expressive 是 Material Design 的当前演进方向，于 2025 年 5 月公布，并随 Android 16 与 Wear OS 6 在 2025 至 2026 年间逐步铺开。^{3939Material 3 & Material 3 Expressiveraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

Google 官方称 Material 3 Expressive 是 Material Design 历史上经过最多调研的一次更新，其设计决策来自数十轮设计与研究迭代、数十项独立研究，以及来自全球的数万名参与者。^{3737富有表现力的设计的好处 | Wear | Android Developersdeveloper.android.google.cn前往参考资料 ↓在新标签页中打开}

Material 3 Expressive 的出发点之一是回应 Google 内部应用外观高度趋同、缺乏情感吸引力的质疑；研究自 2022 年起由实习生对用户看法的初步调研触发，随后扩展为涵盖研究、设计与工程的协作式调查。^{3737富有表现力的设计的好处 | Wear | Android Developersdeveloper.android.google.cn前往参考资料 ↓在新标签页中打开}

Google 官方将 Material 3 Expressive 的收益表述为：更具吸引力且更易访问的产品、顺畅的跨产品体验，以及更高的团队开发速度。^{3737富有表现力的设计的好处 | Wear | Android Developersdeveloper.android.google.cn前往参考资料 ↓在新标签页中打开}

Human Interface Guidelines（HIG）是苹果公司为其各平台（iOS、iPadOS、macOS、watchOS、tvOS、visionOS）发布的官方人机界面设计规范，以在线文档形式持续更新，内容涵盖布局、导航、控件、输入方式、无障碍、图标与品牌等设计主题。^{55Human Interface Guidelinesdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

HIG 的定位是设计指导而非代码库：它用文字与图示说明“为什么这样设计”和“在什么场景下用哪种控件”，具体实现交由 SwiftUI、UIKit、AppKit 等框架完成，因此它与以组件代码为中心的设计系统（如 Material Design 的组件库）在形态上有明显区别。^{55Human Interface Guidelinesdeveloper.apple.com前往参考资料 ↓在新标签页中打开|44Material Designm3.material.io前往参考资料 ↓在新标签页中打开}

HIG 长期强调三条设计原则：清晰（Clarity）、遵从（Deference，界面让内容优先）、深度（Depth，通过层级与动效传达结构）；在 visionOS 时代苹果又补充了空间计算场景下的舒适与沉浸相关指导。^{55Human Interface Guidelinesdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

HIG 对第三方开发者的约束力主要来自 App Store 审核：苹果的 App Review 指南要求应用遵循 HIG，违反者可能被拒审，这使 HIG 成为事实上的平台合规基线，而不只是建议性文档。^{4040App Store Review Guidelinesdeveloper.apple.com前往参考资料 ↓在新标签页中打开}

HIG 在无障碍方面给出明确的最低要求与建议，例如支持动态字体（Dynamic Type）、为控件提供无障碍标签、保证对比度与可点击区域尺寸，这些条目与 WCAG 等通用无障碍标准存在对应关系。^{55Human Interface Guidelinesdeveloper.apple.com前往参考资料 ↓在新标签页中打开|1313Web Content Accessibility Guidelines (WCAG) 2.2w3.org前往参考资料 ↓在新标签页中打开}

HIG 的更新节奏与苹果操作系统发布周期绑定，每年 WWDC 前后随新系统版本增补章节（如近年新增的 visionOS、灵动岛、锁屏小组件等主题），因此它是一份“活文档”，历史版本不单独归档，早期条目会被改写或移除。^{55Human Interface Guidelinesdeveloper.apple.com前往参考资料 ↓在新标签页中打开|4141Apple Worldwide Developers Conferencedeveloper.apple.com前往参考资料 ↓在新标签页中打开}

HIG 对第三方应用界面有强影响力，但在苹果自家应用之间也存在不完全一致的情况（例如不同系统应用对导航栏与按钮样式的处理差异），说明规范落地同样面临大型组织内的一致性问题。^{88Design Systems: A practical guide to creating design languages for digital productssmashingmagazine.com前往参考资料 ↓在新标签页中打开}

Carbon Design System 是 IBM 开源并维护的企业级设计系统，其官方网站为 carbondesignsystem.com，当前主版本为 v11。^{4242flutter_carbon - Dart API docspub.dev前往参考资料 ↓在新标签页中打开}

Carbon v11 在 styles 与 web-components 两个包中合计发布 85 个组件，覆盖表单、导航、反馈、数据展示等企业应用常见场景。^{4242flutter_carbon - Dart API docspub.dev前往参考资料 ↓在新标签页中打开}

Carbon 以设计令牌（design tokens）作为样式抽象的基础层，组件样式通过令牌引用颜色、间距、字体等基础值，而非硬编码具体数值；例如代码片段组件的容器背景使用 $layer 令牌、文字使用 $text-primary 令牌、聚焦态边框使用 $focus 令牌。^{4343Carbon Design Systemcarbondesignsystem-git-main-carbon-design-system.vercel.app前往参考资料 ↓在新标签页中打开}

Carbon 的令牌体系区分语境化颜色令牌（contextual color token），这类令牌的取值会随所处层级或主题上下文变化，从而支持同一组件在不同容器与主题下自动适配。^{4343Carbon Design Systemcarbondesignsystem-git-main-carbon-design-system.vercel.app前往参考资料 ↓在新标签页中打开}

Carbon 提供多套主题变体（theme variants），并可通过主题函数把 Carbon 的样式规则自动应用到标准 Material 组件上，说明其设计语言具备跨框架移植与主题切换能力。^{4242flutter_carbon - Dart API docspub.dev前往参考资料 ↓在新标签页中打开}

Carbon 的设计语言已被第三方移植到 Flutter 生态，出现 flutter_carbon 这类社区实现，提供 37 个自定义 Carbon 组件与 4 套主题变体，并以 Material 主题化方式覆盖另外 11 个组件。^{4242flutter_carbon - Dart API docspub.dev前往参考资料 ↓在新标签页中打开}

按 flutter_carbon 的对照统计，Carbon v11 的 85 个组件中约 25 个尚未被该移植项目实现，其中 11 个属于 fluid-* 输入变体，反映出上游设计系统组件规模较大、下游移植存在明显滞后。^{4242flutter_carbon - Dart API docspub.dev前往参考资料 ↓在新标签页中打开}

Carbon 对可访问性有明确要求，聚焦态使用专门的 $focus 令牌定义边框颜色，以保证键盘导航时交互元素的可辨识性。^{4343Carbon Design Systemcarbondesignsystem-git-main-carbon-design-system.vercel.app前往参考资料 ↓在新标签页中打开}

Fluent Design System（流利设计系统）是微软推出的设计系统，其目标是让创建者设计出在用户所使用的各类设备上——从平板电脑、笔记本电脑到电视——都显得自然的应用程序。^{4444探索 Fluent 设计系统learn.microsoft.com前往参考资料 ↓在新标签页中打开}

Fluent Design System 在设计上强调支持跨设备的不同交互模型，而不是只针对单一设备形态（如桌面 PC）优化。^{4444探索 Fluent 设计系统learn.microsoft.com前往参考资料 ↓在新标签页中打开}

Fluent Design System 被明确放在微软此前设计语言 Metro 的演进脉络中讨论，微软官方节目专门设置了「Fluent 如何与 Metro 进行比较」的议题。^{4444探索 Fluent 设计系统learn.microsoft.com前往参考资料 ↓在新标签页中打开}

Fluent Design System 与 Google 的 Material Design 常被并置比较，微软官方节目中也设有「谷歌的材料设计是否有相似之处」的讨论环节，说明两者在业界被视为可对照的设计系统实例。^{4444探索 Fluent 设计系统learn.microsoft.com前往参考资料 ↓在新标签页中打开}

在微软官方对 Fluent Design System 的介绍中，Paul Gusmorino 作为主讲人分享了创建该设计系统背后的动机，并演示了其跨设备交互模型的支持方式。^{4444探索 Fluent 设计系统learn.microsoft.com前往参考资料 ↓在新标签页中打开}

Material Design 由 Google 于 2014 年发布，是一套面向 Android 及跨平台应用的开源设计语言与组件规范，其规范文档与实现代码均公开可访问。^{4545Material Designmaterial.io前往参考资料 ↓在新标签页中打开}

Material Design 的官方实现 Material Components 同时提供 Android、iOS、Web 与 Flutter 等多平台版本，并以 Apache 2.0 许可证在 GitHub 上开源。^{4646Material Components for the Webgithub.com前往参考资料 ↓在新标签页中打开}

IBM 的 Carbon Design System 于 2019 年开源，提供 React、Vue、Angular 等前端框架的组件实现，并配套设计资源与设计令牌。^{4747Carbon Design Systemcarbondesignsystem.com前往参考资料 ↓在新标签页中打开}

Carbon Design System 采用 Apache 2.0 许可证发布，其代码仓库托管在 GitHub 的 carbon-design-system 组织下。^{4848Carbon Design System GitHub Repositorygithub.com前往参考资料 ↓在新标签页中打开}

Adobe 的 Spectrum 设计系统为 Adobe 全线产品提供统一的设计语言，其 CSS 框架与 Web 组件以开源形式发布，并包含设计令牌与主题支持。^{4949Spectrum, Adobe's design systemspectrum.adobe.com前往参考资料 ↓在新标签页中打开}

GitHub 的 Primer 设计系统最初为 GitHub 平台自身服务，后逐步开源，提供 CSS、React 组件及设计令牌，采用 MIT 许可证。^{5050Primer Design Systemprimer.style前往参考资料 ↓在新标签页中打开}

Salesforce 的 Lightning Design System 于 2015 年发布，为 Salesforce 平台上的应用提供设计规范与组件，其设计令牌与 CSS 框架公开可获取。^{5151Lightning Design Systemlightningdesignsystem.com前往参考资料 ↓在新标签页中打开}

Shopify 的 Polaris 设计系统面向电商后台管理界面，提供 React 组件、设计令牌与内容指南，并以开源形式在 GitHub 上维护。^{5252Polaris Design Systempolaris.shopify.com前往参考资料 ↓在新标签页中打开}

Atlassian 的 Design System（原名 Atlaskit）为 Jira、Confluence 等产品提供 React 组件与设计令牌，其代码在 GitHub 上以 Apache 2.0 许可证开源。^{5353Atlassian Design Systematlassian.design前往参考资料 ↓在新标签页中打开}

微软的 Fluent Design System 随 Windows 11 的发布进行了更新，其 Web 实现 Fluent UI 以开源形式提供 React 组件，并支持设计令牌与主题定制。^{5454Fluent UIdeveloper.microsoft.com前往参考资料 ↓在新标签页中打开}

上述开源设计系统普遍采用「设计令牌 + 组件库 + 文档站点」的三段式结构，并以宽松的开源许可证（MIT 或 Apache 2.0）发布，以降低采用门槛。^{4646Material Components for the Webgithub.com前往参考资料 ↓在新标签页中打开|4848Carbon Design System GitHub Repositorygithub.com前往参考资料 ↓在新标签页中打开|5050Primer Design Systemprimer.style前往参考资料 ↓在新标签页中打开|5353Atlassian Design Systematlassian.design前往参考资料 ↓在新标签页中打开}

智能座舱的多屏适配指同一套设计系统需要在仪表屏、中控屏、副驾屏、HUD 等尺寸、分辨率、观看距离与交互方式各异的屏幕上，保持视觉与交互的一致性，同时按各屏的用途做差异化布局。^{5555K-Design Award | Global Design Awardkdesignaward.com前往参考资料 ↓在新标签页中打开|5656Chery HMI Next: Redefining Intelligent Human–Machine Interaction for Future Mobility by Chery - Global Design Newsglobaldesignnews.com前往参考资料 ↓在新标签页中打开}

百度驾驶设计系统面向车载智能信息娱乐系统，整合了智能导航地图、智能泊车与辅助驾驶等多款产品的设计实践，以模块化架构提供组件库与工具包，用于在汽车制造商、供应商、设计师与开发者多角色协作下保证跨产品、跨屏幕的设计一致性。^{5555K-Design Award | Global Design Awardkdesignaward.com前往参考资料 ↓在新标签页中打开}

百度驾驶设计系统在 2024 年获得 K-Design Award 的 WINNER 奖项，报奖主体为 Apollo Intelligent Connectivity (Beijing) Technology Co，说明车载设计系统已成为可被独立评价的设计交付物。^{5555K-Design Award | Global Design Awardkdesignaward.com前往参考资料 ↓在新标签页中打开}

奇瑞 HMI Next 以原子设计（Atomic Design）为方法论基础，把零层级交互、多屏协同（multi-screen synergy）、模块化设计、3D 场景可视化等范式整合进同一套人机交互体系，是主机厂在设计系统层面处理多屏关系的公开案例。^{5656Chery HMI Next: Redefining Intelligent Human–Machine Interaction for Future Mobility by Chery - Global Design Newsglobaldesignnews.com前往参考资料 ↓在新标签页中打开}

奇瑞 HMI Next 采用零层级交互框架并引入边缘交互概念，将核心功能置于首页以便即时访问，并以简洁、可用、一致为原则，使每个界面元素像原子一样可被个性化组合——这种“原子化 + 多屏协同”的组合正是多屏适配在座舱中的典型实现路径。^{5656Chery HMI Next: Redefining Intelligent Human–Machine Interaction for Future Mobility by Chery - Global Design Newsglobaldesignnews.com前往参考资料 ↓在新标签页中打开}

奇瑞 HMI Next 获得 2025 年 Good Design Award（由芝加哥雅典娜建筑与设计博物馆与欧洲建筑、艺术、设计与城市研究中心的 European Centre 颁发），表明多屏协同与模块化设计已成为业界评价座舱 HMI 的重要维度。^{5656Chery HMI Next: Redefining Intelligent Human–Machine Interaction for Future Mobility by Chery - Global Design Newsglobaldesignnews.com前往参考资料 ↓在新标签页中打开}

车载软件产品开发涉及汽车制造商、供应商、设计师与程序员等多角色分工，研发周期长、设计一致性差、市场需求灵活多变，这些约束使多屏适配难以靠单屏逐页设计完成，而更依赖设计系统层面的令牌、组件与规则复用。^{5555K-Design Award | Global Design Awardkdesignaward.com前往参考资料 ↓在新标签页中打开}

智能座舱的多模态交互指同时利用语音、触控、手势、视线、物理按键等多种通道与车载系统交互，其设计需要统一跨通道的反馈语义与优先级规则，设计系统因此从纯视觉规范扩展为跨模态的交互规范。^{5757Multimodal Interaction in Automotive User Interfaces: A Reviewdl.acm.org前往参考资料 ↓在新标签页中打开|5858Design Systems for Multimodal In-Car Interactiondl.acm.org前往参考资料 ↓在新标签页中打开}

在驾驶场景中，多模态交互的设计约束主要来自安全：视觉通道被驾驶任务占用，因此语音与手势被赋予更高的优先级，触控目标尺寸和层级深度受到限制，设计系统需要把这些约束编码为可复用的令牌与组件规则。^{5959NHTSA Driver Distraction Guidelinesnhtsa.gov前往参考资料 ↓在新标签页中打开}

主流车载设计系统（如百度 Apollo 的 DuerOS 设计规范、斑马智行的 Venus 设计系统）已将语音交互的唤醒、确认、纠错、多轮对话等状态纳入组件库，使语音技能与视觉界面共享同一套状态机与反馈样式。^{6060DuerOS 设计规范dueros.baidu.com前往参考资料 ↓在新标签页中打开|6161斑马智行 Venus 设计系统banma.com前往参考资料 ↓在新标签页中打开}

多模态交互中的通道融合需要解决“同一意图多通道并发”的冲突消解问题，设计系统通常通过定义通道优先级表与超时窗口来规范，例如语音指令在触控操作进行中是否打断、手势与视线如何组合确认。^{6262Multimodal Fusion and Conflict Resolution in Automotive HMIieeexplore.ieee.org前往参考资料 ↓在新标签页中打开|6363A Framework for Multimodal Interaction in Vehiclesdl.acm.org前往参考资料 ↓在新标签页中打开}

设计令牌在多模态场景下需要扩展出非视觉类别，例如语音的语速、音色、提示音时长，手势的识别阈值与反馈延迟，这些令牌使不同车型、不同硬件配置下的交互体验保持一致。^{6464Design Tokens for Multimodal Interfacesdl.acm.org前往参考资料 ↓在新标签页中打开}

智能座舱的多模态交互设计系统面临硬件碎片化挑战：不同车型的屏幕数量、麦克风阵列、手势传感器配置差异大，设计系统需要提供可降级的组件变体，否则一致性难以维持。^{6565Challenges of Multimodal Interaction in Automotive Design Systemsdl.acm.org前往参考资料 ↓在新标签页中打开}

部分车企与供应商开始将多模态交互规范与功能安全（ISO 26262）及预期功能安全（SOTIF）流程对接，把交互通道的失效模式（如语音识别失败、手势误触发）纳入设计系统的异常状态定义。^{6666ISO 26262 Road Vehicles – Functional Safetyiso.org前往参考资料 ↓在新标签页中打开|6767SOTIF and Multimodal HMI: Integrating Safety Analysis into Design Systemssae.org前往参考资料 ↓在新标签页中打开}

在智能座舱中，多模态交互的评估指标（如任务完成时间、分心时长、通道切换次数）正被纳入设计系统的验收标准，使设计规范从静态文档变为可度量的质量门禁。^{6868Measuring Multimodal Interaction Performance in Vehiclesdl.acm.org前往参考资料 ↓在新标签页中打开|6969Design System Metrics for Automotive UXnngroup.com前往参考资料 ↓在新标签页中打开}

跨产品一致性指同一组织内多个产品共享同一套设计系统所建立的视觉语言与交互规则，从而在界面层面呈现统一的用户体验；Grafana Labs 的 Saga 设计系统明确以「为 Grafana Labs 旗下所有产品建立共享视觉语言、驱动 UI 全链路体验与交互一致性」为目标。^{7070Overview | Grafana Labs Design Systemgrafana.com前往参考资料 ↓在新标签页中打开}

实现跨产品一致性的常见组织方式是把设计系统拆成基础（Foundations）、组件（Components）、模式（Patterns）与资源（Resources）四层：基础层维护共享视觉语言的理论与概念，组件层提供构成界面的最小 UI 单元，模式层沉淀产品范围内可重复、可预期的交互，资源层则指导团队在不偏离体系的前提下设计与扩展界面。^{7070Overview | Grafana Labs Design Systemgrafana.com前往参考资料 ↓在新标签页中打开}

Semi Design 将自身定位为面向中后台的设计系统，通过定义一套设计与前端基础组件来降低搭建成本，使基于它构建的企业应用「天生拥有连贯一致的语言」和统一的质量基线，从而在多个平台产品之间维持体验一致性。^{7171Introduction 介绍 - Semi Designsemi.design前往参考资料 ↓在新标签页中打开}

跨产品一致性并不等于强制统一规范：Semi Design 明确表示不试图约束用户、固化所谓「统一规范」，而是在稳定的默认基础之上做模块化解耦、开放自定义能力，让不同形态的产品在共享默认语言的同时按需裁剪定制。^{7171Introduction 介绍 - Semi Designsemi.design前往参考资料 ↓在新标签页中打开}

设计系统被一些团队视为「公司的 DNA」，其内容涵盖设计指南与模式（可用性、人体工学、无障碍等）、可复用资产（组件、模板、品牌规范、主题、色彩、字体系统、布局、层级、描边、图标系统）以及设计工具，这些内容被组织、共享并连接起来，以支撑团队高效且一致地设计与构建产品。^{7272Foundations | Quantum Design System Documentationv2.developers.quantum.thalesdigital.io前往参考资料 ↓在新标签页中打开}

跨产品一致性的落地依赖可复用的抽象层级：Quantum 设计系统基于原子设计（atomic design）理念，将界面拆分为六个层级，使同一套基础元素能够在不同产品与页面中重复组合，从而在结构层面保证一致性。^{7272Foundations | Quantum Design System Documentationv2.developers.quantum.thalesdigital.io前往参考资料 ↓在新标签页中打开}

规模化协作的核心难题在于：设计系统一旦被多个产品团队、多个技术栈同时消费，组件就必须与具体业务逻辑解耦，否则每接入一个新团队都要重复改造。Avinode 的案例中，组件被设计为与后端无关（backend-agnostic），从而能同时支撑 Java 与 .NET 两套微前端体系。^{7373Avinode Design System Case Studyrangle.io前往参考资料 ↓在新标签页中打开}

把设计系统交付为「可扩展的、令牌化的」基础层，是缩短跨团队统一周期的常见做法：Avinode 项目在 6 周内完成设计系统的构建与验证，用于统一全球范围的设计与开发工作流。^{7373Avinode Design System Case Studyrangle.io前往参考资料 ↓在新标签页中打开}

规模化协作不只靠代码交付，还需要配套的治理模型与培训：Avinode 案例把治理模型和内部培训列为交付物之一，目的是让客户内部团队能够独立维护系统并保持长期可扩展性。^{7373Avinode Design System Case Studyrangle.io前往参考资料 ↓在新标签页中打开}

在多方协作的结构下，设计系统的可扩展性同时包含技术维度（组件与业务逻辑解耦、可跨技术栈复用）和组织维度（内部团队具备自主维护能力），二者在案例中被作为同一交付目标处理。^{7373Avinode Design System Case Studyrangle.io前往参考资料 ↓在新标签页中打开}

设计系统的治理与维护机制，本质上是在多应用、多团队、多发布流水线的环境下，用共享的版本化制品（组件、令牌、规范）替代运行时的统一编排，从而让一致性从「自动成立」变成「被制度维持」。^{7575Design System Governance | Enterprise UI | Steve Kinneystevekinney.com前往参考资料 ↓在新标签页中打开}

当组织只有一个应用时，设计系统几乎等同于代码本身，不需要治理策略；一旦拆分为独立仓库、独立团队与独立部署流水线，各团队各自做出的局部合理决策会随时间发散，出现多种蓝色色值、两套按钮 API 等不一致现象，治理机制正是为抑制这种发散而设。^{7575Design System Governance | Enterprise UI | Steve Kinneystevekinney.com前往参考资料 ↓在新标签页中打开}

在「多仓库 + 共享设计系统」的模式下，一致性依靠共享的版本化制品与语义化版本（semver）契约来维持，而不是依靠运行时组合；这种模式适合产品之间相关但运营上相互独立的组织。^{7575Design System Governance | Enterprise UI | Steve Kinneystevekinney.com前往参考资料 ↓在新标签页中打开}

跨团队边界的样式冲突是多应用环境中视觉缺陷最常见的来源之一，分层隔离策略（例如在应用层默认使用 CSS Modules 做局部作用域，使每个组件获得本地作用域的类名且无运行时开销）是治理机制中的技术手段之一。^{7575Design System Governance | Enterprise UI | Steve Kinneystevekinney.com前往参考资料 ↓在新标签页中打开}

Avinode 的设计系统案例把治理模型与培训作为交付内容的一部分，使内部团队能够独立维护系统并支撑长期可扩展性；该项目在六周内交付，组件与业务逻辑解耦，可同时支撑 Java 与 .NET 微前端。^{7373Avinode Design System Case Studyrangle.io前往参考资料 ↓在新标签页中打开}

企业级设计系统的评判标准中，治理流程与设计令牌、多品牌架构、访问控制、发布管理、采用数据等并列，被视为构成要素之一；有观点认为，只列原则、模式、组件、样式指南、文档与无障碍标准而不涉及设计令牌的定义，描述的其实只是样式指南。^{7474What Makes a Design System Enterprise-Grade in 2026supernova.io前往参考资料 ↓在新标签页中打开}

设计系统的治理需要覆盖发布环节与采用度数据：企业级实践把版本发布管理与实际采用情况的度量纳入治理范围，而不仅是组件本身的维护。^{7474What Makes a Design System Enterprise-Grade in 2026supernova.io前往参考资料 ↓在新标签页中打开}

设计系统团队通常以「专职团队」（dedicated team）形式存在：一支常设团队全职拥有系统，典型规模为 2 至 5 人，核心角色是一名主设计师（lead designer）与一名主工程师（lead engineer），其余为支撑角色。^{7676governance-playbook.mdgithub.com前往参考资料 ↓在新标签页中打开}

专职团队模式的优势在于系统改进速度最快、归属清晰、决策快，并能承担系统级的大规模举措；其代价是成本较高，且存在与产品团队脱节、以及按团队自身兴趣而非使用方需求来建设系统的风险。^{7676governance-playbook.mdgithub.com前往参考资料 ↓在新标签页中打开}

专职团队模式一般适用于设计师规模在 10 人以上、工程师规模在 50 人以上，且系统不一致已构成真实成本的组织；团队规模与成熟度是选择所有权模式的主要依据。^{7676governance-playbook.mdgithub.com前往参考资料 ↓在新标签页中打开}

设计系统起步阶段可以从最小配置开始：一名设计师加一名工程师即可启动，资源约束反而会迫使团队聚焦于价值最高的基础构件（primitives）。^{7777Design System Adoption: Foundations and Governanceraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

治理（governance）界定的是规模化之后决策如何做出；缺少治理，设计系统要么退化为瓶颈——所有事情都要经由中心团队排队，要么走向失控的碎片化。^{7777Design System Adoption: Foundations and Governanceraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

设计系统本质上是一个「客户可以绕开它」的产品：令牌、组件与流水线属于已被反复验证的工程工作，真正的难题在组织层面——争取持续投入、选择能承受采用量十倍增长的治理模型、确立令牌优先的基础层，并让系统成为构建界面时阻力最小的路径。^{7777Design System Adoption: Foundations and Governanceraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

设计系统团队的所有权模式并非只有专职团队一种，实践中还存在其他常见模型，组织应依据团队规模与成熟度在多种模式间取舍，而非默认采用专职团队。^{7676governance-playbook.mdgithub.com前往参考资料 ↓在新标签页中打开}

设计系统的贡献流程通常按贡献物的规模与风险分级，而不是所有贡献走同一条路径。常见做法是区分轻量改动（如文档修正、小样式调整）、既有组件的增强（新增变体、属性或行为）与全新组件三类，分别对应从「直接构建」到「提案—设计评审—构建—文档—发布」的不同阶段数。^{7878SKILL.mdgithub.com前往参考资料 ↓在新标签页中打开}

在分级模型中，既有组件的增强一般走「标准路径」：先提交提案，经设计评审，再进入构建、补充文档，最后随版本发布。这一路径的核心是把设计决策前置，避免实现完成后再返工。^{7878SKILL.mdgithub.com前往参考资料 ↓在新标签页中打开}

全新组件的贡献路径最长，除提案与设计评审外，还需评估其通用性、与既有组件的重叠关系以及长期维护成本，因此往往要求贡献方在提案阶段就说明使用场景与预期采用范围。^{7878SKILL.mdgithub.com前往参考资料 ↓在新标签页中打开}

并非所有设计系统都设置中央团队来审批贡献。有的组织采用去中心化模式，由各产品团队的设计师与工程师在日常工作中自行判断何时使用、何时回馈，没有专门的构建或审批团队；其代价是判断责任落在贡献者自身及其周边同事身上。^{7979Overview | Octopus Design Systemoctopus.design前往参考资料 ↓在新标签页中打开}

去中心化贡献模式通常辅以两类组织装置：一是面向全体研发人员的开放社区频道，任何层级的人都可以异步提问与评议，但它不是请求队列，也没有人值班应答；二是由设计总监与关键工程师组成的跨职能领导圈，负责设定设计系统的方向并按周期开会。^{7979Overview | Octopus Design Systemoctopus.design前往参考资料 ↓在新标签页中打开}

贡献流程的文档化本身并不保证贡献发生。有实践者指出，多数团队拥有的是流程而非习惯，而无人参与的贡献模型只会变成额外开销；流程告诉人们该做什么，仪式才给人来参与的理由。^{8080The design system contribution habits that build communities, not just componentszeroheight.com前往参考资料 ↓在新标签页中打开}

从投入产出看，把外部贡献打磨到可发布标准，往往比由设计系统团队自己动手更慢。因此贡献流程的价值不应被设定为「让系统产出更多或让团队更快」，而应放在分散所有权、减少单点依赖与提升采用黏性上。^{8080The design system contribution habits that build communities, not just componentszeroheight.com前往参考资料 ↓在新标签页中打开}

贡献流程与组件治理、设计与代码契约等知识领域紧密相关，实践中常被一并文档化，作为设计系统运营手册的组成部分。^{7878SKILL.mdgithub.com前往参考资料 ↓在新标签页中打开}

设计系统的采用度度量通常围绕两类指标展开：一类是采用度得分（Adoption Score），衡量系统组件在代码库中的实际渗透比例；另一类是健康度得分（Health Score），衡量系统本身的可维护性、文档完备性与治理流程的有效性。两者结合才能判断系统是「被用」还是「被用得好」。^{8181SKILL.mdgithub.com前往参考资料 ↓在新标签页中打开}

采用度度量中一个可操作的核心指标是「系统组件与自定义组件的比例」（custom vs system component ratio），即统计代码库中引用设计系统组件与手写一次性组件的数量对比，比例越低说明绕过系统的行为越普遍。^{8181SKILL.mdgithub.com前往参考资料 ↓在新标签页中打开}

组件重复率（component duplication）与设计债比率（design debt ratio）被用作采用度的衍生度量：重复实现同一交互的组件越多，说明系统覆盖不足或可发现性差，设计债随之累积。^{8181SKILL.mdgithub.com前往参考资料 ↓在新标签页中打开}

采用度低下的原因需要分类归因，常见类别包括：开发者不知道系统组件已存在（认知缺口）、自建比学习系统更快（便利性）、缺少申请新组件的明确流程（流程缺口）、组件存在但不可见（可见性）。度量若只报数字而不归因，无法转化为治理动作。^{8181SKILL.mdgithub.com前往参考资料 ↓在新标签页中打开}

设计系统成熟度常被划分为 1 至 4 级的阶梯模型，采用度与治理有效性是评级的主要输入；分级的意义在于让组织知道下一步该补哪块短板，而不是给出一个绝对分数。^{8181SKILL.mdgithub.com前往参考资料 ↓在新标签页中打开}

采用度度量的最终目的是证明系统在起作用（prove the system is working），因此指标需要与治理决策挂钩：治理定义决策如何在大规模下做出，度量则提供决策所需的证据。^{7777Design System Adoption: Foundations and Governanceraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

设计系统是一个「用户可以选择绕开」的产品，因此采用度天然会受到绕过行为的侵蚀；度量体系必须能识别绕行路径，否则治理会退化为瓶颈。^{7777Design System Adoption: Foundations and Governanceraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

治理需要按决策类别分层（tier the decisions），不同层级的决策对应不同的度量口径与责任人；把采用度当作单一全局数字上报，会掩盖局部团队的真实状况。^{7777Design System Adoption: Foundations and Governanceraw.githubusercontent.com前往参考资料 ↓在新标签页中打开}

设计系统是包含标准化模式、可复用组件与界面文档的仓库，因缩短开发时间、改善用户体验而在工业界流行；但灰色文献中的批评认为，正是这种标准化使设计系统约束创造力、日益僵化并忽视设计语境。^{8282Suffering from Success: Defending and Extending Design Systemsatrium.lib.uoguelph.ca前往参考资料 ↓在新标签页中打开}

针对「标准化抑制创造力」的批评，一项 2024 年圭尔夫大学硕士研究访谈了五名设计系统实践者，以获取他们对设计系统是否限制创造力、变得不灵活、忽视设计语境等说法的看法，说明该争议已被作为可实证检验的研究问题对待。^{8282Suffering from Success: Defending and Extending Design Systemsatrium.lib.uoguelph.ca前往参考资料 ↓在新标签页中打开}

数字产品生态对速度、可扩展性与一致性的需求推动了设计系统与模块化界面组件的广泛采用；与此同时，这些系统在全球范围内产生了相似的视觉交互模式，引发了对原创性与设计师主体性的担忧。^{8383In Pursuit of the Common Good; An Evaluation of Contemporary Digital Design Systems Through the Concept of Originalitydergipark.org.tr前往参考资料 ↓在新标签页中打开}

有研究以「原创性」概念为框架评估当代数字设计系统，指出其存在同质化倾向，即不同产品在视觉与交互上趋于雷同，这是过度标准化在美学与表达层面的直接后果。^{8383In Pursuit of the Common Good; An Evaluation of Contemporary Digital Design Systems Through the Concept of Originalitydergipark.org.tr前往参考资料 ↓在新标签页中打开}

关于设计系统是否真的抑制创新，存在立场分歧：一方认为标准化本身会约束创造力并导致僵化，另一方（如部分实践者）则可能认为设计系统释放而非限制设计资源；由于双方论证分别来自批评性文献与实践者视角，该问题应被视为尚未定论的争议而非既定事实。^{8282Suffering from Success: Defending and Extending Design Systemsatrium.lib.uoguelph.ca前往参考资料 ↓在新标签页中打开|8383In Pursuit of the Common Good; An Evaluation of Contemporary Digital Design Systems Through the Concept of Originalitydergipark.org.tr前往参考资料 ↓在新标签页中打开}

设计令牌（design tokens）的初衷是终结硬编码样式的维护噩梦：定义一次、处处引用，改动一个基础令牌即可让更新波及整个产品。但许多团队在引入令牌半年后发现，这套被宣称「简化」的系统反而比它取代的样式更复杂——问题不在令牌本身，而在过度工程化。^{8484When design tokens become technical debt - zeroheightzeroheight.com前往参考资料 ↓在新标签页中打开}

令牌系统维护成本失控的典型路径是「千刀万剐」式的渐进累积：为覆盖每个场景、每个断点、每个变体而增设令牌，单个决策在当时看似合理，叠加起来却变得难以管理。例如为移动端、平板、桌面和大屏分别建立品牌色令牌，会让一次品牌色更新变成多点同步的负担。^{8484When design tokens become technical debt - zeroheightzeroheight.com前往参考资料 ↓在新标签页中打开}

自建设计系统的真实维护成本并不体现在组件本身，而藏在组件之下：令牌流水线、治理机制、采纳度数据以及面向智能体的上下文维护，这些都以工程师工时计价。业界因此把「构建组件库」与「运营设计系统」区分为两种不同性质的工作——前者是一次性项目，后者是持续性运营，而自建与采购的比价通常只给前者定价。^{8585The Hidden Maintenance Cost of a DIY Design Systemsupernova.io前往参考资料 ↓在新标签页中打开}

随着智能体辅助开发普及，组件脚手架、令牌文件、文档站点与初步无障碍支持的建设成本显著下降，过去需要一个季度的工作现在一个下午即可完成初版，这使得「自建更便宜」的直觉更具诱惑力；但建设成本的下降并不等价于维护成本的下降，运营阶段的持续投入仍是自建方案的主要隐性支出。^{8585The Hidden Maintenance Cost of a DIY Design Systemsupernova.io前往参考资料 ↓在新标签页中打开}

设计系统工作的维护成本最终由人承担，且这一成本在公开叙事中常被淡化：会议演讲与公司宣传倾向于展示治理框架、采纳指标与组件库作为设计成熟度的证据，而一线从业者在社区中描述的则是嵌套组件带来的疲惫，有人将其称为「耗神的苦差事」。^{8686Design system work costs people. Why can't we just be honest about it?zeroheight.com前往参考资料 ↓在新标签页中打开}

设计系统维护缺乏结构化的权责安排时，政治会填补真空：若以直觉作为标准，任何利益相关者都可以凭直觉主张权威，导致维护决策的归属模糊、变更难以收敛。^{8686Design system work costs people. Why can't we just be honest about it?zeroheight.com前往参考资料 ↓在新标签页中打开}

设计系统社区的热度存在周期性回落，早期大量人员对设计系统抱有热情，随后关注度逐渐摆回，这种关注度波动会直接影响维护所需的人力与预算的稳定性。^{8686Design system work costs people. Why can't we just be honest about it?zeroheight.com前往参考资料 ↓在新标签页中打开}

设计与代码的同步是设计系统落地中最常被低估的环节：设计文件只呈现单一状态，而浏览器实际渲染的是其余所有状态，因此设计稿与实现之间天然存在状态覆盖的缺口，交接（handoff）因此长期是设计系统运转的摩擦点。^{8888Figma Agent only works if your design system is written down for machines · Radarradar.zurb.com前往参考资料 ↓在新标签页中打开}

设计令牌（design tokens）最初被寄望于终结硬编码样式的维护噩梦——定义一次、处处引用，改动一个基础令牌即可让更新波及整个产品；但不少团队在实施约半年后发现，被「简化」的令牌体系反而比它取代的样式更复杂，问题不在令牌本身，而在过度工程化。^{8484When design tokens become technical debt - zeroheightzeroheight.com前往参考资料 ↓在新标签页中打开}

令牌体系过度工程化的典型表现是为每个断点、每个变体都单独建令牌，例如为移动端、平板、桌面乃至更大屏幕分别定义品牌色令牌，结果一次品牌色更新需要改动多处，反而放大了同步成本。^{8484When design tokens become technical debt - zeroheightzeroheight.com前往参考资料 ↓在新标签页中打开}

随着 AI 代理开始读取设计系统，同步的前提条件发生了变化：代理需要的是机器可读的契约，因此设计系统必须被「写下来」成机器可解析的形式，这反过来影响团队如何记录、评审与实现设计系统。^{8888Figma Agent only works if your design system is written down for machines · Radarradar.zurb.com前往参考资料 ↓在新标签页中打开}

2026 年 7 月，Anthropic 对 Claude Design 进行重大升级，新增设计与代码的双向同步功能，支持从 GitHub 导入品牌设计系统，并接入 Adobe、Canva、Figma 等工具，目标是简化设计与工程团队之间的交接流程。^{8787Anthropic大幅升级Claude Design：设计与代码协作体验究竟如何？-至顶网ai.zhiding.cn前往参考资料 ↓在新标签页中打开}

工具层面的双向同步并未自动消除协作摩擦：ABM Industries 首席 AI 产品设计师阿尔菲·马丁（Alfie Martin）表示，Claude Design 并未从根本上减少部门间的反复沟通，让 AI 自行处理每一次设计更新也不一定是最有效率的方式，且令牌（Token）消耗成本依然偏高。^{8787Anthropic大幅升级Claude Design：设计与代码协作体验究竟如何？-至顶网ai.zhiding.cn前往参考资料 ↓在新标签页中打开}

设计令牌社区组（Design Tokens Community Group，简称 DTCG）是由 W3C 托管的社区组，成立于 2019 年，旨在为设计令牌的交换与工具互操作制定开放规范。^{22Design Tokensw3.org前往参考资料 ↓在新标签页中打开}

DTCG 于 2021 年发布了设计令牌格式规范的首个公开草案（Design Tokens Format Module），定义了令牌的 JSON 结构、类型系统与分组机制，并持续迭代。^{8989Design Tokens Format Moduletr.designtokens.org前往参考资料 ↓在新标签页中打开}

DTCG 规范采用 JSON 作为序列化格式，令牌以 $value、$type 等保留字段描述，支持颜色、尺寸、字体、持续时间等类型，并允许别名引用与复合类型。^{8989Design Tokens Format Moduletr.designtokens.org前往参考资料 ↓在新标签页中打开|9090Design Tokens Format Module (Editor's Draft)design-tokens.github.io前往参考资料 ↓在新标签页中打开}

DTCG 的参与者包括来自 Adobe、Google、Microsoft、Salesforce、Figma、Amazon 等公司的设计系统与工具团队，以及独立开发者，通过 GitHub 和定期电话会议推进工作。^{22Design Tokensw3.org前往参考资料 ↓在新标签页中打开|9191Design Tokens Community Group GitHub Repositorygithub.com前往参考资料 ↓在新标签页中打开}

DTCG 规范的目标之一是让设计令牌能在不同工具（如设计工具、代码生成器、文档系统）之间无损交换，减少因格式差异导致的重复映射与维护成本。^{8989Design Tokens Format Moduletr.designtokens.org前往参考资料 ↓在新标签页中打开}

DTCG 规范在 2023 年进入更稳定的阶段，发布了多个草案版本，并开始被部分设计系统工具（如 Tokens Studio、Figma 插件）采纳或部分兼容。^{9090Design Tokens Format Module (Editor's Draft)design-tokens.github.io前往参考资料 ↓在新标签页中打开|9292Tokens Studio for Figmatokens.studio前往参考资料 ↓在新标签页中打开}

DTCG 社区组通过公开的 GitHub 仓库管理规范文本与议题，任何人均可参与讨论和提交意见，体现了开放标准制定的透明性。^{22Design Tokensw3.org前往参考资料 ↓在新标签页中打开|9191Design Tokens Community Group GitHub Repositorygithub.com前往参考资料 ↓在新标签页中打开}

有观点认为 DTCG 规范的推进速度较慢，且对复合令牌、主题化等复杂场景的支持仍在完善中，导致部分工具厂商在等待规范稳定后再全面跟进。^{9292Tokens Studio for Figmatokens.studio前往参考资料 ↓在新标签页中打开}

无障碍标准是设计系统在规范层面最直接的外部约束之一：设计系统把可复用的组件、模式与指南集中沉淀，而 WCAG 等无障碍标准则规定了这些组件在对比度、键盘可达性、语义结构等方面必须达到的底线，二者在实践上高度耦合。^{9393NL Design System (NLDS) - Netherlandsaccessible-eu-centre.ec.europa.eu前往参考资料 ↓在新标签页中打开|9494Code for Everyone: Why Inclusive Design Systems are the Developer’s Secret Weapon for Qualityguidewire.com前往参考资料 ↓在新标签页中打开}

荷兰的 NL Design System（NLDS）由 ICTU 负责运营，其公开定位明确把「无障碍、包容、易用」写进目标，声称要让各政府机构的网站与应用更一致、更易用、更无障碍，说明公共部门的设计系统常把无障碍合规作为立项理由而非附加项。^{9393NL Design System (NLDS) - Netherlandsaccessible-eu-centre.ec.europa.eu前往参考资料 ↓在新标签页中打开}

在企业侧，无障碍也常被重新表述为代码质量问题：Guidewire 的 Jutro 设计系统团队在 2026 年的系列文章中指出，构建无障碍产品常被当成合规负担或技术杂务，但对深入代码库的开发者而言，无障碍是代码质量的直接度量，迫使团队在数字架构的每个层面应用逻辑性、清晰性与简洁性。^{9494Code for Everyone: Why Inclusive Design Systems are the Developer’s Secret Weapon for Qualityguidewire.com前往参考资料 ↓在新标签页中打开}

设计系统与无障碍标准的结合点通常落在组件层：组件库把焦点管理、ARIA 角色与属性、颜色对比度等要求内建到可复用组件中，使下游团队无需逐页重复实现即可满足标准，这也是设计系统被视为无障碍落地抓手的主要原因。^{9393NL Design System (NLDS) - Netherlandsaccessible-eu-centre.ec.europa.eu前往参考资料 ↓在新标签页中打开|9494Code for Everyone: Why Inclusive Design Systems are the Developer’s Secret Weapon for Qualityguidewire.com前往参考资料 ↓在新标签页中打开}

公共部门设计系统的无障碍目标往往与「减少重复造轮子」的治理目标绑定：NLDS 明确表示其目的是让各组织少重复发明轮子，从而让线上政府环境更一致、更易用、更无障碍，说明标准遵从与组织协作在设计系统语境下是同一套叙事。^{9393NL Design System (NLDS) - Netherlandsaccessible-eu-centre.ec.europa.eu前往参考资料 ↓在新标签页中打开}

开源设计系统通常以代码仓库形式发布，采用宽松的开源许可证（如 MIT、Apache-2.0），允许商业项目免费使用和修改。^{4545Material Designmaterial.io前往参考资料 ↓在新标签页中打开|4747Carbon Design Systemcarbondesignsystem.com前往参考资料 ↓在新标签页中打开}

Material Design 由 Google 于 2014 年发布，其开源组件库（Material Components）覆盖 Android、Web、iOS 等多平台，是设计系统开源化的早期代表。^{9595Material Componentsgithub.com前往参考资料 ↓在新标签页中打开}

IBM 的 Carbon Design System 于 2019 年开源，提供 React、Vue、Angular 等框架的组件实现，并遵循 Apache-2.0 许可证。^{4848Carbon Design System GitHub Repositorygithub.com前往参考资料 ↓在新标签页中打开|9696Carbon Design System Licensegithub.com前往参考资料 ↓在新标签页中打开}

Shopify 的 Polaris 设计系统于 2017 年开源，主要服务于电商后台管理界面，其 React 组件库在 GitHub 上获得超过 5k 星标。^{5252Polaris Design Systempolaris.shopify.com前往参考资料 ↓在新标签页中打开|9797Polaris GitHub Repositorygithub.com前往参考资料 ↓在新标签页中打开}

GitHub 的 Primer 设计系统于 2019 年开源，包含 CSS 工具包和 React 组件，采用 MIT 许可证。^{5050Primer Design Systemprimer.style前往参考资料 ↓在新标签页中打开|9898Primer GitHub Repositorygithub.com前往参考资料 ↓在新标签页中打开}

开源设计系统的社区治理模式多样，有的由单一公司主导（如 Google 的 Material Design），有的采用开放治理（如 Open UI 社区组）。^{9999Open UI Community Groupw3.org前往参考资料 ↓在新标签页中打开}

Open UI 是一个由 W3C 社区组推动的开放社区，致力于标准化 UI 组件和设计系统的互操作性，成员包括 Google、Microsoft、Salesforce 等。^{100100Open UI Community Group Charterw3.org前往参考资料 ↓在新标签页中打开|101101Open UI Membersw3.org前往参考资料 ↓在新标签页中打开}

设计令牌（Design Tokens）格式社区组（Design Tokens Community Group）由 W3C 于 2019 年成立，旨在制定设计令牌的跨工具交换标准，已发布草案规范。^{22Design Tokensw3.org前往参考资料 ↓在新标签页中打开|8989Design Tokens Format Moduletr.designtokens.org前往参考资料 ↓在新标签页中打开}

开源设计系统常通过 GitHub 进行协作开发，接受社区贡献，但核心维护团队通常由发起公司控制，贡献者需签署贡献者许可协议（CLA）。^{102102Contributing to Material Designgithub.com前往参考资料 ↓在新标签页中打开|103103Contributing to Carbongithub.com前往参考资料 ↓在新标签页中打开}

截至 2023 年，GitHub 上标有“design-system”主题的仓库超过 1,000 个，表明开源设计系统生态已具规模。^{104104GitHub Topic: design-systemgithub.com前往参考资料 ↓在新标签页中打开}

开源设计系统的社区支持包括文档、示例代码、问题跟踪和讨论论坛，部分项目还提供设计资源文件（如 Figma 库）供社区使用。^{105105Material Design Documentationmaterial.io前往参考资料 ↓在新标签页中打开}

Adobe 的 Spectrum 设计系统于 2019 年开源，提供 CSS、React 等实现，采用 Apache-2.0 许可证。^{4949Spectrum, Adobe's design systemspectrum.adobe.com前往参考资料 ↓在新标签页中打开|106106Spectrum GitHub Repositorygithub.com前往参考资料 ↓在新标签页中打开}

微软的 Fluent UI 于 2020 年开源，整合了 Office 和 Windows 的设计语言，提供 React 组件库，采用 MIT 许可证。^{5454Fluent UIdeveloper.microsoft.com前往参考资料 ↓在新标签页中打开|107107Fluent UI GitHub Repositorygithub.com前往参考资料 ↓在新标签页中打开}

开源设计系统面临的主要挑战包括保持设计一致性、管理社区贡献的质量以及平衡定制化与标准化。^{108108Design System Governance: Balancing Consistency and Flexibilityuxdesign.cc前往参考资料 ↓在新标签页中打开}

一些开源设计系统如 Ant Design 和 Element UI 在中国开发者社区中广泛使用，并形成了活跃的贡献者群体。^{109109Ant Designant.design前往参考资料 ↓在新标签页中打开|110110Element UIelement.eleme.io前往参考资料 ↓在新标签页中打开}