Skip to Content

27d - 设计系统与组件库维护

本文是《AI Agent 实战手册》第 27 章第 4 节。 上一节:27c-设计到代码工作流 | 下一节:27e-响应式布局与无障碍

概述

设计系统是前端工程的”宪法”——它定义了颜色、间距、字体、圆角等视觉决策,并通过组件库将这些决策落地为可复用的代码。然而,维护设计系统一直是团队最头疼的工作之一:Token 漂移、文档过时、组件不一致、多品牌主题管理复杂。2025-2026 年,AI 正在从根本上改变这一局面——从 Design Token 的自动提取与同步,到 Storybook MCP 让 AI 编码助手”理解”你的组件库,再到 AI 驱动的视觉回归测试和一致性审计。本节系统化地覆盖 AI 辅助设计系统维护的完整工作流,帮助你用更少的人力维护更高质量的设计系统。


1. Design Token 管理与 AI 辅助主题化

1.1 Design Token 基础概念

Design Token 是设计决策的最小原子单位——将颜色、间距、字体等视觉属性抽象为命名的键值对,实现”定义一次,处处使用”。

Token 层级结构(金字塔模型):

┌─────────────────────────────┐ │ Component Tokens │ ← button-primary-bg, card-border-radius │ (组件级 Token) │ ├─────────────────────────────┤ │ Semantic Tokens │ ← color-action-primary, spacing-md │ (语义级 Token) │ ├─────────────────────────────┤ │ Global/Primitive Tokens │ ← blue-500, 16px, 0.75rem │ (全局/原始 Token) │ └─────────────────────────────┘
  • 全局 Token:原始值,如 blue-500: #3B82F6、space-4: 16px
  • 语义 Token:赋予含义,如 color-action-primary: {blue-500}、spacing-md: {space-4}
  • 组件 Token:绑定到具体组件,如 button-primary-bg: {color-action-primary}

这种分层结构是多品牌主题化的基础——切换品牌时只需替换全局 Token 层,语义和组件层自动继承。

1.2 W3C Design Tokens 规范(2025.10)

2025 年 10 月,W3C Design Tokens Community Group 发布了首个稳定版规范(Design Tokens Format Module 2025.10),为工具间的 Token 交换提供了标准化格式。

标准 Token 格式示例:

{ "color": { "brand": { "primary": { "$value": "#3B82F6", "$type": "color", "$description": "主品牌色,用于主要操作按钮和链接" } } }, "spacing": { "md": { "$value": "16px", "$type": "dimension" } } }

1.3 Token 管理工具推荐

工具用途价格适用场景
Tokens StudioFigma 内 Token 管理、Git 同步、Graph Engine免费基础 / Starter €39/人/月 / Pro €49/人/月需要 Figma 内直接管理 Token 并同步到代码
Style Dictionary v4Token 构建系统,JSON → 多平台输出免费(开源)需要将 Token 转换为 CSS/iOS/Android 等多平台格式
SpecifyToken 引擎,自动同步 Figma → 代码免费试用 / 付费计划按需定价需要自动化 Token 同步管线
Figma VariablesFigma 原生变量系统Figma 付费计划内含已使用 Figma 且需要原生 Token 支持
Cobalt UI轻量级 Token 构建工具,支持 W3C 规范免费(开源)需要符合 W3C 标准的轻量方案
design-lintToken 使用 Lint 检查免费(开源)需要在 CI 中验证 Token 使用合规性
Claude Code + MCPAI 辅助 Token 审计、生成、同步Claude 订阅费用需要 AI 辅助 Token 管理和审计

1.4 AI 辅助 Token 生成与提取

AI 可以从多种来源自动提取和生成 Design Token:

从设计文件提取 Token

操作步骤:

步骤 1:使用 Figma MCP Server 连接设计文件

在 AI 编码助手(Claude Code / Cursor / Kiro)中配置 Figma MCP Server,让 AI 能直接读取 Figma 文件中的样式和变量。

// .mcp.json 配置 { "mcpServers": { "figma": { "command": "npx", "args": ["-y", "@anthropic/figma-mcp-server"], "env": { "FIGMA_ACCESS_TOKEN": "your-figma-token" } } } }

步骤 2:用 AI 提取 Token

提示词模板: 请分析 Figma 文件 [文件URL] 中的设计样式,提取所有 Design Token 并按以下结构组织: 1. 全局 Token(Global/Primitive): - 颜色色板(包含所有色阶) - 间距系统(4px 基准网格) - 字体系统(字族、字重、字号) - 圆角、阴影、边框 2. 语义 Token(Semantic): - 根据使用场景命名(如 color-text-primary, color-bg-surface) - 引用全局 Token 3. 输出格式:W3C Design Tokens Format(JSON) 4. 命名规范:kebab-case,层级用 . 分隔

步骤 3:AI 辅助 Token 命名优化

AI 可以根据使用模式建议语义化的 Token 名称:

提示词模板: 审查以下 Design Token 命名,检查是否存在: 1. 命名不一致(混用 camelCase 和 kebab-case) 2. 语义不清晰(如 color-1, color-2 应改为 color-text-primary) 3. 缺少必要的语义层(直接在组件中使用全局 Token) 4. 冗余 Token(值相同但名称不同) Token 文件: [粘贴 Token JSON] 请给出修改建议和修改后的完整 Token 文件。

