AI 设计 Token 校验：颜色对了，语义也不能乱

AI 设计 Token 校验：颜色对了，语义也不能乱

一、设计 Token 不是一堆变量名

AI 可以根据设计稿生成颜色、字号、间距等 token。这个功能看起来很香，尤其在设计系统早期能省很多录入工作。但如果缺少校验，模型会生成一堆看起来合理、语义混乱的变量。比如primaryBlue、brandMain、buttonPrimary同时出现，后面维护会很难受。

设计 Token 的重点是语义稳定。颜色值可以换，语义不能乱。一个 token 应该表达用途，而不是表达眼前看到的颜色。

二、Token 生成后要做命名、层级和引用校验

校验链路可以分为命名规范、层级归属、重复值检测和使用场景检查。

flowchart TD A[AI 生成 Token] --> B[命名校验] B --> C[层级校验] C --> D[重复和近似值检测] D --> E[语义引用检查] E --> F[进入设计系统]

重复值不是一定错误，但需要解释。两个 token 值相同，如果语义不同，可以存在；如果语义也相同，就该合并。

三、用规则兜住命名边界

下面示例检查 token 命名是否符合基本结构。

const TOKEN_NAME = /^(color|font|space|radius)\\.[a-z0-9-]+\\.[a-z0-9-]+$/; function validateTokenName(name: string) { if (!TOKEN_NAME.test(name)) { throw new Error(`invalid token name: ${name}`); } }

规则不需要一开始很复杂，但必须存在。没有命名边界，AI 会把设计系统写成变量菜市场。

四、语义校验要结合组件使用

Token 不能只在表里看。要看它被哪些组件引用。比如按钮主色、链接色、危险状态色，如果都引用同一个 token，后续改品牌色时可能把危险状态一起改坏。

还要检查可访问性。AI 生成颜色后，应自动计算对比度。低对比文本不能进入设计系统。漂亮不等于可用。

最后，Token 变更要有影响面。改一个 token，会影响哪些组件、哪些页面、哪些截图。没有影响面，设计系统升级就是开盲盒。

Token 还要区分全局语义和组件语义。color.text.primary是全局语义，button.primary.background是组件语义。不要让组件直接引用原始色值，也不要让所有组件都只靠全局 token 硬凑。层级不清，后面换主题会很难看。

AI 生成 Token 后，还要做近似值合并。#1677ff和#1678ff可能只是识别误差，如果都进系统，设计资产会慢慢长毛。合并前要看语义，合并后要保留映射记录。

最后，Token 发布要有版本。组件库引用哪个 token 版本，应用构建时用哪个版本，都要能追踪。设计系统不是一份 JSON 文件，它是依赖。

主题切换也要纳入校验。亮色、暗色和品牌主题下，同一个语义 token 应该都有对应值。AI 只根据一张设计稿生成 token，很可能漏掉其他主题。发布前要跑主题矩阵检查，缺失值不能靠运行时兜底。

还要生成变更报告。新增、删除、改值的 token 分别列出来，并标注影响组件。删除 token 尤其危险，业务代码如果还在引用，构建阶段就应该失败。

五、总结

AI 设计 Token 生成必须配套校验。命名、层级、重复值、组件引用和可访问性都要检查。Token 是语义资产，不是一张配色表。颜色对了只是第一步，语义稳定、引用清楚、影响面可见，才算能进入工程系统。