从前，在一个繁忙的设计小镇上，住着一位名叫小林的设计师。他每天的工作就是为镇上的各种建筑——网站页面、手机应用、海报公告牌——绘制外观。刚开始，每接到一个新建筑任务，他都要从头丈量、调色、设计按钮和字体。他发现自己在重复做着相同的事情，每天都在“重新发明轮子”。 直到有一天，镇长请来了一位名叫“小助手”的智能机器人。小助手很聪明，它沉思片刻，对小林说：“我们一起把小镇的建筑标准建立起来吧！定义一套通用的颜色、字体和零件规范，以后建房就像搭积木一样快！”小林恍然大悟——这就是设计系统。而小助手，正是现在热门的AI。这篇指南，就是要教你怎么和AI一起，从零开始搭建属于你自己的设计系统，让设计从“重复造轮子”变为“高效复用”。

岗位关联

职业价值：掌握AI辅助搭建设计系统，你将从“画图人”升级为“系统架构师”。在团队协作、产品迭代中，这套方法论能直接转化为成倍的效率提升和统一的用户体验，是迈向高级设计师/设计工程总监的核心能力。

目录
  1. 可视化演示
  2. 认识设计系统
  3. 设计令牌体系
  4. 组件库建设
  5. 规范文档编写
  6. AI辅助搭建
  7. 结构驱动协作
  8. 维护与迭代
  9. 综合应用案例
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示AI辅助设计系统搭建全流程：设计令牌体系生成、原子设计组件架构、规范文档与迭代维护。切换模式查看各维度，拖动滑块调节组件层级深度。

本节配有交互动效（进入视口后自动加载，约 3KB）。

设计令牌体系架构 设计令牌(Design Tokens)是设计系统的原子变量，包含色彩、字体、间距、圆角、阴影五大类，通过键值对统一管理视觉属性 AI辅助令牌生成：从品牌指南提取色彩→自动推导色阶→生成语义令牌→输出多平台格式(CSS/JSON/Swift)，效率提升5-10倍 tokens = { color, typography, spacing, radius, elevation } 令牌是设计系统的基石

认识设计系统

想象你的家里有一个超大的乐高积木盒，里面有各种标准化的积木块。你不需要每次拼新模型时都从磨塑料粒子开始，而是直接从这个盒子里取出想要的零件，快速组合。设计系统，就是设计界的“标准乐高盒”。

以前的设计师干的是“手工砖瓦匠”的活：每画一个新页面，都要从选色、定义字重、画按钮开始。设计系统改变了这一切——先把色彩、字体、间距、组件这些“积木块”标准化，然后像搭积木一样拼出页面。这样一来，设计的重心从“造零件”转向“拼装与创意”。

从实践层面看，设计系统是“色彩、字体、组件、规范”的统一体。它由低到高分三层：基础层（设计令牌，如颜色变量）、组件层（按钮、输入框等带状态的零件）、模板层（由组件构成的完整页面骨架）。这三者层层递进，和乐高系统完全同构。

还记得小林吗？当他第一次和小助手一起清点“积木盒”时，才发现自己之前90%的时间都在重复造轮子。而这，正是他与高效设计之间，隔着的那个“设计系统”。

设计系统=设计令牌(色彩、字体、间距)+组件库(按钮、导航、表单)+规范文档(何时用、怎么用)\text{设计系统} = \text{设计令牌}(\text{色彩、字体、间距}) + \text{组件库}(\text{按钮、导航、表单}) + \text{规范文档}(\text{何时用、怎么用})
这个公式说明：设计系统 = 基础变量 + 可复用零件 + 使用说明，三者缺一不可。
  1. 设计令牌是设计系统中最小的原子单位，如同乐高砖，所有组件都由它构成。
    设计令牌∈{色彩,字体,间距,圆角,阴影}\text{设计令牌} \in \{\text{色彩}, \text{字体}, \text{间距}, \text{圆角}, \text{阴影}\}
  2. 组件库将令牌组合成有功能意义的零件，比如“主要按钮”就是“主色令牌+圆角令牌+文字令牌”的组合。
    组件=f(令牌1,令牌2,…,令牌n)\text{组件} = f(\text{令牌}_1, \text{令牌}_2, \ldots, \text{令牌}_n)
  3. 规范文档说明在什么场景下使用什么组件，如同乐高的拼搭说明书。
    规范={组件,场景,行为}\text{规范} = \{\text{组件}, \text{场景}, \text{行为}\}

