1. 为什么我下决心停止手搓切图一次真实交付的账本先说说让我彻底转变的那次交付。上个月接了一个后台管理系统改版不算复杂一共 40 个页面设计稿在 Figma 里已经排得整整齐齐。按老流程走我第一反应是下午先切图把按钮、图标、背景、卡片全部导出再标注间距拿给前端。结果切到第 8 个页面的时候我就有点绷不住了。每个图标要出 1x、2x、3x 三套命名要对齐设计稿里的图层名有些带透明度的按钮导成 JPG 直接白底穿帮重新导 PNG有些组件的悬停态长得一模一样只有图层列表里多了个小状态我漏导了一张。一上午的时间被这些重复劳动切得稀碎前端还在群里催“切图好了吗没图我没法对间距。”停下来算了一笔账40 个页面手工切图加标注满打满算 20 个小时起步。设计稿里的每一个间距、每一个颜色其实都已经写在 Figma 的图层数据里了——明明信息就在那儿我还要拿眼睛一格一格量、拿鼠标一下一下框选、再导出成图片发给前端。这个过程本质上是在做“信息搬运”而搬运的过程丢失了大量信息颜色值变成像素、圆角变成图片、间距变成说不清的“大概 12px”。所以问题的关键不在于“切图这个动作本身有多累”而在于切图这个交付物根本不该是最终形态。前端真正需要的是能改的图层、能读的样式变量、能直接写进组件的结构化信息。当一波工具能把这些信息直接从设计稿里掏出来的时候继续手搓切图就是纯纯的时间税。也正是这次交付让我把所有能试的方案都试了一遍——AI 截图直转代码、Figma 插件生态、Figma MCP 接口、PSD 解析兜底。这篇文章就是一次完整的方法论复盘把每条路线的适用范围、实测效果、翻车场景、止损方案都讲清楚给正在纠结“要不要继续手搓切图”的人一个参考。2. 三条路线怎么选AI直转、Figma生态、PSD兜底的适用边界先别急着选工具想清楚一件事你要的到底是什么如果你的目标是“从设计稿变成能跑的页面”那路线选择取决于你的设计稿在哪儿、你的技术栈是什么、以及你对还原度的要求有多高。2.1 三条路线的数据流差异所谓“能改的图层”背后本质是数据结构的转换设计稿里的图形位置样式要翻译成 HTML 结构 CSS 规则 组件逻辑。不同路线的区别就在于它用什么方式完成这个翻译。路线输入数据来源输出适合场景还原度AI 直转截图/PNG 图片视觉像素靠模型猜层次HTML/CSS/React 等代码原型验证、简单页面快速生成中等复杂页面不稳定Figma 插件生态Figma 设计稿图层树、样式变量、自动布局组件代码、Tailwind CSS已有规范的设计系统、页面级迁移较高Figma MCPFigma 设计稿结构化 JSON 图片导出AI 生成的整页代码让 AI 读懂设计稿全貌后写代码较高取决于提示词PSD 兜底PSD 源文件图层结构、混合模式、蒙版导出图层 手工还原历史项目、遗留设计文件中等耗时长我自己实测下来搬运效率最高的是 Figma 生态生成逻辑最强的是 AI 直转但两者结合才是完整的解法。下面拆开讲。2.2 Figma MCP 到底能不能“直接切图”热词里有一个高频问题“Figma MCP 可以直接切图吗”。这其实是把 MCP 的定位理解偏了。MCPModel Context Protocol做一个桥梁结构让 AI 模型能读取 Figma 文档里的数据。它不是“一键导出所有切图”的按钮而是一个接口——AI 通过它拿到图层树、拿到每个节点的名字、颜色、坐标、尺寸、约束甚至调用 Figma 的图片接口导出某一层的 PNG。所以严格来说它能在一定程度上替代“手动导出单张图”这个动作但它的价值不在于切图而在于让写代码的一方AI真正“看懂”设计稿的结构。打个比方传统切图是拿一张照片给前端前端看着照片自己量尺寸、猜色值。Figma MCP 相当于把设计稿源文件直接递给前端前端不仅能看还能问——“这个按钮的 hover 态在哪儿”“这组卡片的间距排的是不是 12px”——问完还能自己翻图层列表确认。这一下子就把“图片交付”升级成了“数据交付”。实测体验我用 Cursor Figma MCP 连接一个设计稿让它输出一个商品卡片的 React Tailwind 版本。它读到的图层里商品图的尺寸、标题的字号和行高、价格的颜色值、按钮的圆角半径全都直接填进代码里间距用的也是设计稿里的原始值。我再怎么手搓切图也不可能比它传得更精确。但有个前置条件设计稿本身的图层要规范。如果源文件里全是编了号的“矩形 17”“组 23”MCP 拿到也是一堆没语义的数据。这一点后面实操章节细讲。2.3 AI 直转的玩具与实战界线把一张 UI 截图丢给多模态模型让它生成 HTML这个方向的最大争议在于“它能用但什么时候能用”。我测过 v0、也测过直接把截图发给 Claude/ChatGPT 生成代码。结论是适合中低复杂度页面不适合表格密集、交互复杂的业务页面。原因在于AI 看的是像素不是图层。它能识别“这里有个按钮”“那里有个输入框”但它是靠猜的。遇到两个元素长得像、层级叠在一起、或者栅格系统不明显的场景它会编出结构。比如我拿一张包含多级下拉菜单的截图生成 HTML它给你生成一个完全不存在的 hover 面板结构布局还不对齐。所以 AI 直转适合的场景是快速原型、静态展示页、登录注册页、营销落地页。它的优势是快一张图 30 秒出初稿短板是不稳需要人来兜底修。2.4 PSD 兜底还是得给历史项目留一条后路PSD 格式在互联网大厂的新项目里已经很少见了但老项目、外包项目、还有一些第三方合作方交付物里仍然大量存在。如果你拿到的就是一张 PSD里面的图层命名乱成一团混合模式叠了七八层还有些光栅图层已经扁平化说实话你花在“整理 PSD 图层结构”上的时间往往比重画一遍还久。我的判断标准是打开 PSD 之后先看图层列表如果超过 40% 的图层叫“图层 1 副本 3”“组 2 拷贝 2”或者效果全靠智能对象拼合别挣扎直接按视觉稿重画。你把时间省下来放在还原度校对和组件化上比在垃圾图层里翻找一条描边要值得多。3. 实操记录一张UI图从丢进去到改得动我走的四步这一段是全文最值钱的部分。我完整走一遍“从一张 UI 图到能改的图层”的流程包含我反复调整后最终稳定下来的操作步骤和提示词模板。3.1 前置整理源图准备与命名清洗不管走哪条路线源图质量决定还原度。下面这几点我在每个项目里都会检查一遍截图分辨率要足够至少 2 倍图尺寸避免 AI 识别时把 12px 的字号猜成 14px。去掉水印、浮层、浏览器外框这些会让 AI 误认为它们是页面组成部分。如果是从 Figma/PS 里导出尽量用“选区导出”导出干净的内容区别整张画板带边距一起丢进去。文字图层必须保留真实文本如果是图片里的文字AI 生成出来会乱码或肉眼复刻错字。凡是能调源文件的先花 20 分钟把图层命名清一遍。我常用的命名规范是“类型-名称-状态”比如 btn-primary-hover、input-phone-error。这一套做完后续无论是 MCP 读结构还是插件导出代码产出的语义化程度都高一大截。3.2 提示词怎么给一套可复制的结构化模板这一步是很多人容易忽略的以为丢个截图让 AI“写个页面”就行。实测下来直接说“写个登录页”和用结构化提示词出来的代码质量天差地别。我长时间调优后稳定使用的一套模板结构如下你是资深前端工程师请把附件的 UI 设计稿还原成代码。 技术栈: React TypeScript TailwindCSS 输出要求: 1. 按设计稿的视觉层级拆分成组件不要一整个页面塞进一个文件 2. 颜色使用 Tailwind 的 theme 变量不要硬编码 hex 3. 间距遵循 4px 栅格体系 4. 文本使用设计稿中的真实文案不增不减 5. 图片位置用占位 div 尺寸不引入任何外部图片资源 6. 响应式只需实现 1440px 宽度其他不处理 7. 先输出组件树结构再输出每个组件的代码为什么要写这么细因为模型在代码生成任务里是个“极度听话但缺乏常识的执行者”。你不告诉它间距规则它就会自由发挥你不告诉它颜色走变量它就会把 #4F46E5 写死到每个 class 里。这七个限制条件基本覆盖了还原度最关键的点是我踩了好几轮的坑总结出来的。3.3 从生成物里“拆图层”两种主流做法这里要区分两种“图层”第一种是像素级图层也就是一张设计图被拆成很多张独立的图片素材。第二种是代码级图层也就是把页面结构拆成有层级关系的组件树。我们真正追求的是第二种因为前端改的是代码不是图片。做法一直接把整页视觉稿丢进多模态 AI让它按组件拆。适合单页、简单页面。拆完拿到的是一堆组件代码改起来就是改组件文件比在一张 8000px 高的长图里找元素强太多。做法二用 Figma 插件生成。Anima 和 Locofy 是现在比较主流的两个直接从 Figma 的图层数据生成 React/Vue/HTML 代码。它们读的是真正的数据结构所以输出比 AI 看截图稳定很多。Locofy 的 auto layout 识别和响应式生成做得尤其好但学习成本也在那里——你得先理解 Figma 的 auto layout 原则否则生成出来的代码会多出大量无意义嵌套。我的建议是设计稿规范度高的走插件规范度一般但页面数量少的走 AI 直转都不理想的时候才考虑用设计稿重新制作。3.4 把AI生成的代码“翻译”成项目组件这一步决定产出是能用的代码还是玩具。实际项目里我们几乎不可能把 AI 生成的元素级代码直接提交进代码库。原因很简单项目里已经引入了 Element UI、DaisyUI、Antd 这些组件库直接用原生标签生成的页面样式和交互跟项目整体不一致后期维护是灾难。所以生成之后的“翻译”动作才是关键。我拿一个登录页举例AI 生成出来的是一个 form 标签 input button样式用的是 Tailwind 类。我要做的替换逻辑是form 换成 Element UI 的 el-form继承 label 和 rules 配置input 换成 el-input清空自带的边框样式保留间距和字体大小button 换成 el-buttontypeprimary 覆盖原有颜色变量布局容器用 flex 保留间距值从 AI 生成的样式里抄进组件的 style 或 class整个过程不是重写是按 AI 生成的“布局骨架”来套组件库的壳。AI 帮我确定了尺寸、间距、对齐关系组件库负责交互和状态。这个组合才是最可持续的用 AI 解决“画得准”的问题用组件库解决“活得起来”的问题。4. 拿到图层后怎么验货还原度检查清单与量化标准很多人跑到这步就停了以为代码生成出来就完事。实际上把生成的代码跑起来和设计稿对照才是最能拉开高手和普通人的差距的环节。4.1 量化还原度像素比对方法肉眼比对不可靠两个人看同一处间距能得出不同结论。我用的方法是像素比对用 Playwright 或 Puppeteer 打开生成的页面在 1440px 宽度下截图。把设计稿导出同尺寸 PNG。用 pixelmatch 这类库做像素级对比输出差异热力图。你也可以用简单方法把两边截图放到同一个 Figma 文件里做透明度叠加。透明度调到 40% 之后对齐左上角任何偏移和尺寸偏差都会一眼暴露。这个办法不需要任何额外代码只要会用 Figma 就能操作对设计师尤其友好对前端来说也完全够用。如果页面结构复杂得像信息密集的后台管理界面还可以逐个区块对比而不是整个页面一起看——先对 Header再对侧边栏再对表格最后对弹窗。4.2 可维护性审查不是能看就行有一个很容易忽略的维度生成代码能不能在项目里长期活下来。我见过太多 AI 生成得漂漂亮亮、但维护起来头大的代码。审查的时候重点看三件事类名是否语义化是否重复出现无意义字符串比如 ________ 编号类名。间距是否对齐了项目的栅格体系。如果一个页面的间距一会儿 8px 一会儿 11px说明模型在猜没有读到底层设计规范。颜色是否全部走了 CSS 变量。硬编码的颜色值越多主题切换和品牌联动就越难改。拿 Tailwind 举例如果 AI 生成的全是 text-[#4F46E5] 这种任意值而不是 text-primary 语义类说明它没有真正理解设计系统的 Token 体系。这一步不调整后面换主题色的时候全站都要跟着改成本极高。4.3 交互是否保留静态还原与行为还原是两回事这是整个工作流里最大的一个认知坑。AI 和插件能解决的几乎都是“静态结构还原”也就是元素的位置、大小、颜色、间距。页面真正“活”起来靠的是事件绑定、状态管理、接口联调、路由跳转——这些是不可能从设计稿里直接生成的。图表可视化大屏项目里这个感受尤其明显。AI 可以生成一张仪表盘页面的布局甚至把柱状图的宽高、配色都还原出来但柱状图的数据从哪儿来、点击柱子要不要弹出明细、图表和一个筛选条件的联动逻辑怎么走这些还是要前端一行行写。设计稿里有一个 img 标签指向饼图截图我经常会在页面上给它做“点击跳出图层详情”的交互——这个完全是代码层面的活儿。所以在验收环节一定要区分“静态还原度”和“功能完成度”。前者可以用像素比对解决后者要靠流程测试。验收清单里的交互项建议自己列不要指望工具给你。5. 实测最容易翻车的六个场景和对应的止损方案把所有路线试了一遍之后我整理了一份“翻车清单”。在你满怀期待地把整张设计稿丢进工具之前先看看你的页面有没有命中这些场景。5.1 表格类复杂控件的还原度极低后台管理系统里最常见的表格恰恰是 AI 最不擅长的。表头合并、列宽比例、固定列阴影、行内操作按钮、分页器状态这些东西靠视觉识别很难猜准确。实测下来一个 8 列的表格AI 生成的代码能对上 5 列就算成功其余几列要么宽度乱套要么固定列效果完全没有。止损方案表格类页面不要试图整段生成把生成范围缩小到“单元格内的表单/按钮/标签”级别表格结构本身用组件库的 el-table / DataGrid 搭好AI 只负责填充列配置和单元格内容。这样命中率会高出很多。5.2 深浅色主题与 Token 化需求的隐性成本设计稿里如果只有浅色模式下的一套视觉稿但项目要适配暗黑模式直接生成的代码天然缺少主题变量改起来堪比重构。现在很多组件库和设计系统推 Token 化颜色、字号、间距都走变量AI 对这种规则的理解还停留在“硬编码色值”的水平。止损方案先不管设计稿把项目的主题 Token 体系定义好再在设计稿的关键信息如命名中标记变量的别名让 AI 直接引用。如果设计稿没有关联变量那就在提示词里明确写出每个色值的变量名禁止硬编码。5.3 渐变、磨砂玻璃、光栅效果的瞎猜设计稿里常见的背景渐变、backdrop-filter 磨砂效果、光栅纹理AI 生成代码的时候会做出各种“看起来差不多但实际完全不对”的处理。比如一个带径向渐变的欢迎头图AI 可能会生成一个 linear-gradient 方向完全不同的近似值颜色过渡生硬。透明通道的 PNG 图层即使正确导出导入代码也不能像在 PS 里那样叠加混合模式。止损方案视觉上比较复杂的背景、装饰元素、插画直接导出为图片放到 assets 里不要强行让代码去绘制。代码适合处理几何形状、文字、简单渐变不适合处理光栅细节。这条规则一定要在提示词里写清楚否则 AI 会自作主张给你写一堆 CSS。5.4 中文字体与行高导致的还原偏差这个坑特别隐蔽。英文设计稿用 Inter中文项目用 PingFang SC / Microsoft YaHei同样的字号中文渲染出来的实际宽度完全不同。AI 生成时按照设计稿里的文本长度做自动换行但中文会把容器撑破或者出现大面积空白。行高同理设计稿里如果是 24px 行高中文的实际显示可能需要 26px因为部分字体的 ascent/descent 不同。止损方案生成之前先确认项目中文字体和字号体系直接把字体栈写进提示词。交付之前单独发一个“文本溢出测试页”把这个页面里所有文案都拉长 20%看看有没有破坏布局。5.5 嵌入式/HMI/大屏场景别硬用这套工具链从热词里能看到不少人在搜“esp32-p4 ui 源码”“充电桩显示 ui 开发”“HMI 和 UI”这类需求。这类场景和 Web 前端完全是两套东西目标设备通常是 RTOS 或 Linux LVGL/QTUI 文件是 lvgl 的 .c 文件或 QML 资源屏幕分辨率可能只有 480x272而且没有 GPU 做复杂渲染。工具链再强也生成不了 LVGL 的工程文件也不会自动帮你处理多图层内存占用问题。这类项目的正解是先做设计规范再手工写 UI 层代码。顺便说一句那种需要把一个包含几万个面的矢量底图拆成可配置图层的场景也不属于这个工作流是你 GIS 项目里的中层 GIS 拓扑与数据整理问题只能找对应工具解决设计稿转代码是救不了的。止损方案确认目标平台如果非 Web 端把心思放在“设计稿规范化”和“UI 组件库接口定义”上而不是指望 AI 生成目标代码。5.6 第三方资源引用隐患AI 生成的代码里很容易夹杂它“记住”的在线资源地址比如某张图片直接挂在别人的 CDN 上、某个图标库直接引用了旧版本、某个字体走的是 Google Fonts。一旦目标环境网络受限页面直接白屏。更麻烦的是外部资源也可能在后续迭代中被原作者删掉。止损方案生成的代码里出现任何 url() 外部链接一律替换成本地资源。图片用占位 div 替代图标全部走项目已有的 iconfont 或者组件库内置图标。提示词里就得写明“不引入任何外部资源”这比事后删除省事得多。6. 我的最终结论以及一个偷懒但有效的渐进式迁移方法如果你耐心看到了这里大概率已经在心里盘算“我的项目适不适合这套流程”。我把自己给团队定的铁律写在这儿你可以直接抄新项目、改版项目、原型验证项目优先走“设计稿数据结构 AI 生成 组件库翻译”这套流程老项目、技术栈过旧的项目不推倒重来只在新增页面上局部探索。至于渐进式迁移我的做法是先挑一个低复杂度页面跑通全流程比如设置页面、空状态页面、登录页面。这类页面结构简单、交互少、组件库覆盖度高适合建立团队的初始提示词库和组件替换清单。跑通之后再扩展到表单页、列表页最后才是 Dashboard 信息密集页面。这一路积累下来的提示词模板、像素比对脚本、组件翻译映射表会成为团队最值钱的经验资产。在实际操作中有个体会想多说一句工具不会替你理解需求。Figma MCP、AI 直转、插件生态它们解决的是“把设计稿准确拆成代码”的效率问题但解决不了“这个页面要解决什么业务问题”的判断问题。组件库选型、交互逻辑、数据流设计这些是工具替代不了的人类决策。好的工作流是把工具的效率吃干榨净同时把人的精力从复制粘贴里解放出来投入到真正需要判断的地方去。能停下来不再手搓切图的人不是因为他会用什么高级工具而是他愿意花一个下午把流程跑通、把边界测明白——这个投入长期回报比任何单张切图都值。
