1. 这个实验到底在解决什么问题先说说我为什么要做这个实验。做了十几年UI开发切图这件事一直很“反人类”。设计师交付的设计稿通常是一个完整的PSD或Figma文件开发要自己把图标、按钮、背景、插画一张张导出还要按1x、2x、3x适配。十年前是这样十年后还是这样。哪怕现在Figma Dev Mode已经能直接看标注、下载切图但我们依然需要手动操作——选中一个图层按导出选格式塞进项目对应的目录里。如果图层有几百个呢如果只改了某个按钮的hover态呢如果设计师没分组、命名混乱呢我敢说任何一个干过前端或客户端开发的人都动过“能不能自动把图层全给我切出来”的念头。于是就有了这次实验的主题直接用LLM大语言模型理解UI设计稿的图层结构并自动完成切图工作流。听起来挺魔幻对吧LLM又不是设计软件怎么操作图层怎么导出图片怎么知道哪个图层是哪个组件这些问题我一开始也是存疑的但做完一轮实验之后我得说——这条路不是“能不能走得通”的问题而是“怎么走才能走得稳”的问题。我会在下面把这套方法从原理到实操完整拆开包括我踩过的坑、重构过的方案、模型真正擅长和完全不擅长的地方。如果你也在研究“LLM Agent UI设计稿自动化”这篇应该能给你省下至少两天的试错时间。2. 我搭的第一版流程为什么很快就被推翻第一版方案其实很直觉用MCPModel Context Protocol把Figma文件的内容读出来转成结构化的JSON然后让LLM分析哪些节点需要切图最后用Figma API执行导出。这套思路刚搭完跑通的时候我挺兴奋的。技术上确实能跑通Figma API拉取文件Node树、读取节点坐标和尺寸、判断图层类型是矩形还是图片还是组件这些信息LLM都能“看到”。但它立刻暴露了三个致命问题。2.1 第一个问题它是“看好几百个节点”的一个正常的落地页设计稿展开完整节点树之后节点数量经常是几千甚至上万——光是一个按钮组就有背景层、边框层、阴影层、文字层、图标层加上自动布局嵌套叠嵌套。LLM上下文窗口再大也没法同时处理这么多节点更别提让它在几千个节点里准确判断“哪个是按钮图标需要导出”这件事。我试过只截取顶部N层节点来做缩减结果精度掉得更快。因为真正的组件往往埋在树的中下层切断之后LLM连“这是个卡片还是列表项”都判断不出来。2.2 第二个问题LLM不是设计软件这句话听起来像废话但实操的时候会发现它极其致命。LLM在处理图层关系时把它理解成“文本描述”而不是“空间中的像素集合”。它在处理坐标和尺寸的时候如果节点树下出现旋转、透明度、混合模式、层级遮挡这类属性经常会乱掉。举一个很典型的例子。设计稿里按钮上有一个“播放图标的三角形”这个三角形是一个旋转45度之后的正方形。LLM看到的JSON是rotation: 45, width: 20, height: 20。它在自己的“视觉想象力”里是转过的但不会主动把“导出图片”和“需要旋转”关联起来。它会在回复里说“找到播放图标节点ID是xxx”但导出的图片还是没转之前的原始正方形。这类“视觉推理”的问题在图层切图场景里几乎是一票否决的。2.3 第三个问题坐标与命名的“语义失聪”传统切图流程里我们其实有两个信息能帮你快速判断这是什么图层一是位置相对关系它在按钮内部、跟左侧图标对齐二是设计师是否给了有意义的命名ic_play_24这种。但现实是很多设计稿的图层命名是Frame 18279、Ellipse 4、Rectangle 90位置关系也经常被自动布局打散。LLM在这种信息下会开始“猜”而“猜”的结果往往很稳定地偏离真实情况——它特别擅长把一个偏圆的矩形认成“头像”把一个长条矩形认成“进度条”这种语义联想实际上是它的想象补齐不是视觉判断。结果就是切出来的东西看起来很合理但跟设计稿放在一起对比歪得厉害。第一版方案跑了三天我在反复调prompt、调节点裁剪逻辑、调导出参数最终效果一直卡在“能用但不敢上线”的水准。这套方案最大的问题是——LLM被塞进了它最不擅长的工作里精确的空间计算与像素级判断。3. 重新思考图层切图的本质到底是什么被现实打击之后我停下来想了很久为什么人脑切图很轻松我打开Figma扫一眼设计稿10秒钟就知道这个页面有哪几个模块每个模块里有几个icon、几张图、哪几个按钮需要切。这个过程的本质是一个“语义提取 → 匹配规则 → 批量操作”的三段式工作流语义提取理解页面的布局层次知道哪里是卡片、哪里是按钮组、哪里是营销位。规则匹配根据项目已有的切图规范比如导航栏图标统一用24pt、颜色用单色可tint判断每个组件该导出什么尺寸、什么格式。批量操作在设计工具里把对应的图层一个个找出来套用导出设置批量跑完。传统切图的另一个隐藏信息是设计师其实已经把页面“结构化”了。Figma的Frame、Auto Layout、Component Instance一层层往下嵌套这本身就是一种带有业务语义的层级树。我党得传统开发切图真正费时间的不是“找到一个图层并导出”而是“在几千个节点里快速过滤出需要导出的节点同时理解它们之间的关系”。所以LLM的正确用法不是让它精确计算坐标不是让它直接操纵设计软件而是让它处理**“语义提炼 规则匹配”**这一段——也就是传统代码里最难写死、最依赖人来判断的部分。真正需要像素级精度的那一步应该交给程序用设计工具的API去直接处理。这三段式想清楚之后我彻底重构了方案。新架构的核心变化就一句话LLM只做“看懂和决策”图纸上的精确操作全部交给代码。4. 第二版方案LLM只做动脑的部分精确操作交给代码第二版的完整链路长这样我先搭一个总览后面每一个环节单独拆开细说从Figma API拉取文件的节点树过滤掉无用节点生成一个精简后的“图层拓扑描述”把“图层拓扑描述”用文本序列化的方式喂给LLM让它输出需要切图的节点列表 每个节点的语义标签是图标、插画、Logo还是背景纹理程序拿到这些节点ID之后再用Figma API批量设置导出参数并执行切图最后把切出的图片按语义标签自动归类放进项目的 assets 目录。这套流程看起来好像也没比第一版强多少对吧关键的区别在于第2步和第3步的拆法。第一阶段我把“判断哪些节点要切图”和“执行切图”设计成了两个完全独立的步骤。LLM要做的事情是一个决策行为输出内容是一个清单真正的切图动作被隔离在代码层完全受控。4.1 图层拓扑描述的序列化格式为什么我放弃了JSON第一版我直接喂原始JSON效果很差。其中一个核心原因是JSON树里包含了大量对LLM毫无意义但会占上下文窗口的属性——比如每一个节点的opacity、blendMode、relativeTransform的矩阵数组。这些东西叠加起来真正的结构信息被淹没了。第二版我开始尝试对图层树做**“语义化降维”**把几千个节点压成一棵只保留关键关系的逻辑树。格式上我一开始用JSON但很快发现一个问题JSON的嵌套结构虽然完整但对LLM的长文本理解反而不友好——它在生成时容易把花括号和方括号匹配错一旦某个数组少个逗号整个输出就得重来。我在测试中至少遇到10次“少了一个]导致整段JSON失效”的情况。后来我改用了一种类似缩进树的文本结构项目的DSL看起来是这样的Frame[首页] NavBar[导航栏] Icon[菜单] (filled, 24) Text[标题] (首页, bold) Icon[搜索] (outline, 24) CardList[卡片列表] Card[卡片] x4 Image[封面] (16:9) Text[标题] (2行) Button[按钮] Icon[收藏] (outline, 24)这种格式没有花括号没有方括号本质上是一种可以行的缩进树。重点信息一个没丢层级关系保留了、类型保留了、经典的“有多少重复项”也通过x4直接标出来了。LLM对这种文本的处理稳定性比JSON高出一个量级生成的节点项几乎不出格式错误。这一步的教训就是别迷信结构化格式对LLM一定友好。JSON在程序之间交换很完美但让LLM在生成侧处理JSON缩进树和YAML这类人类易读的格式出错的概率要低得多。4.2 给LLM的“切图规则板子”只有图层描述还不够LLM还需要知道“什么该切”。每个人项目的切图标准其实不完全一样所以我准备了一份“切图规则描述”作为prompt的一部分一起发给它。比如我这个项目里的规则长这样所有Icon节点按1x/2x/3x三套尺寸导出PNG所有Image/封面和插画节点导出原始尺寸的JPG或PNG质量不低于90所有Logo节点导出透明的SVG或PNG透明底必须保留通用的Background/背景纹理节点不导出背景通常由开发写代码或使用九宫格拉伸标签、纯文字、不可见的编组Frame一律不导出。这套“规则板子”最大的价值在于它让LLM从“猜什么是切图”变成了“按标准判断”。规则越明确LLM的输出就越稳定。这一版跑下来它的判断精度明显高了因为它不再纠结“这个矩形是不是页面背景图片”而是直接把信息匹配到规则。4.3 二阶段校验让LLM自己抽检自己切图任务跟代码生成还不太一样代码生成如果错了能立刻看到报错切图错了不对比根本发现不了。所以我加了一个“二阶段自检”的操作——第一轮让LLM输出切图清单之后我会让它再过一遍自己选的节点逐个说一句“为什么这个节点要/不要切”。这一步不是为了真的得到一个可靠结论它的自查当然也可能错而是通过要求它“给自己找理由”把那些“瞎猜”的节点逼出来。实测下来这个自检阶段能过滤掉15%到20%的误判节点。最典型的是把“卡片底色的圆角矩形”当成“需要导出的图块”自查的时候它会发现“这个节点只是背景修饰没有独立语义”——然后自己划掉。这种效果是通过纯逻辑校验很难达成的因为它需要理解UI组件的语义关系。当然自检不是万能的。它不会发现“图标其实应该导出color variant还是original color”这种问题这种是否保留色彩的判断需要更细的钩子——我在提示词里就是这么写的增加一个“色彩模式”字段强迫它在输出每个节点时交代它是“single-color还是multi-color”。5. 实测效果我拿一个中型界面做了完整测试这一版方案搭完之后我拿一个实际项目做了完整测试。被测对象是一个带底部Tab栏、首页Feed流、详情页的简化版内容App设计稿。Figma文件里有三个主要页面整体节点数大概2600个。我先把节点树拉下来做降维压缩后的“逻辑树”输出大概600行——LLM的输入量完全可控。5.1 分类输出英文语义标签 vs 中文语义标签LLM输出的一般是一条条带节点ID、语义标签、尺寸、色彩模式的记录。同一批节点我用英文标签和中文标签分别测了一轮结果还挺意外的。项目英文标签icon, logo, illustration...中文标签图标、Logo、插画...识别准确率87%91%误判率多切或漏切12%8%输出格式稳定性高高中文识别率更高可能是模型在中文语料上的语义联想更强也可能是中文标签更接近UI设计语境里的默认表达。如果你的目标是高精度建议先用中文标签后面再把标签映射成英文文件名。5.2 耗时与token消耗处理2600个节点的设计稿完整跑一次大概需要拉取节点树 压缩3到5秒LLM分析第一轮 自检40到60秒批量导出Figma API20到30秒总耗时1.5到2分钟对比我纯手动用Figma切图同样的量差不多需要半小时到四十分钟。token消耗上单次分析的输入token约1.2万输出token约4000以市面上常见的模型计费标准单份设计稿的成本不超过一块钱。这个成本和节省的时间比基本已经具备工具化的价值了。5.3 错误案例分析它认错的最典型的东西再谈谈误差。这版方案把切图任务的精度从第一版的“没法看”拉到了“可验证”但它依然有稳定出现的错误模式。我自己归纳了一下最常见的三类第一“纯色装饰块”跟“功能图块”的区分还是偶尔会错。尤其是设计稿里用了大面积渐变或者带投影的卡片背景时LLM总觉得这玩意儿需要切图——因为它在视觉语义上“足够像一个独立图层”。但实际上前端根本不需要这张图我们用一个CSS渐变或一张九宫格就解决了。第二对重复组里的“边际尺寸”判断不稳定。头像组件里有三种尺寸小的40x40中的64x64大的96x96。LLM有时会把同一个icon导出三份不同尺寸的重复资产而没有合并成一个可缩放的矢量图。这在连接真实工程的时候会产生资产冗余。第三混合模式的图层依然处理不好。如果设计师做了一个正片叠底的阴影图层或滤色的高光图层LLM很难判断“这个图层是设计过程中的辅助层不应该导出”。它会倾向于把这些全部识别成“有独立视觉价值的图层”。这些问题最后没法靠prompt文字绕过去我是在后处理层加了“黑名单过滤机制”——在Figma API侧对节点类型、混合模式、是否孤立无文字关联做规则过滤。区域LLM给方向规则给精度。无论模型多聪明双层保障都是必要的。6. 哪些场景值得用LLM切图哪些不值得这个方案跑下来我的结论是LLM切图不是所有场景的银弹但它有一块非常确定的“甜区”。先说不值得的场景。如果你维护的是一个很小的项目设计稿每次只切十来个图纯手动20分钟搞定用LLM反而要搭一堆流程那是纯粹给自己找事。再比如游戏UI它的图层组织极度碎片化一张界面几百个切图都是常态而且每个切片都精确到像素、有强制技术参数这种情况LLM的自由度反而是个风险不如直接用写好的脚本工具硬跑。从我的体验来看LLM切图真正的适用场景有几个特征6.1 高频迭代的移动端/Web端UI这类项目的设计文件结构清晰组件化程度高Figma里的Auto Layout和Component用得很普遍。LLM在“语义判断”里最擅长的就是从结构化层级中提取“组件和状态”——按钮、弹窗、导航栏、空状态、图标集这些内容对应到工程里的映射规则稳定而重复。改一个按钮颜色改一行文案刷新一次重新切一轮给到前端同学的就是一份跟版本同步的新资源。6.2 老项目资产整理这是我最推荐试水的场景。很多老项目的资源文件是多年堆积的成果icon1.png、icon2.png、logo_final_v3.png——你根本不知道哪个在用、该用哪个。你用LLM去读设计稿结构让它根据语义把设计稿里的资产和工程目录里的资产做名称匹配或语义对齐比人肉“考古”快得多。6.3 设计与工程规范不一致时的“翻译器”规范是理想现实是设计师经常不用规范的命名。LLM在这个场景里相当于一个“中英翻译语义映射器”前端要求ic_nav_home_selected.png设计稿图层叫Home Icon Active 2LLM有能力把二者关联起来甚至直接替你生成符合工程规范的导出文件名。6.4 相比传统切图方案的“最后一公里”对比为了说清楚LLM方案的位置我做了一个很粗粒度的对比方案适用规模配置成本切图精度维护成本纯手动Figma Dev Mode任意零100%人肉保证零脚本硬编码按命名/位置规则中大型、命名规范中高高但遇命名废稿就崩中视觉识别模型传统CV中大型高中高需大量标注训练高LLM方案语义决策API精确导出中大型、结构清晰低90%到95%需要后处理低表格里“切图精度”指的是首次输出完全满足要求的比例。LLM方案的90%到95%已经让我觉得可以拿来做一次性初始化剩下的5%到10%靠人工兜底。但这里有个核心前提——设计稿本身要有多多少少的“结构性”不能是完全拍平的单图层画布。如果你的设计师习惯“全图层拍平导出”那么LLM的语义精度会大打折扣。7. 手把手复现从Figma拉数据到LLM输出的最小可用配置下面我把这套方案的可复现部分完整给出来。不管你是想直接跑通一条链路还是想拿这段代码改成自己项目的“切图机器人”前半段都很值得读完。7.1 最小化链路Figma API拉取节点树Figma API本身很简单一个HTTP GET就能拿到document的节点树结构。我以官方REST API为例curl -L \ -H X-Figma-Token: YOUR_PERSONAL_TOKEN \ https://api.figma.com/v1/files/YOUR_FILE_KEY/nodes?idsYOUR_NODE_ID不过这个原始返回体量极大不能直接拿去喂LLM。我写了一个压缩脚本核心逻辑只保留这些字段id—— 节点的唯一标识最后要通过这个ID调用导出接口name—— 节点名有时本身携带语义type—— FRAME、TEXT、RECTANGLE、COMPONENT等absoluteBoundingBox—— 只保留里面的width和heightchildren—— 递归保留同时全局过滤掉HTML无关节点COVER、DELETED、隐藏节点visible: false、尺寸为0的节点。这一步压缩之后2600个节点的原始文件能降到500-700行逻辑描述LLM可以轻松处理。7.2 LLM侧的Prompt我的实测模板下面是我用下来效果最稳定的一版prompt结构核心是把“背景信息”“任务指令”“输出格式”三段明确切开你是一名资深UI开发工程师。你将收到一个UI设计稿的图层树描述格式为缩进树。 请仔细阅读图层树根据给定的切图规则筛选出需要切图的节点。 切图规则 - 所有Icon节点导出1x/2x/3x三套PNG - 所有Image节点、Illustration节点导出原始尺寸JPG或PNG - 所有Logo节点导出透明底SVG/PNG - 不作为切图对象的纯文字、背景装饰层、背景纹理层、不可见层、重复的自动布局辅助层 要求 1. 输出一个JSON数组不要任何多余文本。 2. 每个节点包含以下字段 - id - semanticTypeicon / image / illustration / logo / background - colorModesingleColor / multiColor - exportFormatpng / jpg / svg - reason一句话说明为什么需要导出 3. 如果某些节点虽然不在规则里但你认为它们明显属于功能组件的一部分例如按钮里的背景图可以额外标注 suggestExport: true。 图层树 {layer_tree}有几个细节值得特别注意。第一我在prompt里同时挂了一段“非导出示例”而不是只写“导出示例”——这在实践里对降低误判的帮助非常大。第二要求输出JSON数组时我在prompt里写死了“不要任何多余文本”。LLM经常在输出框前面加一句“好的根据我的分析...”这在人看起来没关系但脚本解析会直接崩。这个细微的prompt约束能省下不少后处理。7.3 导出后端用Figma API批量导出LLM返回的节点清单落到代码这边就是一次批量循环curl -L \ -X POST \ -H X-Figma-Token: YOUR_PERSONAL_TOKEN \ https://api.figma.com/v1/files/YOUR_FILE_KEY/nodes/export \ -H Content-Type: application/json \ -d {nodes: [{id: YOUR_NODE_ID, settings: {format: PNG, scale: 2}}]}这一步也没啥技术含量重点是按导出的资产类型做目录归档。我在程序里设计了一套很暴力的映射icon/图标→app/src/main/res/drawable-xxhdpi/image/图片→app/src/main/assets/images/illustration/插画→app/src/main/assets/illustrations/logo/Logo→app/src/main/res/drawable-xxxhdpi/命名上我强制用语义类型_节点名_尺寸.后缀比如ic_menu_24.png、img_banner_750x400.jpg。有了这套归档规则哪怕我完全不看LLM返回的内容也能保证文件结构是干净的。7.4 导出后的文件校验我是怎么快速check的最后聊一下验证。这一步非常关键因为它直接决定了你能不能放心把流程交给脚本。我在切完图之后会在本地自动生成一个export_report.html里面用表格把“每个节点的缩略图、节点名、导出路径、尺寸”排列出来。人只需要花两分钟扫一眼就能看到哪一个图标颜色不对、哪一张图尺寸异常。这个网页我自己用着特别舒服比打开设计稿一层层找快得多。如果你不想做这个至少要加一层尺寸校验检查导出的PNG长度和宽度是否跟Figma API返回的absoluteBoundingBox一致。不一致的节点单独挑出来打log人工二次确认——我测试过程中发现的精度问题大部分都是通过这个方式暴露的。8. 这套方案的边界、成本与我的最终判断文章最后说说这套方案现在到底处于什么水平以及我个人的建议。8.1 三个还没有彻底解决的边界第一个是多状态组件的导出策略。按钮有normal、pressed、disabled三个状态LLM很容易只导出其中一种状态因为它在图层树里看到的可能是三个被命名的兄弟节点但“要导出全部状态”这个要求很难通过规则完全覆盖。这个需要后续在规则层增加“组件状态识别”的能力比如把Figma的variant属性也纳入序列化描述。第二个是图标必须按内容语义去重。同一个“返回箭头”图标设计稿里可能出现了8次每次都是独立图层。LLM会把8个全部导出而工程师其实只需要一个。这种“按视觉内容去重”的能力目前LLM没有天然解决——它不是通过识别像素来去重的而是通过文字和位置。第三个是成本模型极不线性。如果设计稿节点特别多LLM输入token会暴涨而很多模型API对长上下文是阶梯定价。我在测试一份超大型文件时单次token费用比普通文件贵了六倍。如果你的场景是几十个页面批量跑成本要提前评估好。8.2 我的最终建议不要全部自动化要做“半自动审查流”如果你问我会不会把整套流程打包成“一键全自动切图”我的答案是不会。不是因为做不到而是业务的现实是切图从来不只是技术问题它是一个“质量预期的边界问题”。设计稿一改、命名一乱、切图需求一变全自动方案必然出错。所以这套方案我最终落地成的是一个“半自动审查流”LLM生成切图清单 → 自动导出 → 出对照报告 → 人工花两分钟确认 → 提交版本。相当于把原本“花半小时跟自己较劲”的活压缩成“花两分钟check别人做好的活”。这中间省下来的时间才是这套方案真正的价值所在。8.3 它到底有没有未来的可能性做过这么一轮实验之后我的看法是LLM切图的未来不在“完全替代切图师”而在“把切图从体力和校对问题变成一个纯粹的语义映射问题”。现在这套方案已经把90%的重复劳动剥离掉了。再往前走一步当更多设计工具支持把图层树作为更干净的结构导出当模型在多模态方向上真正能做到逐像素级理解设计稿剩下的那10%误差会一点点被抹平。归根结底LLM在这个场景里真正的价值不是“它会切图”而是“它懂设计语言也懂代码工程”。能同时站在两端理解语义的过去只有资深工程师现在算是多了一个不太完美但足够快的竞争对手。如果你也想做类似的实验我建议你从老项目资产整理这种场景开始不要一上来就挑战全自动流程。那会是一段体验相当“分裂”的经历——你会在同一天里既觉得AI牛到不行又觉得它蠢得离谱。但正是这种分裂才说明这套方案已经碰到真正值得解决的问题了。最后分享一个小技巧在prompt里加一句“如果图层名以Frame/Group开头且内部没有Icon或Image子节点默认不要导出”这句规则能过滤掉一半以上的误判。这是我反复试出来的性价比最高的一句话。