1.5 多品牌主题化工作流

多品牌主题化是设计系统的高级需求——同一套组件库支持多个品牌的视觉风格。AI 可以大幅简化这一过程。

主题化架构

tokens/ ├── global/ │ ├── colors.json # 全局色板(所有品牌共享的原始值) │ ├── spacing.json # 间距系统 │ └── typography.json # 字体系统 ├── brands/ │ ├── brand-a/ │ │ ├── colors.json # Brand A 的品牌色覆盖 │ │ └── typography.json # Brand A 的字体覆盖 │ ├── brand-b/ │ │ ├── colors.json # Brand B 的品牌色覆盖 │ │ └── typography.json # Brand B 的字体覆盖 │ └── brand-c/ │ └── ... ├── semantic/ │ ├── light.json # 浅色模式语义映射 │ └── dark.json # 深色模式语义映射 └── components/ ├── button.json # 按钮组件 Token └── card.json # 卡片组件 Token

AI 辅助品牌 Token 生成

提示词模板: 基于以下基础设计系统 Token,为新品牌 [品牌名] 生成品牌 Token 覆盖文件: 基础 Token: [粘贴 semantic/light.json] 品牌要求: - 主色调:[色值或描述,如"科技蓝 #0066FF"] - 风格:[如"现代简约"、"温暖亲和"、"专业严肃"] - 圆角偏好:[如"圆润"、"直角"、"微圆"] - 字体:[如"Inter"、"Noto Sans SC"] 请生成: 1. brands/[品牌名]/colors.json — 品牌色覆盖 2. brands/[品牌名]/typography.json — 字体覆盖 3. 确保所有语义 Token 引用正确 4. 包含浅色和深色模式的变体

Style Dictionary 多品牌构建配置

// style-dictionary.config.js import StyleDictionary from 'style-dictionary'; const brands = ['brand-a', 'brand-b', 'brand-c']; const modes = ['light', 'dark']; brands.forEach(brand => { modes.forEach(mode => { const sd = new StyleDictionary({ source: [ 'tokens/global/**/*.json', `tokens/brands/${brand}/**/*.json`, `tokens/semantic/${mode}.json`, 'tokens/components/**/*.json', ], platforms: { css: { transformGroup: 'css', buildPath: `dist/${brand}/${mode}/`, files: [{ destination: 'tokens.css', format: 'css/variables', options: { selector: `[data-brand="${brand}"][data-mode="${mode}"]`, }, }], }, js: { transformGroup: 'js', buildPath: `dist/${brand}/${mode}/`, files: [{ destination: 'tokens.js', format: 'javascript/es6', }], }, }, }); sd.buildAllPlatforms(); }); });

1.6 让 AI 读懂你的 Token:AI-Ready Token 设计

大多数 Token 文件是为人类设计的——嵌套的 JSON 对象缺少上下文信息。当 AI 通过 MCP 读取这些 Token 时,它看到的只是一堆键值对,不知道何时该用哪个 Token。

AI-Ready Token 的关键原则:

  1. 添加 $description 字段:每个语义 Token 都应说明用途
{ "color": { "text": { "primary": { "$value": "{gray.900}", "$type": "color", "$description": "主要文本颜色,用于标题和正文。在深色模式下自动切换为 gray.100" }, "secondary": { "$value": "{gray.600}", "$type": "color", "$description": "次要文本颜色,用于辅助说明、时间戳、占位符文本" } } } }
  1. 创建 Token 使用指南文件:在 Token 目录中添加 USAGE.md
# Token 使用指南 ## 颜色选择规则 - 主要操作按钮:使用 `color.action.primary` - 危险操作按钮:使用 `color.action.danger` - 禁用状态:使用 `color.action.disabled` - 永远不要直接使用全局 Token(如 blue-500),始终使用语义 Token ## 间距规则 - 组件内部间距:使用 `spacing.sm`(8px)到 `spacing.md`(16px) - 组件之间间距:使用 `spacing.lg`(24px)到 `spacing.xl`(32px) - 页面级间距:使用 `spacing.2xl`(48px)到 `spacing.3xl`(64px)
  1. 在 Steering 规则中引用 Token:
# .cursorrules 或 CLAUDE.md 中添加 ## 设计系统规则 - 所有颜色值必须使用 tokens/semantic/ 中定义的语义 Token - 禁止在代码中硬编码颜色值(如 #3B82F6) - 间距使用 Token 变量(如 var(--spacing-md)),不使用魔法数字 - 新增组件时,先检查 tokens/components/ 是否已有对应 Token - Token 文件位于 tokens/ 目录,使用指南见 tokens/USAGE.md

2. Storybook 集成与 AI 辅助组件开发

2.1 Storybook 在设计系统中的角色

Storybook 是组件库的”展厅”和”实验室”——它让每个组件在隔离环境中渲染,提供交互式文档、视觉测试和开发工作台。2025-2026 年,Storybook 的角色进一步扩展:通过 MCP Server,它成为 AI 编码助手理解组件库的”桥梁”。

2.2 Storybook 工具生态

