Huolala Figma MCP 原理与实践
一、背景
1.1 UI编程痛点
客户端工程师们大概没少花时间在重复还原UI视觉稿这件事上——统计下来,UI开发耗时能占到移动端总开发时间的三分之一。这可不是个小数目。
具体痛点有哪些?
- :大量重复劳动,开发速度极慢。按钮、卡片、间距、阴影、圆角……每个都要手写一遍,复制粘贴改参数,纯粹是体力活。对齐、居中、间距差1px,就得反复改、刷新、看效果,循环往复。
效率低下
- :安卓、iOS、鸿蒙三个端,UI代码要分别维护,工作量直接翻倍。
多端维护
- :光靠眼睛和经验去还原设计稿,很难做到1:1精准,走查时间花得一点都不少。
视觉还原度低
1.2 AI技术飞速发展
自从2022年底ChatGPT发布以来,Agent、MCP、SKILLS等一系列AI技术接连涌现。传统的手写UI代码已经跟不上AI编程的节奏了——行业在变,工具也得跟着升级。
二、现有技术方案
目前开发团队主要用以下几种方式生成UI代码,但每种都有明显的短板:
| 方案 | 转码语言 | 开源 | UI还原度 | 自动切图 | 原理 | 缺点 |
|---|---|---|---|---|---|---|
| figma插件+低代码平台 | 支持H5、RN等Web语言,不支持Kotlin、Object C等原生客户端语言 | 不开源 | 较高 | 有 | figma插件提取UI信息后规则转码,低代码平台编辑和预览 | 生成的代码灵活性和语义化差 |
| 图片输入+多模态大模型 | H5、RN、Object C、Swift、Kotlin等 | 部分开源 | 比较低 | 基本不可用(原始设计稿) | 利用多模态大模型识别图片中的UI细节 | 还原度最差,无法精确还原设计稿属性 |
| 开源figma context mcp | H5、RN、Object C、Swift、Kotlin等 | 开源 | 高 | 复杂图层切图大小不对,正常情况可用 | 调用RESTful API提取关键信息,合并相同属性后送大模型转码 | 没有融合多模态大模型,对循环组件分组处理不理想 |
| figma官方MCP | H5、RN、Object C、Swift、Kotlin等 | 不开源 | 高 | 部分case切图不对(原始设计稿) | 同时获取设计稿JSON信息+截图,调用多模态大模型融合 | 复杂页面还原度差 |
| 百度自研F2C | H5、RN、安卓、iOS、鸿蒙、小程序等 | 不开源 | 高 | 支持 | 自研F2C插件+自研大模型 | 不对外开放 |
产品定位:UI开发日常必备工具
为了弥补上述方案的不足,我们自研了
Huolala Figma MCP
- :通过独家图层清洗和精简算法,在复杂/不合理的设计稿上实现更高还原度
高UI还原度
- :自研icon识别算法,能同时导出2x、3x多倍切图,满足多个平台场景
准确切图
- :一键安装到Cursor,无需手动配置,SSO登录即用
便捷使用
- :提供prompts模板、SKILLS,可开箱即用,也可自由组装定制
高扩展性
- :支持React、Vue、Objective-C、Kotlin、React Native等
多语言支持
三、Huolala Figma MCP 原理
3.1 MCP整体架构
主要功能模块:
- :分析用户输入的提示词,提取figma url等关键参数,转换成MCP工具需要的参数
用户输入参数提取
- :通过Figma REST API获取设计稿的节点信息、图层结构、样式属性等原始数据
获取Figma数据
- :通过独家算法对Figma图层进行清洗,去除冗余图层,处理不合理的autolayout,优化图层结构。同时自动识别设计稿中的ICON,去重后导出
AI服务
- :根据用户需求动态加载对应的Skills(如循环组件调整、转码风格适配等),最后将HTML、切图等产物交给智能IDE,结合用户提示词生成目标语言代码
智能IDE转码
3.1.1 MCP功能
| 类型 | 名称 | 说明 |
|---|---|---|
| Tool | figma_to_code_package | 获取Figma设计稿数据,返回包含HTML、切图资源、字体、多模态数据的ZIP包 |
| Prompt | ui2code_with_skills | 预设的提示词模板,一键触发完整转码流程,适合全线界面或UI模块 |
| Prompt | get_figma_property | 获取Figma节点的属性,用于局部UI界面修改 |
| Resource | Skills列表 | 内置多种Skills资源,支持按需加载 |
3.1.2 产物说明
Huolala Figma MCP返回的ZIP包包含以下产物:
| 产物 | 说明 |
|---|---|
| index.html | 通过规则转码生成的精确还原页面,可作为大模型转码的参考基准。包含图层、布局、样式等完整信息 |
| vlm_result.json | 多模态大模型对设计稿的理解结果 |
| images_2 / images_3 | 2x和3x倍率的切图资源,语义化命名 |
| fonts | 导出的字体文件 |
3.1.3 Skills机制
Huolala Figma MCP内置多种Skills,实现功能的可扩展性:
- :循环组件调整,自动识别列表/网格布局
adjust-list-group
- :支持React、Vue、Objective-C、Swift、Kotlin、React Native等
多语言转码
用户还可以自定义Skills,满足个性化需求,如图片压缩、上传CDN等。
3.2 AI算法服务
算法服务涉及的技术点很多,下面挑几个重点来解析:
3.2.1 列表识别与合并
列表识别一直是UI组件识别的难点——循环组件样式多样,传统的规则算法只能处理简单场景,复杂场景就会变成case by case的问题,逐个适配成本太高。所以我们采用了多模态大模型来识别循环组件,再编写Skills让智能IDE自动处理层级。
1)多模态大模型提示词
识别UI结构,输出前端可用json结构,要求包含x,y,width,height,type,text(如有),children(如有)字段
{"type": "tabBar","x": 0,"y": 768,"width": 375,"height": 44,"backgroundColor": "#FFFFFF","items": [{"text": "首页","icon": "home","x": 28,"y": 770,"width": 40,"height": 40},{"text": "订单","icon": "order","x": 108,"y": 770,"width": 40,"height": 40},{"text": "消息","icon": "msg","x": 188,"y": 770,"width": 40,"height": 40},{"text": "我的","icon": "my","x": 268,"y": 770,"width": 40,"height": 40}] }
2)列表Skills编写
对横向、纵向、网格排布的列表分别进行识别与处理。
---name: adjust-list-layout
description: 根据vlm_result.json识别JSON文件中的列表控件,并调整HTML代码中的布局结构,使其更符合语义化和响应式布局要求。
---
# 调整列表布局层级
根据JSON布局描述文件识别列表控件类型(横向、纵向、网格),并自动调整HTML代码中的布局结构。
## When to Use
- 当需要将设计稿转换后的HTML代码进行布局优化时
- 当HTML中的列表元素层级结构不合理时
- 当需要将平铺的元素转换为语义化的列表、表格或Flex布局时
- 当存在`vlm_result.json`等布局描述文件,需要据此调整代码结构时
## Instructions
### 参数说明
| 参数名 | 类型 | 默认值 | 说明 |
|--------|------|--------|------|
| `json_file` | string | `vlm_result.json` | JSON布局描述文件路径 |
| `code_file` | string | `index.html` | 需要调整的HTML代码文件路径 |
### 前置条件
- 检查`${json_file}`是否存在(可选,不存在则跳过JSON相关步骤)
### 第1步:识别列表控件
从`${json_file}`中找出列表控件,判断条件如下:
| 列表类型 | 判断条件 |
|----------|----------|
| 横向列表 | 子元素的y和height一致;或者两组交错y和height一致的元素交错排列 |
| 纵向列表 | 子元素的width和x坐标都一致;或者局部连续的元素width和x坐标相同,且子元素的结构相似 |
| 网格列表 | 子元素height相同,存在多行,同行y坐标相同 |
### 第2步:控件匹配
遍历列表控件,在`${code_file}`中进行控件匹配:
- **横向列表匹配**:找到`${code_file}`中一个容器,其包含的文本大部分都能与横向列表元素匹配成功
- **纵向列表匹配**:找到`${code_file}`中一个容器,其包含的文本大部分都能与纵向列表元素匹配成功
- **网格列表匹配**:将网格拆成多行,逐行文本匹配,每行中的文字大部分都能匹配成功
### 第3步:调整布局
将原始`${code_file}`备份为`${code_file}.backup`,然后修改`${code_file}`调整布局。
#### 3.1 横向列表调整
| 子类型 | 处理方式 |
|--------|----------|
| 交错列表 | 将`${code_file}`中相邻的交错元素用一个新容器进行包裹和分组,变成标准横向列表 |
| 带分割线列表 | 如果横向列表元素中包含垂直分割线,且分割线和其他元素间隔分布,则将分割线提取出来,剩余的元素包裹容器宽度进行等分,内部元素垂直居中 |
#### 3.2 局部纵向列表调整
如果`${code_file}`中的局部纵向列表元素未被包裹,用一个新容器将这些元素包裹起来。
#### 3.3 网格列表调整
> ⚠️ **必须按顺序判断**
如果`${code_file}`中每一行的文本匹配到的容器都不一样,将这些容器合并成一个大的网格布局:
| 判断顺序 | 类型 | 条件 | 处理方式 |
|----------|------|------|----------|
| 1 | 表格 | 行列元素间距都 ≤ 2px,且同一列的元素宽度相同(误差 ≤ 1px) | 不要用flex-wrap: wrap布局,改成``结构 |
| 2 | 折行布局 | 不满足表格条件(不同列元素宽度不一致) | 采用`display: flex; flex-wrap: wrap`,并计算设置`row-gap`和`column-gap` |
3)列表识别与合并结果截图
3.2.2 红点和气泡识别
在前面列表识别时,经常碰到一些红点和气泡,做循环组件分组时需要单独剔除。红点气泡样式很多,而且部分红点非常小,通用多模态模型对于小尺寸的红点和气泡组件识别准确率不高。为此,我们专门训练了一个基于YOLO的小模型来做红点气泡识别。
采用目标检测模型YOLO v8,自己标注数据并人工合成数据集,训练了红点和气泡识别模型,识别准确率超过90%。识别案例如下:
3.2.3 icon识别
原始设计稿中的icon由多个矢量图形组合而成,开发期望导出成一个图片放到代码中。目前的多模态大模型、开源的figma context mcp和官方的figma mcp都无法精确导出这种需要合并的icon。我们采用
控件属性+几何特征+元素排布
的方式,对icon进行识别与合并。算法流程如下:
在打包阶段,还会对图标进行像素级相似度检测,去除重复的图标图片。
3.2.4 图层清洗
两个大小一模一样的图标叠加在一起。设计稿中会出现一些开发不可见、但存在于设计稿中的冗余元素或图层。比如上图中圆形头像下面盖住了一个大小一模一样的图层。
我们采用投影方法,得到一个控件树不可见图层的层级序号矩阵。如果一个控件区域的投影矩阵值的最小值大于当前层级序号,表示被完全覆盖,可以删除。投影时还要考虑透明、圆角的情况。
3.2.5 布局计算
设计稿中存在很多布局方式不合理的情况。例如图中8个元素原本应该是一个分组,内部用折行或网格布局实现,但设计稿中用了多个行布局组成,因此需要进行布局识别,根据不同局部类型重新计算布局。
类别 方案选型 图示
网格类别 多行相同列表合并成网格布局计算
红点气泡 绝对定位
底部tab栏 绝对定位
分散对齐识别 flex布局
宽度自适应容器识别 flex布局
文本宽高去除 结合文本渲染宽度、容器宽度、是否多行、左右间距等综合去除
分割线处理 分割线分组,转成bottom_line属性
左中布局 flex+绝对定位布局
重叠布局 flex+绝对定位
四、Huolala Figma MCP 实践
4.1 同类方案对比
原始设计稿 多模态大模型 开源figma context mcp figma官方MCP 货拉拉figma MCP
首页 1.图标不对
2.顶部背景渐变色不对
3.输入卸货地下单渐变色边框不对 1.气泡布局处理不对
2.冷藏车的布局不对
3.顶部渐变背景和标题排布错乱
4.对多层嵌套的边框处理不好 1.右上角图标不对
2.“啥车都有都便宜”没有加粗字体
3.选车地址图标不对
4.我的图标拉伸了 叫车流程字体不对,其他基本还原
4.2 具体业务实践
目前已经在货拉拉企业、司机、专送、多拉等多个业务中落地使用。下面以其中一个业务的应用举例说明:
场景 手写耗时 Huolala Figma MCP 耗时 提示词
新页面 0.5天 2分钟 /user-mdap-u2c/ui2code_with_skills url链接[2x,3x] 转码风格:这个半屏弹窗用EBaseBottomModalView实现,代码入口:点击"车长车型"单元格后弹出这个页面
原有页面上新增一种卡片样式 30分钟 2分钟 /user-mdap-u2c/get_figma_property url链接生成一种新的单元格样式,切图同时导出2x,3x,参考当前目录的资源存放方法
2. 当用户点击了零担拼车后,将价格样式从EConfirmOrderOptionPriceCell换成前面的新样式。
3. 用户点击新样式上的"查看【快车】等更多价格"单元格样式切回EConfirmOrderOptionPriceCell
界面上新增一个按钮 10分钟 1分钟 1.修改viewWithCommodityModel,当model.title=="零担拼车"时,进入零担拼车显示模式,初始化gotoUserBtn按钮
2.按钮的UI细节通过/user-mdap-u2c/get_figma_property url链接获取
实际业务中,不同项目、语言风格差异很大,除了Huolala Figma MCP提供的能力,业务还会自己定制Skills、Commands、Rules来适配自己的业务。
4.3 多语言转码
Huolala Figma MCP支持多种语言转码,目前在H5、Objective-C、Swift、Kotlin、React Native语言上均有落地经验,还原度都比较高。
目标语言 原始设计稿 转码结果
H5
Objective-C
Swift
Kotlin
React Native
五、小结
5.1 成果总结
Huolala Figma MCP结合Cursor后功能大幅提升,不仅可以应用于新增页面,也能用于局部UI改版,在写UI代码的同时还能顺带生成逻辑代码。
它补齐了三方MCP在复杂设计稿UI还原差和切图不对的问题,还能自定义Skills实现个性化功能。
5.2 经验与不足
新增页面
:提示词相对简单,提效明显,界面总体还原度高
局部改版
:UI占比小,逻辑部分占比更重,提示词会相对复杂,微调更多
工程适配
:图片存放路径、组件实现偏好等需要手动指定,增加了提示词复杂度
5.3 后续优化方向
自动分析工程组件
:能够自动分析用户工程的组件实现和使用偏好,减少指定基类、图片存放路径的提示词
界面自动定位
:能自动分析用户界面,定位到某个设计稿界面对应的类实现
Skills扩展
:支持更多个性化需求,如图片压缩、上传CDN等
视觉还原度计算
:自动计算生成代码与设计稿的还原度差异,实现UI代码自动生成和自动验收闭环
参考资料
github.com/glips/figma…
help.figma.com/hc/en-us/ar…
docs.ultralytics.com/
modelcontextprotocol.io/docs/gettin…
agentskills.io/specificati…