设计 Token 自动同步：别让颜色停在设计稿里

里欧跑得慢

13人浏览 · 2026-07-02 22:00:29

里欧跑得慢 · 2026-07-02 22:00:29 发布

设计 Token 自动同步：别让颜色停在设计稿里

一、Token 的价值是跨工具一致，而不是换个名字存颜色

设计 Token 把颜色、字号、间距、圆角、阴影和动效参数变成可管理变量。它的意义不只是让设计稿看起来规范，而是让设计工具、前端代码、移动端代码和文档使用同一套语义。否则设计稿里叫 primary-500，代码里写 #1677ff，组件库里又叫 brandBlue，一致性会慢慢失控。

自动同步要解决两个问题：谁是 Token 的源头，以及变更如何进入代码。源头可以是设计工具、Token 仓库或设计系统平台；进入代码时要经过版本、评审和测试。不要让设计师随手改一个颜色，就自动影响生产环境。Token 也是代码资产，需要发布流程。

二、同步链路：从设计语义到多端产物

flowchart TD
    A[Token 源文件] --> B[Schema 校验]
    B --> C[构建转换]
    C --> D[Web CSS Variables]
    C --> E[Flutter Theme]
    C --> F[文档站]
    D --> G[组件库发布]
    E --> G

Token 应该按语义分层。基础层可以是原始色板，例如 blue.500；语义层是业务含义，例如 color.action.primary.background；组件层是具体组件变量，例如 button.primary.bg。项目中真正大量使用的应是语义层和组件层，而不是到处引用基础色板。

多端同步时，命名规范要稳定。Web 需要 CSS Variables，Flutter 需要 ThemeData 或常量类，小程序可能需要 JSON 或 WXSS 变量。构建工具可以把同一份 Token 转成不同平台格式，但前提是源文件结构清晰。

三、Token 源文件：先做 Schema 校验

下面是一份简化的 Token 文件。实际项目中可以加入描述、暗色模式和废弃标记。

{
  "color": {
    "action": {
      "primary": {
        "background": { "value": "#2563EB", "type": "color" },
        "text": { "value": "#FFFFFF", "type": "color" }
      }
    }
  },
  "radius": {
    "control": { "value": "6px", "type": "dimension" }
  }
}

Schema 校验至少检查字段完整性、颜色格式、单位合法性、命名层级和重复定义。还要避免直接删除正在被代码使用的 Token。可以引入废弃周期：先标记 deprecated，组件库迁移完成后再删除。这样能减少破坏性变更。

构建产物也要可读。Web 端可以生成 :root { --color-action-primary-background: #2563EB; }，Flutter 端可以生成静态常量或 ThemeExtension。自动生成不代表不可理解，研发仍然需要能追踪某个变量来自哪里。