Muse 设计令牌

问题从哪来

组件里散落的 #336699、margin: 12px 和「这个按钮再绿一点」的改法，在主题切换、深色模式或多品牌场景下会迅速失控：改一处要搜全仓，Figma 与代码也容易各说各话。Muse 面向的是把视觉语言写成可演进的令牌系统，而不是在组件层堆一次性样式。

技能如何工作

Muse 遵循基础 → 语义 → 组件三层模型，优先在代码里引用语义令牌（如 color.surface.primary），并尽量以 W3C DTCG v2025.10（$value / $type / $description）作为交换格式；主题与多品牌可通过解析器文档合并多个 .tokens.json，减少文件重复。

典型工作流为 SCAN → POLISH → REFINE → VERIFY → PRESENT：先审计变更与硬编码、脱离 8px 网格的间距和深色模式缺口，再落地令牌、清理命名与生命周期漂移，最后做对比度与覆盖率验证并记录决策。技能会产出面向下游的交接物，例如给 Artisan 的令牌感知组件规范、给 Flow 的动画/时序令牌、给 Vitrine 的文档更新，以及给 Polyglot 的 RTL 感知间距令牌。

与上游协作时，Frame 负责 Figma 提取，Palette 带来可用性侧的颜色调整诉求，Pixel 可把「设计到代码差距」里的 CSS 变量差异系统化成令牌回归任务。

边界与注意点

• 先问再做：破坏性改值、整页布局重构、完整设计系统迁移、直接覆盖组件样式而不修令牌、弃用 STABLE 令牌——这些需要先对齐。
• 硬性禁忌：组件内裸写 HEX/RGB（除非正在定义令牌）、按色值命名（如 green-500）、为好看牺牲 WCAG 2.2 AA、无迁移路径地删改令牌、把 Inter/Roboto/Arial 当主展示字体。
• 别抢别人的活：完整组件实现找 Artisan，关键帧与编排找 Flow，创意方向找 Vision，Figma 画布 API 找 Frame；端到端设计→实现流水线且要持久化设计系统时，更适合 Atelier。

健康目标上，技能文档强调令牌覆盖率 95%+、深色模式 100%、组件令牌使用率 100%，并建议用 Style Dictionary v5、Tokens Studio 等流水线，避免在 Figma 与代码之间手抄令牌值。