用LLM自动识别UI设计稿并批量切图：坐标映射与Python脚本全实践

周五下午，设计扔过来一版新的商城详情页，Figma里两百多个图层，嘴里说着“今晚能出吧”。我看着那些嵌套了三层的自动布局、加了特殊阴影的按钮、一个渐变背景拆成四个图层的小卡片，心里清楚今晚大概率又要熬夜手动切图标了。当晚我顺手做了个实验，让手里的大模型直接对着设计稿截图，返回所有可切图区域的坐标和命名，再写脚本批量切出来。

这轮实验的成果很有意思：单纯靠LLM的图像理解能力，确实能识别UI图层的边界、类型和层次，切小图标和卡片区域的效果远超预期，但在坐标精度和重叠图层判断上又确实够不着生产标准。这篇文章会把我的思路、完整Prompt、坐标转换方案、Python切图脚本，以及踩过的坑全部拆开来讲，给同样在做AI提效探索的设计师和前端同学做个参考。实验思路不一定能直接落地到你的工作流，但它足够展示LLM在处理UI视觉结构任务时，能力和边界分别在哪儿。

1. 项目背景与实验动机

1.1 切图这个活为什么让人头疼

做过UI交付的人都清楚，切图从来不是“把图层拖出来导出”这么简单。设计师交付的设计稿里，光是一个按钮可能就拆了背景、描边、文字、阴影四五个图层；一套完整的电商详情页里有商品图、价格文字、标签、按钮、底部栏，每一个区域都得单独切出来给开发用。过去我的流程是：打开设计稿，手动隐藏不需要的图层，框选区域，导出2x和3x两套尺寸，命名成类似btn_buy_now_normal.png的格式，再拖进标注工具里圈出位置。一次完整的页面切图，耗掉两三个小时是常态。

更麻烦的是命名规范。不同设计师习惯完全不一样，有人喜欢叫“矩形1”，有人叫“icon-购物车-48”，前端拿到的资源命名乱七八糟，还要自己猜到底是什么。手动切图本质上是一件高度重复、低创造性、又特别容易出错的机械劳动，但这件活儿对准确率的要求还特别高，切错一个坐标，前端还原页面时就会糊。

1.2 LLM带来的新变量是什么

传统自动化工具解决的是“已经知道要切什么，但不想手动做”的问题，所以要人工先把要切的区域圈出来，工具只负责执行导出动作。但LLM解决的是完全不同的一个问题：它能不能直接看懂设计稿的视觉结构，自主判断哪些区域应该成为独立的切片，并且把切片的语义、尺寸、层级关系一起给出来。

这在两年前是想都不敢想的。过去的图像识别模型擅长的任务是“图里有什么”，给它一张UI截图，它能识别出里面有个按钮、有商品图、有导航栏，但没办法把每个元素的位置和大小精确框出来当作切图坐标。现在的多模态大模型，视觉理解能力和结构化输出能力都上了一个台阶，理论上它能看到整个页面，理解层次关系，然后把坐标、尺寸、类型、命名全部结构化输出。这个能力一旦成立，等于把“看图理解结构”这一步自动化了，切图这个环节的人力和时间成本会大幅下降。

1.3 查了一圈资料之后的判断

正式动手之前，我先花了一个晚上调研目前已有的方案和资料。当时翻了不少关于大模型原理的讨论和实验笔记，留意到几个有意思的点：一是大模型的图像理解本质是“语义空间里的推测”，它不是像人眼一样通过像素去精确定位，而是更像“理解了一个页面大概长什么样，再按语义去猜位置”，这种模式决定了它在粗粒度识别上很强，但在像素级精确上天然偏弱。二是结构化输出对大模型来说属于强项，只要Prompt写清楚要求的JSON格式，它就能稳定返回组织良好的数据。

基于这些信息，我对实验做了一个预判：用LLM直接切图标和色块这种大区域，应该可行；但切尺寸严格、需要像素级精确的资产，大概率会有偏移。实验目标定在不追求一步到位做生产工具，而是先跑通流程、量化能力边界，摸清楚哪些环节可以留给LLM，哪些环节必须靠脚本校正。这个定位让整个实验的路径变得非常清晰。