工具用途价格适用场景
Storybook 8组件开发、文档、测试工作台免费(开源)所有组件库项目
@storybook/addon-mcpStorybook MCP Server,让 AI 读取组件信息免费(开源)需要 AI 编码助手理解组件库
Chromatic视觉回归测试、UI 审查、Storybook 托管免费 5,000 快照/月 / Pro $149/月起需要自动化视觉测试和团队协作
storybook-addon-ai-documentationAI 自动生成组件文档免费(开源)需要自动化组件文档
@storybook/test组件交互测试免费(Storybook 内置)需要组件级交互测试
Storybook Test RunnerCI 中运行 Story 测试免费(开源)需要在 CI 中验证所有 Story

2.3 Storybook MCP Server:让 AI 理解你的组件库

Storybook MCP Server(@storybook/addon-mcp)是 2025 年设计系统领域最重要的创新之一。它通过 MCP 协议将 Storybook 中的组件信息暴露给 AI 编码助手,让 AI 在生成代码时能够:

  • 查询可用组件列表及其 API(props、事件、插槽)
  • 读取组件文档和使用示例
  • 了解组件的变体和状态
  • 自动生成符合组件库规范的 Story

安装与配置

步骤 1:安装 Storybook MCP Addon

npx storybook@latest add @storybook/addon-mcp

步骤 2:配置 Storybook

// .storybook/main.ts import type { StorybookConfig } from '@storybook/react-vite'; const config: StorybookConfig = { stories: ['../src/**/*.mdx', '../src/**/*.stories.@(js|jsx|mjs|ts|tsx)'], addons: [ '@storybook/addon-essentials', '@storybook/addon-mcp', // 添加 MCP addon ], framework: { name: '@storybook/react-vite', options: {}, }, }; export default config;

步骤 3:在 AI 编码助手中配置 MCP 连接

// .mcp.json(Claude Code / Kiro) { "mcpServers": { "storybook": { "command": "npx", "args": ["@anthropic/storybook-mcp-server", "--storybook-url", "http://localhost:6006"] } } }

步骤 4:启动 Storybook 并使用 AI

# 终端 1:启动 Storybook npm run storybook # 终端 2:使用 AI 编码助手 # AI 现在可以查询你的组件库了

AI + Storybook MCP 工作流

开发者描述需求 ↓ AI 通过 MCP 查询可用组件 ↓ AI 选择合适的组件组合 ↓ AI 生成使用现有组件的代码 ↓ AI 自动生成对应的 Story ↓ 开发者在 Storybook 中预览验证 ↓ Chromatic 运行视觉回归测试

2.4 AI 辅助 Story 生成

为每个组件编写完整的 Story 是一项繁琐但重要的工作。AI 可以自动分析组件的 Props 接口,生成覆盖所有变体和状态的 Story。

提示词模板:生成组件 Story

提示词模板: 为以下 React 组件生成完整的 Storybook Story 文件(CSF 3 格式): 组件代码: [粘贴组件代码] 要求: 1. 使用 CSF 3 格式(export const StoryName: Story = {}) 2. 包含 Meta 配置(title、component、argTypes、decorators) 3. 为每个重要的 props 组合创建独立的 Story: - Default:默认状态 - 每个 variant/size/color 的变体 - 禁用状态 - 加载状态(如适用) - 错误状态(如适用) - 空状态(如适用) 4. 添加 autodocs 标签 5. 为复杂 props 配置 argTypes 控件 6. 添加 play 函数测试关键交互(如点击、输入) 7. 使用项目的 Design Token 作为装饰器背景

示例:AI 生成的 Button Story

// Button.stories.tsx — AI 生成 import type { Meta, StoryObj } from '@storybook/react'; import { expect, fn, userEvent, within } from '@storybook/test'; import { Button } from './Button'; const meta = { title: 'Components/Button', component: Button, tags: ['autodocs'], argTypes: { variant: { control: 'select', options: ['primary', 'secondary', 'outline', 'ghost', 'danger'], description: '按钮变体', }, size: { control: 'select', options: ['sm', 'md', 'lg'], description: '按钮尺寸', }, disabled: { control: 'boolean' }, loading: { control: 'boolean' }, }, args: { onClick: fn(), }, } satisfies Meta<typeof Button>; export default meta; type Story = StoryObj<typeof meta>; export const Primary: Story = { args: { variant: 'primary', children: '主要按钮', }, }; export const Secondary: Story = { args: { variant: 'secondary', children: '次要按钮', }, }; export const AllVariants: Story = { render: () => ( <div style={{ display: 'flex', gap: '12px', alignItems: 'center' }}> <Button variant="primary">Primary</Button> <Button variant="secondary">Secondary</Button> <Button variant="outline">Outline</Button> <Button variant="ghost">Ghost</Button> <Button variant="danger">Danger</Button> </div> ), }; export const AllSizes: Story = { render: () => ( <div style={{ display: 'flex', gap: '12px', alignItems: 'center' }}> <Button size="sm">Small</Button> <Button size="md">Medium</Button> <Button size="lg">Large</Button> </div> ), }; export const Disabled: Story = { args: { variant: 'primary', disabled: true, children: '禁用按钮', }, }; export const Loading: Story = { args: { variant: 'primary', loading: true, children: '加载中...', }, }; // 交互测试 export const ClickTest: Story = { args: { variant: 'primary', children: '点击测试', }, play: async ({ canvasElement, args }) => { const canvas = within(canvasElement); const button = canvas.getByRole('button'); await userEvent.click(button); await expect(args.onClick).toHaveBeenCalledOnce(); }, };

