文章目录 / 点击展开
设计令牌不是一张颜色表，而是设计决策在不同工具和代码中的共同语言。没有治理时，团队很容易出现相近颜色、重复间距、随意字号和状态语义不一致。AI 可以帮助盘点命名、发现重复和生成迁移建议，但令牌含义与发布规则需要由设计和工程共同确定。
先区分基础令牌与语义令牌
基础令牌描述原始值，例如某个色阶、间距或字号；语义令牌描述用途，例如正文文字、危险操作、主要按钮背景。页面和组件应优先引用语义令牌，而不是到处写具体颜色或像素值。
先定义哪些维度纳入治理：颜色、字体、间距、圆角、边框、阴影、层级、动效和断点。不要一开始把所有视觉细节都令牌化，优先处理高复用且容易漂移的部分。
第一步：盘点真实使用而非理想规范
从设计库、样式文件、组件和高流量页面中收集实际值与命名。记录令牌来源、使用位置、是否重复、是否仍被支持和对应负责人。AI 可以把代码和设计导出的清单聚类，但需要人工确认哪些差异是故意的。
根据以下设计变量和代码样式清单，列出可能重复、命名冲突、用途不明和未映射项。
只基于提供数据输出差异；不要自行假设哪个值应被删除。第二步：建立可读的命名规则
命名应表达层级和用途，例如 color.text.primary、space.layout.section、radius.control，而不是用页面名称或临时编号。区分全局、语义、组件和主题层级，避免一个令牌同时承担互相冲突的用途。
为每类令牌写定义、适用场景、禁止用法和示例。命名规则越稳定，AI 辅助生成和检查才越可靠。
第三步：映射设计、代码和组件
建立设计变量、代码变量、组件属性和文档的映射表。若不同端需要不同值，使用同一语义令牌在各平台映射，不要让页面作者直接写平台特例。映射中记录版本和变更原因。
组件文档的结构可使用 AI 辅助设计系统文档 承载，确保设计和开发查到的是同一份约定。
第四步：设计令牌的变更流程
更改语义令牌可能影响大量页面，因此需要提出原因、影响范围、视觉对比、代码变更、迁移策略、验收人和回滚方式。不要直接把某个基础色值替换到全局后再观察线上效果。
AI 可以根据引用关系生成影响清单，但不能保证搜索范围完整。高影响变更应在预发布环境走查关键页面与状态。
第五步：处理旧值和例外
历史页面中可能存在临时值、第三方组件和特殊品牌场景。为它们标记过渡令牌或例外原因，而不是悄悄绕过规范。例外需要负责人与到期时间，避免永久积累。
迁移时先替换低风险、重复多的引用，再处理组件和页面模式。每轮迁移保持可回滚，并用视觉回归或人工走查验证。
第六步：持续审计一致性
定期检查未使用令牌、直接写值、设计与代码不一致、无文档组件和高频例外。AI 可以将审计结果归类为命名、映射、使用或状态问题，最终修复优先级仍应结合页面影响和用户风险判断。
上线前的页面状态、响应式与可读性走查可参考 AI 设计交付工作流。
令牌治理检查清单
- 是否区分基础值与语义用途。
- 是否以真实设计和代码使用情况完成盘点。
- 命名是否表达层级、用途和可复用边界。
- 设计变量、代码变量和组件是否有映射关系。
- 高影响变更是否包含影响、迁移和回滚计划。
- 例外是否有原因、负责人和到期时间。
- 是否定期检查直接写值与设计代码漂移。
常见问题
所有样式都应该变成设计令牌吗
不需要。优先治理高复用、跨页面和具有语义的值，避免把一次性排版细节过度抽象。
AI 能自动合并重复颜色吗
它可以找出候选，但是否合并取决于用途、对比度、主题和品牌规则，需要设计与工程确认。
令牌更新后为什么还要验收页面
同一令牌在不同组件、背景和状态下可能产生不同效果。引用替换正确不代表视觉和可读性一定正确。