一、从设计到开发的完整集成流程 #

1. 设计师产出原始Tokens #

我们团队用Figma做设计，设计师会在统一的设计系统文件里，把所有可复用的设计元素定义成Tokens：

• 命名严格按「类别-属性-层级」来，比如color-primary-500（主色调500色阶）、spacing-lg（大间距），避免乱起名导致后续混乱
• 按颜色、排版、间距、组件属性这几大类分组，方便后续批量管理
• 直接用Figma的Design Tokens插件导出JSON格式的原始Tokens文件，确保和设计稿100%对齐

2. 格式转换与标准化 #

我们用style-dictionary做跨端格式转换，提前写好配置文件（指定输入源、输出格式和路径），然后执行命令：

npx style-dictionary build

一次就能生成多端可用的文件：

• 前端：CSS全局变量、SCSS混合宏、JS对象
• iOS：Swift枚举文件
• Android：XML资源文件
  同时还会自动生成一份Markdown格式的Tokens文档，把每个Token的取值、用途、适用场景都写清楚，方便团队查阅。

3. 项目端集成 #

• 前端：把生成的CSS变量文件导入全局样式，业务组件里直接用var(--color-primary-500)；动态样式场景就引用JS对象里的取值
• 移动端：把对应平台的资源文件直接导入项目，开发时调用枚举或资源ID即可

二、团队日常工作流 #

1. 变更发起：设计师如果要调整Tokens（比如把主色调从蓝色改成深绿），先在Figma里更新，导出最新JSON后提交到Git仓库的Tokens专属分支
2. 评审环节：设计负责人和前端负责人一起过变更内容，确认不会影响现有业务组件的视觉一致性，没问题就合并到主分支
3. 自动同步：主分支有更新时，GitLab CI会自动触发style-dictionary构建，把生成的多端文件同步到内部私有包管理库——前端用私有npm包，移动端用私有Maven库
4. 业务适配：各端开发收到包更新通知后，按需调整组件，确保新Tokens在业务里生效

三、用到的工具栈 #

• 设计端：Figma + Design Tokens插件
• 转换工具：style-dictionary
• 版本管理：Git（单独的Tokens仓库，和业务代码分开）
• 包管理：内部私有npm包（前端Tokens）、Maven库（移动端Tokens）
• CI/CD：GitLab CI

四、团队职责划分 #

• 执行设计师：负责Tokens的日常定义、更新，严格遵循命名规范，确保设计稿和Tokens完全匹配
• 设计负责人：审核Tokens变更的合理性，把控整个设计系统的视觉一致性，避免随意变更破坏统一
• 前端开发：维护style-dictionary的配置文件，负责前端Tokens的集成、问题排查，以及和设计师对齐Tokens细节
• 移动端开发：负责对应平台Tokens资源的导入、适配，确保移动端组件能正确调用Tokens
• DevOps：维护CI/CD流程，确保Tokens变更后能自动同步到各端的包管理库，减少手动操作

内容的提问来源于stack exchange，提问作者argooo