设计令牌与主题系统：把换肤做成配置而不是改代码

主题系统最容易做成一次性工程：上线时能切深色，之后就没人敢动。这次我按"换肤即配置"的目标重做了一遍，思路分享出来。 核心是三层结构。第一层是原始值，比如具体的色值、像素数、字体名，这一层是唯一写死数字的地方。第二层是语义令牌，比如 surface、text-primary、border-subtle，它们引用第一层的原始值。第三层是组件，组件只引用语义令牌。 这样做的好处是换主题只改第二层到第一层的映射关系，组件代码一行不动。深色模式本质上是另一套映射表，而不是另一套组件。 工程实现上做两件事： 一，运行时注入。把令牌编译成 CSS 变量或者样式对象，切换主题时替换这一层。不要在组件里用条件判断来决定颜色，那是最难维护的做法。 二，构建期校验。写一个脚本扫描组件代码，禁止出现裸色值。这个校验放进 CI，一旦有人写了硬编码颜色就拦下来。这条规则看似严苛，实际执行下来是省事的。 关于用 agent 做这件事，有个很顺手的用法：让 Claude Code 写那个校验脚本和令牌的转换工具，这类"规则明确、需要精确执行"的活它很擅长；让 MiMo Desktop 做视觉验收，把两套主题在同一个预览页面里并排铺开，一次看完整。这样能有效避免"改了一个主题，另一个主题某个角落花掉"的问题。 最后一个经验：主题数量超过三套之后，令牌的命名会开始打架。建议提前定好命名规范，并且定期清理没人用的令牌。令牌表本身也需要维护，它不是一次性资产。