设计 Token 审计颜色统一不等于语义统一一、Token 不是颜色表很多团队把设计 Token 理解成颜色变量blue-500、gray-100、radius-8。这能减少硬编码但还不等于设计系统成熟。真正可维护的 Token 要表达语义主按钮背景、危险操作文本、弱提示边框、焦点轮廓。颜色统一只是第一层语义统一才决定界面能不能随业务演进。二、审计 Token 使用方式flowchart TD A[界面样式] -- B[原始值] A -- C[基础 Token] A -- D[语义 Token] D -- E[组件 Token]审计时要找三类问题直接写颜色值、只用基础 Token 但没有语义、同一语义在不同组件里使用不同 Token。第三类最隐蔽视觉上可能差不多但主题切换时会散掉。token_audit: forbid_raw_value: true prefer_semantic_token: true detect_duplicate_meaning: true track_component_override: true审计报告要指向具体文件和组件否则修复成本会很高。三、语义命名要稳定语义 Token 不应该描述颜色本身而要描述用途。color-danger-text比red-600更适合业务代码因为未来危险色可能从红色变成橙色调用方不需要改。:root { --color-action-primary-bg: #2563eb; --color-action-primary-text: #ffffff; --color-feedback-danger-text: #dc2626; }命名稳定后主题切换、暗色模式、品牌换肤都会更顺。四、审计要覆盖状态和层级Token 审计不能只扫默认状态。hover、active、disabled、focus、selected、error 都可能出现临时色值。尤其是焦点轮廓和错误提示常被业务页面自己补样式。state_token_check: hover: required focus_visible: required disabled: required error: required selected: required还要检查视觉层级。标题、正文、弱提示、占位符、辅助说明如果都使用相近灰度界面会失去信息秩序。Token 审计应该输出对比度和层级关系而不是只看变量是否存在。最后审计要接入 CI。新增原始颜色值、新增未登记 Token、语义 Token 被错误复用都应触发提醒。Token 体系一旦靠人工记忆维护很快会长出新的旁路。Token 审计还要关注跨端映射。Web、iOS、Android、Flutter 可能使用不同单位、命名和主题机制。如果只审计 Web 代码移动端仍可能出现另一套颜色和圆角。统一源数据再生成各端产物会比人工同步稳定。token_pipeline: source: tokens.json targets: - css_variables - flutter_theme - ios_assets - android_resources设计侧也需要审计。组件库代码已经语义化但设计稿里仍然直接使用局部色值工程就会被迫迁就。可以定期扫描设计文件找出未绑定 Token 的颜色、字号和间距。最后Token 变更要有影响面报告。比如修改color-feedback-danger-text应列出受影响组件、页面截图和对比度变化。这样评审看到的不只是变量改动而是界面后果。五、总结设计 Token 审计要检查原始值、语义命名、状态覆盖、层级关系和 CI 约束。颜色统一不等于语义统一。Token 的目标不是变量更多而是界面决策更可控。
