现代设计语言与设计体系¶

除了 Google Material Design、Microsoft Fluent Design 和 Apple Human Interface Guidelines（HIG），软件与硬件领域还有许多面向不同生态、任务和设备的设计体系。本文按应用场景整理它们的定位、特征和选型思路。

三大平台的详细介绍见 谷歌、微软、苹果的设计语言。本文核对日期：2026-10-14；产品名称与技术实现可能继续变化。

概念与分类¶

讨论“设计语言”时，常会把视觉规范、交互原则与开发工具放在一起。它们承担的职责不同：

这些类别可以交叉：设计系统通常包含组件库，组件工具也可以成为自建设计系统的基础。选型需要同时考虑交互规范、视觉表达和工程实现。

企业软件与专业工具¶

IBM Carbon Design System¶

Carbon 是基于 IBM Design Language 建立的开源设计系统，定位于企业级产品。它提供基础规范、组件、交互模式和数据可视化资源。官方介绍

• 重点：复杂业务、数据展示与一致的工作流程。
• 风格概括：严谨的网格、清晰的层级和偏专业的工具界面；中性色常用于承载内容，颜色承担状态与强调作用。
• 适用场景：云控制台、数据平台、开发工具和企业 SaaS。
• 取舍：适合信息密集的界面，但密度仍需按用户任务调整，不能直接等同于“黑白灰”或“越密越好”。

Adobe Spectrum¶

Spectrum 为 Adobe 产品提供共享的设计基础、令牌、组件与模式，强调跨产品的一致性和可扩展性。官方介绍

• 重点：专业工具中复杂控件与内容之间的协调。
• 风格概括：工具台式布局、明确的控件状态和可调整的界面结构。
• 适用场景：编辑器、资产管理、创作工具和专业工作台。
• 取舍：深色面板是部分创意工具的常见体验，不能概括 Spectrum 的全部视觉方案。

Atlassian Design System¶

Atlassian 的设计系统提供基础规范、组件和模式，用于构建其产品生态中的一致体验。官方介绍

• 重点：团队协作、任务管理与清晰的信息结构。
• 风格概括：现代 B2B SaaS，强调导航、状态、反馈和协作上下文。
• 适用场景：项目管理、知识库、工单系统和团队工作空间。
• 取舍：Jira、Confluence 等产品可作为体验参考；同属 Atlassian 的产品不一定使用完全相同的组件和布局。

Shopify Polaris¶

Polaris 服务于 Shopify 应用与平台体验，当前官方文档以 Web Components 为基础，并按 App Home、Admin、Checkout、Customer accounts 和 POS 等界面划分可用能力。官方文档

• 重点：商家操作、业务信息表达与平台一致性。
• 风格概括：清晰、实用，重视表单、列表和操作反馈。
• 适用场景：Shopify 应用、商品与订单管理、商家后台。
• 取舍：可以借鉴其后台设计模式；具体组件与 API 的适用范围要按 Shopify 界面核对。商家后台效率也不等同于店铺前台转化率。

Ant Design¶

Ant Design 面向企业级产品，结合设计价值观、模式和 React 组件，常用于中后台界面。官方介绍

• 重点：业务操作效率、复杂表单、表格和一致的反馈。
• 风格概括：结构明确、组件丰富，适合快速形成完整的业务界面。
• 适用场景：管理系统、运营平台和企业应用。
• 取舍：直接使用默认样式容易产生相似外观；品牌差异化需要主题令牌、布局和内容设计共同完成。
• 相关方案：Ant Design Pro 可作为中后台应用脚手架与实践参考；它和 Ant Design 设计系统的层级不同。

Tencent TDesign¶

TDesign 是腾讯开源协同建设的企业级设计体系与组件库，提供 Web、移动端和小程序等方向的实现。官方仓库

• 重点：企业应用、多端一致性与设计开发协作。
• 风格概括：简洁的业务界面，强调组件复用和主题定制。
• 适用场景：企业后台、移动业务应用和小程序。
• 取舍：应按目标框架与平台核对组件覆盖程度；TDesign 不能代表腾讯所有产品的视觉风格。

移动设备与跨设备生态¶

Samsung One UI¶

One UI 是 Samsung Galaxy 生态的界面体系。其设计思路包括区分查看区域与交互区域，改善大屏设备上的单手操作体验。Samsung 设计介绍

• 重点：设备日常使用、易读性和触控可达性。
• 风格概括：大标题、明确的触控区域和卡片式内容组织。
• 适用场景：手机及 Galaxy 设备体验参考。