2. 方案设计与技术选型

2.1 核心设计：让模型输出结构，而不是让它直接裁图

实验最开始我有过一个想法，直接把设计稿截图丢给模型，让它返回一张切好的图片压缩包。试了一次就放弃了，大模型确实可以返回图片，但那是生成的“新图”，不是从原图里切出来的精确像素区域，对于生产来说毫无意义。

后来我把方案改成了一个更务实的架构：模型只负责“理解和规划”，脚本负责“执行”。具体来说，LLM需要输出一份结构化的JSON，里面有每个切片的名称、类型、边界框、缩放建议和层级关系；然后由Python脚本读取这份JSON，把边界坐标映射回原始设计稿，用图像处理库完成裁切、导出。

设计稿截图 -> LLM（理解和规划） -> 结构化JSON（切片坐标+类型+命名） | v 原始高清图 <—— 坐标映射与缩放补偿 —— Python脚本批量裁切

这样设计的核心考虑是让每一步都做它最擅长的事。LLM的强项是语义理解和判断，它知道这块区域应该叫product_image还是price_text，知道哪些图层应该合并成一个卡片；而裁切需要的是像素级精度，这件事交给图像处理库做再可靠不过。模型在虚拟坐标系里输出相对位置，脚本再换算成真实像素，误差控制在自己手里。

2.2 模型选型：三类视觉模型的对比实测

实验里我同时测了三类模型，分别是闭源商业模型、开源社区模型、以及针对视觉任务微调的专用模型。要说明的是，这里的测试结果只是我基于当时API服务的实际表现，不构成权威评测，但方向上对选型有参考价值。

实际跑完一轮后，我的选择是主模型用闭源旗舰模型做语义规划，因为它的命名质量和对复杂结构的判断远超其他两类；坐标精度靠后续脚本补偿。开源模型很适合批量处理海量设计稿的初筛阶段，成本低，但命名和分类结果基本不能直接用。专用模型在这个场景里的定位比较特殊，适合对位置要求高但结构简单的场景，比如单独切图标。

2.3 为什么不能让模型直接返回像素坐标

这里有个非常重要的设计决策：我不让模型在原图纸素坐标系里返回坐标，而是让它在一个0到1000的虚拟坐标系统里工作。

原因很简单，模型看到的输入图通常是经过缩放的。我把1440像素宽的设计稿截图压缩到1024像素甚至更小喂给模型，如果让模型直接返回“x=356, y=728”，它返回的数字是基于缩放后图像的，直接映射回原图会有偏差。更麻烦的是，不同模型对同一张图的内部表示方式不一样，有的模型视觉编码器会把图切成固定网格，像素坐标本身就带上了网格偏差。干脆让模型在虚拟坐标里框选，再由脚本按比例映射，反而更稳定。

原图宽度1440，输入模型时缩放为900。 模型在虚拟坐标系0~1000内返回某个图标的bbox为： { "x_min": 235, "y_min": 600, "x_max": 302, "y_max": 667 } 映射回原图的公式： 真实x = 虚拟x / 1000 * 1440 = 235 / 1000 * 1440 = 338.4 真实y = 虚拟y / 1000 * 设计稿高度（假设2560）= 600 / 1000 * 2560 = 1536

这个换算简单到不能再简单，但它规避了所有因图像缩放和模型内部预处理带来的坐标漂移问题。后面实验数据的偏差控制，很大程度归功于这个“虚拟坐标系”的设计。

3. 实验过程与核心实现

3.1 测试素材准备：怎么挑设计稿最能测出水平

素材选择直接决定实验结论是否可信，我特意准备了四种类型的UI页面：

• 一张PC端数据后台Dashboard，特点是卡片多、表格多、信息密度高，顶部还有侧边导航和多级筛选器，适合测试复杂结构的拆解能力。
• 一张移动端设置页，元素密集但类型单一，有大量的开关、列表项、头像和分组标题，适合测细粒度图标的识别。
• 一张电商详情页，有大图、价格区、促销标签、规格选择、底部固定购物栏，元素大小跨度极大，适合测多尺度场景。
• 一张我故意做了嵌套阴影和半透明叠加层的设计稿，很多图层视觉上是重叠的，适合测试模型对图层物理边界的判断。

