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 Studio | Figma 内 Token 管理、Git 同步、Graph Engine | 免费基础 / Starter €39/人/月 / Pro €49/人/月 | 需要 Figma 内直接管理 Token 并同步到代码 |
| Style Dictionary v4 | Token 构建系统,JSON → 多平台输出 | 免费(开源) | 需要将 Token 转换为 CSS/iOS/Android 等多平台格式 |
| Specify | Token 引擎,自动同步 Figma → 代码 | 免费试用 / 付费计划按需定价 | 需要自动化 Token 同步管线 |
| Figma Variables | Figma 原生变量系统 | Figma 付费计划内含 | 已使用 Figma 且需要原生 Token 支持 |
| Cobalt UI | 轻量级 Token 构建工具,支持 W3C 规范 | 免费(开源) | 需要符合 W3C 标准的轻量方案 |
| design-lint | Token 使用 Lint 检查 | 免费(开源) | 需要在 CI 中验证 Token 使用合规性 |
| Claude Code + MCP | AI 辅助 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 # 卡片组件 TokenAI 辅助品牌 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 的关键原则:
- 添加
$description字段:每个语义 Token 都应说明用途
{
"color": {
"text": {
"primary": {
"$value": "{gray.900}",
"$type": "color",
"$description": "主要文本颜色,用于标题和正文。在深色模式下自动切换为 gray.100"
},
"secondary": {
"$value": "{gray.600}",
"$type": "color",
"$description": "次要文本颜色,用于辅助说明、时间戳、占位符文本"
}
}
}
}- 创建 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)- 在 Steering 规则中引用 Token:
# .cursorrules 或 CLAUDE.md 中添加
## 设计系统规则
- 所有颜色值必须使用 tokens/semantic/ 中定义的语义 Token
- 禁止在代码中硬编码颜色值(如 #3B82F6)
- 间距使用 Token 变量(如 var(--spacing-md)),不使用魔法数字
- 新增组件时,先检查 tokens/components/ 是否已有对应 Token
- Token 文件位于 tokens/ 目录,使用指南见 tokens/USAGE.md2. Storybook 集成与 AI 辅助组件开发
2.1 Storybook 在设计系统中的角色
Storybook 是组件库的”展厅”和”实验室”——它让每个组件在隔离环境中渲染,提供交互式文档、视觉测试和开发工作台。2025-2026 年,Storybook 的角色进一步扩展:通过 MCP Server,它成为 AI 编码助手理解组件库的”桥梁”。
2.2 Storybook 工具生态
| 工具 | 用途 | 价格 | 适用场景 |
|---|---|---|---|
| Storybook 8 | 组件开发、文档、测试工作台 | 免费(开源) | 所有组件库项目 |
| @storybook/addon-mcp | Storybook MCP Server,让 AI 读取组件信息 | 免费(开源) | 需要 AI 编码助手理解组件库 |
| Chromatic | 视觉回归测试、UI 审查、Storybook 托管 | 免费 5,000 快照/月 / Pro $149/月起 | 需要自动化视觉测试和团队协作 |
| storybook-addon-ai-documentation | AI 自动生成组件文档 | 免费(开源) | 需要自动化组件文档 |
| @storybook/test | 组件交互测试 | 免费(Storybook 内置) | 需要组件级交互测试 |
| Storybook Test Runner | CI 中运行 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-update3. 组件库一致性验证
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 同步
- 打开 Tokens Studio Figma 插件
- 进入 Settings → Sync Providers
- 选择 GitHub/GitLab/Bitbucket
- 配置仓库地址、分支、Token 文件路径
- 设置同步方向(双向/单向)
步骤 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. 需要更新的文档和 Story4.3 组件库版本管理
语义化版本策略
| 变更类型 | 版本号 | 示例 |
|---|---|---|
| 新增组件/Token | Minor(x.Y.z) | 新增 Tooltip 组件 |
| 新增 Props/变体 | Minor(x.Y.z) | Button 新增 icon prop |
| 修复 Bug | Patch(x.y.Z) | 修复 Select 下拉位置偏移 |
| 删除组件/Props | Major(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 / 内部 registry5.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案例分析
关键决策点:
-
Token 架构选择:采用三层金字塔(全局→语义→组件),而非扁平结构。这让品牌切换只需替换全局层,语义和组件层自动继承。
-
Style Dictionary 而非手动构建:自动化 Token 到多平台的转换,避免手动维护 CSS 变量、JS 常量、iOS/Android 值的同步问题。
-
Storybook MCP 集成:让 AI 编码助手在生成新页面时自动使用现有组件,而非重新造轮子。
-
Chromatic 多主题快照:每个组件在 6 种主题组合(3 品牌 × 2 模式)下都有视觉基线,任何 Token 变更都能被检测到。
-
ESLint 强制 Token 使用:在代码层面防止硬编码值,确保所有视觉属性都通过 Token 系统管理。
避坑指南
❌ 常见错误
-
Token 层级混乱:组件直接引用全局 Token
- 问题:
button-bg: {blue-500}直接引用全局色值,切换品牌时需要逐个修改组件 Token - 正确做法:
button-bg: {color-action-primary}引用语义 Token,品牌切换只需修改语义→全局的映射
- 问题:
-
Storybook Story 只覆盖”快乐路径”
- 问题:只写了 Default Story,缺少禁用、加载、错误、空状态、长文本溢出等边缘情况
- 正确做法:为每个组件编写覆盖所有状态的 Story 矩阵,使用 AI 自动生成确保完整性
-
视觉测试只在一个主题下运行
- 问题:只在浅色模式下运行 Chromatic,深色模式的视觉问题直到用户反馈才发现
- 正确做法:配置 Chromatic modes,在所有品牌×模式组合下运行视觉快照
-
Token 命名不语义化
- 问题:使用
color-1、color-2或blue-primary这样的命名,AI 和新成员都无法理解用途 - 正确做法:使用语义化命名如
color-text-primary、color-bg-surface、color-border-default,并添加$description
- 问题:使用
-
组件 API 不一致
- 问题:Button 用
variant,Badge 用color,Tag 用type,表达同一概念却用不同 Props 名 - 正确做法:制定 API 设计规范文档,使用 AI 定期审计一致性,新组件开发前先检查规范
- 问题:Button 用
-
忽略无障碍测试
- 问题:组件库没有无障碍测试,上线后被用户投诉或审计不通过
- 正确做法:在 Storybook 中集成
@storybook/addon-a11y,在 CI 中运行 axe-core 检查,将无障碍作为组件发布的门禁条件
-
Token 同步断裂:设计和代码不一致
- 问题:设计师在 Figma 中修改了颜色,但代码中的 Token 没有同步更新
- 正确做法:使用 Tokens Studio 的 Git 同步功能,或 Specify 的自动化管线,确保 Figma → Git → 构建 → 发布的全链路自动化
-
过度依赖 AI 生成,缺少人工审查
- 问题:AI 生成的组件代码直接合并,没有检查是否符合设计系统规范
- 正确做法:AI 生成作为起点,人工审查 Token 使用、API 一致性、无障碍合规后再合并
✅ 最佳实践
-
Token 优先:任何视觉属性都先定义为 Token,再在组件中引用。永远不要在组件代码中硬编码颜色、间距、字体值。
-
AI-Ready Token:为每个语义 Token 添加
$description字段,创建USAGE.md指南,在 Steering 规则中引用 Token 规范。这让 AI 能正确选择和使用 Token。 -
Story 即文档:利用 Storybook 的 autodocs 功能,让 Story 自动生成 API 文档。配合 AI 生成的 MDX 页面,实现文档的零维护成本。
-
视觉测试全覆盖:每个组件的每个变体、每个主题组合都应有视觉快照。使用 Chromatic 的 modes 功能自动化多主题测试。
-
CI 门禁:将 Token 合规检查、视觉回归测试、无障碍审计、API 一致性检查全部集成到 CI 中,作为 PR 合并的必要条件。
-
定期 AI 审计:每个 Sprint 使用 AI 进行一次全面的设计系统健康度审计,追踪 Token 覆盖率、Story 覆盖率、文档覆盖率、无障碍合规率等指标。
相关资源与延伸阅读
- W3C Design Tokens Community Group — Design Tokens 规范的官方社区,2025.10 版本是首个稳定版规范
- Style Dictionary 官方文档 — Token 构建系统的完整文档,包含 v4 的新特性和多品牌配置指南
- Tokens Studio 官方网站 — Figma Token 管理插件,支持 Graph Engine 和 Git 同步
- Storybook MCP Addon — 官方 MCP Server 插件,让 AI 编码助手理解组件库
- Chromatic 官方文档 — 视觉回归测试平台,由 Storybook 维护团队开发
- Design Tokens that AI Can Actually Read — 如何设计 AI 友好的 Token 结构
- Best AI Tools for Design System Teams in 2026 — 设计系统团队的 AI 工具推荐
- Supercharge Your Design System with LLMs and Storybook MCP — Storybook MCP 与 LLM 集成的深度教程
- AI in Design Systems: Consistency Made Simple — AI 辅助设计系统一致性验证的实践指南
- How to Automate Design System Audits and Testing — 设计系统审计和测试自动化的完整指南
参考来源
- W3C Design Tokens Specification 2025.10 (2025-10)
- Storybook MCP Sneak Peek (2025-11)
- Storybook 8 Release (2025-05)
- Design Tokens in the AI Era (2025-11)
- Design Tokens and Theming in AI-Generated UI Systems (2026-01)
- Best AI Tools for Design System Teams (2025-12)
- How Design Systems Teams Are Using AI Tools (2025-11)
- Supercharge Your Design System with LLMs and Storybook MCP (2025-12)
- AI in Design Systems: Consistency Made Simple (2026-01)
- How to Connect Your Design System to LLMs with Storybook (2025-09)
- Percy vs Chromatic: Visual Regression Testing Comparison (2025-05)
- 12 Automated Visual Testing Tools to Consider in 2026 (2026-01)
- Chromatic Pricing (2025)
- Tokens Studio Pricing (2025)
- Style Dictionary v4 (2025-08)
- Implementing Multi-Brand Theming with Style Dictionary (2025-04)
- 11 Proven Design System Tools (2026 Guide) (2026-02)
- Atlassian ESLint Plugin Design System (2025-08)
- MetaMask ESLint Plugin Design Tokens (2025)
📖 返回 总览与导航 | 上一节:27c-设计到代码工作流 | 下一节:27e-响应式布局与无障碍