两者处于不同层级，不能简单比较为“Material 紧凑、One UI 宽松”；实际密度与触控区域取决于设备、版本和页面任务。

Huawei HarmonyOS 设计¶

HarmonyOS 的设计规范面向鸿蒙应用与设备体验，涉及布局、组件、动效和多设备适配。官方设计入口

• 重点：跨设备体验、内容组织和服务的便捷访问。
• 风格概括：卡片化信息、连贯的转场与适配不同设备的界面结构。
• 适用场景：鸿蒙应用、服务卡片和多设备协作。
• 取舍：卡片、服务入口和跨设备能力分别涉及界面模式与平台能力；不能只凭外观将其等同于 iOS Widget、Material You 或其他手机系统。

Web 开发中的组件与样式工具¶

这些工具可以帮助建立产品自己的设计系统，但提供的视觉与交互约束各不相同。

Tailwind UI 已于 2025 年更名为 Tailwind Plus。它提供带样式的界面资源，不能与无样式的 Headless UI 混为一谈。更名公告、界面示例、Headless UI

Radix 需要区分 Primitives 与带视觉样式的 Themes。这里讨论的是无样式的 Primitives。Radix Primitives 文档

Chakra UI 提供可定制的组件体系；shadcn/ui 强调把组件源码纳入项目并由团队掌控。Chakra UI、shadcn/ui 文档

无样式组件提高视觉自由度，也意味着团队要自行建立颜色、间距、字体、状态和组件规范。组件提供无障碍基础，最终体验仍需结合内容、组合方式和真实交互验证。

shadcn/ui 详细介绍¶

定位与工作方式¶

shadcn/ui 提供具有默认样式的组件，以及将代码分发到项目的工具。其核心是让团队掌控组件的上层源码：添加组件后，可以直接修改结构、样式和接口，并逐步形成自己的组件体系。官方介绍

典型流程如下：

选择组件与预设 → CLI 写入组件源码并安装依赖
→ 应用从本地文件导入 → 按产品需求修改 → 团队维护

例如，页面通常从 @/components/ui/button 导入按钮。这个文件属于项目，可以进入版本控制；底层交互库、图标等仍可作为 npm 依赖安装。因此，“源码可控”指的是可以定制的组件层，并不意味着全部依赖都复制进仓库。Button 文档

与 React、Tailwind 和组件原语的关系¶

早期常见组合是 Radix UI + Tailwind CSS；当前官方 CLI 已支持选择 Base UI、Radix UI 和 React Aria 等基础方案，不能将 shadcn/ui 固定理解为 Radix 的样式包装。不同方案的组件接口与组合方式可能不同，应以项目实际生成的代码为准。CLI 文档、组件实现选项

官方提供 Next.js、Vite、React Router、Astro 等安装路径。这里介绍的是 React 组件体系；某个框架有安装指南，不代表其所有渲染模式都能直接使用交互组件。在 React Server Components 项目中，仍需处理客户端组件边界。安装文档、项目配置

视觉风格与主题定制¶

默认界面通常呈现简洁的表面、明确的边框、圆角和清晰的文字层级，适合作为 SaaS 的起点；这些是可修改的默认选择，不是产品必须遵守的品牌语言。

官方推荐通过 CSS 变量定义语义令牌，再由 Tailwind 映射为样式类。例如 primary 与 primary-foreground 分别表达主操作表面及其上的文字颜色；组件使用 bg-primary、text-primary-foreground 等类。深色主题覆盖同一套令牌，无需逐个重写控件。主题文档

团队实践上，公共颜色与尺寸应优先放入令牌或统一变体。若每个页面都通过零散的 className 覆盖同一组件，后续统一调整会更加困难。

入门示例¶

在已经完成对应框架、Tailwind 和导入别名配置的项目中，可以初始化并添加组件：

npx shadcn@latest init
npx shadcn@latest add button card

init 配置项目基础，add 按配置写入所选组件并处理依赖。components.json 记录样式、CSS 路径和导入别名等信息，供 CLI 使用；手动复制组件时不一定需要它。新项目也可以通过官方可视化入口选择预设并生成安装命令。CLI 文档、配置说明、安装入口

下面展示本地按钮组件的使用方式，假设 @/ 已映射到正确目录：

import { Button } from "@/components/ui/button"

export function TaskActions() {
  return (
    <div className="flex gap-2">
      <Button type="button">创建任务</Button>
      <Button type="button" variant="outline">查看历史</Button>
    </div>
  )
}

