设计系统 Token 设置页

大理论

Token 设置页处在设计系统治理的高风险位置：一次颜色、间距或字体修改可能影响上百个组件、品牌主题、暗色模式、移动端布局和无障碍对比。健康的 token UI 要把 primitive、alias、semantic、component token、mode 和 platform output 分开显示，让用户先理解依赖关系，再允许修改和发布。

小知识点

1. Token 值需要角色名和来源：例如 color.brand.primary、color.action.background.default 和 button.primary.background 是三种不同层级，不应混在一个表格里。
2. 变量模式要可见：light/dark、brand、density、locale、platform 或 responsive mode 都会让同一个 token 有不同值。
3. 影响范围必须在保存前展示：affected components、states、pages、themes、generated CSS/JSON/iOS/Android 输出和截图预览。
4. 版本治理包括 draft、review、approved、released、deprecated 和 rollback；每次发布需要 changelog、owner 和 reason。
5. 对比、非文本对比、focus ring、状态色和图表色需要自动检查，不要只保存合法 hex。
6. Token 编辑器要暴露 alias graph 和循环/断链错误，避免 component token 指向不存在或过度具体的值。

设计判断

如果设计师、工程师和 reviewer 能在保存前回答“这个 token 表达什么语义、哪些模式下值不同、哪些组件会变、是否破坏对比、如何回滚”，这个设置页才可用于生产治理。

实现建议

建立 token change model：tokenId、tokenType、tier(primitive/alias/semantic/component)、mode、currentValue、proposedValue、references、affectedComponents、contrastChecks、platformOutputs、owner、status、version、changeReason、rollbackTarget。UI 上左侧按 collection/tier/mode 过滤，中间编辑值和语义说明，右侧显示组件预览、diff、对比结果和发布清单。提交前生成 review packet，并禁止直接发布高风险 token。

反例/风险

只有一个颜色 picker；暗色模式值藏在另一个文件里；修改 primary 后不知道哪些按钮、链接和图表会变；保存没有版本号；semantic token 直接使用品牌色导致状态不可扩展；删除 token 后组件静默 fallback 到黑色。

案例分析

Style Dictionary 把 design tokens 描述为平台无关的设计决策输入，并可导出到 iOS、Android、CSS、JS、HTML 等目标；DTCG 的格式规范目标是让工具之间交换 token 文件；Figma variables 文档说明 variables 和 modes 可把同一设计系统放入 light/dark 等上下文。可学习点是：token 设置页必须同时服务设计语义、跨模式编辑和跨平台输出，而不是只管理 CSS 变量文本。

来源链接

Style Dictionary Design Tokens: https://styledictionary.com/info/tokens/ Style Dictionary DTCG: https://styledictionary.com/info/dtcg/ DTCG Format Module: https://www.designtokens.org/TR/2025.10/format/ Figma Variables Guide: https://help.figma.com/hc/en-us/articles/15339657135383-Guide-to-variables-in-Figma Figma Variable Modes: https://help.figma.com/hc/en-us/articles/15343816063383-Modes-for-variables