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

设计 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 -- GToken 应该按语义分层。基础层可以是原始色板例如blue.500语义层是业务含义例如color.action.primary.background组件层是具体组件变量例如button.primary.bg。项目中真正大量使用的应是语义层和组件层而不是到处引用基础色板。多端同步时命名规范要稳定。Web 需要 CSS VariablesFlutter 需要 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。自动生成不代表不可理解研发仍然需要能追踪某个变量来自哪里。四、变更治理Token 发布需要回归测试Token 变更可能影响大面积界面。一个背景色变浅可能导致文字对比不足一个间距变大可能让移动端按钮换行一个圆角变化可能破坏组件截图基线。因此 Token 发布应触发视觉回归、无障碍对比检查和组件快照测试。设计评审也要从“颜色好不好看”升级为“语义是否正确”。例如危险按钮使用红色不应直接引用red.500而应引用color.danger.background。当暗色模式或品牌换肤出现时语义 Token 才能稳定映射。最后要有版本记录。Token 包可以独立发版组件库声明依赖版本。业务项目升级 Token 时知道引入了哪些视觉变化。没有版本设计系统会变成一组难以追踪的全局变量。五、总结设计 Token 自动同步的核心是语义、校验、转换和发布治理。让 Token 从设计稿进入代码不是复制颜色值而是建立跨端一致的设计语言。源文件清晰、Schema 严格、变更可回归Token 才能真正成为设计和工程的共同资产。