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 是语义资产不是一张配色表。颜色对了只是第一步语义稳定、引用清楚、影响面可见才算能进入工程系统。