这四类页面基本覆盖了日常切图的典型场景。为了让结果对比更有说服力，我还同时准备了一份“标准答案”，所有目标切片区域都是我在Figma里手动框选导出的，坐标用像素级工具标注出来，作为脚本跑分的Ground Truth。

3.2 Prompt模板：把要求写清楚比什么都重要

Prompt是整个实验里性价比最高的优化点，同一个模型，Prompt写不写清楚，输出的可用率能差出三倍。我最终的Prompt模板是反复迭代出来的，核心诉求有四个：输出格式必须严丝合缝、切片类型必须语义化、坐标必须按虚拟坐标系返回、每个切片必须给出置信度。

你是资深UI切图专家。下面会给出一张完整的UI设计稿截图。 请你把这张界面中所有需要单独导出给前端使用的图片资源列出来， 包括但不限于：图标、图片、按钮背景、卡片背景、logo、插画、装饰元素。 要求： 1. 只输出JSON数组，不要输出任何解释性文字。 2. 每一项结构如下： { "name": "英文小写语义化命名，比如product_image、icon_cart_48、btn_bg_primary", "type": "icon | image | button | card | logo | illustration | decoration", "bbox": {"x_min": 0, "y_min": 0, "x_max": 0, "y_max": 0}, "scale_suggest": "1x或2x或3x", "confidence": 0到1之间的小数 } 3. bbox坐标系为0~1000的绝对虚拟坐标，左上角是(0,0)，右下角是(1000,1000)。 请严格按视觉边界框选，不要包含外间距。 4. 对视觉上嵌套的元素，只要它在界面上能看见、能独立使用，就单独列出来。 5. 对于纯文字、分割线、纯背景色块，不需要切图，不要输出。 6. 同一类型、同一尺寸的图标，如果出现三次以上，只输出一次，并在name里加后缀批量标记。 现在请开始分析这张设计稿。

几个细节值得展开说一下。第三点“不要包含外间距”很关键，模型默认会把元素的外边距甚至阴影区域一起框进去，加上这句话后框选结果明显干净很多。第四点解决了嵌套切图的问题，比如一个卡片背景里有张商品图和一个标签，设计上它们可能是同一个父图层组，但切图时卡片背景、商品图、标签要各自独立切片，这句要求就是让模型把嵌套内部的可见元素拆出来。第五点是减少无效输出，裸文字和分割线在CSS里可以实现，不需要图片资源。第六点则是偷懒神器，很多后台界面有几十个同尺寸图标，让模型只输出一个代表再加批量标记，脚本里就能自动生成整批图标。

3.3 坐标补偿与可视化校验：先画出来看再决定要不要切

拿到模型返回的JSON之后，我不会直接拿去切图，而是先做一次可视化校验。脚本会把模型返回的每个bbox画在原图上，生成一张红色矩形框的标注图，我用眼睛快速扫一遍，框的位置准不准、有没有漏掉关键元素、有没有把两块区域合并成一个框，基本一眼就能看出来。

这个环节帮了大忙。第一轮跑完，Dashboard的顶部导航和侧边栏被模型识别得很干净，但页面中间几个卡片，明明视觉边界很清楚，模型的框却明显偏了，右边界多框了一大截，把相邻卡片的边缘也圈进去了。后来排查发现，这几个卡片在虚拟坐标系里的边界本身没问题，问题出在截图压缩后几个卡片之间的留白区域太小，模型在低分辨率下把两个卡片的视觉边界混在一起了。

解决办法分两层。第一层是把截图按区域切块，每块放大后再单独让模型识别，小区域内的相对坐标精度会明显提升；第二层是在JSON里增加了一个padding字段，允许脚本在裁切时做边缘收缩，把模型框选时可能多包含的外边界统一裁掉。