2.5 AI 辅助组件文档生成

组件文档是设计系统采用率的关键——没有好文档的组件库等于没有组件库。AI 可以从组件代码自动生成高质量文档。

提示词模板:生成组件文档

提示词模板: 为以下组件生成 Storybook MDX 文档页面: 组件代码: [粘贴组件代码] 组件 Story: [粘贴 Story 代码] 文档要求: 1. 概述:一句话说明组件用途 2. 何时使用 / 何时不使用 3. Props API 表格(自动从 TypeScript 类型生成) 4. 使用示例: - 基础用法 - 常见组合 - 与其他组件配合使用 5. 设计指南: - 推荐的 Token 使用 - 间距和对齐规则 6. 无障碍说明: - ARIA 属性 - 键盘交互 - 屏幕阅读器行为 7. 变更日志(如有) 输出格式:Storybook MDX

自动化文档更新工作流

# .github/workflows/docs-update.yml name: Auto-update Component Docs on: push: paths: - 'src/components/**/*.tsx' - '!src/components/**/*.stories.tsx' - '!src/components/**/*.test.tsx' jobs: update-docs: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Detect changed components id: changes run: | echo "files=$(git diff --name-only HEAD~1 | grep 'src/components.*\.tsx$' | grep -v '.stories\|.test' | tr '\n' ',')" >> $GITHUB_OUTPUT - name: Generate/update stories and docs if: steps.changes.outputs.files != '' run: | # 使用 AI 检查是否需要更新 Story 和文档 echo "Changed components: ${{ steps.changes.outputs.files }}" # 触发 AI 辅助文档更新(通过 Claude Code API 或自定义脚本) npx tsx scripts/update-component-docs.ts --files "${{ steps.changes.outputs.files }}" - name: Create PR with doc updates uses: peter-evans/create-pull-request@v6 with: title: "docs: auto-update component documentation" body: "AI-generated documentation updates for changed components" branch: docs/auto-update

3. 组件库一致性验证

3.1 一致性验证的三个维度

组件库的一致性需要从三个维度进行验证:

┌──────────────────────────────────────────────┐ │ 一致性验证金字塔 │ ├──────────────────────────────────────────────┤ │ │ │ 🔺 视觉一致性 │ │ (像素级视觉回归测试) │ │ │ │ 🔺🔺 API 一致性 │ │ (Props 命名、类型、模式统一) │ │ │ │ 🔺🔺🔺 无障碍一致性 │ │ (ARIA、键盘导航、对比度合规) │ │ │ └──────────────────────────────────────────────┘

3.2 视觉回归测试

视觉回归测试通过截图对比,确保代码变更不会意外改变组件的视觉外观。

视觉测试工具对比

工具类型价格Storybook 集成AI 能力适用场景
Chromatic云服务免费 5K 快照/月 / Pro $149/月起原生集成(同团队开发)智能差异检测Storybook 项目首选
Percy (BrowserStack)云服务免费试用 / Team $399/月起插件支持AI 视觉对比需要跨浏览器截图
Applitools Eyes云服务免费试用 / 按需定价插件支持Visual AI(业界领先)需要最先进的 AI 视觉对比
Playwright本地/CI免费(开源)需手动集成无需要免费方案或自定义流程
Lost Pixel开源 + 云免费(开源)/ 云版按需原生支持基础对比需要开源自托管方案

Chromatic + Storybook 视觉测试工作流

步骤 1:安装 Chromatic

npm install --save-dev chromatic

步骤 2:首次发布基线

npx chromatic --project-token=<your-project-token>

步骤 3:配置 CI 自动化

# .github/workflows/chromatic.yml name: Chromatic on: push: branches: [main] pull_request: branches: [main] jobs: chromatic: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 # Chromatic 需要 git 历史 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - uses: chromaui/action@latest with: projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }} autoAcceptChanges: main # main 分支自动接受变更作为新基线 exitZeroOnChanges: true # PR 中有变更时不阻塞,等待人工审查

步骤 4:PR 中审查视觉变更

Chromatic 会在 PR 中自动评论,展示所有视觉变更的截图对比。团队成员可以逐个审查并接受或拒绝变更。

AI 辅助视觉测试分析

提示词模板: Chromatic 检测到以下组件的视觉变更: [粘贴 Chromatic 报告或截图描述] 请分析: 1. 这些视觉变更是否是预期的?(基于最近的代码变更) 2. 是否有意外的副作用?(如修改 Button 影响了 Card) 3. 变更是否符合设计系统的 Token 规范? 4. 是否需要更新其他相关组件? 最近的代码变更: [粘贴 git diff 或变更描述]

3.3 API 一致性检查

组件 API(Props)的一致性是设计系统可用性的基础。AI 可以帮助检测和修复 API 不一致问题。

常见 API 不一致问题

问题类型示例正确做法
命名不一致Button 用 color,Badge 用 variant统一使用 variant
尺寸命名不一致Button 用 sm/md/lg,Input 用 small/medium/large统一使用 sm/md/lg
布尔 Props 命名isDisabled vs disabled统一使用 disabled(HTML 原生属性名)
事件命名onClick vs onPress vs handleClick统一使用 on + 事件名(onClick)
子元素传递label vs text vs children简单文本用 children,复杂内容用具名 Props

