规划 Token 别名时，先把原始值、语义用途和组件引用分开：raw 记录色值或间距，semantic 表达“主要操作色”，component 再决定按钮如何使用。将关系放进设计系统方法的评审流程，团队能在主题切换前发现缺值和循环引用。
三层关系各自回答一个问题
raw 层回答“这个值是多少”，例如蓝色 600 或 16px；semantic 层回答“它在界面里代表什么”，例如主要操作色；component 层回答“按钮的背景、边框和文字分别引用谁”。三层关系清楚，替换品牌时不会把组件写成一堆具体色值。
别名不是复制值。semantic token 应引用 raw token，component token 再引用 semantic token；如果组件直接写 raw 值，主题层就无法统一替换。命名文档可以记录关系，但不能用命名表掩盖依赖图。
主题切换先查覆盖范围
默认、深色和高对比主题不一定拥有同样数量的 token。先列出每个 semantic token 在各主题是否有映射，再决定缺失时继承、回退还是阻止发布。回退必须可解释，不能静默变成难以辨认的颜色。
以按钮为例，默认主题的主要操作色映射到品牌蓝，深色主题映射到更亮的蓝；组件仍引用“主要操作色”。设计稿中同时放三种主题，比较文字对比、禁用态和焦点态，才能看见映射的副作用。
把循环和越级引用挡在评审前
常见错误是 A 引用 B、B 又引用 A，或者 component token 越过 semantic 直接引用某个品牌色。为每个 token 标注层级和引用方向，检查是否跨层、循环或出现未定义值。
变更时记录影响组件和主题，不只改名字。一次 token 调整可能影响按钮、表单、图表和客户案例页面；先在代表性组件上试点，再决定是否扩大到整套系统。
在 Pixso 画布中交付关系
用变量/样式面板和三组主题画板展示 raw、semantic、component 的映射，旁边写出缺值、回退和对比检查。画布是讨论和验收证据，不要把尚未核验的导出或代码同步能力写成已具备。
发布前让设计、研发和品牌负责人各完成一次核对：设计看视觉结果，研发看引用方向，品牌看主题覆盖。三方都能从同一关系图定位问题，Token 别名才真正减少后续修改。
命名和分层并不能替代治理。为每次变更登记影响范围、负责角色和回滚方式；如果一个 semantic token 被多个业务线共用，先建立试点组件再扩大覆盖，避免一次改色让所有页面同时失去对比度。
验收时不要只看变量面板。把 token 关系映射到按钮、输入框和图表三个不同密度的组件，检查默认、深色和高对比主题的文字、焦点和禁用态。出现未覆盖值时，设计稿应显示它如何被发现和处理。
Token 分层可结合Design Tokens 社区格式草案和Material Design tokens 概览讨论；示例不代表 Pixso 已实现全部导出能力。
