品牌色彩系统如何落地为代码 Token

设计稿上的色板，和代码里的颜色，常常是两套割裂的世界。设计师说「朱红再深一点」，工程师就要在一堆 #b8292e 里翻找。色彩 Token 就是架在两者之间的桥。

给颜色起「语义名」

不要用 #b8292e 这种魔法值，也不要用 red-500 这种只描述色相的名字。语义名描述的是「用途」，而不是「颜色本身」：

--color-bg: #0e0e10;
--color-fg: #f5f0e8;
--color-brand: #b8292e;
--color-brand-bright: #d0363c;

当有一天品牌把朱红换成另一种红，改的是 Token 的值，而不是散落各处的十六进制。

建立色阶

单一颜色不够，交互需要 hover、disabled、弱化等状态。我用「主色 + 提亮 + 弱化」三件套覆盖绝大多数场景：

--color-brand: #b8292e;          /* 主色 */
--color-brand-bright: #d0363c;   /* hover 提亮 */
--color-brand-dim: rgba(184, 41, 46, 0.16); /* 弱化底色 */

透明度处理的弱化色尤其有用：它能自动适配任何底层，而不需要为每种背景单独配一个实色。

文字的分层

文字颜色其实是「对比度」的问题。我把它分成三档：

与框架结合

在 Tailwind v4 里，这些 Token 可以直接写进 @theme，自动生成对应的工具类，也能以 CSS 变量形式直接引用：

@theme {
  --color-brand: #b8292e;
  --color-fg: #f5f0e8;
}

于是 text-brand、bg-brand、border-brand 全都可用，设计师和工程师终于说同一种语言。

结语

色彩 Token 的价值不在「定义」，而在「共识」。它让一次调色，从「全局搜索替换」变成「改一个值」。这，才是设计系统真正的意义。