提示词模板:API 一致性审计

提示词模板: 请审计以下组件库的 Props API 一致性: 组件列表: [列出所有组件的 Props 接口,或指向组件目录] 检查项: 1. **命名一致性**: - variant/color/type 是否统一? - size 的值是否统一(sm/md/lg vs small/medium/large)? - 布尔 Props 是否统一(isX vs X)? - 事件处理器命名是否统一(onX 模式)? 2. **类型一致性**: - 相同概念是否使用相同类型? - 是否有不必要的 string 类型(应该用联合类型)? 3. **模式一致性**: - 所有可禁用组件是否都支持 disabled? - 所有可加载组件是否都支持 loading? - 所有组件是否都支持 className/style 透传? - 所有组件是否都正确使用 ref 转发? 4. **默认值一致性**: - 相同 Props 的默认值是否一致? 请输出: - 不一致问题列表(按严重程度排序) - 建议的统一规范 - 需要修改的组件和具体变更

ESLint 插件强制 Token 使用

通过 ESLint 插件在代码层面强制使用 Design Token,防止硬编码值:

// .eslintrc.js module.exports = { plugins: ['@your-org/design-system'], rules: { // 禁止在 CSS-in-JS 中使用硬编码颜色值 '@your-org/design-system/no-hardcoded-colors': 'error', // 禁止在 CSS-in-JS 中使用硬编码间距值 '@your-org/design-system/no-hardcoded-spacing': 'error', // 强制使用 Token 变量 '@your-org/design-system/use-design-tokens': 'warn', }, };

参考实现:

  • Atlassian 的 @atlaskit/eslint-plugin-design-system:强制使用 Atlassian Design Token
  • MetaMask 的 @metamask/eslint-plugin-design-tokens:强制使用 MetaMask Token
  • Carbon Design System 的 stylelint-plugin-carbon-tokens:Stylelint 版本

3.4 无障碍一致性审计

设计系统的无障碍合规需要在组件级别保证,而不是在应用级别补救。

AI 辅助无障碍审计

提示词模板: 请对以下组件进行无障碍审计: 组件代码: [粘贴组件代码] 检查项: 1. **ARIA 属性**: - 是否有正确的 role 属性? - 是否有必要的 aria-label / aria-labelledby? - 动态内容是否使用 aria-live? - 展开/折叠是否使用 aria-expanded? 2. **键盘交互**: - 是否可以通过 Tab 聚焦? - 是否支持 Enter/Space 激活? - 是否支持 Escape 关闭(弹窗/下拉)? - 焦点顺序是否合理? 3. **颜色对比度**: - 文本与背景的对比度是否 ≥ 4.5:1(AA 标准)? - 大文本对比度是否 ≥ 3:1? - 非文本元素对比度是否 ≥ 3:1? 4. **屏幕阅读器**: - 图标按钮是否有文本替代? - 装饰性图片是否标记为 aria-hidden? - 表单元素是否有关联的 label? 请输出问题列表和修复建议。

Storybook 无障碍测试自动化

// .storybook/preview.ts — 全局无障碍检查 import type { Preview } from '@storybook/react'; const preview: Preview = { parameters: { a11y: { // 使用 axe-core 进行自动化无障碍检查 config: { rules: [ { id: 'color-contrast', enabled: true }, { id: 'label', enabled: true }, { id: 'aria-roles', enabled: true }, { id: 'keyboard-access', enabled: true }, ], }, // 在 Story 面板中显示无障碍检查结果 element: '#storybook-root', }, }, }; export default preview;
// 在 CI 中运行无障碍测试 // scripts/a11y-audit.ts import { checkA11y } from '@storybook/addon-a11y'; // 配合 Storybook Test Runner 使用 // package.json { "scripts": { "test:a11y": "test-storybook --url http://localhost:6006 --tags a11y" } }

4. 设计系统自动化工作流

4.1 端到端自动化管线

一个成熟的设计系统需要自动化管线来保证质量和效率:

Figma 设计变更 ↓ Token Studio 同步 Token 到 Git ↓ CI 触发 Style Dictionary 构建 ↓ 生成多平台 Token 文件(CSS/JS/iOS/Android) ↓ AI 检测受影响的组件 ↓ AI 更新组件 Story 和文档 ↓ Chromatic 运行视觉回归测试 ↓ ESLint 检查 Token 使用合规性 ↓ 无障碍自动审计 ↓ PR 审查 → 合并 → 发布新版本

4.2 Token 同步自动化

Tokens Studio → Git 同步

Tokens Studio 支持直接将 Token 同步到 Git 仓库:

步骤 1:在 Tokens Studio 中配置 Git 同步

  1. 打开 Tokens Studio Figma 插件
  2. 进入 Settings → Sync Providers
  3. 选择 GitHub/GitLab/Bitbucket
  4. 配置仓库地址、分支、Token 文件路径
  5. 设置同步方向(双向/单向)

步骤 2:配置 CI 自动构建

# .github/workflows/tokens-build.yml name: Build Design Tokens on: push: paths: - 'tokens/**/*.json' jobs: build-tokens: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - name: Validate token format run: npx tsx scripts/validate-tokens.ts - name: Build tokens for all platforms run: npx style-dictionary build - name: Check for breaking changes run: npx tsx scripts/check-token-breaking-changes.ts - name: Commit built files uses: stefanzweifel/git-auto-commit-action@v5 with: commit_message: "build: update generated token files" file_pattern: "dist/tokens/**"