# 可视化校验脚本核心片段 import json import cv2 from PIL import Image, ImageDraw image = Image.open("design_preview.png") draw = ImageDraw.Draw(image) with open("llm_output.json", "r", encoding="utf-8") as f: items = json.load(f) scale_x = 1440 / 1000 # 原图宽/虚拟坐标 scale_y = 2560 / 1000 # 原图高/虚拟坐标 for item in items: box = item["bbox"] x1 = box["x_min"] * scale_x y1 = box["y_min"] * scale_y x2 = box["x_max"] * scale_x y2 = box["y_max"] * scale_y draw.rectangle([x1, y1, x2, y2], outline="red", width=3) draw.text((x1, y1 - 12), item["name"], fill="red") image.save("visual_check.png")

可视化产出之后，我还会跑一个比对脚本，把模型坐标和Figma里手动框的标准坐标求IoU（交并比）。IoU超过0.85的视为优秀，0.7到0.85的视为可用，低于0.7基本就要靠后处理去修了。统计下来，第一轮优秀率只有四成左右，低得可怜，但这也是整个实验最有价值的起点。

3.4 批量裁切脚本：从JSON到PNG的最后一步

可视化校验通过之后，就进入真正的裁切环节。我写了一个Python脚本完成整条流水线：读取JSON、换算坐标、执行裁切、按命名规则保存、输出2x和3x两套尺寸。

import json import os from PIL import Image output_dir = "./slices" os.makedirs(output_dir, exist_ok=True) image = Image.open("design_fullhd.png") img_width, img_height = image.size scale_x = img_width / 1000 scale_y = img_height / 1000 with open("llm_output.json", "r", encoding="utf-8") as f: items = json.load(f) for item in items: box = item["bbox"] left = int(box["x_min"] * scale_x) top = int(box["y_min"] * scale_y) right = int(box["x_max"] * scale_x) bottom = int(box["y_max"] * scale_y) # 边缘收缩修正 shrink = 4 left, top = left + shrink, top + shrink right, bottom = right - shrink, bottom - shrink cropped = image.crop((left, top, right, bottom)) base_name = item["name"] # 1x切图 cropped.save(os.path.join(output_dir, f"{base_name}.png")) # 2x切图（特殊处理） w, h = cropped.size if item.get("type") in ("icon", "logo"): cropped_2x = cropped.resize((w * 2, h * 2), Image.LANCZOS) cropped_2x.save(os.path.join(output_dir, f"{base_name}@2x.png"))

这里有一个值得注意的细节：脚本里只对icon和logo类型做了2x放大，其他类型直接导出1x。原因是UI切片里只有图标和Logo这种矢量类元素需要2x甚至3x的尺寸来适配不同分辨率的屏幕，图片类的切片本身就是位图，设计稿给多大就用多大，强行放大只会糊。这个判断来自Prompt里给模型定义的scale_suggest字段，模型对每个切片都给出了缩放建议，脚本再根据建议决定导出策略。

3.5 首轮跑分结果：看完数据我沉默了

第一轮完整实验一共处理了4张设计稿，模型返回了127个切片项，和人工标准答案对齐后的统计结果如下：

数据能说明几个问题。移动端设置页的表现最好，因为结构规律、元素排列整齐、图标边界清晰，识别率和坐标精度都高。电商详情页差一些，主要坑在商品大图区域，模型经常把一整块商品展示区拆成好几个不存在的切片，或者把促销标签和价格文字合并成一个切片。复杂叠加设计稿直接翻车，IoU只有0.51，说明当图层有阴影、半透明、视觉重叠时，模型的边界判断能力明显不够用。

4. 常见问题与排查心得

4.1 坐标偏移为什么这么顽固

坐标偏移是整个实验里最折磨人的问题。我把每次裁切结果和人工标准坐标叠加后，发现偏移不是随机分布的，而是有系统性的规律：模型框选的位置整体偏向元素中心靠拢，特别是对面积较大的卡片区域，框会“内缩”；而对尺寸较小的图标，框又会“外扩”一点。

这个现象背后的原因，后来我理解为是模型的视觉编码器在处理图像时天然带有注意力中心化的倾向，它“看到”一个元素时会优先聚焦在语义最突出的部分。像一个卡片，模型关注的是里面的大标题和主要图片，对卡片边缘这类低语义密度的区域就不敏感，导致框选范围偏保守。文字和图标这种独立语义元素注意力集中，模型就会把周围的留白也一起算进去，造成外扩。

