北京
我写了十年设计令牌，给人类工程师用的。到了2026年，这个系统的头号消费者变了物种——大部分设计团队还没意识到这件事。
设计令牌过去是一份合同：这是我们说的蓝色，这是间距节奏——它以数据形式存在，你的代码可以直接消费，不用设计师在场。我在戴尔重建设计系统的令牌架构时，完全围绕这个思路来推进。当时系统停滞不前，基础很扎实，但运作得像一个黑箱。领导层认为是治理出了问题，真正卡住的地方不在这里——令牌是设计师命名的、为设计师服务的，没有导出管线。真正要消费它们的前端工程师，在命名环节被彻底忽略了。
我们翻转了逻辑：简化核心加语义层级，明暗双模，以JSON和CSS的形式输出到dell.com的每一个页面。我后来反复说的一句话是：命名是一项产品决策，要为真正的消费者优化，而不是为作者自己。我只是没想到，真正的消费者又变了一次，而且变得这么快。
到2026年，新生成的UI代码中很大一部分是机器写的。接受调查的设计师里，有一半说他们已经在生产环境中发布过AI生成的代码。Claude Design直接从代码仓库里读取团队的设计系统并应用。Figma推出了原生AI设计代理。每个产品团队的流程里都嵌着某种编码代理，以设计评审根本跟不上速度往外吐组件。生成式UI有一个特定的失败模式：有速度，没记忆。每一次会话、每一个模型、每一段提示词，都会发明自己的内边距、自己的灰色、自己的圆角半径。单独看都合理，合在一起就散了。过去一个组织积累这种漂移需要几个季度，一个代理集群一个下午就能完成。
这件事应该让你重新规划路线图：当代理生成UI时，它读的不是你的Figma组件库。它读的是你的代码仓库。你的令牌文件。你的组件签名。你的文档——前提是文档格式它能解析。Figma对自己Dev Mode MCP服务器的定位说得很清楚，输出质量跟你系统的连接程度挂钩。文档里记录的失败模式正是：当系统不具备机器可读性时，硬编码数值就会悄悄混进来。
你的设计系统面向机器的那个面，现在就是它的主界面。令牌文件不再是导出物。它变成了提示词。
如果令牌就是提示词，一个新问题就出现了：提示词只是建议。模型跟忙起来的人类一样，先照着来，直到它不照了。我参与过的每一个设计系统，治理靠的都是约定：指南、评审仪式、某个Slack频道里偶尔有人发一条“请别硬编码颜色”。它会被侵蚀。永远如此。新人入职不读维基，截止日期碾压指南，而现在，代理还会因为统计上更可能出现，凭空编出一个看似合理的十六进制色值。
唯一不会随着时间消解的执行节点，是编译器。不是约定，不是文档，不是评审流程——是那些不讨价还价的规则，在构建阶段直接运行的东西。我观察到这个领域正在转向三种强制模式：第一种，把令牌测试放进CI流程，检测硬编码值和未声明的令牌，跑不过就阻断构建。第二种，用类型系统来编码约束——不是文档里的注释，不是在Figma里手动维护图层面板，而是组件签名本身携带类型信息，让不匹配的状态在编译时就暴露出来。第三种，将设计系统自身作为API来暴露。一个团队通过MCP端点输出品牌色和间距，代理在运行时实时抓取，这意味着设计师调整一个令牌后，下一个生成的组件就会自动接收新值，不需要通过评审环节。
这些做法有一个共同点：它们把治理从沟通层面降到了基础设施层面。沟通会疲劳，基础设施不会。
这背后还有一个更深的转变。设计令牌诞生在这样一个世界里：人类在不同工具之间做状态同步。一个颜色在Figma里改一次，在代码里再改一次。而AI代理从根本上改变了这个假设。设计与代码之间的那个翻译层正在消失。当代码由机器产出时，设计本身必须变成机器能直接摄取的结构化语言。令牌文件的读者已经从人变成了另一个程序。这个消费者不需要你的理由，不需要你的品牌故事，不需要你解释为什么蓝色代表信任。它只需要数据，结构干净，语义明确，能解析就行。
我之前给团队的建议是：把令牌文件当成API文档来写。现在看来，这个建议需要升级。你应该把它当成提示词工程来处理——每一个命名、每一层嵌套、每一个默认值，都是在给一个非人类的消费者下达指令，这个消费者会严格照做，也会在语义模糊时毫不客气地走偏。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