示例只展示控件与样式，业务事件由应用接入。安装命令中的 @latest 会随发布变化；正式项目应记录所用 CLI、依赖版本和预设，便于团队复现。Button 用法

组件、组合示例与 Registry¶

按钮、输入框和卡片是基础积木；弹窗、菜单和选择器还依赖交互原语。复杂界面通常需要继续组合：例如官方 Data Table 指南通过 Table 与 TanStack Table 构建排序、筛选、分页和选择能力，而不是一个已包办所有业务需求的数据表格组件。Data Table 指南

Registry 是代码分发机制，可以发布自定义组件、Hooks、页面、配置及其他文件。团队可以借此向多个项目分发统一的业务组件；Registry 机制本身也不限于 React。Registry 文档

这使 shadcn/ui 可以作为内部设计系统的起点，但组件说明、版本管理、变更记录和跨项目升级策略仍需要团队建设。

优势与维护成本¶

以下取舍是基于源码分发与本地定制方式的工程判断：

已经复制并修改的组件不会仅因更新 CLI 或底层依赖就自动获得全部上游改动。建议把通用组件与业务组件分层，记录定制原因，并在接入上游修复时检查受影响的交互。

适用场景与 AI 产品¶

如果团队使用 React，需要品牌定制，并愿意维护组件源码，shadcn/ui 可以作为 SaaS、管理工具和 AI 工作区的起点。若项目更看重完整的企业组件覆盖与统一升级，可以同时评估 Ant Design 或其他组件体系，而不是只比较默认外观。

源码开放、组合接口和现成组件便于 AI 辅助工具读取并修改界面，这是官方强调的设计方向；它并不能直接证明某种市场占有率或流行度排名。官方设计原则

对 AI 产品而言，组件可以承载消息、任务状态、工具结果和编辑区。产品仍需设计取消与重试、长任务进度、结果检查和失败恢复；使用 shadcn/ui 不会自动补齐这些工作流。

如果希望构建跨框架的标准组件体系，可以参考 Lit 框架简介与跨框架组件设计，其中讨论了用 Web Components 实现组件时的 API、主题与适配成本。

现成组件与自建基础的选择，见 Web Components 组件库分类与选型，涵盖 Web Awesome、Fluent、Carbon、Lion、Vaadin 与 Spectrum。

游戏、汽车与硬件界面¶

以下例子主要是具体产品的界面与交互实践，公开资料的完整程度与可复用组件覆盖不同于 Carbon、Ant Design 等设计系统。表中的风格与借鉴方向是对产品体验的归纳。

车载界面还需要考虑驾驶中的可读性、操作负担和反馈。大屏、极简或减少实体控件都是设计选择，不能单独作为“低干扰”的证据；不同车型、硬件与软件版本也会影响体验。

AI-native 界面趋势¶

“AI-native Design”可用来描述围绕 AI 能力组织产品体验的趋势，目前更适合作为设计思路，而非统一的设计系统名称。下面是交互模式的概括，并非产品普及度排名。

• 目标表达：用户可以通过自然语言提出任务，也可以从按钮、表单和模板开始。
• Agent 工作流：界面需要表达计划、进度、中间结果、失败原因和用户可干预的步骤。
• 工作区与产物：对话可与编辑器、预览、画布或结构化结果结合，支持持续修改。
• 情境化界面：根据任务提供适合的控件与信息，同时保持稳定的导航和可预测的操作。

传统交互的常见路径：菜单 → 页面 → 操作 → 结果
AI 辅助交互的一种路径：目标 → 计划／执行 → 产物 → 检查与修改

两种路径可以共存。设计重点是让用户理解系统正在做什么、结果来自哪里，以及何时可以修改、停止或撤销。视觉层仍可以建立在 Carbon、Fluent 或自建组件体系上。Carbon 已提供面向聊天、Agent 和自动化体验的 AI 设计方向。Carbon for AI 入口

按场景选型¶

以下是基于定位与实现方式的建议，不代表市场份额或流行度排名。

Material Design 与 Tailwind CSS 可以配合使用，但 Tailwind 只是样式实现工具，不会自动落实 Material 的组件行为和交互规范。同样，采用 shadcn/ui 也不意味着产品已经具备完整的设计系统。

实际评估时，可以选取一个包含表格、表单、弹窗、错误反馈和键盘操作的业务流程制作原型，对比组件覆盖、主题定制成本、无障碍表现与团队维护能力。AI 产品还应加入任务进度、结果编辑和失败恢复等场景。