Figma 转代码，为什么总是差最后一公里？

过去几年，Figma 转代码一直是一个很有吸引力的方向。

从 Demo 看，它几乎总是很惊艳：给一张设计稿，几秒钟生成页面；把 Figma 链接丢进去，系统吐出 HTML、CSS、React 组件；再配上一个浏览器预览，看起来已经非常接近“设计稿直接变代码”。

但只要把它放进真实工程现场，问题就会很快暴露出来。

页面第一眼像不像，只是最表层的问题。真正麻烦的是：生成的代码是不是响应式的？是不是用了项目里的组件？样式是不是接入了 design token？布局是不是一堆绝对坐标？页面改一版后，代码还能不能继续维护？开发同学敢不敢接着往上写业务逻辑？

这也是 Figma 转代码一直很尴尬的地方。

它看起来离成功很近，但一进入真实研发流程，就总是差最后一公里。

我觉得这最后一公里，不在“把图变成 HTML”，而在“把设计稿翻译成工程系统能理解、能维护、能验证的代码”。

换句话说：D2C 最难的不是第一眼像不像，而是第二天能不能接着开发。

我们通常理解的 D2C，是“设计图转代码”。这句话没错，但太粗了。

如果输入只是一张截图或一张设计图，模型看到的是视觉结果。它能看到这个页面有一个标题、一张图、几个按钮、几块内容区域。多模态模型足够强时，也确实能大致还原视觉布局。

但截图只告诉模型“页面长什么样”，并不会告诉模型“这个页面为什么这么组织”。

比如，一个视觉区域到底是 Card，还是普通容器？
一个按钮是不是设计系统里的标准 Button？
一组元素是 List、Grid，还是设计师手动摆出来的几个块？
某个间距是布局约束，还是当前画布上的像素结果？
哪些样式应该复用 token，哪些只是临时视觉效果？
哪些节点应该抽成组件，哪些只是一次性的装饰元素？

这些问题，从截图里很难稳定推出来。

所以截图转代码最大的问题不是不能生成，而是生成出来的东西经常停留在“视觉复刻”。它可能看起来很像，但缺少工程语义。最后代码里堆满 div、绝对定位、硬编码尺寸、临时颜色值和不可复用的样式。

这类代码适合做 Demo，不适合进入长期维护的工程。

所以我更愿意把截图转代码理解成 D2C 的第一阶段：它解决的是“看起来像不像”，但还没有真正解决“能不能工程化”。

一句话：截图是结果，不是设计现场。

如果把 D2C 拆开看，今天大概有几条路线。

第一条，是截图或设计图转 HTML。

这是最容易被看见的一类，也是 Demo 效果最强的一类。输入是一张图片，输出是一段 HTML / CSS / React 代码。它的优势是门槛低，不依赖设计工具，也不依赖团队资产。只要能看到图，就能生成。

但它的问题也很明显：它只有视觉结果，没有设计结构，也没有工程上下文。它离 Demo 最近，离真实工程最远。

第二条，是读取 Figma 节点树或 JSON，再通过规则或模型生成代码。

这也是很多 Figma 插件更接近的路线。它不只是看图，而是读取 Figma 文件里的节点树、坐标、样式、文本、资源，再把这些信息转换成 HTML、CSS 或框架代码。

这比截图路线多了一层结构信息。至少模型不必完全从图片里猜层级、字体、颜色和资源。

但这里有一个更隐蔽的问题：Figma 的结构是设计工具的结构，不是前端工程的结构。

Figma 里有 Frame、Group、Layer、Auto Layout、坐标、样式、组件实例。前端工程里关心的是 Component、Props、Layout、State、Responsive、Token、可复用边界和业务语义。两者有关联，但不能直接等价。

所以，Figma JSON 转代码看似更接近工程，实际上也可能只是把设计工具里的结构原样翻译成代码。它解决了“看图猜结构”的问题，但还没有解决“设计结构如何转成工程语义”的问题。

