前端设计系统建设复盘Design Token从理念到代码的落地全过程一、设计的不一致性有多贵某SaaS产品的UI经历2年开发后积累了82种灰色值不同组件用了不同的gray-100、14种主色调变体、7套不同的圆角规则。设计师抱怨开发实现的总是跟设计稿不一样开发抱怨设计规范变了我怎么知道改了哪。目标是建立单一真相来源——它不是口头约定的规范而是代码化的约束任何变更都能自动同步到所有组件。二、从Figma到代码的Token管道第一步在Figma中定义Variables设计师在Figma中集中管理Design Variables——颜色、字体、间距、阴影、圆角。通过Figma Variables插件导出为JSON。第二步Style Dictionary做多平台转换// tokens.json —— 中间格式 { color: { primary: { 500: { value: #4F46E5 }, 600: { value: #4338CA } }, neutral: { 100: { value: #F3F4F6 }, 200: { value: #E5E7EB }, 900: { value: #111827 } } }, spacing: { xs: { value: 4px }, sm: { value: 8px }, md: { value: 16px }, lg: { value: 24px } }, typography: { heading: { xl: { value: { fontFamily: Inter, fontSize: 32px, lineHeight: 40px, fontWeight: 700 } } } } }// build-tokens.js —— Style Dictionary 配置 const StyleDictionary require(style-dictionary); StyleDictionary.extend({ source: [tokens/**/*.json], platforms: { css: { transformGroup: css, buildPath: dist/css/, files: [{ destination: variables.css, format: css/variables, options: { outputReferences: true, }, }], }, js: { transformGroup: js, buildPath: dist/js/, files: [{ destination: tokens.js, format: javascript/es6, }], }, }, }).buildAllPlatforms();输出/* dist/css/variables.css */ :root { --color-primary-500: #4F46E5; --color-primary-600: #4338CA; --color-neutral-100: #F3F4F6; --color-neutral-200: #E5E7EB; --spacing-xs: 4px; --spacing-sm: 8px; --spacing-md: 16px; --typography-heading-xl-font-family: Inter; --typography-heading-xl-font-size: 32px; }// dist/js/tokens.js export const colorPrimary500 #4F46E5; export const spacingMd 16px;第三步组件库100%引用Token!-- Button.vue —— 零硬编码值 -- template button :classbuttonClasses slot / /button /template style scoped .btn { padding: var(--spacing-sm) var(--spacing-md); background: var(--color-primary-500); color: var(--color-neutral-100); border-radius: var(--radius-md); font-family: var(--typography-body-md-font-family); font-size: var(--typography-body-md-font-size); :hover { background: var(--color-primary-600); } } /style三、Token变更的自动化传播流程设计师改Figma Variables → 导出JSON → CI中运行Style Dictionary → 生成新的CSS/JS → 自动创建PR → Review合并 → npm publish新版本组件库# .github/workflows/token-update.yml name: Token Update on: push: paths: [tokens/**/*.json] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - run: npm ci - run: npm run build:tokens - name: Create PR uses: peter-evans/create-pull-requestv6 with: title: Token更新设计规范变更 body: | 自动检测到Token文件的变更。 请确认变更符合设计意图后合并。 branch: token-update四、Token落地的实际挑战挑战一历史组件的迁移。82种灰色值不可能一次性全部Token化。采取增量迁移——新组件用Token老组件逐步改造。每次改老组件时将其硬编码值替换为Token引用。6个月内老组件Token覆盖率从0%升至85%。挑战二Token的命名共识。设计团队和开发团队对命名有分歧。设计师习惯用Primary/Secondary开发者习惯用蓝色/灰色。最终采用了设计团队主导的语义化命名如color-primary-500——因为命名面向的是视觉意图而非颜色值。挑战三暗色模式的Token设计。不是if dark then #000 else #FFF——而是定义语义Token如color-surface、color-text-primary每套主题各自赋值:root { --color-surface: #FFFFFF; --color-text-primary: #111827; } [data-themedark] { --color-surface: #1F2937; --color-text-primary: #F9FAFB; }五、总结Design Token体系的核心价值设计与开发的单一真相来源。设计师改颜色不需要通知开发者——Token自动同步。多平台一致性。Web、iOS、Android从同一份Token源生成各自的代码——品牌色真正统一。暗色模式/品牌白标等主题切换变得简单——换一套Token值即可代码不变。Token化的代价需要设计师学习Figma Variables开发者学习Style Dictionary配置CI/CD管道的维护。但对于3人以上团队的中大型产品这个投资在6个月内即可收回——从设计师-开发者-测试三方沟通成本中节省出来的时间远超搭建Token体系的时间投入。最大的经验Token不是写一份规范文档让大家遵守而是代码强制约束不遵守就无法编译。硬编码的颜色值被ESLint规则禁止后Token覆盖率从纸面上的100%变成代码检查器验证过的100%。这才是落地的真正含义。