D2C：前端的自我革命
序言
这半个月一直在专注于 Figma-to-Code 的相关工作，也在不断思考和调研已有的 D2C（Design to Code）方案。
目前市面上主流的实现方式，大多是基于 Figma 插件，通过插件调用 Figma 的 Open API 获取设计稿的结构和样式信息，再转换成对应的 DSL（中间描述语言），最终通过渲染引擎生成各端代码。也有一些方案尝试通过设计稿的截图，结合视觉识别算法实现 0 到 1 的生成，但这种方式在还原度和一致性方面存在明显短板，难以满足生产需求。
这几天阅读了大量相关资料，包括公司内部方案，也参考了外部团队的一些实践。其中印象较深的有：
- 网易云音乐技术团队的 海豹 D2C：提出了基于 DSL + 引擎驱动的完整设计转码链路，思路清晰，落地程度较高。
- 字节跳动的 Semi Design：虽然更偏向组件体系，但其设计-开发一体化理念、设计规范约束和配套工具链也对 D2C 体系建设有很强的借鉴意义。
总体来看，D2C 的核心逻辑可以归纳为三步：
- 解析设计稿：通过 Figma Open API 提取结构与样式；
- 转换为 DSL：构建平台无关的中间描述层；
- 生成端代码：通过模板或引擎渲染出对应平台代码（Web / Native / Flutter 等）。
虽然整体流程逐渐清晰，但受限于 Figma 本身的表达能力、设计规范一致性、插件能力边界等因素，还原度始终是当前最大的挑战，尤其在复杂交互、自适应布局、组件语义识别等方面，仍有大量细节需要补齐。
产品整体流程
Figma API中的信息
节点类型
| 节点类型 | 说明 |
|---|---|
FRAME | 框架，是Figma中最常用的容器节点（也可作为画板）。可嵌套其他节点。 |
GROUP | 分组，用于逻辑上组合多个元素，不具备 Frame 的布局功能。 |
RECTANGLE | 矩形，最常见的形状元素。 |
ELLIPSE | 椭圆或圆形。 |
LINE | 直线。 |
POLYGON | 多边形。 |
STAR | 星形。 |
VECTOR | 矢量路径（Pen 工具画出的路径）。 |
TEXT | 文本元素。 |
节点属性
🧱 通用基础属性（所有节点都具有）
| 属性 | 类型 | 说明 |
|---|---|---|
id | string | 节点的唯一 ID。 |
name | string | 节点的名称。 |
type | string | 节点的类型，如 "FRAME"、"TEXT" 等。 |
visible | boolean | 节点是否可见。 |
locked | boolean | 是否锁定节点。 |
parent | BaseNode | null |
removed | boolean | 是否已从文档中移除。只读。 |
children | SceneNode[] | 子节点数组（如果节点支持包含子节点）。 |
🖼️ 通用场景属性（大多数可视节点具有）
| 属性 | 类型 | 说明 |
|---|---|---|
x, y | number | 节点相对于父节点的位置。 |
width, height | number | 节点的尺寸。 |
rotation | number | 旋转角度（度）。 |
relativeTransform | Transform | 节点相对于父节点的变换矩阵。 |
absoluteTransform | Transform | 相对于画布的变换矩阵。 |
constraints | Constraints | 自动布局的约束条件。 |
layoutAlign | string | 在自动布局中的对齐方式（如 "STRETCH"、"CENTER"）。 |
layoutGrow | number | 在自动布局中是否可扩展。 |
🎨 图形样式属性（大多数图形节点具有）
| 属性 | 类型 | 说明 |
|---|---|---|
fills | Paint[] | 填充颜色、渐变、图片等。 |
strokes | Paint[] | 描边样式。 |
strokeWeight | number | 描边粗细。 |
strokeAlign | string | 描边对齐方式（"CENTER"、"INSIDE"、"OUTSIDE"）。 |
cornerRadius | number | mixed |
opacity | number | 不透明度（0~1）。 |
blendMode | BlendMode | 混合模式。 |
effects | Effect[] | 阴影、模糊等效果。 |
isMask | boolean | 是否作为遮罩。 |
exportSettings | ExportSettings[] | 导出配置。 |
🔠 文本节点（TEXT）特有属性
| 属性 | 类型 | 说明 |
|---|---|---|
characters | string | 文本内容。 |
fontSize | number | mixed |
fontName | { family: string, style: string } | 字体。 |
textAlignHorizontal | string | 水平对齐（"LEFT"、"CENTER"、"RIGHT"）。 |
textAlignVertical | string | 垂直对齐（"TOP"、"CENTER"、"BOTTOM"）。 |
lineHeight | LineHeight | 行高。 |
letterSpacing | LetterSpacing | 字间距。 |
textAutoResize | string | 文本自动调整尺寸方式。 |
textStyleId | string | 关联的文本样式 ID。 |
🧱 自动布局属性（如 FRAME, COMPONENT 等）
| 属性 | 类型 | 说明 |
|---|---|---|
layoutMode | "NONE" | "HORIZONTAL" |
primaryAxisAlignItems | string | 主轴对齐方式。 |
counterAxisAlignItems | string | 交叉轴对齐方式。 |
itemSpacing | number | 子元素间距。 |
paddingLeft/Right/Top/Bottom | number | 内边距。 |
🧩 组件相关属性（COMPONENT, INSTANCE）
| 属性 | 类型 | 说明 |
|---|---|---|
mainComponent | ComponentNode | INSTANCE 实例对应的组件定义。 |
componentPropertyReferences | Record<string, string> | 实例中引用的属性。 |
variantProperties | Record<string, string> | 组件变体中的属性值（在 COMPONENT_SET 中）。 |
全链路跑通
大概用了半个月的时间，我们基于 Dify + MCP + LLM 的组合，成功打通了 D2C 的完整链路。相比市面上不少公司繁琐复杂的方案，我们的目标很简单：只做一件事——输入一个设计稿，输出所需的组件。
是的，这就是我们第一阶段的 MVP。看似简单，但我们确实做到了端到端的打通。
不过，现实也没有那么理想。由于底层技术方案还存在一些限制，尤其是在解析复杂结构、还原视觉细节等方面，当前方案在设计稿还原度上依然存在较大提升空间。这也是接下来需要重点攻克的方向。
Figma 在布局结构上的表达方式与传统 HTML 有着明显差异，尤其是在自动布局、约束关系等方面。因此，Figma API 提供的节点信息，往往无法直接映射为标准的 HTML 布局结构。
图1
图2
在第一阶段，我们完成了从 Figma 设计稿到初步 HTML 结构的转换。随后在 HTML 向 React 组件的规范化转换中，我们进行了多轮迭代，并测试了多种大模型的表现。
对比结果显示，Claude 4 和 Gemini 2.5 Pro 在生成准确性和结构还原方面表现最优，明显优于其他同类模型。这也解释了为何一些 D2C 工具会选择集成 Claude 模型作为其底层能力——更强的代码结构理解力带来了更高的还原度和更少的人工干预。
D2C 已知痛点
1. 设计稿中存在无用图层
UI 设计师在设计过程中，往往会隐藏一些暂不使用或用于参考的图层。这些隐藏元素在视觉交付时无影响，但在解析 Figma 设计稿时仍然会被包含，导致我们在判断其是否应渲染时需额外处理层级、可见性等逻辑，增加了解析成本。
图1
针对无用节点的排除问题，主要有两种可行方案：
- 人工标注：通过人工方式对设计稿中的无效元素进行标注与筛选，从源头减少冗余结构，但是会增加设计师工作量；
- 自动对比优化：结合大模型的图像理解能力，在 dify 流程中将设计稿作为图片输入，并与生成的 HTML 页面进行结构和视觉对比，从而自动调整 HTML 布局，优化输出结果。
2. 图层是否需要整体导出为图片
在遇到复杂图层结构（如多个图层交错、遮罩、混合模式等）时，直接还原为代码会增加实现难度和不确定性。此类场景下，若能自动识别并将其作为整体导出为一张图片，会显著简化开发流程。
3. 无响应式布局信息
Figma 原生输出的信息大多是基于绝对像素（px）的定位和尺寸，没有包含响应式布局的语义。这对需要适配不同屏幕的 Web 端开发非常不友好，若无后续处理，将导致导出的代码缺乏灵活性和扩展性。
总结
周参与了公司内部关于 Figma 的邀请制会议。Figma 官方计划在未来几个月正式发布 MCP，这意味着相较于我们当前基于第三方方案所开发的 MCP，官方版本在还原度、交互细节及整体稳定性方面将具有显著优势。这也意味着，我们近期投入的相关工作很可能在未来被替代。
尽管如此，这段过程依然收获颇丰。通过实践，我不仅深入理解了设计到代码转换的技术路径，也重新激发了初学时那种不断探索与攻克难点的热情。某种程度上，这段经历更像是一场自我打磨与能力进阶。