AI 辅助 Token 变更影响分析

提示词模板: 以下 Design Token 发生了变更: 变更前: [粘贴旧 Token 值] 变更后: [粘贴新 Token 值] 请分析: 1. 哪些组件会受到影响?(基于组件 Token 的引用链) 2. 视觉影响程度(微小/中等/显著) 3. 是否是破坏性变更(需要 major 版本号)? 4. 建议的迁移步骤(如果是破坏性变更) 5. 需要更新的文档和 Story

4.3 组件库版本管理

语义化版本策略

变更类型版本号示例
新增组件/TokenMinor(x.Y.z)新增 Tooltip 组件
新增 Props/变体Minor(x.Y.z)Button 新增 icon prop
修复 BugPatch(x.y.Z)修复 Select 下拉位置偏移
删除组件/PropsMajor(X.y.z)移除 deprecated 的 Card v1
Token 值变更(兼容)Patch(x.y.Z)调整 spacing-md 从 16px 到 14px
Token 重命名/删除Major(X.y.z)重命名 color-primary 为 color-brand

AI 辅助变更日志生成

提示词模板: 基于以下 Git 提交记录,为组件库生成 CHANGELOG: 提交记录: [粘贴 git log --oneline] 要求: 1. 按 Conventional Commits 分类(feat/fix/breaking/docs) 2. 按组件分组 3. 标注破坏性变更(BREAKING CHANGE) 4. 包含迁移指南(如有破坏性变更) 5. 格式遵循 Keep a Changelog 规范

4.4 设计系统健康度仪表板

通过自动化指标追踪设计系统的健康度:

// scripts/design-system-health.ts interface DesignSystemHealth { // Token 覆盖率:代码中使用 Token 的比例 tokenCoverage: number; // 目标 > 95% // 组件覆盖率:有 Story 的组件比例 storyCoverage: number; // 目标 100% // 文档覆盖率:有文档的组件比例 docsCoverage: number; // 目标 100% // 无障碍合规率:通过 axe-core 检查的组件比例 a11yCoverage: number; // 目标 100% // 视觉测试覆盖率:有视觉快照的 Story 比例 visualTestCoverage: number; // 目标 > 90% // API 一致性得分 apiConsistencyScore: number; // 目标 > 90% // 组件采用率:应用中使用设计系统组件的比例 adoptionRate: number; // 目标 > 80% }
提示词模板: 请分析我们设计系统的健康度指标: [粘贴健康度数据] 请给出: 1. 总体健康度评分(A/B/C/D/F) 2. 最需要改进的 3 个领域 3. 每个领域的具体改进建议 4. 优先级排序和预估工作量

5. AI 辅助组件库开发完整工作流

5.1 新组件开发流程

1. 需求分析 ├── 从设计稿提取组件规格 ├── AI 分析是否可复用现有组件 └── 确定 Props API 设计 2. Token 准备 ├── 检查现有 Token 是否满足需求 ├── AI 建议新增 Token(如需要) └── 更新 Token 文件 3. 组件开发 ├── AI 生成组件骨架代码 ├── 开发者完善业务逻辑 └── AI 检查 Token 使用合规性 4. Story 编写 ├── AI 生成覆盖所有变体的 Story ├── 添加交互测试(play 函数) └── 配置 argTypes 控件 5. 文档编写 ├── AI 生成 MDX 文档 ├── 添加使用指南和设计规范 └── 添加无障碍说明 6. 质量验证 ├── Chromatic 视觉快照 ├── 无障碍自动审计 ├── API 一致性检查 └── 单元测试和交互测试 7. 发布 ├── AI 生成变更日志 ├── 语义化版本号 └── 发布到 npm / 内部 registry

5.2 提示词模板:完整组件开发

提示词模板: 请为设计系统开发一个新的 [组件名] 组件。 设计规格: - 用途:[组件用途描述] - 变体:[列出所有变体,如 primary/secondary/outline] - 尺寸:[列出所有尺寸,如 sm/md/lg] - 状态:[列出所有状态,如 default/hover/active/disabled/loading] 技术要求: - 框架:[React/Vue/Svelte] - 样式方案:[Tailwind CSS / CSS Modules / styled-components] - Token 文件位置:[tokens/ 目录路径] - 现有组件参考:[参考类似组件的代码路径] 请生成: 1. 组件代码(使用 Design Token,支持 ref 转发) 2. TypeScript 类型定义 3. Storybook Story(CSF 3 格式,覆盖所有变体和状态) 4. 单元测试(使用 Vitest + Testing Library) 5. MDX 文档页面 API 设计规范: - variant Props 使用联合类型 - size 使用 sm/md/lg - 布尔 Props 不加 is 前缀(disabled 而非 isDisabled) - 事件使用 on 前缀(onClick, onChange) - 支持 className 和 style 透传 - 使用 forwardRef

实战案例:从零搭建多品牌设计系统

案例背景

一家 SaaS 公司需要为三个产品线(企业版、教育版、个人版)搭建统一的设计系统,每个产品线有不同的品牌色和字体,但共享相同的组件库。

步骤 1:Token 架构设计

使用 AI 设计 Token 层级结构:

