Design Token 的通用语言
设计稿定好了品牌色，开发做出来跟设计稿不一样。换了一个设计工具，之前定义的颜色全要重来一遍。让 AI 生成网页，它总是用那个"AI 味靛蓝"而不是你的品牌色——哪怕你告诉它了。
为什么你的品牌色，换个工具就要重来一遍？ 三个问题的根因一样：每套工具、每个平台、每个 AI 各说各的语言，没有翻译层。 你在 Figma 里定的"按钮色 #38608F"，到了网页变成变量名，到了 App 变另一套名字——每一层都是人肉翻译。
Design Token 的通用语言就是那个翻译层，正式名字叫 Design Tokens Format，由 DTCG（W3C 下的 Design Tokens Community Group）制定。它做的事很简单：不管你在哪个工具里定义的颜色、字体、间距，导出成一个标准文件，其他工具和平台直接读。
它是什么？
一种文件格式。你写："品牌主色是 #38608F"，它规定这句话在文件里怎么写——不是写成自然语言，是写成机器也能读的格式。这样：
- 设计工具（Figma、Sketch）能导出成它
- 网页代码能读取它
- App 代码也能读取它
- AI Agent 也能读取它
一套定义，不用重复口述。
为什么需要它？
市面上的设计系统各有各的叫法。同一个"品牌主色"：
| 在哪个系统 | 叫法 | 支持 DTCG 导出吗 |
|---|---|---|
| Google Material Design | primary |
可导出 |
| Microsoft Fluent | AccentFillColorDefault |
已支持 |
| 华为 HarmonyOS | brand |
手动映射 |
| Apple 设计规范 | systemBlue 或自定义 |
可映射 |
名字都不一样，但指的都是"你的品牌色"。没有 DTCG 之前，从这个系统换到那个系统——不是你导出我导入，是人肉对照表。DTCG 让每个系统都认同一套写法，不用翻译。
核心原理
- 单一翻译层，不规定内容 — DTCG 只规定颜色/字体/间距在文件里怎么写，不规定写什么值。各体系保留自己的叫法，只是都认同一套文件格式。
- 导出一次，处处可读 — 设计稿在 Figma 定义，导出成 DTCG 文件，Web、App、AI 直接读。换工具不用重录。
- 基础层与语义层分离 — 令牌分"品牌主色 #38608F"（基础层）和"按钮色 = 品牌主色"（语义层）。换肤只改基础层，语义层引用不动。
- 机器可读，人也可读 — 文件既给程序解析，也给 AI 生成页面时当约束。告诉 AI"按这个文件写"，它就知道你的品牌色。
它省的不是"翻译"，是"翻译的数量"
翻译躲不掉——A 系统的话总要变成 B 系统能懂的话。真正的问题是：有多少个系统要互相翻译？
- 两个系统：一条对接线，写个转接就行，标准格式纯属多余。
- 十个系统：每两个系统之间都要一条线，十个系统要四十五条对接线——系统越多，线涨得越疯。如果大家都认同一个中间格式，十个系统只要十条线：每个对接一次枢纽，就全通了。
所以 DTCG 的价值不在"让翻译消失"，在"把对接线的疯涨，压成一条条加"。值不值得用标准格式，只取决于一件事：有几个消费者要互相读。 两个消费者，私有约定最划算；消费者一多，标准格式才值回票价。
它不是 W3C 官方标准
名字里有 W3C，但 DTCG 不是官方标准。W3C 有两种产出物，地位差很多：
| 类型 | 相当于 | 例子 |
|---|---|---|
| 工作组报告（Recommendation） | 国标——正式标准，被广泛引用 | HTML、CSS |
| 社区组报告（Community Group Report） | 白皮书——业内共识，无强制力 | DTCG |
DTCG 2025 年 10 月发布的是 Final Community Group Report，属于后者：是"大家谈妥了"，不是"官方背书了"。这不影响它的实用价值——Google、Microsoft、Apple、Adobe、Figma、Shopify 都参与制定并实际采用。
另一个现实：基础 token（颜色、间距、圆角）已经稳定；复合 token（字体、阴影、渐变）工具支持还滞后。用复合 token，等于"赌在工具前面"——标准定了，工具还没跟上。
AI 要理由，不要只要值
翻译层解决了"机器能不能互相读"，没解决"AI 和人懂不懂为什么"。
token 给的是值，不给理由。AI 拿到 #38608F，不知道"为什么是它、什么时候不能用、跟品牌什么关系"——只能猜，猜错就是 AI 味靛蓝。
Google Labs 2026 年 4 月开源 DESIGN.md 专治这个。做法：一个 Markdown 文件塞两层——结构化数据写 token 值（机器读），散文写理由（AI 和人读）。它的核心理念原文是 "Prose, not Tokens"：散文是重点，token 不是。
| 解决什么 | 类比 | |
|---|---|---|
| DTCG | 机器之间能不能互相读 | 字典：词对应意思 |
| DESIGN.md | AI 和人懂不懂为什么这么用 | 说明书：为什么这么用、什么时候别用 |
两个不冲突，是叠加。DESIGN.md 的 token 部分就参考 DTCG 语义，还能导出成 DTCG。
怎么选？
不用"迁" DTCG，用 DESIGN.md 当真相源，按消费者各取所需。
迁 DTCG = 改存储格式、重写定义、改所有读取方——代价大，通常不值。 导出 DTCG = 存储不动，加转换层按需输出——代价小，互操作时再做。
DESIGN.md 值 + 理由一个文件装下：
| 消费者 | 怎么用 |
|---|---|
| 你自己 + AI agent | 直接读 DESIGN.md，值、理由都在里面 |
| 工具（Figma / Style Dictionary / 生成器） | 从 DESIGN.md 导出 DTCG |
它的 token 部分精简，但没丢关键信息——分组名（colors、spacing）暗含类型，组件里的内联引用保住"语义层指向基础层"，所以导出的是真 DTCG，不是空壳。
判断标准一句话：协调成本高不高。 一个 builder 一套意见时，协调成本为零，任何格式迁移都是纯损耗；消费者一多，加导出层比迁格式便宜得多。
延伸阅读
- m3-material-io — 用 DTCG 可导出的令牌体系
- 去AI味网页设计指南 — 用令牌文件管住 AI 的默认色
原文存档
- Design Token 的通用语言 — 原文存档