第三条，是设计组件到代码组件的映射。

这条路线更工程化。

它不是把每个图层都翻译成 div，而是希望识别出：这个是 Button，这个是 Card，这个是 Form，这个是 Table，这个是导航区，这个是内容列表。然后把它们映射到项目里的真实组件库。

如果 Figma 里的设计组件能对应代码仓库里的 React 组件，设计 token 能对应工程里的 token，组件属性能对应 props，那么 D2C 就不再只是“生成一份看起来像的代码”，而是开始接入真实研发资产。

这条路线价值最大，但也最依赖组织基础。

团队要有设计系统，要有组件库，要有命名规范，要有 token 体系，要有设计组件和代码组件之间的一致性。如果这些资产本身是断的，AI 很难凭空补齐。

所以真正可维护的 D2C，不是从图层生成代码，而是从设计组件恢复工程组件。

第四条，是 Figma / PRD / 代码库共同进入 Agent。

这条路线更接近未来真实研发自动化。

它不是只生成一个静态页面片段，而是让 Agent 同时读取 Figma、PRD、现有代码库、组件库、路由、状态管理、接口约定、历史实现，然后在真实仓库里完成一次改动。

这时候，D2C 不再是一个单点插件，而是一条工程链路。

它需要理解上下文，选择组件，修改代码，运行项目，看浏览器结果，发现偏差，修复问题，生成验证证据，最后交给人 review。

这条路线没那么适合做炫酷 Demo，但它更接近真实交付。

所以，D2C 的几条路线差别不只是输入不同，而是离真实工程现场的距离不同。

从截图转 HTML，到 Figma JSON 转代码，再到设计组件映射代码组件，最后到 Agent 进入真实代码库，每往后一步，视觉还原的重要性都在下降，工程上下文的重要性都在上升。

Figma2Code 这篇论文的价值，正在这里。

它没有继续把 D2C 简化成“截图转代码”，而是把问题往真实工作流推进了一步：真实团队里，设计稿通常不是一张孤立图片，而是一个 Figma 文件。

Figma 文件里不只有截图，还有 metadata 和 assets。

这里的 metadata，可以简单理解成设计稿背后的结构化数据。它里面包含页面、Frame、Group、Layer 的节点树，也包含每个节点的位置、尺寸、层级、文本、字体、字号、颜色、圆角、阴影、资源引用、组件和样式信息。

assets 则包括图片、图标、背景图等资源。

所以，Figma2Code 这篇论文的一个关键提醒是：如果真实工作流里设计稿本来就是 Figma 文件，那么 D2C 不应该只看最终截图，而应该使用 Figma 文件中更丰富的上下文。

可以压成一句话：截图告诉 AI“它长什么样”，Figma metadata 告诉 AI“它是怎么被组织出来的”。

这一步很重要。

因为从图片里猜 UI 结构，本来就是一个很不稳定的问题。模型可能看得懂大概布局，但很难准确知道一个复杂页面的层级关系、资源引用、样式来源和组件结构。

Figma metadata 相当于把一部分“设计现场”暴露给模型。它让模型不必只从像素里猜，而是可以直接看到设计工具里的结构和属性。

这也是 Figma2Code 相比很多 image-only design-to-code benchmark 更接近真实工作流的地方。

它不是只问：模型能不能看图写网页？

它问的是：当模型同时拥有截图、设计结构和资源文件时，能不能生成更好的 UI 代码？

但问题也出在这里。

Figma metadata 有价值，但它不是答案。甚至在某些情况下，它会成为陷阱。

因为 Figma 的数据结构，本质上是设计工具为了表达视觉稿而组织出来的结构。它能描述图层、坐标、尺寸、样式和层级，但它并不天然等于前端工程需要的组件结构、布局语义和复用边界。

这就像拿到一份装修图纸，并不等于知道这套房子以后如何居住、如何维修、如何扩建。

