Figma 这次最刺眼的功能，不是用提示词做动画，也不是在画布里加 shader。
而是 Code layers：你可以在 Figma Design 画布里克隆代码仓库，让 agent 生成方向，把流程抽成可编辑设计层，再同步回代码。
一个设计工具开始碰代码资产，事情就变了。Figma 想让设计、代码、AI agent 和交付链条都留在同一块画布上。AI 特效只是门面，流程入口才是生意。
四个更新：画布开始接管更多生产环节
Figma 在 Config 2026 放出的核心更新，可以压成四件事：代码、动效、视觉效果、AI 工作流。
| 功能 | 做什么 | 直接影响 |
|---|---|---|
| Code layers | 在 Figma Design 画布中处理代码：克隆仓库、用 agent 生成方向、把流程抽成可编辑设计层，并同步回代码 | 产品设计师、前端开发者、设计系统团队 |
| Motion | 用提示词生成动画、转场和 3D transform；也能用预设或时间线手动调整；Figma 称其 code-backed、ready to ship | 交互动效设计、前端实现、产品交付 |
| Shaders | 基于 WebGPU，在画布里生成 dither、pixelate、多种 blur 等原本不在 Figma 里的视觉效果 | 视觉设计师、品牌团队、创意工具使用者 |
| Weave workflows | 集成 20 多个 AI 工具，把复杂视觉生成流程封装进 Figma 画布 | 依赖 Figma 做协作交付的产品组织 |
这张表里，Code layers 最关键。
Motion 和 Shaders 会让设计表达更快。Weave 会让视觉生成少跳几个工具。但 Code layers 直接碰到了工程资产。它把 Figma 从“设计交付前的协作工具”，推向“交付过程中的操作界面”。
边界要说清。Figma 还没有取代 IDE，也没有吃掉完整开发流程。材料里讲的是优化 full-stack development、支持代码层和同步。真实开发仍然要经过工程审查、测试、权限、上线和回滚。
但门已经开了。
以前 Figma 文件是开发的参考物。现在它开始变成开发流程的一部分。
影响谁：设计师更靠近代码，工程师更靠近设计债
这次最该关心的，不是普通用户，而是两类人：产品设计师与设计系统负责人，前端开发者与产品团队管理者。
对产品设计师来说，动作会变得更具体。以后交互动效、状态切换、视觉效果，不再只是“标注一下、口头解释一下”。Motion 可以生成动画和转场，Shaders 可以把更多视觉效果直接放进画布，Code layers 又让代码流程进入设计环境。
这会提高表达能力，也会提高责任密度。
设计师可能要开始关心：这个动画是不是可交付？这个视觉效果有没有工程成本？这个设计层同步回代码前，谁来确认它没有破坏组件规则？
对设计系统负责人来说，麻烦更现实。组件、变量、动效、代码实现之间的关系，要重新写规矩。过去设计系统更多管“设计一致性”。现在它可能还要管“设计资产如何进入代码”。
这会逼团队做几件事：
- 明确哪些 Figma 生成内容可以进仓库，哪些只能做探索。
- 给 Motion、Shaders 这类效果设定可用范围，避免设计稿看起来很爽，实现时全是债。
- 把 review 规则前置到画布里，而不是等开发阶段再返工。
前端开发者也不会轻松。
他们会更频繁看到来自 Figma 的代码同步、AI 生成方向和所谓 ready to ship 的动效。效率可能提高，噪音也会增加。开发者要调整的不是工具审美，而是工作流：哪些内容接受同步，哪些必须重写，哪些要进 code review。
产品团队管理者则要做一个不讨巧的决定：要不要把 Figma 从“协作工具”升级成“流程入口”。
如果团队依赖 Figma 做跨职能协作，可以先小范围试。比如只让 Code layers 服务原型探索，或者只让 Motion 处理低风险动效。别一上来就把它当成绕过工程流程的捷径。
采购和迁移也不该冲动。材料里没有价格、开放状态、性能指标、客户采用率这些信息。企业团队现在更适合观望功能成熟度和治理能力，而不是立刻改主流程。
Figma 想要中枢位，但责任不能糊在画布上
Figma 过去赢在协作。设计师、产品经理、工程师能在同一个文件里评论、改稿、对齐。
现在它想继续往前走：不只是让大家看同一张图，而是让大家在同一个地方推进产品。
这就是它的野心。工具位赚订阅，中枢位吃流程。
“天下熙熙，皆为利来。”放在这里很合适。协作工具的利润，不只来自座席。谁控制流程入口，谁就更容易控制团队习惯、插件生态、AI 调用、版本资产和交付标准。
Motion 的价值也在这里。如果只是生成几段漂亮转场，它只是玩具。Figma 强调 code-backed、ready to ship，意思就重了：动效不再只是设计表达，而是被包装成可交付资产。
Shaders 同理。WebGPU 带来的 dither、pixelate、blur 等效果，减少了设计师跳出 Figma 的理由。Weave 更直白，把 20 多个 AI 工具压进画布。看起来是省事，实质是收口。
我肯定这个方向。产品团队确实被太多缝隙折磨：设计稿和实现不一致，动效靠口头描述，视觉效果跨工具导来导去，AI 结果散在不同平台。
Figma 把这些缝隙往一个画布里合并，是抓住了真问题。
但我不太买账的是轻飘飘的交付叙事。能生成，不等于能上线。能同步，不等于可信。看起来像代码，不等于工程团队愿意负责。
代码不是图层。
代码有依赖、测试、权限、性能、安全审查和回滚。Figma 如果只是帮团队更快探索方向，很好。如果组织把它当成绕过工程流程的通道，问题会来得很快。
AI agent 最容易制造一种错觉：流程变短了，责任也变轻了。
实际正相反。流程越短，责任越要硬。设计师能不能改代码？改到什么程度？AI 生成的动效谁验收？同步回仓库前谁 review？线上出问题算谁的？
这些问题不解决，一体化就会从效率工具变成摩擦放大器。
历史上这类变化反复出现。桌面出版让编辑更接近排版，CMS 让作者更接近发布，低代码让业务更接近应用搭建。效率上去了，边界也被重新划线。
Figma 这次不完全一样，但重复的是同一种权力移动：生产工具把更多角色拉进同一个界面，再重新分配责任。
接下来最该观察的，不是 Figma 能不能生成更炫的动画。
要看三件事：Code layers 同步回代码的可信度，Motion 这类 code-backed 资产在真实工程里的审查方式，以及企业团队会不会建立清楚的权限和责任规则。
画布能碰代码以后，问题就不再是“这个稿子好不好看”。
问题变成：这个画布里的东西，谁敢让它上线。