提示词: 我需要为一个多品牌 SaaS 产品设计 Design Token 架构。 三个品牌:Enterprise(专业蓝)、Education(活力绿)、Personal(温暖橙)。 共享组件库,通过 Token 切换品牌主题。 每个品牌支持浅色和深色模式。 请设计完整的 Token 目录结构和示例文件。

AI 生成的 Token 结构:

tokens/ ├── global/ │ ├── colors.json # 完整色板(blue-50~950, green-50~950, ...) │ ├── spacing.json # 4px 基准网格(space-1: 4px ~ space-16: 64px) │ ├── typography.json # 字体系统 │ ├── radius.json # 圆角系统 │ └── shadow.json # 阴影系统 ├── brands/ │ ├── enterprise/ │ │ └── overrides.json # 主色 blue-600, 字体 Inter │ ├── education/ │ │ └── overrides.json # 主色 green-500, 字体 Nunito │ └── personal/ │ └── overrides.json # 主色 orange-500, 字体 DM Sans ├── semantic/ │ ├── light.json # 浅色模式映射 │ └── dark.json # 深色模式映射 └── components/ ├── button.json ├── input.json ├── card.json └── ...

步骤 2:Style Dictionary 构建配置

// build-tokens.js import StyleDictionary from 'style-dictionary'; const brands = ['enterprise', 'education', 'personal']; const modes = ['light', 'dark']; for (const brand of brands) { for (const mode of modes) { const sd = new StyleDictionary({ source: [ 'tokens/global/**/*.json', `tokens/brands/${brand}/**/*.json`, `tokens/semantic/${mode}.json`, 'tokens/components/**/*.json', ], platforms: { css: { transformGroup: 'css', buildPath: `dist/${brand}/${mode}/`, files: [{ destination: 'variables.css', format: 'css/variables', options: { selector: `:root[data-brand="${brand}"][data-mode="${mode}"]`, }, }], }, tailwind: { transformGroup: 'js', buildPath: `dist/${brand}/${mode}/`, files: [{ destination: 'tailwind-tokens.js', format: 'javascript/es6', }], }, }, }); await sd.buildAllPlatforms(); console.log(`✅ Built tokens for ${brand}/${mode}`); } }

步骤 3:Storybook 多主题预览

// .storybook/preview.ts import type { Preview } from '@storybook/react'; // 导入所有品牌主题 import '../dist/enterprise/light/variables.css'; import '../dist/enterprise/dark/variables.css'; import '../dist/education/light/variables.css'; import '../dist/education/dark/variables.css'; import '../dist/personal/light/variables.css'; import '../dist/personal/dark/variables.css'; const preview: Preview = { globalTypes: { brand: { name: 'Brand', description: '切换品牌主题', defaultValue: 'enterprise', toolbar: { icon: 'paintbrush', items: [ { value: 'enterprise', title: 'Enterprise' }, { value: 'education', title: 'Education' }, { value: 'personal', title: 'Personal' }, ], }, }, mode: { name: 'Mode', description: '切换颜色模式', defaultValue: 'light', toolbar: { icon: 'sun', items: [ { value: 'light', title: 'Light' }, { value: 'dark', title: 'Dark' }, ], }, }, }, decorators: [ (Story, context) => { const brand = context.globals.brand; const mode = context.globals.mode; return ( <div data-brand={brand} data-mode={mode}> <Story /> </div> ); }, ], }; export default preview;

步骤 4:Chromatic 多主题视觉测试

// .storybook/modes.ts — 配置 Chromatic 多主题快照 export const allModes = { 'enterprise-light': { brand: 'enterprise', mode: 'light', }, 'enterprise-dark': { brand: 'enterprise', mode: 'dark', }, 'education-light': { brand: 'education', mode: 'light', }, 'education-dark': { brand: 'education', mode: 'dark', }, 'personal-light': { brand: 'personal', mode: 'light', }, 'personal-dark': { brand: 'personal', mode: 'dark', }, }; // 在 Story 中使用 // Button.stories.tsx export const Primary: Story = { args: { variant: 'primary', children: 'Button' }, parameters: { chromatic: { modes: allModes, // Chromatic 会为每个品牌×模式组合截图 }, }, };

步骤 5:AI 辅助一致性审计

每次发布前,使用 AI 进行全面审计:

提示词: 请对我们的设计系统进行发布前审计: 1. Token 审计: - 检查 tokens/ 目录中是否有未使用的 Token - 检查是否有组件直接使用全局 Token(应使用语义 Token) - 检查三个品牌的 Token 覆盖是否完整 2. 组件 API 审计: - 检查所有组件的 Props 命名一致性 - 检查 TypeScript 类型导出是否完整 3. Story 审计: - 检查是否所有组件都有对应的 Story - 检查是否覆盖了所有变体和状态 4. 文档审计: - 检查是否所有组件都有 MDX 文档 - 检查文档中的代码示例是否可运行 5. 无障碍审计: - 运行 axe-core 检查所有 Story - 检查颜色对比度(所有品牌×模式组合) 组件目录:src/components/ Token 目录:tokens/ Story 目录:src/components/**/*.stories.tsx

案例分析

