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: #3B82F6space-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)移除 deprecatedCard v1
Token 值变更(兼容)Patch(x.y.Z)调整 spacing-md 从 16px 到 14px
Token 重命名/删除Major(X.y.z)重命名 color-primarycolor-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-1color-2blue-primary 这样的命名,AI 和新成员都无法理解用途
    • 正确做法:使用语义化命名如 color-text-primarycolor-bg-surfacecolor-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