设计令牌体系

如果说设计系统是乐高盒，那设计令牌就是盒子里那一颗颗最基础的标准砖。红砖、蓝砖、长条砖、方砖，各有固定尺寸和颜色。在数字世界里，“色彩分级”“字体阶乘”“间距度量”就是这些砖的生产标准。

设计令牌不是简单的变量，它是携带语义的设计决策。比如“品牌主色”是令牌，“警示状态色”也是令牌，但后者还携带了“出错时使用”的语义。实践中通常用层级结构组织令牌：Primitive Token（原始值，如#FF0000）→ Semantic Token（语义值，如color-danger）→ Component Token（组件级，如button-danger-bg）。

等级化的令牌体系带来两个好处：“换肤”只需要改Primitive层的映射，“语义变更”（比如把警示色从红色改为橙色）只需改Semantic层定义，而不必全局搜索替换。AI在这里大显身手——它能批量分析设计稿中的色值使用频率，自动聚类出语义颜色，从旧项目中迁移出规范化的令牌层级。

有了这套“标准砖”，小林的“换肤”工作从痛苦的彻夜加班，变成了只需调整Primitive层的几只“源砖”，整个“乐高城”都能瞬间变换色系。

T=Tprimitive→映射Tsemantic→绑定TcomponentT = T_{\text{primitive}} \xrightarrow{\text{映射}} T_{\text{semantic}} \xrightarrow{\text{绑定}} T_{\text{component}}
三层令牌结构如同“原料库→调料配方→成品菜”，逐层解耦，让大规模换色、换风格变得安全可控。
  1. Primitive Token存最原始的设计决策，比如品牌蓝色值 #3366FF。
    Tprimitive={blue-500:#3366FF}T_{\text{primitive}} = \{\text{blue-500}: \#3366FF\}
  2. Semantic Token赋予原始值业务语义，色值会变，语义不变。
    Tsemantic={color-primary:blue-500}T_{\text{semantic}} = \{\text{color-primary}: \text{blue-500}\}
  3. Component Token把语义变量绑定到具体组件部位。
    Tcomponent={btn-primary-bg:color-primary}T_{\text{component}} = \{\text{btn-primary-bg}: \text{color-primary}\}

组件库建设

积木盒里若只装了散碎的砖块，拼搭效率仍然有限。聪明的乐高玩家会把常用的小结构（门、窗、车轮）预先拼好，下次玩直接取用。组件库，就是设计系统里“预拼好的零件”。

组件库建设有几个关键原则。单一职责：每个组件解决一个明确功能问题，按钮就是按钮，不要混入布局逻辑。分类归档：按基础组件（Button/Input）、导航组件（Menu/Tabs）、反馈组件（Toast/Modal）、业务组件（商品卡片/订单列表）等类别整理。状态齐全：每个组件要覆盖默认、悬停、点击、禁用、加载等交互状态，这是和普通“素材”最大的区别。文档配套：每个组件要有使用说明、代码示例和设计规范。

AI在组件库建设上能做的事情，往往出乎初学者意料。它可以分析Figma设计稿的图层结构，自动识别“这组图层组合被反复使用，应该抽成组件”；它还能为每个组件批量生成配套的Storyboard文档，甚至直接产出React/Vue代码骨架。

小林把经常用的“操作按钮”“搜索框”“用户卡片”预先拼好，下次需求来了直接“拎包入住”——他的拼搭速度，从此比别人快了三倍。

C=∑i=1NComponenti(statesi,variantsi,doci)C = \sum_{i=1}^{N} \text{Component}_i(\text{states}_i, \text{variants}_i, \text{doc}_i)
一个组件 = 状态（默认/悬停/禁用……）× 变体（大小/主题……）× 文档（用法/示例）。AI能自动补齐这些组合。
  1. states_i第 i 个组件的交互状态集合，按钮至少有 default/hover/disabled 三种。
    statesi∈{default,hover,active,disabled,loading}\text{states}_i \in \{\text{default}, \text{hover}, \text{active}, \text{disabled}, \text{loading}\}
  2. variants_i组件的变体维度，如尺寸（大/中/小）、主题（主/次/危险）。
    variantsi=size×theme\text{variants}_i = \text{size} \times \text{theme}
  3. doc_i组件文档，包含属性说明、使用场景、代码示例。
    doci={desc,usage,code}\text{doc}_i = \{\text{desc}, \text{usage}, \text{code}\}

规范文档编写

没有图纸的建筑队会乱成一锅粥。设计系统必须配一份“施工蓝图”——规范文档，告诉所有人“什么场景用什么零件，怎么用”。这份文档连接着设计与开发。

一份好的规范文档，首先要写清设计原则，比如“清晰优先于美观”“操作反馈即时可见”。这些原则是组件行为的决策依据。其次要写清使用场景：什么情况下用表格而非卡片列表？什么情况下用模态框而非新页面？命名规范同样重要：组件命名要语义化且层级清晰，比如 Button / PrimaryButton / ButtonGroup，让设计稿和代码一一对应。

AI在规范文档编写上的杀手锏是“对话式整理”。你可以把研究文档、竞品截图、团队聊天记录直接丢给AI，它会提取出高频关键词，帮你形成规范草案；它还能根据你的组件库自动生成属性表格和代码片段，省去了录屏、截图、排版的海量重复劳动。

现在，小林不必再一遍遍口头跟开发解释设计意图。他拿出“施工蓝图”，开发同事一看便知：这个场景用次级按钮，命名是 SecondaryButton，代码里面也这么写——设计系统，成了团队共同的语言。

Dspec=Rprinciple⏟设计原则+Uscenario⏟使用场景+Nnaming⏟命名约定+Scode⏟代码示例D_{\text{spec}} = \underbrace{R_{\text{principle}}}_{\text{设计原则}} + \underbrace{U_{\text{scenario}}}_{\text{使用场景}} + \underbrace{N_{\text{naming}}}_{\text{命名约定}} + \underbrace{S_{\text{code}}}_{\text{代码示例}}
规范文档四要素：原则（为什么）、场景（何时用）、命名（叫什么）、代码（怎么实现）。
  1. 设计原则决定“用什么”和“不用什么”的顶层判断标准。
    Rprinciple={清晰≻美观,即时反馈}R_{\text{principle}} = \{\text{清晰} \succ \text{美观}, \text{即时反馈}\}
  2. 使用场景描述组件适用的业务上下文，避免用错组件。
    Uscenario:场景↦组件U_{\text{scenario}}: \text{场景} \mapsto \text{组件}
  3. 命名规范让设计标注、代码变量、文档目录三处名称保持一致。
    Nnaming:设计稿术语≡代码变量名N_{\text{naming}}: \text{设计稿术语} \equiv \text{代码变量名}

AI辅助搭建

理解了设计系统的“积木盒”结构之后，你可能会问：搭建这个过程太繁琐了，有没有捷径？AI，就是专业为你“搭积木”的智能助手。

AI辅助搭建设计系统，贯穿需求分析、生成、验证、文档化全流程。交互式生成是第一步——你只需描述“我需要一套科技感的色彩体系”，AI就能给出一组候选色板及对应的令牌命名。批量转换是提高效率的关键——面对历史遗留的杂乱工程（比如颜色值散落各处），AI能自动扫描并映射为新的令牌变量，完成“拆迁重建”。一致性校验是质量保障——AI能定期扫描设计稿与代码，检查是否还有硬编码的色值/字号（即“漏网的野砖”）。文档整理则把聊天记录、设计决议自动归档成维护日志。

AI的本质是“模式识别+推断补全”。它能从你的设计稿中归纳出潜在的规律（如“所有主要按钮都是主色底+白色字+8px圆角”），然后自动提出规范建议；也能在你修改一个令牌时，自动指出所有受影响的下游组件。

小林的“小助手”就像他的私人工程队长：听需求、拆任务、整材料、把质量、写报告。小林终于从繁重的重复劳动中解脱出来，把时间花在真正需要创造力的地方。

PAI=Ggenerate⏟草案生成+Ttransfer⏟批量迁移+Vverify⏟一致性校验+Ddoc⏟自动文档P_{\text{AI}} = \underbrace{G_{\text{generate}}}_{\text{草案生成}} + \underbrace{T_{\text{transfer}}}_{\text{批量迁移}} + \underbrace{V_{\text{verify}}}_{\text{一致性校验}} + \underbrace{D_{\text{doc}}}_{\text{自动文档}}
AI辅助搭建四步法：生成草案→迁移旧值→校验龛漏→输出文档，帮你把搭建时间从数周压缩到数天。
  1. 草案生成AI根据业务属性（行业、气质）生成令牌初始值，提供选择基础。
    Ggenerate:design_brief↦candidate_TokensG_{\text{generate}}: \text{design\_brief} \mapsto \text{candidate\_Tokens}
  2. 批量迁移AI扫描旧产物，把硬编码值替换为令牌引用。
    Ttransfer:#3366FF↦var(–color-primary)T_{\text{transfer}}: \#3366FF \mapsto \text{var(--color-primary)}
  3. 一致性校验AI定期巡检，找出未被令牌覆盖的“漏网之鱼”。
    Vverify:design⊕code=∅V_{\text{verify}}: \text{design} \oplus \text{code} = \emptyset

结构驱动协作

设计系统不仅是零件盒，更是团队协作的“通用语言”。以前设计师交付设计稿，开发要反复确认色值和圆角；现在，她只需要拖出组件库里的现成件，开发拿到的代码里引用的令牌完全相同。UI 设计师与前端工程师之间，终于不用当传话筒。

在结构驱动下，团队可以“并行开发”而互不干扰——A 组正在设计首页模板，B 组正在开发支付组件，两者通过同一套令牌和组件库协同，不会因为底层的依赖混乱而互相踩脚。新成员加入团队时，熟悉系统的时间从几周缩短到一两天——他要学的不是“哪个按钮长什么样”，而是“规范写在哪儿、怎么查”。品牌的一致性也因此有了制度保障，而不是依赖某个老设计师的记忆。

AI 驱动下的协作还能提升至“组件需求预测”——AI 根据产品路线图和用户反馈，提前预测需要新增的组件，并在协作工具中自动生成待办卡片和验收标准。

有了共同语言，小林的团队从“两人三脚”变成了“雁阵飞行”，设计和研发的效率都呈几何级数提升。

团队效能=并行度⏟组件解耦×沟通成本−1⏟统一语言×入职速度⏟文档完备\text{团队效能} = \underbrace{\text{并行度}}_{\text{组件解耦}} \times \underbrace{\text{沟通成本}^{-1}}_{\text{统一语言}} \times \underbrace{\text{入职速度}}_{\text{文档完备}}
设计系统通过“组件解耦”提升并行开发效率，通过“统一语言”降低沟通成本，是团队提效的乘法器。
  1. 并行度组件之间依赖最小化，团队可同时开发互不阻塞。
    Parallel=∏i=1nComponenti(解耦)\text{Parallel} = \prod_{i=1}^{n} \text{Component}_i \quad (\text{解耦})
  2. 沟通成本设计和开发共享同一套命名与规范，减少误解。
    Comm∝1Shared Vocabulary\text{Comm} \propto \frac{1}{\text{Shared Vocabulary}}
  3. 入职速度文档规范把“隐性经验”变成“显性知识”，新同事照单操作即可。
    Onboarding=规范化程度摸索时间\text{Onboarding} = \frac{\text{规范化程度}}{\text{摸索时间}}

维护与迭代

设计系统不是博物馆展品，而是活的生命体。它需要持续维护与迭代，否则就会像无人修剪的花园般杂草丛生。维护，是搭建之后更考验功力的事。

首先是版本管理：设计系统要用语义化版本号（v1.0.0 → v1.2.0 → v2.0.0），主版本号变更代表破坏性更新（如删除旧令牌），次版本号代表向后兼容的新增，修订号代表问题修复。其次是废弃令牌清理：老代码里可能残留过时的颜色变量，AI 工具可以一键扫描出引用次数为 0 的废弃令牌并生成删除建议。变更日志会自动记录每次增删改的原因和影响范围，让团队随时知道“现在系统里有什么、为什么长这样”。新组件评审则要建立一套准入机制：够通用吗？和现有组件重复吗？有业务场景验证吗？通过评审才能进入组件库。

小林为系统设置好“自动巡检”流程，AI 每周替他查一遍废弃令牌和版本日志。他的设计系统不再是“一次性工程”，而是不断生长的城市，且有清楚的城市规划档案。

v=vmajor.vminor.vpatch,Deprecated={T:ref(T)=0}v = v_{\text{major}}.v_{\text{minor}}.v_{\text{patch}}, \quad \text{Deprecated} = \{T : \text{ref}(T) = 0\}
语义化版本号 v=主。次。修订；引用数为 0 的令牌该进垃圾桶了。维护就是“垃圾分类+定期盘点”。
  1. 版本主号破坏性更新时递增，比如删除旧组件、改名。
    vmajor←vmajor+1(breaking change)v_{\text{major}} \gets v_{\text{major}} + 1 \quad (\text{breaking change})
  2. 版本次号向后兼容的新功能或新组件时递增。
    vminor←vminor+1(new feature)v_{\text{minor}} \gets v_{\text{minor}} + 1 \quad (\text{new feature})
  3. 废弃判定扫描全仓库代码，统计每个令牌的引用次数。
    deprecated  ⟺  references(Tk)=0\text{deprecated} \iff \text{references}(T_k) = 0

综合应用案例

积累了设计系统与AI工具之后，一家产品公司可以迎来真正的“效率革命”。以某跨境电商公司的实际场景为例：旗下有 Web 端、iOS/Android App 和小程序三个触达渠道，过去一次品牌色更新需要设计与研发前后折腾一个月；搭建设计系统后，更新只需改 8 个色彩令牌，AI 自动同步生成三端代码，一天全部完成——这就是“一次部署，全端生效”。

在运营活动场景中，AI 辅助搭建的“换肤能力”让团队能在 2 小时内生成一套节日主题。从元旦红色主题切换到春节金色主题，只需要替换一组令牌映射，所有页面组件自动换装。设计研发提效之后，设计师能同时支持更多业务线，整体研发效率提升 60%。而附带的品牌资产沉淀：每一套主题、每一次设计决策、每一段组件代码，都自动归档进系统，成为公司专属的设计知识产权库。

小林的故事迎来了皆大欢喜的结局：他的“小助手”帮他盖起了一座设计大厦，而这座大厦，又将陪伴他未来更多的产品。从“画图匠”到“架构师”，他找到了设计真正的杠杆——系统与AI。

ROI=ΔEfficiency×TeamnCostbuild+Costmaintain\text{ROI} = \frac{\Delta \text{Efficiency} \times \text{Team}_n}{\text{Cost}_{\text{build}} + \text{Cost}_{\text{maintain}}}
设计系统的投资回报率 = 提效幅度 × 团队规模 / （建设成本 + 维护成本）。团队越大，收益越惊人。
  1. 提效幅度搭建前后单个需求的平均耗时对比。
    ΔE=Tbefore−TafterTbefore×100%\Delta E = \frac{T_{\text{before}} - T_{\text{after}}}{T_{\text{before}}} \times 100\%
  2. 团队规模使用系统的设计师与开发总人数。
    Teamn=ndesign+ndev\text{Team}_n = n_{\text{design}} + n_{\text{dev}}
  3. 总成本建设期间的投入加上持续维护的日常开销。
    Cost=Cbuild+Cmaintain×months\text{Cost} = C_{\text{build}} + C_{\text{maintain}} \times \text{months}

AI 应用场景

电商全平台品牌升级

阶段：维护与迭代 / 批量转换

解决的问题：以往品牌换色要改几十个页面、上百个色值，还容易漏改。通过设计令牌体系和AI批量迁移工具，只需更新底层Primitive Token，AI自动扫描全代码库替换并生成变更清单。

具体案例：某跨境电商公司决定把品牌主色从蓝色彻底换为绿色，涉及Web/App/小程序三端约200个页面。AI辅助后，设计令牌修改加三端同步耗时仅1天，而过去需要跨部门开7次协调会、耗时三周。

设计系统从零到一的搭建

阶段：需求分析与生成

解决的问题：创业公司想从“每个页面各不相同”走向规范化，传统方法需外包或招聘专家梳理数月。AI通过分析现有产品截图与代码，自动归类色彩、组件和间距，生成初版规范草案。

具体案例：AIGC产品创业团队有3个设计师、10个开发，产品变更频繁。用AI辅助搭建后，两周产出全套设计令牌与基础组件库，第二个月所有新功能均基于组件开发，返工率下降50%。

设计系统运营与自动化问诊

阶段：自动校验与文档化

解决的问题：设计系统上线后，缺少“质检员”导致乱用组件、乱写颜色。AI定时巡检设计与代码仓库，将龛漏问题（如硬编码色值）自动生成工单分发给负责人。

具体案例：某在线教育公司的设计系统维护官用AI每周五自动扫描，输出“系统体检报告”，汇报新增组件使用率、废弃令牌热力学图、规范违反次数。团队从“救火”变为“预防”，设计债务持续下降。

Python 演示

python73 行
# 设计令牌生成器：帮你从一堆CSS/设计稿色值中自动提取设计令牌import refrom collections import Counter, defaultdict  class TokenGenerator:    def __init__(self, raw_colors):        self.raw_colors = raw_colors        self.color_counter = Counter()        self.token_map = defaultdict(set)     def normalize_color(self, color):        """规范化色值: #3366FF -> #3366ff"""        color = color.lower().strip()        m = re.match(r'^#([0-9a-f]{6})$', color)        if not m:            raise ValueError(f'非法色值: {color}, 仅支持 #rrggbb 格式')        return color     def scan_colors(self):        """扫描颜色统计出现频率, 生成token候选列表"""        for color in self.raw_colors:            try:                norm = self.normalize_color(color)                self.color_counter[norm] += 1            except ValueError as exc:                print(exc)        return self.color_counter     def assign_semantic_names(self, primary_rules=None):        """分配语义名: 出现频率最高的蓝色调=color-primary"""        common_blue = ['#3366ff', '#1a73e8', '#3182f6']        common_green = ['#10b981', '#22c55e', '#0f9d58']        common_red = ['#f43f5e', '#ef4444', '#e11d48']        rules = {'blue': common_blue, 'green': common_green, 'red': common_red}        for color, freq in self.color_counter.items():            semantic = None            for group, customs in rules.items():                if color in customs:                    semantic = f'color-{group}'                    break            if semantic is None:                if freq > 3:                    semantic = 'color-primary'                elif freq > 1:                    semantic = 'color-secondary'                else:                    semantic = 'color-neutral'            self.token_map[semantic].add(color)        return dict(self.token_map)     def generate_css_variables(self):        """生成CSS自定义属性形式的最终令牌"""        lines = [':root {']        for semantic in sorted(self.token_map):            for color in self.token_map[semantic]:                lines.append(f'  --{semantic}-{color.replace("#", "")}: {color};')        lines.append('}')        return '\n'.join(lines)  if __name__ == '__main__':    dirty_css = [        '#3366FF', '#3366ff', '#1a73e8', '#3366ff', '#10b981', '#10b981',        '#f43f5e', '#e5e7eb', '#9ca3af', '#6b7280', '#374151', '#111827'    ]    gen = TokenGenerator(dirty_css)    counter = gen.scan_colors()    print('颜色频率Top5:', counter.most_common(5))    token_map = gen.assign_semantic_names()    print('分配的语义令牌:', token_map)    print('\n生成的CSS变量:')    print(gen.generate_css_variables())
目的：这段代码像一个“色彩侦探”，自动从杂乱的色值清单中统计高频颜色，按语义分组（主色/辅助色/中性色），并输出标准化的CSS变量——这就是搭建设计令牌的自动化雏形。
  1. TokenGenerator定义了一个“色彩侦探”类，专门负责从混乱中找出规律。
  2. normalize_color规范化色值格式，把 #3366FF 统一为 #3366ff，便于统计和比较。
  3. scan_colors扫描所有颜色并统计出现频率，找到最常用的“品牌主色”。
  4. assign_semantic_names为高频颜色赋予语义名称，例如将常蓝归类为 color-primary。
  5. generate_css_variables输出标准化的 CSS 自定义属性，这就是设计系统中的"Primitive Token"层。
  6. counter.most_common(5)打印出现频率最高的5种颜色，帮助你快速识别主色板。

常见误区

误区很多初学者认为，设计系统就是把按钮、输入框等组件整理到一个页面里，这个页面就是设计系统。

正解组件库是“积木中的预拼件”，它确实很重要，但只是设计系统三层结构中的“组件层”。设计系统还包括底层的设计令牌层（色彩、字体、间距等原子变量）和顶层的规范文档层（何时用、怎么用）。缺少令牌，组件无法灵活适配主题；缺少规范，团队会乱用组件。全乎三件套才算设计系统。

为何常见：因为组件库是看得见摸得着的部分，管理者容易误以为“我花钱做了个组件库页面，设计系统就建成了”；而底层变量和规范文档需要更高认知才能理解。

误区我的代码里有 `--primary: #3366ff`，所以我已经有设计令牌了。设计系统嘛，不就这么点事？

正解设计令牌不只是“变量名+值”，关键是层级化的语义体系。Primitive Token（原始值）只是最底层；Semantic Token（语义值，如 color-brand）是抽象层；Component Token（组件级，如 button-primary-bg）连接业务。真正的设计令牌体系，是要把“值”和“含义”解耦，让换肤、换主题只用改一个映射关系，而不是全局搜索替换。

为何常见：初学者往往从代码里看到一个变量就觉得掌握了全部；但设计系统的价值恰恰来自结构的顶层设计，而非单点取值。

误区AI 都能自动生成组件和文档了，那我是不是可以把它做成一个定期自动更新的东西，然后三年不管？

正解AI是帮你“减负”的助手，不是“自动驾驶”。设计系统要持续维护：新业务带来新组件需求，旧组件会过时，品牌策略会调整。AI能帮你自动扫描废弃令牌、生成变更日志、辅助一致性校验，但是“要不要改”“为什么要改”这些决策需要人来做。设计系统是活的城市，AI是修路工具，规划还是要人工判断。

为何常见：看到AI的高效执行能力，人们容易高估它的决策能力，低估设计系统的业务耦合性——设计系统本质是业务与品牌的中枢，业务不变，系统就得跟着变。

误区我的设计系统还不够完善，配色少一个success色，组件缺一个DatePicker。先不发，等完美了再推广。

正解设计系统应该是“生长型”的。只要有一个完善的核心基座（基础色彩、核心组件、基本规范），就可以发布 v0.1，在真实的业务迭代中不断丰富。等待完美的代价是团队继续各行其是，规范永远落不了地。正确做法是小步快跑：先搭地基，再在项目反馈中迭代新组件。

为何常见：完美主义在系统设计中是陷阱。人们类比“系统=教科书”，以为要敲定所有知识点才能出版；但优秀的设计系统更像“开源软件”，版本迭代才是常态。

误区设计系统嘛，就是UI/UX团队内部的事情，跟我们开发没关系。

正解设计系统的核心价值在于连接设计与开发。它的三层结构里，设计令牌层需要开发编码实现，组件库需要前端搭建，规范文档要嵌入代码示例。AI辅助设计系统的全流程中，开发更是“一致性校验”的关键执行者。没有研发参与的设计系统是空中楼阁——图纸再漂亮，无法被真正落地。

为何常见：很多人停留在“设计=画图”的旧认知，忽略了现代软件开发中“设计即代码”的趋势。设计系统从诞生的第一天起，就横跨设计与技术两个领域。

面试题

Q1. 设计系统三层结构中，最底层的基础是什么？

单选题 · easy

  • A.组件库
  • B.设计令牌← 正确答案
  • C.规范文档
  • D.页面模板

答案：B。设计系统是“积木盒”，最底层是“标准砖”——设计令牌（色彩、字体、间距等原子值）。组件库是中层预拼件，规范文档是最上层的使用说明。所以选B。

Q2. Primitive Token（原始令牌）的主要作用是？

单选题 · easy

  • A.定义组件交互逻辑
  • B.存储原始设计值如色值← 正确答案
  • C.编写用户使用手册
  • D.管理组件归档分类

答案：B。Primitive Token 坐落在最底层，保存原始值，如具体色值 #3366ff。Semantic Token 给值赋予语义，Component Token 绑定到组件部位。原始令牌是“原料”，而选A说的是逻辑层，选C是文档层，选D是组件库管理。

Q3. 一个设计完善的组件，通常不会缺少下列哪一项？

单选题 · mid

  • A.多种尺寸变体
  • B.完整的交互状态
  • C.配套组件文档
  • D.自定义业务逻辑← 正确答案

答案：D。组件的三要素是状态（default/hover/disabled等）、变体（尺寸/主题）和文档（使用说明+代码示例）。“自定义业务逻辑”恰恰是组件要保持单一职责而避免的——组件应该通用，业务逻辑放在外部，所以选D。

Q4. 在AI辅助设计系统搭建中，“批处理转换令牌”描述的是下列哪个环节？

单选题 · mid

  • A.AI扫描旧代码并自动把硬编码值替换为令牌引用← 正确答案
  • B.AI生成设计原则
  • C.AI自动规划组件分类
  • D.AI编写用户调研问卷

答案：A。批处理转换是把遗留工程中的硬编码色值/字号批量迁移为统一的令牌变量，类似“拆迁重建”中AI自动把野砖换成标准砖。生成设计原则、规划组件分类属于AI辅助的生成环节，但“批处理转换令牌”专指旧值迁移，因此选A。

Q5. AI在设计系统维护与迭代中，可以做哪些事情？

多选题 · mid

  • A.自动扫描废弃令牌← 正确答案
  • B.生成变更日志← 正确答案
  • C.定期校验一致性← 正确答案
  • D.自动作出版本升级决策

答案：ABC。AI能扫描引用次数为0的废弃令牌、生成变更日志、巡检一致性。但“是否升级主版本号”“是否做破坏性更新”是需要人参与的决策——AI是修路工具，不是城市规划师，所以不选D。

Q6. 语义化版本号 v2.1.0 中，次版本号"1"表示？

单选题 · hard

  • A.破坏性更新已发布
  • B.向后兼容的新功能已添加← 正确答案
  • C.紧急漏洞已修复
  • D.设计令牌已全部废弃

答案：B。语义化版本规则：主版本号递增代表破坏性更新，次版本号递增代表向后兼容的新增功能（如新组件入库），修订号递增代表兼容性修复。v2.1.0 中"1"是次版本号，表示新增了向后兼容内容，故选B。

Q7. 下列哪些做法有助于“结构驱动协作”？

多选题 · hard

  • A.组件库与代码域名保持同名← 正确答案
  • B.团队并行开发独立组件← 正确答案
  • C.规范文档内嵌代码示例← 正确答案
  • D.所有组件由一个设计师独揽

答案：ABC。结构驱动协作的核心是解耦+统一语言。同名让设计稿和代码一一对应，并行开发依赖组件解耦，文档内嵌代码示例让开发直接复用。而“一个设计师独揽”是瓶颈，不是提效，故选A、B、C。

Q8. 设计系统的“积木盒”比喻中，“预先拼好的门窗结构”对应下列哪一项？

单选题 · easy

  • A.设计令牌
  • B.组件库← 正确答案
  • C.规范文档
  • D.配色方案

答案：B。设计令牌是“标准砖块”，组件库是“预先拼好的门窗结构”，规范文档是“拼搭说明书”。所以“预先拼好的门窗结构”对应组件库。选B。

Q9. AI生成的规范文档，最不建议采用哪种形式？

单选题 · mid

  • A.从聊天记录提取高频词生成草案
  • B.同时生成设计原则与组件说明
  • C.自动嵌入组件的代码示例
  • D.完全替代人工作最终评审← 正确答案

答案：D。AI 能生成草案、整理高频词、自动化文档生成与代码嵌入，但“最终评审”需要人来做——设计原则的价值观取舍和业务对错判断不能完全外包给AI。故最不建议选D。

Q10. 关于设计系统的投资回报率，下列说法正确的是？

多选题 · extreme

  • A.团队规模越大ROI越高← 正确答案
  • B.提效幅度与ROI正相关← 正确答案
  • C.维护成本与ROI负相关← 正确答案
  • D.设计系统只对企业有利，对个人成长无益

答案：ABC。ROI公式 = 提效幅度 × 团队规模 /（建设成本+维护成本）。团队越大收益越大，效率越高收益越高，维护成本越高收益越低。设计系统对个人成长也有巨大价值——你将具备架构思维与AI协作能力，这是最稀缺的复合型竞争力。因此D错误。