每天写服务代码的我，最近被老板要求把前端页面的开发也给包了。

对于我们写 API、设计数据库习惯了的人来说，写前端最折磨人的根本不是逻辑和接接口，而是还原设计稿。那个 CSS 样式、间距调整、响应式布局，随便选个像素对不上就能折腾我一整天。

后来为了偷懒，我尝试走 Vibecoding 路线：把设计稿截图或节点交给 AI，让模型生成前端代码。Figma 官方 MCP 其实已经比只喂截图靠谱不少：[官方文档](https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Figma-MCP-server)显示，它能把组件、变量、布局等结构化上下文交给 IDE，还能配合 Code Connect 复用代码库里的真实组件。最终代码质量也不只取决于 MCP，客户端、模型、提示词和项目上下文都会影响结果。

但在我的实际测试里，它还没有稳定做到设计稿一贴，生产代码直接可用。一方面，按 Figma 当前的[用量与权限说明](https://developers.figma.com/docs/figma-mcp-server/plans-access-and-permissions/)，Starter 方案以及付费方案中的 View/Collab 席位每月最多只有 6 次读取类工具调用；Dev/Full 席位则采用按分钟计算的限频。另一方面，官方 MCP 更偏向把 Figma 上下文提供给 Agent，最终如何组织图片、布局和组件，仍依赖 Agent 的实现能力。

下面这组就是一次真实结果。左边是原始 Figma 设计稿，右边是我用 Figma 官方 MCP 配合 Agent 生成的页面。整体结构、文案和主要模块都还原出来了，不能说完全不好用，但细节距离可交付仍有差距。

[完整 Figma Community 设计稿](https://www.figma.com/community/file/1621166836274739738/free-finmori-smart-budget-expense-tracker-ui-kit)（社区公开设计稿，仅作展示case，非内部使用）

| Figma 设计稿 | Figma 官方 MCP + Agent 实现 |
| --- | --- |
| <img src="https://developer.qcloudimg.com/http-save/yehe-12698709/5468b43d7322081c456e8b0e6c335b5a.png" alt="原始 Figma 设计稿" width="360"> | <img src="https://developer.qcloudimg.com/http-save/yehe-12698709/a1b9c257ce728f1239886ec557e744d5.png" alt="Figma 官方 MCP 配合 Agent 生成的页面" width="360"> |

从结果看，页面骨架基本正确，但视觉资源、字体和布局精度还不够稳定，仍需要不少人工校准才能达到设计验收标准。具体差异从图里就能直观看出来。

这也是我继续找其他方案的原因：不是官方 MCP 没价值，而是我更需要一个在进入模型之前，就先把视觉几何和图片资源处理得更确定的链路。

直到前阵子在折腾替代方案的时候，我试了下 Sloth D2C，这才算救了我这条狗命。用了一段时间感觉确实有点东西，顺便记录一下我是怎么靠它搞定设计稿还原的。

## 它是怎么解决还原度问题的？

我特意研究了一下它的实现思路，发现挺巧妙的。先说结论：**Sloth D2C 不会把视觉还原全部交给大模型，而是先在本地把设计稿转成一份绝对定位 HTML（`absolute.html`）**。节点的坐标、宽高、基础样式和层级先由转换程序保留下来，再让模型处理布局语义和工程结构。

说白了思路很朴素：能用代码确定性算出来的东西，就别交给大模型去猜。Sloth 在把数据交给模型之前，自己先把转译的脏活累活干完了，主要做了这么几件事：

1. **清洗设计数据，提高信噪比**：过滤隐藏节点，并把原始节点转换成更适合后续生成的结构。复杂稿件仍可能有需要人工确认的图层，并非所有内容都能自动判断取舍。
2. **样式提取和空间关系计算**：把节点的坐标、宽高、颜色、字号和层级等信息落成可直接预览的绝对定位 HTML。**这份 HTML 是一个高保真的视觉基准**，能减少模型对几何关系的猜测；但字体缺失、Figma 特效、响应式行为和复杂矢量等场景仍可能产生差异，不能承诺像素信息无损。
3. **图标碎片合并**：Sloth 提供自动合并能力，也允许在预览中调整合并结果和距离阈值。它能减少多个矢量碎片被分别输出的问题，但不保证每一组复杂图形都能一次识别正确。

还原度的大头会在这一步先建立一个基准：Sloth 输出的 HTML 可以直接在浏览器里预览，再进入分组、组件映射和代码生成。大模型拿到的不只是一张截图或原始 JSON，而是一份保留具体视觉和几何信息的中间产物；之后再把绝对定位重构成相对布局、做 CSS 语义化、映射项目存量组件。复杂页面还可以拆成模块任务（chunks）分批处理，而不是让模型一次吞下整个页面。响应式适配和最终工程质量仍需要模型与人工 Review，不能理解为全自动保证。

这套「确定性转译打底 + 大模型做语义重构」的组合，想取两条路线的长处：先用程序尽量保留视觉数据，再用模型处理纯算法难以覆盖的组件边界和工程语义。它通常比只靠截图猜布局更可控，但最终效果仍会受设计稿规范程度、字体与资源可用性、模型能力和人工配置影响。

上面的对比也说明了这条路线想解决的问题：先给 Agent 一个更稳定的视觉基准，再谈工程化重构，而不是把最终还原度全部押在一次模型生成上。

下面分别是 Sloth D2C 生成的 `absolute.html` 视觉基准，以及进一步重构出的 React 实现（这版由 Opus 5 模型转换）：

| `absolute.html` 预览 | React 实现预览（基于Claude-Opus-5生成） |
| --- | --- |
| <img src="https://developer.qcloudimg.com/http-save/yehe-12698709/3344b9bd0f09533afeb3b00ec498c7a7.png" alt="Sloth D2C 转换生成的绝对定位 HTML 预览" width="360"> | <img src="https://developer.qcloudimg.com/http-save/yehe-12698709/28354c3421faf4310b2a0d54078b2dc4.png" alt="Sloth D2C 重构生成的 React 实现预览" width="360"> |

从结果看，`absolute.html` 已经把页面的主要结构、卡片样式和空间关系保留下来；进一步生成 React 后，整体视觉没有因为工程化重构而明显跑偏。字体渲染、部分图标和局部间距仍有细节差异，但问题已经从重新猜一遍设计缩小到了对着基准做局部校准。

这也是这套流程实际好用的地方：中间结果可以先看、先改，再交给 Agent 生成项目代码。接下来具体看看这条链路怎么跑。

## 这玩意儿怎么用？先看下基本操作

如果只是想先把它跑起来试试，核心逻辑可以概括成两步：

1. **提取和预览**：通过 Figma 插件、MCP 或 CLI 读取目标节点，生成 `absolute.html`、清理后的节点数据和图片映射；在预览界面检查图标合并、分组和组件映射。
2. **生成和校验**：把确认后的中间数据交给支持的 AI Coding 工具，生成 React、Vue 等目标代码，再在真实项目中运行和 Review。

如果是在终端里用，基本就是几行简单的指令：

```bash
# 1. 全局安装 Sloth D2C CLI
npm install -g sloth-d2c
# 验证安装
sloth --version

# 2. 直接对设计稿链接转码（自动从 URL 提取 fileKey / nodeId）
sloth d2c --link "https://www.figma.com/design/你的fileKey/节点名?node-id=12-34"

# 3. 或把 Sloth 配成 MCP Server，由 AI 编辑器调用 d2c_figma
# 具体配置见下文
```

更多命令可随时 `sloth --help` 查看，常用还有 `sloth config`（查看配置）、`sloth server stop/restart`（服务管理）、`sloth update`（升级到最新版）。

明白了这个基本用法之后，就可以把它揉进我们日常的开发环境里了。

## 日常我主要用到的几个场景

### 在 Figma 插件里直接选区转码

平时拿到设计稿最顺手的还是在设计软件里。打开 Figma 插件，选中要转换的组件或页面区域，可以把设计数据送入本地流程，预览绝对定位 HTML，并检查图标合并结果。这条链路不需要通过 Figma REST API 拉取节点数据，因此不受对应读取接口的限频影响。

下面是从 Figma 里选中节点、完成转码并预览结果的过程：

<video src="https://cdn-y.tencentmusic.com/fe/yx/base/figma-plugin-preview.mp4" controls alt="Figma 插件转码流程演示">
若视频无法播放，请打开 [Figma 插件转码流程演示](https://cdn-y.tencentmusic.com/fe/yx/base/figma-plugin-preview.mp4)。
</video>

插件地址：[Sloth D2C Plugin](https://www.figma.com/community/plugin/1497969094291954974/sloth-d2c)

### 配合 MCP 或 Skill 复用项目存量组件

项目里经常已经有前面页面实现过的业务组件，比如卡片、列表项和导航栏。用 Sloth D2C 的 MCP 或 Agent Skill，可以在生成新页面时继续复用这些组件，避免 Agent 又写一套相似的 `div` 和样式。

MCP 和 Skill 不需要同时安装，按场景选一种就行：日常转码优先用 Skill；页面复杂、需要 Sampling 自动分组或分析导入组件时，再用 MCP。

**方式一：安装 Skill**

```bash
npx skills add git@github.com:TME-Sloth/skills.git
```

**方式二：安装 CLI 并配置 MCP**

```bash
pnpm install -g sloth-d2c --registry=https://registry.npmjs.org/
```

```jsonc
// .cursor/mcp.json  /  CodeBuddy MCP 配置（二选一即可，command 用全局安装的 sloth）
{
  "mcpServers": {
    "sloth-d2c": {
      "command": "sloth",
      "args": ["--stdio"]
    }
  }
}
```

如果使用 Codex Plugin，还可以在对话里引用已有组件的目录或文件，让 `sloth-d2c-components` Skill 扫描真实源码并长期登记：

```
请扫描 src/pages/account/components 里的可复用组件，
并登记到 Sloth D2C 组件库。
```

它会读取组件的真实导出方式和 Props，把名称、源码路径、导入语句和用途等信息写入项目根目录的 `.sloth/components.json`。在 MCP 拦截工作台里，也可以直接导入业务组件，让模型分析组件结构、Props 和引用方式，再把选中的设计区域映射到对应组件。匹配结果仍建议人工确认，尤其是外观相似但业务语义不同的组件。

下面是通过 Codex Plugin 扫描并登记已有组件：

![使用 Codex Plugin 登记项目已有组件](https://developer.qcloudimg.com/http-save/yehe-12698709/219ddcc3c8394714b8b6979301f029ca.png)

登记完成后，可以在拦截工作台的 Prompt 中引用对应组件：

![在拦截工作台的 Prompt 中引用已登记组件](https://developer.qcloudimg.com/http-save/yehe-12698709/4c7e2c6decdaf0fb01a764370b2d687c.png)

生成的代码会按登记信息直接引入项目里的组件。这里可以看到页面复用了已有的 `TabBar`：

![生成代码中引用已登记的 TabBar 组件](https://developer.qcloudimg.com/http-save/yehe-12698709/0ebb19747237ccaacb689c20b807aeeb.png)

组件登记信息和其他转换配置都保存在项目的 `.sloth/` 中。如果团队选择把这些文件纳入 Git，其他同学也能复用；是否提交仍取决于项目自己的版本管理策略。

### 扔进 Codex / Cursor 里生成代码

我现在写代码主要在 Codex 和 Cursor 里。走 Skill 时，直接把 Figma 链接交给 Agent，它会调用 `sloth d2c`、读取 chunks 并写代码；走 MCP 时，则调用 `d2c_figma`，还可以在拦截工作台里确认分组和组件映射。简单组件可能很快得到初稿，复杂页面仍需要运行验证和视觉校准。

如果主要使用 Codex，还可以直接安装 Sloth D2C 的 Codex Plugin。我自己一开始也没分清它跟上面那个 Skill 到底啥关系，后来用下来才明白：Skill 就像一个个单独的技能，想用哪个装哪个；Codex Plugin 更像一个打包好的全家桶，把首次转码、拦截工作台确认、组件登记、生成稿标注、视觉 Diff 这些能力一次性都塞进来，而不是只帮你注册几个 MCP 工具。要是你经常要反复预览、改来改去，装这个全家桶会省心不少。

```bash
# Codex 里接入 Sloth Plugin（适合生成、标注、修复和视觉 Diff 的长链路）
codex plugin marketplace add TME-Sloth/sloth-d2c --ref main
codex plugin add sloth-d2c --marketplace sloth-d2c
```

使用 Skill 时，可以直接说：

```
请把这个 Figma 设计稿生成 React 代码，
并优先复用 .sloth/components.json 中登记的项目组件：
https://www.figma.com/design/你的fileKey/节点名?node-id=12-34
```

如果走 MCP，则把第一句换成“使用 `#d2c_figma` 打开这个设计稿并生成 React 代码”。

使用 Codex Plugin 时，可以直接让它打开拦截工作台：

```
使用 Sloth D2C 打开这个 Figma 设计稿的拦截页，
我想先确认分组和组件映射，再生成 React 代码：
https://www.figma.com/design/你的fileKey/节点名?node-id=12-34
```

下面是使用 Codex Plugin 完成转码的实际效果：

![使用 Codex Plugin 完成 Sloth D2C 转码](https://developer.qcloudimg.com/http-save/yehe-12698709/12217ae3ac99b2534bcdb2037e437fd5.png)

### 用 CLI 和静默模式接自动化

最近老板看我一个人搞定前后端效率挺高，又想把这套写代码流程做成自动化。Sloth D2C 的 CLI 支持结构化 JSON 输出和静默模式（Silent Mode），刚好能接住这种自动化场景。

CLI 和 Silent Mode 让无人值守转换成为可能，但 Sloth 本身不负责监听 Figma、触发 CI 或创建 PR，这些步骤需要团队自己接起来。Figma 的 [Webhooks V2](https://developers.figma.com/docs/rest-api/webhooks/) 确实提供 `FILE_UPDATE`，但它会在文件停止编辑后的 30 分钟内触发，而且只返回文件级信息，并不能直接告诉你哪个节点发生了变化。

更适合转码自动化的是 [`DEV_MODE_STATUS_UPDATE`](https://developers.figma.com/docs/rest-api/webhooks-events/#dev_mode_status_update)：当设计师把某个图层标记为 `READY_FOR_DEV` 时，Webhook 会返回对应的 `file_key` 和 `node_id`。团队准备一个可公开访问的接收服务，校验 Webhook 后再触发 CI 或任务队列，就能把这两个参数交给 Sloth。实际链路可以用下面这张团队自动化工作台示意图来理解：

![团队 CLI 自动化工作流示意图](https://developer.qcloudimg.com/http-save/yehe-12698709/079cc665c4459093aa99de37d129b4ab.png)

如果团队没有使用 Dev Mode，也可以监听 `FILE_VERSION_UPDATE`，约定设计师创建命名版本后触发流程；但这个事件不包含节点 ID，仍需要团队自己维护待转换节点的映射。

顺带说下调用限制，需要把数据读取和模型调用分开看：

- **Figma 数据读取**：走插件链路时，选中节点的数据会由插件送入本地流程，不经过 Figma REST API，因此不受对应读取接口的限频影响；本地没有对应设计数据、需要通过 REST API 拉取时，才需要配置 API Key，并受接口限频约束。如果团队有多组合法授权的 Token，还可以通过 Token 池轮换分摊请求，减少单个 Token 触发限频的影响，提高整体可用吞吐。
- **本地 Agent**：`sloth server start` 可以启动本地服务，`sloth agent status --provider auto` 用来检查当前环境可用的 Agent provider。实际模型使用量仍受对应服务和订阅规则约束。

```bash
# 启动本地桥，并检查当前可用的 provider
sloth server start
sloth agent status --provider auto
```

## 一点使用下来的感受

这一轮被迫兼任前端的经历下来，工具选对了确实能少折腾很多无用功。Sloth D2C 用绝对定位 HTML 建立视觉基准，再配合模型做分组和工程化重构；它还提供 Figma 插件、Skill、MCP、Codex Plugin 和 CLI 等入口。对我来说，它最大的价值不是承诺一键 100% 还原，而是把原本全靠模型猜、全靠人肉调的过程，变成可预览、可干预、可复用的工作流。

---

**🛠️ 相关链接（按需自取）**

- **官网**：[Sloth D2C](https://tme-sloth.github.io/d2c/)
- **Figma Sloth 插件**：[Sloth D2C Plugin](https://www.figma.com/community/plugin/1497969094291954974/sloth-d2c)
- **CLI / MCP 工具**：[NPM: sloth-d2c](https://www.npmjs.com/package/sloth-d2c)
- **Codex Plugin / Marketplace 仓库**：[TME-Sloth/sloth-d2c](https://github.com/TME-Sloth/sloth-d2c)

---

大家现在被逼着写前端都在用啥工具？有没有跟我一样被 AI 转码还原度坑过、碎图合并不了的踩坑经历？评论区聊聊，互相抄抄作业 😂

对于我们写 API、设计数据库习惯了的人来说，写前端最折磨人的根本不是逻辑和接接口，而是还原设计稿。那个 CSS 样式、间距调整、响应式布局，随便选个像素对不上就能折腾我一整天。

被老板逼着连前后端一起写，分享我搞定 Figma 设计稿还原的一点心得

后端被迫写前端，最难的是还原设计稿。试过Figma官方MCP不够稳，改用Sloth D2C：先转绝对定位HTML建视觉基准，再让大模型语义重构，把「靠猜＋人肉调」变成可预览、可干预、可复用的流程。

前端

后端

开发工具

SlothD2C通过将Figma设计稿转为绝对定位HTML建立视觉基准，再用大模型进行语义重构，有效解决前端开发中的设计稿还原难题。支持Figma插件、MCP、CLI多种接入方式，可复用项目存量组件，并提供CodexPlugin全家桶实现转码、标注、视觉Diff全流程。相比官方Figma MCP，其确定性转译加AI重构的组合显著提升还原精度，减少人工校准成本。

代码解释

数据库

CodeBuddy

Agent

ReAct 

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

SlothD2C通过将Figma设计稿转为绝对定位HTML建立视觉基准，再用大模型进行语义重构，有效解决前端开发中的设计稿还原难题。支持Figma插件、MCP、CLI多种接入方式，可复用项目存量组件，并提供CodexPlugin全家桶实现转码、标注、视觉Diff全流程。相比官方Figma MCP，其确定性转译加AI重构...

被老板逼着连前后端一起写，分享我搞定 Figma 设计稿还原的一点心得-腾讯云开发者社区-腾讯云

被老板逼着连前后端一起写，分享我搞定 Figma 设计稿还原的一点心得

被老板逼着连前后端一起写，分享我搞定 Figma 设计稿还原的一点心得

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