什么是 Token 漂移？

Token 漂移是指设计系统里记录的决定，与产品实际使用的取值之间逐渐拉开的差距。当某个界面来源不再引用共享源头，转而积累自己的取值时就会发生，比如一个 Figma 文件、一份样式表，或是 AI 生成的代码。

它是怎么开始的

漂移从不会预告。它以一个个单看都合情合理的小决定出现。

设计师给一张信息密集的表格需要一根稍浅的边框，就在文件里挑了一个，而没有去提一个 Token。开发在夜里十一点发出 margin-top: 18px，因为刻度里有 16 和 20，两个都不对味。有人从另一个项目复制了一个组件，连同它写死的阴影一起。

这里面没有一件值得卡住一个 pull request。可这样过上半年，代码库里的"主色蓝"就有了四个值。

这件事最近变快了，值得把原因说准。

一个被要求做设置页的 AI 助手，默认没有任何途径接触你的设计系统。于是它从别处见过的东西里造出看着合理的值：主色用 #3B82F6，间距用 16px，阴影跟你的很像但并不一致。

结果在代码评审里看着是对的，用的都是合理的值。只不过是跟你*不一样*的合理的值，而且它是以你团队产出代码的速度这么干的，比一个人手写 CSS 快得多。

数出来的结果通常比团队预想的糟，而早点知道这件事是有价值的。

让每一个要用它的界面都能够到这套系统。 漂移基本上是分发的失败。如果一个人或一个模型必须中断手上的事去找那个正确的值，总会有不去找的时候。

把 Token 直接交给智能体。 一个提供当前值的 Model Context Protocol 服务器，能让模型读到你的主色，而不是去猜。

拿生成的代码跟系统核对。 把有 Token 对应的写死值检出来，漂移就成了代码评审里看得见的东西，而不是一年后才发现的东西。

让一个方向说了算。 当 Figma 和代码对不上时，必须有人能说清哪个为准。设立一个评审环节，让设计改动变成一份由人批准后才进入仓库的 diff，这是通常的答案。

Flash DSM 通过 MCP 把当前的 Token 提供给 AI 智能体，提供 check_violations 工具返回写死的值以及应当替换它的 Token，并把 Figma 的发布变成可评审的 diff，以 pull request 的形式打开。