PAYATHON 2026

团队如何在实际项目中生成、转换并接入 Design Tokens？

数据阿明

团队可以用 Design Tokens 作为设计与代码共享的样式数据。以 Web 项目为例，设计师和开发人员先约定命名和数据来源，再把设计值整理成可维护的数据文件，通过构建生成项目所需的格式，供组件使用。具体流程可以按团队规模调整。

先确定谁维护数据，以及修改从哪里开始

接入之前，设计师和开发人员需要共同确定 Token 表达什么、名称如何组织，以及哪一份数据是最终依据。

Token 可以分为以下层次：

  • 基础 Token：保存色板、间距、字号等原始值，例如 color.blue.600。
  • 语义 Token：表达用途，例如引用基础色值的 color.text.link。
  • 组件 Token：表达特定组件的需求，例如按钮内边距。是否需要这一层取决于组件的复杂度。

业务组件通常优先使用语义 Token。链接颜色变化时，调整映射关系即可，不必逐个修改使用该颜色的组件。

团队还需要明确数据来源。数据可以由设计端维护并导出，也可以在 Git 仓库中维护，再同步到设计工具。无论采用哪种方式，都应约定修改入口和冲突处理方式，避免设计文件与代码各自更新。

设计师如何生成 Design Tokens？

设计师先在设计工具中整理颜色、文字、间距等变量或样式，为它们设置稳定的名称和用途，再通过工具的导出功能、插件或团队脚本，将数据导出为结构化文件。

设计稿中的属性不必全部转成 Token。可以先覆盖多个页面或组件反复使用、需要统一维护的设计决策。

导出时要保留数值，以及适用时存在的类型、引用关系和主题信息。如果导出结果只有一组颜色值，开发人员就难以判断哪些颜色用于正文、链接或错误提示。

工具能否完整导出这些信息，需要结合实际能力确认。缺失的部分应在数据整理环节补齐，并经过评审。

格式转换具体做什么？

转换环节将共享数据变成各平台可以直接使用的产物。例如，Web 项目可以生成 CSS Custom Properties，JavaScript 项目可以生成模块导出。

下面是一个自定义中间数据格式的示例，用来说明引用关系，不代表某个标准或工具的固定格式：

{
  "color.blue.600": {
    "type": "color",
    "value": "#2563eb"
  },
  "color.text.link": {
    "type": "color",
    "value": "{color.blue.600}"
  },
  "space.control.inline": {
    "type": "dimension",
    "value": "12px"
  }
}

{color.blue.600} 是示例约定的引用写法，需要由转换程序解析，不能直接作为 CSS 值使用。构建后可以得到：

:root {
  --color-blue-600: #2563eb;
  --color-text-link: var(--color-blue-600);
  --space-control-inline: 12px;
}

转换程序也可以将引用展开为最终值。具体采用哪种方式，需要结合运行时主题切换和产物的使用方式决定。

转换过程至少应检查名称重复、引用不存在、循环引用，以及数值类型和单位是否符合约定。名称转换也可能引入冲突，例如两个不同名称被转换成同一个 CSS 变量名，需要在生成时发现。

项目如何接入生成结果？

在上述 Web 示例中，可以将生成的文件放入共享样式包，在应用入口加载，再由组件使用：

@import "./tokens.css";

.link-button {
  color: var(--color-text-link);
  padding-inline: var(--space-control-inline);
}

项目较小时，数据文件、转换脚本和生成结果可以放在同一个仓库。多个应用共用时，可以将生成结果作为独立包发布，让各应用显式升级版本。

如果需要多主题，可以在不同选择器下生成语义变量覆盖。除了处理代码中的变量，还要在设计端明确各主题的对应值。

接入已有项目时，可以先迁移一组基础组件，再逐步替换页面中的硬编码样式。替换前要检查用途：两个位置当前恰好使用同一个颜色，并不意味着它们应该共用同一个语义 Token。

工具和职责如何划分？

具体工具可以更换，但各环节需要有明确的负责人：

环节工具类型主要职责
设计维护设计工具的变量、样式及导出能力设计师维护取值、用途和主题关系
数据整理插件、导出脚本、结构化数据文件设计师与开发共同确认命名和映射
格式转换自定义脚本或 Token 构建工具开发维护引用解析、类型检查和平台输出
组件接入样式包、组件库、应用工程开发将 Token 应用于组件并处理迁移
评审发布Git、CI、包管理工具共同审查变更，确认发布范围和升级方式

小团队可以由同一个人负责多个环节。每一步都应有维护者，这样出现同步问题时，团队才能找到修改入口。

一次修改怎样完成闭环？

例如，调整链接颜色时可以按以下步骤处理：

  1. 设计师确认新的取值，以及它在不同主题和状态下的表现。
  2. 修改约定的数据源，导出或同步到 Token 文件。
  3. 提交变更，展示原始数据和生成产物的差异。
  4. CI 执行格式、引用和构建检查。
  5. 在组件示例页检查实际效果；涉及文字颜色时，还应检查与背景的对比度。
  6. 发布样式包或合并应用变更，由使用方验证后升级。

生成文件应通过数据源重新构建，手工修改容易在下次生成时丢失。删除或重命名 Token 时，也需要检查使用方，必要时保留旧名称一段时间并安排迁移。

评估流程是否有效，可以看设计修改能否稳定传递到组件，以及团队能否查清每次变更影响了哪些使用方。

备注：内容仅供参考。