Figma JSON 里有很多信息，但这些信息未必是工程上真正需要的抽象。

比如，设计稿中两个元素相距 24px，工程里可能应该理解成一个标准 spacing token；也可能只是设计师拖拽时形成的结果。
一个 group 里面放了几个元素，工程里可能应该是一个 List，也可能只是视觉上的临时组合。
一个按钮在 Figma 中是一个组件实例，但它是否对应代码库里的 Button，还取决于团队的组件库、命名规范和实现约定。
一个复杂页面里有大量 absolute position，设计工具能正常展示，但前端工程如果照抄，很容易变成不可响应、不可维护的代码。

所以，metadata 的危险在于：它会让模型更容易“照着设计稿翻译”。

这种翻译会提升视觉还原，但也可能带来大量硬编码、绝对坐标、非标准样式 token 和僵硬布局。页面第一眼更像了，代码质量却更差了。

Figma2Code 论文里的实验也印证了这一点：metadata 能显著提升视觉还原，但 metadata-based 方法往往更容易产生 rigid layout 和 arbitrary style tokens。也就是说，模型拿到了更多设计属性，却未必知道哪些属性应该被抽象成工程约束，哪些只是视觉结果。

这也是 D2C 很容易误入歧途的地方。

我们以为多给模型一点 Figma JSON，它就能更接近真实工程。结果它可能只是更精确地复刻了设计工具里的痕迹。

所以这句话很关键：Figma JSON 不是前端代码的蓝图，它只是设计工具留下的痕迹。

它有用，但不能直接等价为工程结构。

真正的最后一公里，在这里。

不是从 Figma 到 JSX，也不是从截图到 HTML，而是从设计结构到工程语义。

所谓设计结构，是 Figma 文件里已有的东西：节点、图层、坐标、样式、资源、组件、层级。

所谓工程语义，是前端工程真正关心的东西：组件、属性、布局、状态、响应式规则、设计 token、可复用边界、可维护结构、验证方式。

这两者之间需要一次翻译。

Figma2Code 论文里的 F2CAgent 就做了一个很有启发性的尝试：它不是直接操作原始 Figma JSON，而是先把 raw Figma JSON 转成一个更简化、结构化的 Intermediate Representation，也就是中间表示。然后再基于规则模板生成 UI 代码，并通过 critic / refiner 的方式做迭代修正。

这个 IR 不一定已经是工业级方案，但方向非常重要。

因为原始 Figma JSON 太贴近设计工具，直接喂给模型容易带来噪声和误导。中间表示的价值，就是把设计工具里的原始节点，整理成更接近工程系统可理解的结构。

它需要回答一组问题：

这个区域在工程里应该是什么组件？
这些元素之间到底是什么布局关系？
哪些样式应该转成 token？
哪些节点只是装饰，哪些节点应该保留？
哪些元素应该合并，哪些元素应该拆开？
哪些信息是视觉结果，哪些信息是工程约束？
这段代码应该如何适配不同屏幕？
生成后如何通过浏览器渲染结果做验证？

这些问题，单靠“看图”很难稳定解决，单靠“读 Figma JSON”也很难稳定解决。

所以 D2C 的关键不是“看懂设计稿”，而是“重建工程语义”。

这也是我觉得 Figma2Code 这篇论文最有价值的地方。

它没有只是告诉我们“多模态模型变强了”，而是暴露了一个更真实的问题：模型已经能在视觉还原上做得越来越好，但仍然很难同时兼顾响应式布局和代码可维护性。

这其实是前端工程里很熟悉的问题。

一个页面看起来像，不代表代码好。
一个样式还原得准，不代表组件边界合理。
一个布局在当前尺寸下没问题，不代表换个屏幕还能用。
一个 Demo 可以跑，不代表它能进入真实项目。

D2C 的最后一公里，本质上是工程问题，不只是模型问题。

这也解释了为什么**“设计稿没用了”**这个判断太粗糙。

