先给结论：评审一次设计 Token 变更，先回答“改了谁、何时生效、出问题怎样退回”三件事，再讨论颜色看起来是否更漂亮。下面以订单后台把 color.text.muted 从 #667085 改为 #475467 为例，说明如何在Pixso 设计系统流程中把影响矩阵、兼容窗口和回滚决策画在同一份文件里。
先区分基础值、语义值和组件覆盖
这次不是把画布上的每个灰色文字手工改一遍。先登记 Token 的层级、消费者和当前值：基础灰色调色板有 8 个值，语义 Token color.text.muted 被订单表、筛选器、空状态和帮助提示共 18 个组件使用，其中 4 个旧组件仍直接引用基础值。直接替换基础值会漏掉这 4 个组件，所以变更单要把“改 Token”与“补迁移”拆开。
| 检查项 | 本次记录 | 决策 |
|---|---|---|
| 变更对象 | color.text.muted：#667085 → #475467 | 保留旧基础值，先改语义别名 |
| 影响消费者 | 18 个组件、3 个产品页面 | 逐组件抽样，不能只看总数 |
| 直接引用 | 4 个旧组件绕过语义层 | 迁移任务单独排期 |
| 风险 | 深色主题和禁用态对比度可能变化 | 两种主题各测一组长文案 |
命名和层级可参照Token 命名方法，但不要把示例名称当成团队现成字段；评审记录中必须写出真实引用关系。
用兼容窗口控制一次性切换的风险
把发布拆成三个时间点：T0 在设计稿中更新语义值并标出 18 个消费者，T1 让研发在测试环境接入新值，T2 才允许生产页面移除旧别名。兼容窗口内，旧组件仍能读取旧别名，但新组件不得再直接引用基础值。每个时间点都记录负责人、版本和验收证据，避免出现“设计稿已经改了，代码还不知道”的半发布状态。
审查时至少走两条内容路径：订单表的长标题和空状态的两行说明。若文字变长导致截断，先调整容器或字号层级，不为了通过截图把 Token 改回去。深色主题应单独核对禁用文字、悬停文字和焦点环，不能用浅色主题的截图代替。
把批准、灰度和回滚写成可执行动作
评审卡片应包含变更前后值、受影响组件清单、未迁移引用、对比度或视觉检查结果、兼容截止时间和批准人。灰度时先选订单表与筛选器两个页面，观察 24 小时内是否出现文字截断、主题错配或旧别名读取失败。发现任一项，就冻结后续发布，恢复 color.text.muted 的旧别名；已经上线的页面要记录回滚版本和受影响页面，不把“撤销”写成没有对象的按钮。
如果只影响一个组件，可以回滚组件别名；如果基础值已经被多个语义值复用，则先恢复语义层，再处理直接引用。对于无法回滚的历史截图或导出文件，保留新旧值的映射说明，避免审计时把视觉差异误判为数据错误。
在 Pixso 画布中验收四个证据点
画四个相连画板：变更单、影响矩阵、灰度检查、回滚记录。验收人按组件编号抽查 18 个消费者中的 6 个，确认每个都能追溯到语义 Token；再切换浅色和深色主题，检查长标题、禁用态和焦点环。最后把一条“旧别名仍被 4 个组件直接引用”的失败项保留下来，验证修正后可以重新评审。这样评审结果是可操作的决定，而不是一张只显示新颜色的截图。
