设计系统与规范
设计系统与规范
设计系统是把产品团队的设计决策固化成可复用资产的机制：它回答的不是"这个页面长什么样"，而是"下一个页面为什么自动长成这样"。对有经验的产品经理与设计师，设计系统是规模化团队的基础设施投资——投入的是组件、令牌与治理流程，换回的是跨产品的一致性与交付速度。
本页是产品设计与原型总览的设计系统专章，按"是什么 → 为什么 → 怎么建 → 建什么 → 怎么管 → 怎么挂"组织；相关术语速查见设计师黑话速查。
设计系统是什么
从风格指南到设计系统：四个概念的演进
风格指南、模式库、组件库、设计系统经常被混用，但它们是不同层级的资产：
| 概念 | 载体 | 回答的问题 | 局限 |
|---|---|---|---|
| 风格指南（style guide） | 文档：颜色、字体、Logo、排版规则 | 品牌长什么样 | 只管视觉规范，不覆盖交互与代码 |
| 模式库（pattern library） | 可复用交互模式的集合 | 这类任务怎么交互 | 偏交互描述，缺代码实现 |
| 组件库（component library） | 设计稿与代码中的组件集合 | 这个控件怎么用 | 缺规则与治理，容易各自为政 |
| 设计系统（design system） | 组件 + 规则 + 模式 + 工具 + 治理 | 产品如何长期保持一致 | 需要持续投入维护，建了就要养 |
设计系统 = 前三者 + 治理流程 + 工具链：风格指南定义"看起来怎样"，模式库定义"行为怎样"，组件库定义"用什么实现"，而治理流程与工具链保证三者不脱节、持续演进。只做一个 Figma 组件库或一套 CSS 变量，是设计系统的零件而不是设计系统。
设计系统不是"UI 库"
UI 库管控件，设计系统管决策。一套完整的设计系统至少约束四件事：
- 视觉：颜色、字体、间距、圆角、阴影、动效——由 tokens 承载（见下文）
- 行为：按钮层级、空状态、错误兜底、加载反馈的决策规则，与交互设计基础配套
- 文案：语气、动词、错误信息模板——AI 产品里文案是能力契约，更该进系统（见产品设计与原型总览的文案规则）
- 品牌：色彩、字体、语气跨产品一致，多产品线共享同一品牌资产
提示
判断一个"设计系统"是不是真系统：换一个新产品时，它是给你资产还是给你作业？ 真系统让新页面 80% 的决策自动成立（引用组件与 token 即可），假系统只给你一堆要逐项对照的规范文档。
为什么需要设计系统
一致性与效率的经济账
一致性不是审美洁癖，是认知成本与维护成本：用户跨页面、跨产品时，同一控件同一表现，学习成本趋近于零；反之每页一个样，用户每次都要重新学习。
效率的账更好算——复用次数 × 修正成本：一个按钮组件被 20 个页面使用，修复它的一次样式问题，改一处发布即 20 处生效；没有系统的团队要逐页排查、逐个改、逐个验收，修正成本随页面数线性增长，而且常常漏改几处，制造新的不一致。同一逻辑适用于设计稿：一次 token 调整同步全站设计稿，而不是手工刷几十个画板。
品牌规模化
品牌一致性在单一产品里靠"氛围"就能维持，一旦进入多产品、多端、多市场，就必须靠系统：同一个品牌色在不同平台上要呈现一致的"品牌感"（色值、字体气质、语气），只有 token 化与组件化能同时保证一致性与各平台适配（同一品牌，iOS 用系统控件、Web 用自研组件，但 token 同源）。
设计与开发的协作契约
设计系统本质上是设计与开发之间的共享语言：设计稿里写 color.surface.hover，代码里引用同名 token；设计稿用组件库拖拽，代码里引用同名组件。好处是：
- 验收从"对照着抄"变成"引用即正确"——还原度问题的根源从"看走眼"变成"变量对齐"
- 设计评审从逐像素走查变成"有没有越出系统"的例外审查
- 新人上手成本降低：系统文档就是最好的 onboarding 材料
设计系统的成本：三本账
投资要对得起收益，设计系统的成本至少有三本账：
- 建设成本：tokens 体系、基础组件、工具链、文档的初始投入，通常以"人月"计，且前几个月几乎看不到产出
- 维护成本：每个组件的持续投入（状态、变体、跨端、无障碍、废弃），是长期最大的开销；组件不是一次性的，是"生下来就要养"
- 机会成本：系统团队的时间花在组件上，就花不到产品上；系统阻碍演进时，全公司的迭代速度都在为它买单
算账的结论不是"别建"，而是按资产思维建：每个组件立项时就要有"养它的人与预算"，发布节奏与团队产能匹配，组件面宁可小、不可烂。
团队规模：组件与维护者的比例
组件不是免费的：每个组件都有提案、设计、实现、文档、无障碍、兼容与废弃的持续成本。Nathan Curtis（EightShapes）在 Design Systems Teams 系列中给出过一组广为流传的经验比例：
- 8 倍法则：每 1 名专职系统设计师约可支撑 8 名产品设计师，即系统团队约为产品设计师数量的 ⅛ 起步
- 组件数量与维护者不是线性关系：组件越多，每个组件的边际维护成本越高（状态、变体、跨端、废弃叠加），一个小团队可持续维护的组件量级通常是"数十个"，超出后要么收缩组件面，要么扩张团队
比例因组织而异（组件复杂度、跨端数量、团队经验都会改变它），但规律是稳定的：系统团队的规模要按"组件资产的总维护成本"算，而不是按"公司设计师总数"拍脑袋。
什么时候不该建
设计系统是投资，投资要选时机。以下情况建系统大概率是浪费：
- 规模过小：1~2 个产品、设计师个位数——先用手工规范 + 少量共享组件顶着
- 产品形态快速变化期：早期产品每个季度都在改交互范式，固化下来的规则很快作废
- 没有人专职维护：系统没有专职维护者，三个月后必然与产品脱节，变成没人信的"僵尸规范"
误区
最常见的错误不是"不该建"，而是为还在漂移的产品提前建系统：早期产品最需要的是一致性习惯（命名、流程、走查），不是组件资产。先建习惯，等产品稳定、复用点出现，再升级为系统——顺序反了，系统会成为产品演进的刹车片。
Design tokens（设计令牌）
token 是什么
Design token（设计令牌）是把设计决策的最小原子（颜色、字号、间距、圆角、阴影、动效时长……）以"带语义的命名变量"存储的机制。核心思想是把"值"与"用途"分离：#1565C0 这个值本身没有意义，color.primary 才有——组件永远引用名字，不引用值。
三级分类：原始 / 语义 / 组件
| 层级 | 命名示例 | 说明 |
|---|---|---|
| 原始 token（primitive） | color.blue.500、space.8 | 唯一事实来源，描述"有什么"，不直接用于组件 |
| 语义 token（semantic） | color.surface.hover、space.md | 绑定用途，描述"干什么用"，主题切换只换这层映射 |
| 组件 token（component） | button.bg.primary、card.radius.lg | 组件内部引用语义 token，是组件样式与系统之间的接缝 |
原始 token 是全系统的基础色板与尺度；语义 token 是产品与主题之间的适配层；组件 token 让组件可以局部定制而不污染全局。三层的好处：改值只动原始层，换主题只动语义层，调组件只动组件层。
命名规范
token 命名是给全公司用的公共 API，规范不统一后面全是返工：
- 命名空间层级：
类别.对象.属性.状态，如color.surface.hover、type.size.body、elevation.level.2 - 小写、点分、语义化：
color.text.primary优于c-tp或blue1；不写死值，写用途 - 状态进名字：
hover、focus、disabled是 token 名的一部分，不是临时拼出来的 - 避免意义重叠：
color.blue与color.primary并存时，组件必须只引用后者
token 落地检查清单
评审 token 体系时逐项打勾，任何一项不过都会在后期加倍偿还：
- 组件与页面代码里没有裸值（色值、字号、间距全部走 token）
- 语义层完整：surface / text / border / state（hover、focus、disabled、error）都覆盖
- 深色模式与品牌换肤只需替换语义层映射，组件零改动
- token 名全仓库唯一、小写点分、不含具体值（
color.blue.500是原始层，组件不直接引用） - token 仓库是唯一事实来源，各端产物由构建生成，无手工维护副本
- 设计工具（Figma）与代码共用同一 token 源，两端名称一致
- 新 token 走提案评审，不随组件悄悄加
主题化：token 映射的替换
主题（theme）就是一张 token 值映射表。浅色/深色模式、品牌换肤、多品牌白标，本质都是"同一套语义 token 换成不同的值"：
| 主题 | color.surface | color.text.primary | 说明 |
|---|---|---|---|
| 浅色 | #FFFFFF | #1A1A1A | 默认主题 |
| 深色 | #121212 | #F5F5F5 | 语义层换值，组件零改动 |
| 品牌 A / 品牌 B | 各品牌主色 | 各品牌文字色 | 品牌换肤 = 换一张映射表 |
组件与页面代码只认识语义 token，不感知主题——这就是"主题化"能低成本实现的原因。设计工具侧（如 Figma variables）与代码侧共用同一套 token 名，主题才能在两端一致切换。
token 的跨端落地
| 平台 | 落地方式 | 说明 |
|---|---|---|
| Web | CSS custom properties（--color-surface）+ 构建产物 | 运行时换主题只需切 data-theme 属性 |
| iOS | 生成 Swift 枚举 / 动态色（UIColor + 深色模式） | 编译期生成，token 名对应枚举名 |
| Android | resource XML 或 Compose MaterialTheme | 与 Material 主题体系可映射 |
| 设计工具 | Figma variables（token 同步插件） | 设计稿与代码共用同一 token 源 |
关键实践：token 仓库是唯一事实来源，各端产物由构建生成，不手工维护——手工复制必然漂移。
开放生态：DTCG、Style Dictionary、Tokens Studio
- DTCG（Design Tokens Community Group，W3C 社区组）：制定开放的设计令牌格式规范（
$type/$value语法），目标是 token 在不同工具、不同平台之间无损流转 - Style Dictionary：源自 Amazon 的开源构建工具，把 token 编译成 CSS、Swift、Kotlin 等各端产物，是"token 仓库 → 多端产物"流水线的事实标准
- Tokens Studio for Figma：Figma 插件，在 Figma 内管理 token 并与代码仓库双向同步
三者组合的典型流水线：Tokens Studio 在 Figma 里维护 → Style Dictionary 编译出各端产物 → DTCG 格式作为交换标准。
token 与"像素级还原"
"像素级还原"之争在 token 化之后基本消解：设计稿与代码引用同一变量名，还原问题从"人眼对照"变成"变量对齐"。真正剩下的偏差是语义层的缺失——设计稿里没有 token 名、只有具体色值的地方，就是还原事故的高发区。所以 token 化的验收标准不是"变量够多"，而是"组件与页面里没有裸值"。
组件库设计
原子设计：五层与实用性争论
Brad Frost 在《Atomic Design》（2016）中提出从原子到页面的五层：
| 层级 | 含义 | 示例 |
|---|---|---|
| 原子（atoms） | 不可再分的基础元素 | 按钮、输入框、图标、标签 |
| 分子（molecules） | 原子的组合，构成一个功能单元 | 搜索框 = 输入框 + 图标 + 按钮 |
| 组织（organisms） | 分子组合成区块 | 页头、卡片列表、筛选栏 |
| 模板（templates） | 区块布局成页面骨架 | 详情页模板（无内容） |
| 页面（pages） | 模板填充真实内容 | 某商品详情页 |
实用性争论：五层是分析心智模型，不是强制目录结构。真实组件库里"分子"和"组织"的边界经常模糊（一个搜索框既是分子也是页面级组件），强行分层会导致过度拆解与命名争论。实务上把层级当粒度对话语言用（"这是原子级还是页面级组件？"），目录按功能域组织即可。
变体、状态与可组合性
- 变体（variants）：同一组件的属性化差异（尺寸、颜色、图标、密度）用 variant property 表达，而不是复制出多个组件——变体让"一个组件"在属性面板里可配置，使用方按需组合
- 状态：每个组件都要覆盖完整状态集，不是"默认能用就行"：
| 状态 | 要点 |
|---|---|
| default / hover / pressed | 基础三态，反馈可见 |
| focus / focus-visible | 键盘焦点环，见下文无障碍 |
| disabled | 置灰 + 说明原因（"未登录"而不是无理由禁用） |
| loading | 加载态与内容占位（骨架屏），防布局跳动 |
| error | 错误态 + 恢复路径（重试/编辑） |
- 可组合性：组件像函数——单一职责、组合优于继承。
Input+Icon组合出SearchInput，而不是新造一个组件；组合层让基础组件保持简单，派生需求在组合层解决
组件 API 设计
组件对外暴露的 props 就是它的 API，标准与软件接口一致：
- props 最小化：默认值覆盖 80% 用例，非必要不暴露；每个 props 都要有"谁会用、为什么用"的答案
- 语义化命名：
onSelect优于onClick（表达语义而非事件）、size="md"优于size="12"（表达档次而非像素） - 受控与非受控：明确组件的受控模式（value + onChange）与非受控模式（defaultValue），两种都要可用
- 类型安全：props 类型即文档；TS 类型推导让使用方在编译期就发现误用
提示
组件 API 与软件 API 共享同一条铁律：发布即契约。一次"顺手"的 props 改名，就是全公司使用方的 breaking change——这也是为什么组件版本管理要 semver（见下文治理）。
组件健康度评审清单
组件发布前逐项打勾，任何一项不过不得转正式：
- 至少两个产品线的真实使用方，且有明确维护人
- 变体与状态齐全：默认 / hover / focus / disabled / loading / error
- 样式全部引用 token，无裸值；深色模式与主题切换下验证通过
- 键盘可达、焦点可见、ARIA 语义、读屏验证通过（WCAG AA）
- 文档含用途、反例、代码示例、无障碍说明、版本历史
- API 已评审：props 最小化、语义化命名、受控/非受控明确
- 性能与体积可接受（按需加载、无冗余依赖）
- 与现有组件无重复职责；重复则先走废弃流程再上新
无障碍默认内置
可访问性不是组件的"附加项"，是组件的默认值：组件自带键盘可达、焦点管理、ARIA 语义与读屏支持，使用方不做任何事就能得到 WCAG AA 基线（对比度 ≥ 4.5:1、键盘可操作、焦点可见、动效可关闭）。具体到组件：
- 焦点管理：弹窗/抽屉的焦点圈定（focus trap）、关闭后焦点归还触发元素
- 语义：原生语义标签优先（
button、dialog），必要时补 ARIA；状态变化用aria-live播报 - 键盘：所有操作可键盘完成，焦点环（focus-visible）可见不丢
- 减动效：尊重
prefers-reduced-motion，动效提供关闭开关
误区
"无障碍后续再补"在组件库语境下等于永远不补：使用方在几十个页面里逐处补丁的成本远高于组件内一次性内置。组件评审清单里无障碍与功能验收同级，不通过不得发布。
主流设计系统巡礼
Material Design 3 / Material You（Google）
- 体系结构：M3 是 token 化最彻底的主流系统，五个 token 分类：color、typography、shape、elevation、state；token 命名如
md.sys.color.primary、md.sys.shape.corner.large，系统级（sys）与参考级（ref）分层 - 动态取色（dynamic color）：Material You 从用户壁纸提取颜色生成色板（tonal palettes），让整个系统的配色随用户个性化——主题从"品牌固定"走向"用户可塑"
- 组件体系：FAB（悬浮操作按钮）、bottom sheets、cards、top app bar、navigation bar/rail/drawer、dialog、snackbar、chips、switch 等，每个组件有明确的 elevation 层级与状态规范
- Material Theme Builder：官方 Web 工具与 Figma 插件，输入品牌色即可生成整套 M3 主题与 token
- 取经点：token 分类与动态主题思路（品牌色 → 系统色板）值得任何系统借鉴；局限：与 Android 生态绑定深，跨平台落地需自行映射；风格辨识度强，品牌自定义空间相对小（以官方页面为准）
Apple Human Interface Guidelines（HIG）
- 平台惯例优先：HIG 的核心立场是"遵守平台惯例，不强求跨平台一致"——iOS（触控）、macOS（多窗口、菜单栏、键盘）、visionOS（空间计算、玻璃材质）、watchOS（表盘）各有自己的惯例，系统组件默认即最佳实践
- App 结构：启动、导航（层级/扁平/内容驱动）、模态的组织方式有明确文档；设计模式：内容、导航、反馈等模式都有规范页
- 设计原则：美学完整性、一致性、直接操作、反馈、隐喻、用户控制（iOS）；macOS 侧是 clarity / deference / depth（清晰、谦逊、纵深）
- Liquid Glass：2025 年 WWDC 引入的新一代视觉语言，以半透明玻璃材质、光感与深度为特征，统一各平台外观（以官方页面为准，2026-08 整理时点）
- 取经点：平台惯例意识（"在哪个平台就长得像哪个平台"）与系统组件默认策略；局限：HIG 不开源组件代码，仅覆盖 Apple 平台，Web/跨端团队只能借鉴其原则
Ant Design（蚂蚁集团）
- 定位：企业级中后台设计语言，2015 年起伴随 React 生态（antd）成长，是中后台场景组件覆盖最全的系统之一（表格、表单、数据可视化、反馈组件），中文文档与案例生态最好
- 设计价值观：自然、确定性、意义感、生长性（4.0 起）
- 主题化演进：less 变量定制（4.x）→ CSS-in-JS（5.x，
@ant-design/cssinjs）；token 分三层：seed token（如colorPrimary，种子）→ map token（派生色板）→ alias token（组件别名），ConfigProvider支持全局与局部定制，algorithm提供 dark / compact 预设 - 取经点：中后台密集场景的组件覆盖思路与 token 派生机制（改一个种子 token 全系统联动）；局限：风格强绑定蚂蚁审美，定制自由度低于 token 化更彻底的系统；移动端另用 antd-mobile
补充：IBM Carbon 与 Microsoft Fluent 2
- IBM Carbon：完全开源的企业级设计系统，主题体系（white / g10 / g90 / g100）、图标库、React/Vue/Angular 多框架实现；适合强品牌、高定制诉求的大型企业产品
- Microsoft Fluent 2：微软跨平台设计系统（WinUI / Web / iOS / Android），开源，token 化主题；与 Windows / Office 生态绑定深，Web 端组件质量稳定
- 其他可参考：Salesforce Lightning Design System（平台级设计系统，CSS-first，服务 Salesforce 生态）、Atlassian Design System（Jira / Confluence 的协作型系统，内容与语言规范突出）
横向对比
| 系统 | 机构 | token 体系 | 主题方式 | 组件规模 | 适用场景 |
|---|---|---|---|---|---|
| Material 3 | 五类 token + 动态取色 | 动态色 + Theme Builder | 全平台，大 | Android / 跨端移动 | |
| HIG | Apple | 平台级，未公开 token 规范 | 系统浅深色 + 材质 | 平台原生 | Apple 生态 |
| Ant Design | 蚂蚁 | seed / map / alias 三层 | CSS-in-JS algorithm | 中后台全覆盖 | 企业级中后台 Web |
| Carbon | IBM | token 体系完善 | 四套主题包 | 大，多框架 | 企业级、强品牌 |
| Fluent 2 | Microsoft | token 化 | 主题化 | 大，跨平台 | Windows / Office 生态 |
选型建议：参考对象按"你要解决的问题"选——做 C 端移动产品看 Material 与 HIG，做中后台看 Ant Design，做企业级强品牌看 Carbon；取"体系结构"而不是"抄组件外观"，自己的系统最终要长在自己的品牌与场景上。
设计系统治理（DesignOps）
治理模型：集中 / 联邦 / 混合
| 模型 | 运作方式 | 适用规模 | 优点 | 缺点 |
|---|---|---|---|---|
| 集中式（centralized） | 一个专职团队全权设计、开发与发布 | 单产品、小团队（设计师 <10） | 一致性最强、决策快 | 离业务远、容易成为瓶颈 |
| 联邦式（federated） | 各产品线各自贡献、共享资产 | 多产品线的大型组织 | 贴近业务、贡献面广 | 一致性弱、质量参差 |
| 混合（hybrid） | 核心团队 + 各业务代表组成的治理委员会 | 大多数中大型组织 | 兼顾一致性与业务贴近度 | 治理成本高，决策权需明确 |
混合式是目前大厂的主流：核心团队负责平台层（tokens、基础组件、工具链），业务代表负责业务层（业务组件、模式），两者通过评审流程衔接。
贡献模型：提案 → 评审 → 发布
"谁可以加组件"必须有明确门槛，否则系统会被一次性需求的组件淹没：
- 提案：RFC / issue 说明用途、使用场景、至少两个潜在使用方；没有使用方的组件不立项
- 评审：设计评审（是否与现有组件重复、是否符合 token 体系）+ 代码评审（实现质量、性能、可访问性）+ 无障碍走查
- 发布：版本化发布 + 变更公告；新组件先进"实验性"，验证使用后再转正式
- 反馈：使用方问题回收、使用数据统计，驱动下一轮迭代
门槛铁律：一个组件至少服务两个产品线，且有人承诺维护——为单个页面造的"组件"是页面代码，不是系统资产。
版本管理：semver 与 breaking changes
- 组件与 tokens 按 semver 版本化：新增向后兼容（minor）、破坏性变更（major）
- breaking changes 走废弃周期：先标记 deprecated 并给出迁移路径，保留一个版本的过渡窗口，再移除——禁止"明天删掉"式破坏
- 变更公告与 changelog 是系统团队的正式对外沟通渠道；重大变更附迁移指南与 codemod（自动迁移脚本）
- 升级节奏：定"升级日"集中升级，比每个团队各升各的更容易控制风险
组件文档的必备内容
一个组件的文档至少要回答使用方的五个问题：
- 用途：什么时候用、什么时候不用（含与相似组件的区分）
- 规则：变体、状态、布局行为、文案规范
- 代码：正确用法示例 + 反例（常见误用）
- 无障碍：键盘、读屏、对比度的实现与验证
- 版本：API 变更历史与迁移说明
Figma 落地
设计侧的系统落地依赖 Figma 的四个能力：
- Team Library：跨文件共享组件，改动同步所有画板
- Variants：组件的变体属性化，使用方在属性面板配置
- Variables / Themes：token 的 Figma 实现，一套组件多主题切换（浅色/深色/品牌）
- Dev Mode：开发侧查看标注与代码片段，配合 token 名对齐设计稿与代码
度量与持续改进
系统没有度量就是"感觉很好"：
| 指标 | 怎么测 | 健康线 |
|---|---|---|
| 采用率 | 设计稿与代码中系统组件占比 | 80% 以上为健康，低于 60% 说明使用方在绕开系统 |
| 组件使用分布 | 各组件被引用的次数 | 发现僵尸组件（无人用）与高频组件（重点投入） |
| 设计-开发偏差 | 设计稿与实现的 diff | 偏差集中在 token 未覆盖处，说明语义层有洞 |
| 使用方满意度 | 定期调研（NPS 或 Likert） | 连续下滑说明系统成为负担 |
| 交付效率 | 页面/功能交付周期变化 | 系统价值的最终证据，长期追踪 |
实践
度量不是为了考核系统团队，而是为了找投资方向：采用率低 → 查文档与上手成本；偏差高 → 补语义 token；僵尸组件多 → 启动废弃流程。每季度一次资产盘点 + 一次使用方访谈，比任何仪表盘都管用。
DesignOps 团队角色
一个健康的系统团队（混合模型下约 5~15 人）通常包含以下角色，职责边界要写清楚：
| 角色 | 职责 | 常见误区 |
|---|---|---|
| 系统负责人 | 方向、roadmap、治理决策、资源协调 | 变成"超级设计师"，事必躬亲 |
| 系统设计师 | tokens、组件设计、文档、使用方支持 | 远离真实产品，闭门造车 |
| 系统工程师 | 组件实现、构建流水线、发布与升级工具 | 只做实现，不参与 API 评审 |
| 内容设计师 | 文案规范、内容模式、错误信息模板 | 被省略——文案是行为的一部分 |
| 布道者 / 社区经理 | onboarding、答疑、使用方反馈回收 | 变成客服，反馈不回流到产品 |
关键实践：系统团队的成员要定期轮换到产品团队（每半年到一年），否则系统必然脱离真实场景；产品团队的代表进治理委员会，是混合模型运转的关节。
常见失败模式
| 失败模式 | 症状 | 对策 |
|---|---|---|
| 系统团队成为瓶颈 | 所有变更排队等系统团队，使用方绕道自建 | 混合治理下放贡献权；组件评审自动化；明确"业务组件业务建" |
| 组件过度抽象 | 为一个用例做十个 props，为"未来"预留一堆参数 | YAGNI：先服务真实用例，第二次复用时再泛化 |
| 文档与实现脱节（drift） | 组件更新了、文档没更，使用方按旧文档写出坏代码 | 文档与代码同源（组件内注释生成文档）、发布流程强制同步 |
| 只看组件不看行为 | 组件库很全，文案、交互模式、信息架构全靠各团队自己悟 | 模式库与内容规范与组件库并重，行为规则也进系统 |
| 系统僵化阻碍创新 | "系统里没有"成为不做新设计的理由 | 例外流程（escalation）+ 定期修订：系统必须给"打破它"留合法通道 |
提醒
设计系统的失败几乎都不是"组件不够好"，而是治理失灵：要么管得太死（瓶颈、僵化），要么放得太开（漂移、失控）。维护系统的第一责任是保持"一致性"与"演进速度"的平衡，而不是追求组件数量的增长。
AI 时代的设计系统
AI 生成 UI：design-to-code 的能力与局限
AI 生成界面的工具在快速成熟：Figma AI / Make（文生 UI、图生 UI）、Vercel v0（文生组件代码）、Motiff（妙多，中文 AI 设计工具）、Anima / Builder.io（Figma 设计稿转代码）等。能力边界大致是：
- 能做：从一句话或一张草图生成页面布局、生成组件代码、设计稿转 React/Vue 实现
- 做不好：复杂状态与交互（loading/error/权限分支）、无障碍细节、动效、长流程的信息架构，以及品牌一致性——裸模型生成的界面"看起来不错，但不是你的产品"
判据：生成结果能不能落到你的组件库与 token 上，决定它是否可用——能对齐组件库的生成是加速器，对齐不了的生成是返工源头。
设计系统作为 AI 生成的护栏
设计系统在 AI 时代的角色从"给人看的规范"变成"约束生成的先验"：
- 约束生成空间：把允许的组件、token、模式注入生成上下文（提示词、检索增强），生成结果天然落在系统内，而不是生成后人工审查兜底
- 品牌一致性：token 与组件库是生成质量的"先验"——模型先学会你的语言，再谈生成，比"生成了再改"便宜一个数量级
- 典型实践：v0 对组件库（如 shadcn/ui）与 Tailwind token 的原生支持、Motiff 对设计稿中组件与 token 的识别复用，都是"系统约束生成"的雏形
AI 改变设计交付：从"切图标注"到"语义描述 + token"
传统 handoff 是"设计稿 + 标注 + 切图"，开发照着像素实现；AI 时代的交付物在变：
- 设计产出从"像素"变成"决策"：AI 直接消费 token 名与组件 API，交付物是语义描述 + token 引用 + 组件调用
- handoff 从"人翻译"变成"机器直接读"：设计稿里的组件与 token 结构越干净，AI 生成代码的准确率越高——设计系统的规范程度直接决定 AI 交付质量
- 设计师的工作重心从"画"转向"定规则与审结果"：定义组件行为、评审 AI 输出、维护 token 语义，与原型与设计交付的 handoff 章节呼应
组件级 AI 与可组合性的未来
- 组件开始内嵌 AI 能力：智能默认值、内容自动填充、表单自动校验——可组合性让 AI 能力像组件一样插拔（需要时引入、不需要时摘掉）
- 设计系统成为 AI 时代的记忆库：模式、文案、行为被 AI 检索复用的知识资产；系统的文档与 token 质量，就是 AI 生成质量的上限
- 长期看，设计系统的价值重心从"组件资产"转向"决策资产"：可被 AI 引用与执行的规则，比可被人类翻阅的文档更值钱
提示
反直觉的结论：AI 越强，设计系统越重要——AI 生成的规模效应放大了"系统内生成"与"系统外生成"的质量差。没有系统约束的 AI 生成是"每个页面都长得不一样"的自动化，有了系统约束才是"每页都是你的产品"的规模化。
来源说明
以下来源均于 2026-08-24 整理；官方页面可能随时更新，事实以官方页面为准。
官方文档
- Material Design 3（design tokens、dynamic color、components、Material Theme Builder）
- Apple Human Interface Guidelines（平台原则、App 结构、设计模式、Liquid Glass）
- Ant Design（antd 5 主题化与 design token 文档）
- IBM Carbon Design System、Microsoft Fluent 2、Salesforce Lightning Design System
- DTCG（Design Tokens Community Group）、Style Dictionary、Tokens Studio
经典著作与博客
- Brad Frost, Atomic Design（2016，atomicdesign.bradfrost.com）
- Alla Kholmatova, Design Systems（2017，设计系统的模式与原则）
- Nathan Curtis / EightShapes, Design Systems Teams 系列（eightshapes.com，团队规模与组件维护比例、8 倍法则的讨论）
- NN/g（Nielsen Norman Group）与 Smashing Magazine 关于设计系统治理与度量的文章（按需引用）
相关页面
- 产品设计与原型总览
- 视觉设计基础（色彩、排版、栅格与 tokens 的视觉侧）
- 交互设计基础（心智模型、反馈、可达性）
- 原型与设计交付（handoff 与设计交付）
- 设计评审与可用性度量（评审与度量方法论）
- 设计师黑话速查（FAB、bottom sheet、design token 等术语）
发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用