应对方式我总结出三招。

第一招是区域切块放大。把一张1440宽的设计稿横向切成三段，每段单独送进模型识别，相当于让模型在更高分辨率下“看”局部，框选精度能提升两到三个百分点。第二招是锚点校对，让模型先识别页面四个角落的标志性元素，用它们的坐标反推虚拟坐标系和原图的映射关系，再做一次线性回归校正。第三招最简单也最暴力，针对某一种固定版式的页面，先跑一批数据统计出平均偏移量，直接在脚本里做反向补偿。

4.2 图层命名混乱：模型给的名字能不能直接用

模型返回的命名，第一眼看过去挺像那么回事，但细看问题很多。比如它会给同一页面里的多个商品图都命名成product_image，不会自动加序号；给图标命名时会出现icon_search_blue_large这种把视觉特征全塞进去的长命名；最头疼的是同一个元素在不同轮次实验里可能被命名成完全不同的词，btn_bg_primary和button_background_normal指的根本是同一个东西。

命名问题是这个方案能不能进入生产环境的关键，因为切图资产最终是给前端用的，命名不稳定比切歪几张图更致命。我的解决方案是给模型加了一层“命名词表约束”，在Prompt里附上一份规范化的命名清单，包含动词和名词的可选范围，比如图标必须用icon_开头、按钮类必须用btn_开头、商品图统一叫product_image_序号。加了词表约束之后，命名的稳定率从六成左右提升到了八成以上，虽然还不能完全替代人工审核，但已经减少了大量来回沟通的成本。

4.3 成本与超时：一次完整切图到底花了多少钱和时间

成本问题在实验里无法回避。旗舰模型的单次调用要同时处理设计稿图像和输出一大段JSON，尤其设计稿信息密度很高的时候，输出token数量会暴涨。统计下来，处理一张密集的Dashboard设计稿，单次调用大约消耗1万到1.5万输入token和3000到5000输出token，按当时的API计价，一张图切图过程的视觉理解成本大概在几毛钱到一块钱人民币之间。四张设计稿做完，总花销不到五块钱。

时间上更可控。模型从收到截图到输出完整JSON，平均耗时在10秒到25秒之间，比人工框选快得多。把脚本裁切、可视化校验的时间加起来，一张设计稿全流程大约能在1分钟内跑完，即使加上人工过一遍标注图的时间，也比从零开始手动切快上一个数量级。

不过这里有个大坑：模型对超长JSON的输出容易在中途截断，特别是页面元素特别多的时候，输出到一半断了，整个JSON无法解析。我踩过这个坑后，给脚本加了重试机制，检测到JSON解析失败就自动重发一次请求，并且把Prompt里多加了“继续输出上一轮未完成的List”的指令，勉强把成功率拉回到了九成以上。

4.4 识别幻觉：模型会切出根本不存在的图层

实验里最让设计师崩溃的问题是幻觉。有一次模型对着一张没有底部栏的设计稿，硬是生成了一个bottom_nav_bar，坐标还有模有样地框在页面最底部。还有一次，它把深色页面里的一个装饰性背景纹理识别成了图片资源，但实际上那是CSS渐变就能实现的效果。

这类幻觉有两个主要来源。一是模型对常见UI模式有强先验，它“知道”电商页面应该有底部导航，于是即使截图里没有，它也会“脑补”出来；二是模型对装饰性元素和功能性元素的边界判断不清，它看到一块有纹理的区域就会默认这是资源图片。我的解决方案是在Prompt的负向清单里明确写了“不需要切图的内容”，把纯文字、分割线、背景色块、阴影、线性渐变这些通通列为禁止输出项。效果立竿见影，幻觉产生的无效切片数量下降了将近一半。

另外我也学到一个调参技巧，可以把返回字段里的confidence用起来，设定一个0.55的阈值，低于这个置信度的切片直接丢弃。代价是有时候会误伤真实切片，但比起让前端拿到错资源来说，宁可少切一点后续人工补，也不能多给一堆幻觉资产污染资源目录。

5. 可行性结论与扩展思路