AI 时代，设计稿的地位确实会变化。但更准确的说法不是设计稿消失，而是设计稿不再默认成为每个需求的必经交付物。

过去很多团队习惯了一个默认流程：产品提出需求，设计师出设计稿，研发照稿开发，最后再走验收。

这个流程在复杂页面、关键体验、品牌表达、创新交互里依然有价值。但它不一定适合所有需求。

对于一些低风险、模式明确、组件化程度高的需求，未来可能不需要每次都经过完整设计稿。它可以直接从产品意图、历史页面、组件库、代码上下文进入原型或实现。

比如一个后台管理页新增筛选项，一个列表页增加字段，一个已有流程里补一个状态页，一个标准表单增加配置项。这类需求的关键可能不是重新设计，而是准确理解业务意图、复用已有组件、遵守交互规范，并确保实现正确。

在这些场景里，设计稿可能从默认交付物，变成按复杂度、风险和体验要求选择的工具。

但这并不意味着设计稿不重要。

相反，当一个需求确实需要设计稿时，设计稿的要求会更高。

它不能只是“给人看的视觉图”，还要成为 AI 和工程系统能读取的上下文。它需要承载更清晰的结构、更稳定的组件关系、更明确的 token、更可识别的布局意图，以及和真实代码库之间的映射关系。

也就是说，AI 不是让设计稿没用，而是让“只交付一张图”的设计稿不够用了。

设计稿的价值，会从“让开发照着写”，逐渐变成“为研发自动化系统提供高质量上下文”。

这个变化对设计师、前端工程师和产品团队都有影响。

设计师不只是画出视觉结果，还需要更重视组件结构、状态表达、交互规则和设计系统一致性。
前端工程师不只是还原页面，还需要把组件库、token、布局规范和验证体系建设好，让 AI 有东西可以接。
产品团队不只是等设计稿出来再推动开发，而要更早把需求意图、验收标准和复杂度判断说清楚。

这背后其实是产品、设计、研发，也就是 PDE 协作方式的变化。

设计稿仍然重要，但它不再只是流程中的一个文件，而是整个交付系统中的一种上下文资产。

所以，Figma 转代码为什么总是差最后一公里？

不是因为模型还不够聪明，也不是因为 Figma API 还不够开放，更不是因为某个插件少做了几个功能。

真正的问题是：设计稿、组件系统、代码仓库、响应式规则、验证环境、团队规范，还没有被连接成一个完整系统。

如果没有设计系统，AI 很难知道哪个视觉元素应该映射到哪个组件。
如果没有组件库，AI 只能生成一次性代码。
如果没有 token 体系，AI 只能硬编码颜色、间距、字号。
如果没有真实代码上下文，AI 不知道项目里的路由、状态、接口和工程约束。
如果没有浏览器渲染验证，AI 不知道生成结果到底偏了多少。
如果没有人工 review 和回归机制，AI 生成的代码很难安全进入主干。

所以成熟的 D2C，不会只是一个“把 Figma 变 HTML”的插件。

它更像一条链路：

这条链路里，Figma 很重要，但它只是输入之一。真正决定效果的，是中间有没有工程化的表示，有没有项目级上下文，有没有验证闭环。

这也是为什么很多 D2C Demo 看起来很近，但真实落地总是差一口气。

Demo 只需要生成一次。
工程需要长期演化。

Demo 只需要像。
工程需要能改、能接、能验、能复用。

Demo 面向截图。
工程面向系统。

所以，Figma 转代码的最后一公里，本质上不是从设计稿到代码，而是从视觉交付物到研发自动化系统。

最后可以把这篇文章压成一句话：设计稿不会消失，但它会从视觉交付物，变成研发自动化系统里的高质量上下文。

而 D2C 真正要解决的，也不是“如何让 AI 更会看图”，而是：如何把设计现场，翻译成工程系统能理解、能维护、能验证的代码。