Figma 把设计系统的债务变成了所有人的问题

Figma 在 2026 年上半年密集发布了一系列功能，从 AI 画布代理、MCP 服务器接入第三方代理、Code Connect UI，到 Make 直接编辑生产代码库并发起 Pull Request，再到 Config 2026 主舞台上的 Check designs、Figma Motion、基于 WebGPU 的着色器以及组件插槽守卫（slot guardrails）。UX Collective 的一篇分析文章指出，这些功能看似分散在不同表面，实际上共享同一个输入：它们都在读取你的设计系统。

这意味着设计系统一旦糟糕，失败不再是维护者一个人的事，而是会在代码、原型、营销模板里被快速扩散。

设计系统债务从隐形变得可见

多年以来，设计系统的工作在路线图争夺战中一直默默落败。「我们下个季度再讨论」几乎等同于永远不会做。维护者反复在规划会上解释令牌需要重构、组件正在漂移、产品文件中一半按钮已经脱离源组件，最终被礼貌地搁置，功能优先上线，债务继续累积。

UX Collective 的作者认为，问题不在于汇报方式，而在于设计系统的腐烂对非维护者完全不可见。你无法让一个以本季度发布功能数衡量成绩的领导团队，感受到一项他们看不见的成本。

2026 年的每一项发布都在读取你的设计系统

把 Figma 2026 年上半年的发布清单当作一组依赖关系来看，会得到一个一致的结论：

• 5 月 20 日，Figma 上线原生 AI 代理，可在画布上生成与改写界面；
• 3 月 24 日，通过 MCP 服务器向 Claude、Cursor 等第三方代理开放画布，并通过「skills」（一份描述团队约定的 Markdown 文件）约束代理行为；
• 3 月 4 日，推出 Code Connect UI，把 Figma 组件映射到真实代码组件，Dev Mode 直接显示 React 引入路径；
• 5 月 28 日，Make 从原型工具升级为可编辑生产代码库并自动提交 PR；
• 6 月 4 日，发布 Check designs；
• Config 2026 现场又新增 Figma Motion、WebGPU 着色器、组件插槽守卫。

上述每一个功能都依赖设计系统的输入，一旦系统不健康，失败会公开发生。Figma 自己的发布文章也承认，缺乏设计系统上下文时，代理生成的界面会显得「陌生而通用」（unfamiliar and generic）。这种通用界面不会停留在设计文件里，它会出现在评审中，被利益相关者默认为团队的产出标准；Code Connect 缺少映射时，开发者被拉回逐像素对照的旧流程；Make 把偏离品牌的内容推进代码库，受影响的是审阅 PR 的工程师；插槽守卫的有效性同样取决于定义插槽的系统本身。

一个无法辩驳的数字

Check designs 是这套发布中最锋利的一把刀，也是大多数 Config 回顾文章低估其意义的原因。它把当前文件与设计系统比对，标记所有不匹配项：应为令牌却硬编码的值、未通过 WCAG 的对比度、已脱离源文件的组件、以及来自未订阅库的令牌。关键在于它不使用 AI，也不做语义猜测，它只做计数。打开面板，顶部就会显示一个总数。

「我们的设计系统存在漂移」过去是一句话，柔软、可否认、易推迟。现在它变成屏幕上任何人可见的数字：47 处不一致，然后是下一个文件，再下一个。一句话会输掉路线图之争，一个持续攀升的数字则不会以同样的方式落败。

这才是真正的转变：设计系统债务曾由一个人在没人打开的文件里悄悄偿还，如今由生成错误组件的工程师、因为交接断裂而延误的 PM、以及产出偏离品牌素材的营销人来共同承担。成本从维护者的角落转移到了他们手中。

Config 没有解决的部分

作者在结尾给出了冷静的注脚：可见性不等于决定权。最理解系统的人几乎从来不是掌握路线图的人。设计系统中真正决定其存续的部分——评审流程、审批模型、所有者归属——恰恰是永远上不了演示稿的部分。你可以运行 Check designs、截下数字、带着最干净的证据走进规划会，但数字说服的是愿意被说服的人，对于那些把维护视为非交付性支出的人，证据本身并不改变权力结构。