5.1 这套流程的真实能力边界

所有实验数据收完之后，我对“用LLM直接做UI图层切图”的判断是：粗粒度可用，细粒度不可用；内部工具可用，对外交付不可用；辅助可大幅提效，全自动替代还差一条鸿沟。

具体拆开说，边界大概在四种场景里显得特别分明。小尺寸独立元素，比如图标、小按钮、段落的背景块，模型识别率和坐标精度都很好，结合脚本修正后基本能直接用。中等尺寸的语义区域，比如卡片区域、图片占位区、弹窗容器，模型的命中率可观，输出可以作为草稿给人工筛一遍。大尺寸复杂区域和多层叠加的场景，目前能力不足，识别结果即使修了坐标，也难以保证切出来的视觉还原度。最后一类严格规范场景，比如需要逐层叠加阴影、一个按钮切成多层背景资源、或者设计系统里有明确切图规范的，LLM目前完全无法胜任，建议直接放弃。

我自己的判断是，这个方案现阶段最适合的场景是“快速把设计稿变成可用的前端资产草稿”，它能把最烦人的体力活先干完，把设计师从重复劳动里解放出来，让设计师把精力花在整理、规范和校验上，而不是花在框选、命名的原始操作上。

5.2 能落地的三条路径

实验做完后我认真想过落地路径，目前最可行的是三个方向。

第一个方向是Figma插件。在Figma里直接读取设计稿的图层信息和位图数据，调用LLM API生成切图规划，再调用Figma的导出接口把切片输出到本地。这个路径能让设计师完全不离开设计工具，交互最顺滑。严格来说，Figma本身有图层数据接口，既可以把图层树结构发给模型辅助判断，也可以用位图做视觉识别，双通道输入理论上效果比只用截图更好。

第二个方向是UI自动化测试断言生成。切图规划和组件识别能力实际上也是在识别UI结构，这个能力在UI自动化测试里同样成立，模型能帮测试工程师批量判断页面结构是否符合设计稿，自动化测试脚本从“手动写断言”进化成“比对模型结构输出”。实验里的JSON结构化输出，天然就是一份可解析的UI组件清单。

第三个方向是前端代码生成的前置环节。LLM返回的切片不仅包含坐标，还包含类型、层次和命名，这些东西揉在一起，就是一份半成品的页面结构描述。让模型在切图的同时输出每个区块的CSS建议，前端拿到切图的同时也拿到布局草图，开发效率可以再往前提一截。

5.3 后续还能怎么玩：把设计规范喂进去

如果要把这个实验继续深化，我最想做的改进是把RAG接进来。现在的模型完全依赖通用知识做判断，它对“哪些元素该切”的理解是来自海量网页的通用经验，而不是你团队的设计规范。如果把公司设计规范文档、历史切图资产清单、组件库命名规则提前切好块，灌进知识库，再让模型在生成切图方案时先检索匹配的规范条目，输出的命名和分类会更贴合团队习惯。

我在实验里用简单的方式验证过这个方向的有效性。我在Prompt里直接粘贴了一段简短的命名规范和必须切图的元素清单，模型的命名可用率立刻提升了十几个百分点。这说明模型不是不理解规范，而是之前没人告诉它规范是什么。RAG把这件事从手工粘贴提升成了自动检索，效果理论上会更好。

再往后一步想，这类能力还可以和设计稿版本管理结合起来。每次设计稿更新，模型只对比新旧版本的切片差异，只重新切变化的区域，形成增量切图，那效率还能再上一个台阶。这些都是后话，但方向已经通过实验验证了是通的。

跑完这轮实验，我最大的感受是：LLM做UI切图，最强的不是“切图”这个动作本身，而是在切图过程中暴露出来的对页面结构语义的理解能力。它能告诉你这张图里什么重要、什么可忽略、元素之间怎么组织，信息密度远高于一张导出好的PNG。所以就算切图这个任务最终被传统工具或其他方式替代，让模型参与UI结构理解的思路也不会过时。我最后给自己留下了一个习惯：每跑完一批设计稿，把模型识别失败的案例截图存档，把它们当作下一轮实验Prompt里的反面例子。这比调什么参数都管用。