关键决策点:

  1. Token 架构选择:采用三层金字塔(全局→语义→组件),而非扁平结构。这让品牌切换只需替换全局层,语义和组件层自动继承。

  2. Style Dictionary 而非手动构建:自动化 Token 到多平台的转换,避免手动维护 CSS 变量、JS 常量、iOS/Android 值的同步问题。

  3. Storybook MCP 集成:让 AI 编码助手在生成新页面时自动使用现有组件,而非重新造轮子。

  4. Chromatic 多主题快照:每个组件在 6 种主题组合(3 品牌 × 2 模式)下都有视觉基线,任何 Token 变更都能被检测到。

  5. ESLint 强制 Token 使用:在代码层面防止硬编码值,确保所有视觉属性都通过 Token 系统管理。


避坑指南

❌ 常见错误

  1. Token 层级混乱:组件直接引用全局 Token

    • 问题:button-bg: {blue-500} 直接引用全局色值,切换品牌时需要逐个修改组件 Token
    • 正确做法:button-bg: {color-action-primary} 引用语义 Token,品牌切换只需修改语义→全局的映射
  2. Storybook Story 只覆盖”快乐路径”

    • 问题:只写了 Default Story,缺少禁用、加载、错误、空状态、长文本溢出等边缘情况
    • 正确做法:为每个组件编写覆盖所有状态的 Story 矩阵,使用 AI 自动生成确保完整性
  3. 视觉测试只在一个主题下运行

    • 问题:只在浅色模式下运行 Chromatic,深色模式的视觉问题直到用户反馈才发现
    • 正确做法:配置 Chromatic modes,在所有品牌×模式组合下运行视觉快照
  4. Token 命名不语义化

    • 问题:使用 color-1、color-2 或 blue-primary 这样的命名,AI 和新成员都无法理解用途
    • 正确做法:使用语义化命名如 color-text-primary、color-bg-surface、color-border-default,并添加 $description
  5. 组件 API 不一致

    • 问题:Button 用 variant,Badge 用 color,Tag 用 type,表达同一概念却用不同 Props 名
    • 正确做法:制定 API 设计规范文档,使用 AI 定期审计一致性,新组件开发前先检查规范
  6. 忽略无障碍测试

    • 问题:组件库没有无障碍测试,上线后被用户投诉或审计不通过
    • 正确做法:在 Storybook 中集成 @storybook/addon-a11y,在 CI 中运行 axe-core 检查,将无障碍作为组件发布的门禁条件
  7. Token 同步断裂:设计和代码不一致

    • 问题:设计师在 Figma 中修改了颜色,但代码中的 Token 没有同步更新
    • 正确做法:使用 Tokens Studio 的 Git 同步功能,或 Specify 的自动化管线,确保 Figma → Git → 构建 → 发布的全链路自动化
  8. 过度依赖 AI 生成,缺少人工审查

    • 问题:AI 生成的组件代码直接合并,没有检查是否符合设计系统规范
    • 正确做法:AI 生成作为起点,人工审查 Token 使用、API 一致性、无障碍合规后再合并

✅ 最佳实践

  1. Token 优先:任何视觉属性都先定义为 Token,再在组件中引用。永远不要在组件代码中硬编码颜色、间距、字体值。

  2. AI-Ready Token:为每个语义 Token 添加 $description 字段,创建 USAGE.md 指南,在 Steering 规则中引用 Token 规范。这让 AI 能正确选择和使用 Token。

  3. Story 即文档:利用 Storybook 的 autodocs 功能,让 Story 自动生成 API 文档。配合 AI 生成的 MDX 页面,实现文档的零维护成本。

  4. 视觉测试全覆盖:每个组件的每个变体、每个主题组合都应有视觉快照。使用 Chromatic 的 modes 功能自动化多主题测试。

  5. CI 门禁:将 Token 合规检查、视觉回归测试、无障碍审计、API 一致性检查全部集成到 CI 中,作为 PR 合并的必要条件。

  6. 定期 AI 审计:每个 Sprint 使用 AI 进行一次全面的设计系统健康度审计,追踪 Token 覆盖率、Story 覆盖率、文档覆盖率、无障碍合规率等指标。


相关资源与延伸阅读

  1. W3C Design Tokens Community Group  — Design Tokens 规范的官方社区,2025.10 版本是首个稳定版规范
  2. Style Dictionary 官方文档  — Token 构建系统的完整文档,包含 v4 的新特性和多品牌配置指南
  3. Tokens Studio 官方网站  — Figma Token 管理插件,支持 Graph Engine 和 Git 同步
  4. Storybook MCP Addon  — 官方 MCP Server 插件,让 AI 编码助手理解组件库
  5. Chromatic 官方文档  — 视觉回归测试平台,由 Storybook 维护团队开发
  6. Design Tokens that AI Can Actually Read  — 如何设计 AI 友好的 Token 结构
  7. Best AI Tools for Design System Teams in 2026  — 设计系统团队的 AI 工具推荐
  8. Supercharge Your Design System with LLMs and Storybook MCP  — Storybook MCP 与 LLM 集成的深度教程
  9. AI in Design Systems: Consistency Made Simple  — AI 辅助设计系统一致性验证的实践指南
  10. How to Automate Design System Audits and Testing  — 设计系统审计和测试自动化的完整指南

参考来源


📖 返回 总览与导航 | 上一节:27c-设计到代码工作流 | 下一节:27e-响应式布局与无障碍

Last updated on