1. 为什么想拿LLM干切图这活传统流程的痛点1.1 切图在传统工作流里到底卡在哪先交代一下背景。我既有设计背景也有前端开发背景日常最烦的一件事就是“切图”。不管是设计师还是开发者应该都经历过这样的流程设计师在Figma/Sketch/PS里画好界面开发打开设计稿用蓝湖、墨刀或者自带的标注插件一张一张把需要的图标、按钮、背景图导出来再按1x、2x、3x的倍率命名好扔进工程目录。听起来不复杂但实际体验极其折磨。折磨点主要在三处。第一图层命名混乱。很多设计稿的图层长这样“矩形副本 8”“未命名图层 12”“组 328”你根本不知道这个图层到底是个返回按钮还是一块空白底色只能一层一层点开看。第二一屏页面可能有几十个需要切出来的元素尤其遇到图标凑成一排但每个都要单独导出的时候光点选图层就要半天。第三尺寸倍率问题。Web端要一套iOS要2x和3xAndroid要dp对应的多套相同的图标得反复导出多次。我掐过表一个中等复杂度的页面从打开设计稿到把所有资源切完、命名好、放进工程手顺也得十五到二十分钟手不顺图层乱到亲妈都不认识四十分钟都有可能。这个痛点存在很多年了行业内也有各种解法。比如组件化设计系统从源头规范图层或者用一些自动化插件批量导出再或者让开发直接用SVG代码而不是切图。但这些方案都有一个前提设计稿本身得比较规范。一旦遇到外面的外包稿、两三年前的旧项目、或者只有一张最终效果截图没有源文件的情况前面所有省事方案全部失效只能回到手动切图的老路。1.2 一个反直觉的猜想LLM能不能“看”图切图我最近一直在研究LLM大语言模型和多模态模型尤其是它们对图像的“理解”能力。说实话现在的视觉语言模型已经能很准确地描述图片内容了一张UI截图上它能看出“顶部有导航栏包含返回按钮和标题”“中间是商品卡片列表”“底部有标签栏”。这让我冒出一个念头既然它能精准描述一个UI里有什么元素那它能不能直接告诉我每个元素在什么位置如果能拿到位置信息切图这个事是不是就自动化了这个猜想最初听起来有点离谱因为切图本质上是像素级操作而LLM是token级模型它根本不直接处理像素它只是“看”了一张压缩后的图片。但是换个角度想切图这个动作其实可以拆成两步第一步是“理解图像里有哪些独立的视觉元素”第二步是“把这些元素按照边界裁剪出来”。第一步恰好是LLM越来越擅长的事第二步虽然不是LLM直接擅长的但只要第一步能输出准确的元素边界框bounding box第二步完全可以用Python脚本或者图像处理库来完成。顺着这个思路我决定做一个小实验拿真实的UI截图喂给多模态LLM让它在无任何额外工具辅助的情况下直接输出各个图层的名称、位置和尺寸然后我用脚本按照它给的坐标裁剪出PNG。整个实验不接入任何传统切图插件完全靠LLM的“眼睛”和“嘴”来走通流程。这个实验如果成功了意味着以后碰到只有一张效果图的老项目也能快速还原出可用的UI资源如果失败了我也能知道边界到底在哪。2. 实验方案设计把“切图”重新定义成“视觉理解坐标输出”2.1 输入与输出的边界先想清楚什么叫“实验成功”做实验最怕的就是目标不明确。我一开始的想法很朴素“让LLM把图层切出来”但什么叫“切出来”其实有歧义。是让LLM输出一张裁剪好的PNG图片还是让LLM告诉我裁剪坐标我自己切还是让LLM直接把一张图里所有可见元素都分离成多层这三种理解的难度天差地别。“直接输出PNG图片”对于多模态LLM来说基本不可能因为目前主流多模态模型的输出模态要么是文本要么是带视觉输入但输出仍以文本为主。而且就算以后有能直接输出图片的模型让它逐像素精确抠图也违背了LLM的设计原理。所以我把实验目标定义为LLM输出结构化的元素清单每项包含名称、类型、坐标和尺寸后续用传统图像处理脚本完成实际裁剪。这个定义下LLM的职责是“视觉理解”和“空间定位”裁剪是确定性算法该干的事。至于成功标准我定了三条。第一条元素识别要准确页面上肉眼可见的独立视觉模块图标、按钮、卡片、图片区域、文本块不能漏掉超过10%。第二条边界框坐标要基本可用人工把框画回原图后边缘误差不超过5像素超出算失败。第三条元素命名要有语义不能输出“图层1”“矩形2”这种废话得能看出这是什么功能。2.2 模型选型与提示词策略实验第一步是选模型。我选用了一个当前效果比较稳定的多模态API模型支持图像输入和文本输出上下文窗口足够容纳一整张UI截图的描述。我也考虑过部署本地模型毕竟有些UI设计稿涉及敏感业务信息不适合传到外部API但本地模型的视觉理解精度目前还是差了一截定位坐标经常偏得离谱所以第一轮实验先用云端多模态模型本地模型留到后面做对比。提示词是整个实验里最关键的变量。我第一版提示词写得很简单就是“请告诉我这张图片里有哪些UI元素并给出每个元素的坐标”。结果返回的内容虽然是标准JSON但坐标是百分比形式而且有些元素它认为“不需要切”比如背景色块导致裁剪结果缺背景。后来我把提示词改成了三段式结构。第一段是身份与任务设定明确告诉模型它是一位资深UI切图工程师正在把一张高保真UI截图拆解成前端可用的图层资源。第二段是输出格式要求严格限定为JSON数组字段固定为name、type、bbox格式为[x, y, width, height]、background_transparent布尔值并且明确“所有坐标必须为正整数以图片原始像素为准禁止使用百分比”。第三段是处理策略引导要求模型“先概述这张图的整体布局再逐块输出元素注意不要遗漏小的图标元素”。这三段式提示词相比第一版成功率提高了很多当然也踩了不少坑这个后面单独写。我还做了一个小技巧在提示词末尾加了一句“如果某个元素与其他元素重叠请把重叠情况在备注字段中说明不要强行切割位于下方的图层”。这句看起来不起眼但直接影响了模型对叠加图层的处理否则它会硬生生把按钮上覆盖的文字和按钮本身切成两个互相重叠的框后续裁剪时全乱掉。2.3 实验环境的搭建细节环境搭建并不复杂核心是一个Python脚本读取本地图片调用多模态模型API拿到JSON输出解析后把坐标画回原图用于人工核对同时用OpenCV根据坐标把元素裁出来。我用的图像处理部分是OpenCV的cv2.imread和数组切片坐标校验部分最容易被忽略因为模型吐出来的bbox有可能越界比如xwidth超过图片宽度或者数值为负。脚本里必须加一层裁剪前校验把所有坐标强制限制在图像范围内否则cv2切出来的图会出现黑边或者直接报错。图像预处理方面我一开始想把大图压缩到模型输入上限比如最长边限制在1024像素以内但后来发现压缩会直接导致坐标偏移因为模型看到的是压缩后的图返回的坐标也是基于压缩图的如果忘了缩放回去裁出来的图全是偏的。这个问题在踩坑部分会详细展开这里先给出结论要么不压缩直接送原图要么压缩后必须记录缩放比并在后处理时还原。我最后选择的是送原图分辨率模型处理速度慢一点但坐标准确度明显更高。验证环节我做了两层。第一层是可视化验证把所有bbox画到原图上生成一张“标注预览图”人眼扫一遍就能看出哪个框偏了、哪个元素漏了。第二层是像素级验证裁剪后检查每张图的尺寸是否大于0背景透明标记是否正确以及被裁区域的平均色彩是否接近预期。这套验证脚本看起来基础但实测帮我发现了很多隐蔽问题比如模型把卡片阴影也算进了卡片本身导致裁出来的图左右两侧各多出一截半透明暗影。3. 第一轮实测布局识别很惊艳坐标偏移让人头痛3.1 结构识别LLM对UI的理解远超预期第一轮实测我挑了一张电商App的商品列表页截图这张图不算复杂顶部状态栏、搜索框、Banner位、一行分类入口图标、四列商品卡片。按要求让模型输出JSON后结果让我挺意外的——结构识别相当准确。它把页面拆成了14个图层元素包括“status_bar”“search_box”“banner”“category_icon_1”到“category_icon_4”以及8张商品卡片的图片区域。名字也起得能看不是“矩形 5”这种而是能直接映射到业务含义的名字。更让我惊喜的是它对元素类型的判断。我在提示词里允许的type字段值包括icon、image、button、text、card、background模型对商品大图判断为image对分类小图标判断为icon对“立即购买”按钮判断为button14个元素只有一个判断错了它把价格文字“99”当成了text但又额外标了个overlaps_withproduct_card_3说明它感知到了文本叠加在卡片上没有强行算成独立不重叠区域。这种“分层感知”能力比我预想的强。不过结构识别准不代表切图能用因为切图最终要落到像素。我当时想如果每个元素的bbox都准就算偶尔命名不准脚本也能兜底。但实际情况是bbox的问题比命名问题严重得多。3.2 坐标定位最大的尴尬在于“看起来差不多”我拿模型给的14组bbox画回原图肉眼一看——大方向全对比如搜索框确实框住了搜索框Banner也框住了Banner。但只要你放大到像素级问题就出来了。第一类问题是边缘误差搜索框这个元素模型给出的矩形比实际搜索框左右各宽了大约4像素把圆角的半透明抗锯齿像素一起框进去了。单独看没什么但真正切出来之后图层的边缘会带上一圈淡淡的背景色放到白色页面上不显眼放到深色页面上就会露馅。第二类问题是圆角图标的老毛病。App首页底部那排分类图标是圆形底图标的形式模型给出的bbox是个正方形正好把这个圆形元素包住。理论上正方形框圆形没问题但问题是圆形四周是透明区域模型没法判断“这个透明区域该不该保留”所以它给的矩形是紧贴圆形内容的而实际切图时我们需要保留一定的安全边距通常是元素尺寸的10%以上否则图标贴到界面上会显得很拥挤。这个“安全边距”的设定模型完全无感它只会按照“视觉上的可见边界”来框而不是按照“设计上的安全区”来框。第三类问题是最要命的——重叠元素。商品卡片上有一层价格文字叠在图片上模型给了文字一个bbox也给了图片一个bbox两个框确实重叠了。如果想要把图片区域单独切出来做普适性资源就必须要“挖掉”文字那一块或者干脆以整张卡片为边界切不要这一层文字。模型给出的JSON里虽然标注了overlaps_with字段但后处理脚本没办法智能决定到底应该保留哪一层、合并哪一层。也就是说bbox输出就算全对重叠图层的取舍逻辑依然得靠人工规则或者更复杂的视觉分割模型来解决。3.3 让LLM直接给“裁剪指令”而不是“图片”既然模型没法直接输出PNG我试了另一个思路让它输出更接近“操作指令”的内容而不是简单的坐标列表。比如让它判断“这个元素是否需要透明背景”“这个图标边缘是否需要留白2像素”“这个区域是否包含圆角是否需要在裁剪后添加圆角蒙版”。这个思路的好处是把设计切图里的隐性经验显性化逼着模型输出除了坐标之外的工程参数。结果喜忧参半。对于“是否需要透明背景”模型判断得相当准它知道图标类元素要透明底照片类元素要铺满。对于“是否包含圆角”它也能从视觉上看出按钮是圆角的所以建议裁剪后加10像素圆角蒙版。但在实际解码时遇到了新问题模型对这些参数的理解经常和设计规范冲突。比如它给一个原本只有6像素圆角的小标签页建议加12像素圆角蒙版理由仅仅是“这个按钮看起来圆角比较大”。这种“看起来差不多”的估计作为人肉切图时的参考还行但直接进自动化管线就属于不精确指令会产出废图。我把这一轮实验结果总结成了三句话结构识别可用粗定位可用精确定位勉强语义化参数不可全信。这也让我意识到如果继续走“LLM直接给出最终可用的切图参数”这条路短期内很难收到完美结果不如换一个思路——让LLM做它擅长的事把不擅长的事交给确定性算法。4. 思路转型LLM做语义标注传统工具做像素裁剪4.1 从“切图”转向“识别标注切片指令”经历了第一轮的“坐标偏移暴击”我开始重新思考LLM在这个流程里到底该扮演什么角色。它最擅长的是语义理解知道哪些元素是一组的、知道按钮和图标的功能含义、知道页面层级关系。它最不擅长的是精确到像素的几何计算。那为什么不把它的“不擅长”剥离出去只保留“擅长”的部分于是实验方向变成了LLM不直接输出裁剪坐标而是输出一份带有语义标注的页面结构描述再由一段确定性脚本根据这份描述结合图像处理算法去生成坐标并裁剪。换句话说LLM负责“告诉系统页面上有什么”系统负责“精确地把它找出来”。这个思路其实和UI自动化测试里的概念非常接近。UI自动化测试框架比如Appium、Airtest之所以能定位元素靠的是底层控件树里的accessibility节点而不是纯视觉识别。如果页面上没有控件树比如面对一张截图自动化测试领域的传统做法就是图像匹配而这个匹配过程恰恰需要人工预先截好每一个元素的模板图。——绕了一圈还是回到了“切图”本身。但LLM提供了一个很关键的新能力它可以先给出元素的语义线索比如“这个按钮的文字是‘立即购买’底色是红色位于卡片右下角”。拿到这些线索后脚本就可以用OCR或者颜色阈值分割等算法精确找到这个按钮的边界而不是让LLM直接编一个bbox出来。这个组合方式在第一轮实验中没有体现因为当时我把所有信任都押在LLM的空间感知能力上事实证明那是它最薄弱的一环。4.2 完整管线LLMOpenCV校验脚本的配合调整后的管线长这样第一步把UI截图发给LLM要求它输出结构化描述重点是每个元素的文字内容、大致区域用“左上/中间/右下”这种粗粒度表述、颜色特征、元素类型。第二步写一段Python脚本针对不同元素类型用不同算法定位文本元素用OCR比如PaddleOCR在LLM给出的粗定位区域内查找文字并计算文本框纯色按钮用颜色阈值分割在指定色相范围内寻找最大连通域图标元素则用边缘检测加上LLM给出的“位于屏幕顶部右侧”这类先验位置缩小搜索范围。第三步把脚本找到的精确边界和LLM给出的语义标签合并成标准切图JSON再用OpenCV裁剪输出。这条管线的核心变化是把“LLM的模糊描述”和“算法的精确定位”做了组合。实测效果比第一轮好很多。拿同一个电商页面来说LLM负责把“立即购买”按钮的语义、文字、相对位置描述出来PaddleOCR在搜索框区域里做识别拿到的文本框比第一轮LLM直接画的bbox准了不止一个量级误差从4到5像素降到了1像素以内。而颜色按钮用HSV阈值分割找连通域边缘误差也在2像素左右。两者一结合切图质量才第一次达到“能直接用”的级别。不过这条管线也不是万能的。如果按钮没有纯色背景、文字颜色和周围颜色接近、图标又是渐变半透明底OCR和颜色分割算法都会失灵最后还得退回人工。但从实验价值来看这已经是一个能落地的组合方式了。我后来把它接到了另一套UI自动化测试的流程里用LLM生成的元素标签反过来辅助自动化脚本做断言效果居然也不错这说明切图和UI自动化在“元素理解”这个层面本质上是在解决同一个问题。4.3 RAG注入设计规范让命名从“能看”变成“能直接用”命名规范在切图里看起来是个小事实际上非常重要。前端工程里图片资源的命名通常要遵循一定体系比如ic_nav_back、btn_primary_pressed、bg_card_shadow而不是button1、icon2。第一轮实验里LLM输出的名字虽然能看懂但风格完全是“自然语言式”的和工程规范对不上。这个问题我用RAG检索增强生成来解决。我把团队的设计规范文档——包括图标命名前缀规则、常用组件部件名称、设计系统里定义的色板值、圆角尺寸梯度——切分成段落放入一个轻量级向量数据库。每次让LLM分析UI截图时先把截图中的元素语义抽取出来用它生成检索关键词把设计规范里相关的片段检索出来和图片一起喂给模型让模型在输出name字段时必须遵循检索到的规范。实测效果非常明显。在没有RAG注入时返回的名字是“blue_rounded_button”注入规范后模型知道蓝色圆角按钮在这套设计系统里叫btn_primary_default紫色渐变叫btn_secondary_gradient。这不是模型本身学会了而是它读了规范文本后“照着写”的结果。对做过前端工程化的人来说这个价值很直观LLM切图之后生成的文件名不需要人工再批量重命名了。RAG在这个场景里不是炫技而是解决“模型不了解项目私有约定”这个核心问题的高效手段。不过RAG注入也有副作用。如果设计规范文档本身写得不够结构化检索出来的文本片段会包含大量无关内容反而干扰模型对UI布局的判断。我的经验是规范文档一定要按“组件类型-命名规则-示例”的粒度拆分并附上示例命名检索效果才稳定。5. 踩坑记录提示词、坐标还原、输出格式三个坑5.1 提示词不写“绝对像素”模型全程给你百分比首先要说的是最坑的一个问题坐标单位。第一版提示词没写明坐标单位模型返回的全部是百分比形式比如bbox是[12.5, 8.3, 25, 30]。百分比坐标本身不是不能用但它有个致命问题模型对“百分比”的感知也是模糊的同一张图让它输出两次两次的百分比可能差出两个点折算成像素就是几十像素的偏移。而且百分比坐标没法直接用于切图必须依赖一个前提——“模型看这张图时的视觉分辨率”这个值如果没有精确获取后处理还原出来的坐标就是歪的。后来我的解决办法是在提示词里强制写一句话“该图片的原始宽度为{width}像素原始高度为{height}像素请以原始像素坐标输出禁止使用百分比。”实测这一句话就把坐标稳定性提高了非常多。但即使这样模型偶尔还是会“自作聪明”。有一次我明明传了1080x1920的图提示词也写了原始尺寸模型返回的bbox却全部落在“缩略图坐标系”疑似它内部处理时自动缩放了图像。最后我不得不在后处理脚本里加了一个“坐标合理性校验”如果返回的bbox最大值小于图片宽度的50%就判定模型使用了压缩坐标系自动乘以缩放系数。这个自动纠偏机制在后来的几十次测试里救了我好多次。5.2 压缩上传导致的“坐标缩放陷阱”这个坑是我个人最想提醒大家的。很多多模态模型的输入接口有图像大小限制比如最长边不能超过2048像素超过就会自动压缩。问题在于模型看到的是压缩后的图返回坐标必然基于压缩后的尺寸。如果压缩比例是0.75真实的x坐标应该是模型返回的x除以0.75。第一次实验时我就是没做这个反向还原用模型给的坐标直接裁剪结果所有元素都偏了而且不是整体平移的偏是越靠右下角偏得越多整个切出来的资源完全没法看。后来我写了个统一的图像处理入口函数先读取原图尺寸再用cv2.resize把图片缩放到模型输入上限内同时记录缩放比拿到模型返回的bbox后所有坐标除以缩放比还原回原图坐标再做裁剪。这一步写完后坐标偏的问题从“系统性发生”变成了“偶发抖动”。如果你也想复现这个实验我强烈建议把缩放还原作为默认逻辑而不是靠模型“自觉”地在原图坐标上工作省得后面白白浪费时间排错。5.3 强制JSON输出比Markdown表格靠谱一百倍最初的提示词版本里我图省事让模型“用Markdown表格输出元素清单”这直接导致后面解析代码写得极其痛苦。Markdown表格里只有字符串没有类型区分所有数字都是文本解析时还要处理竖线冲突、单元格换行、空列一堆问题。更麻烦的是如果元素描述里包含|字符表格结构就崩了一崩就是整页输出作废。而且模型在Markdown表格里的数值经常被截断比如宽度写成24长度写成8不知道它是想要表示小数还是什么。后来我改成强制JSON输出并在提示词里给出JSON Schema示例。但JSON也有JSON的问题最典型的是模型喜欢在JSON外面包一层说明文字比如“根据图片分析结果如下”然后才跟一个代码块。直接解析会失败。我的处理办法是在后处理时加一层文本清理提取第一个{到最后一个}之间的内容作为JSON体再用json.loads解析如果失败就调用一次重试让模型重新输出纯JSON。这套“格式清洗失败重试”机制把解析成功率从70%左右拉到了95%以上。另外提醒一下有些模型参数里可以开启“JSON模式”或“结构化输出”这种情况下模型会严格保证输出格式合法建议优先开启。如果用的本地模型没有这个能力就老老实实用提示词限定后处理清洗的组合基本也够用。6. 实验结果与适用边界LLM切图的能行与不行6.1 什么场景下LLM切图真能用跑完整个实验我的结论是LLM直接切图在特定场景下已经能用但不是所有场景。目前最适用的是那些只有一张最终效果图、没有任何源文件的情况。比如接手的旧项目只有线上页面的截图又急需替换某个图标或按钮资源比如视觉评审时拿到的只是一张设计稿导出图但需要快速做一个可点击的Demo再比如设计师自己用AI生成了一张高保真界面图想快速拆出里面可复用的元素。这类场景的共同点是“没有源文件”传统切图工具完全使不上力LLM反而成了唯一能自动化的途径。但如果你是直接从Figma、Sketch、PS这类设计工具里拿原始图层那LLM切图的意义就不大了。因为设计工具本身就保留了完整的分层信息每个元素的精确边界、透明度、图层名全都现成用插件一键导出比任何CV算法都精准。让LLM去看一张“已经压平”的效果图再猜坐标属于脱裤子放气——多此一举。所以我把这个方案的适用边界定义为源文件缺失时的“考古式”还原而不是日常设计交付的标准流程。还有一类场景值得单独提就是无障碍测试或UI自动化测试里的元素标注。这类场景其实不需要精确到像素的透明背景切图只需要知道“这个按钮在哪个区域、是什么功能”。LLM输出的语义标签加上粗略bbox正好可以当作测试脚本的定位参考。如果配合OCR做文字定位几乎可以替代部分人工标注工作。6.2 和现有工具链的搭配不是替代是互补在实验过程中我也把这套方案和手边的其他工具做了对比心里大概有了一个分工判断。首先是传统切图插件比如蓝湖、Zeplin、墨刀它们处理有源文件的设计稿时体验极好但面对截图就是睁眼瞎。其次是ComfyUI这类图像生成/处理工作流它在像素级图像操作上能力极强比如抠图、放大、风格迁移但它完全不懂UI语义让它判断“哪个ID是返回按钮”等于让厨师修车。最后是纯CV方案比如OpenCV加目标检测模型可以做到像素级精准但需要大量标注数据训练而且换一套UI风格效果就崩。这三类工具加上LLM恰好构成一个互补矩阵源文件场景用插件像素级处理用ComfyUI类工具像素级定位用CV模型语义理解、命名规范、跨风格泛化用LLM。就我目前的实践来看最稳的组合是“LLMOpenCV”各干各的LLM给语义和粗定位OpenCV做像素级精修。如果你想把这个方向产品化不妨考虑把它做成一个插件系统先自动调LLM识别截图产出粗标注再在粗标注基础上用CV算法吸附边缘最后输出带规范命名的切图资源人只需要做最终确认。6.3 这个方向后续值得做的扩展实验进行到后面我其实已经没有再纠结“LLM能不能代替切图师”这个问题了更让我感兴趣的是它暴露出的机会。第一个机会是微调一个专门针对UI组件的视觉语言模型。现在通用模型对UI的理解是“顺带的”如果用一个包含了大量UI截图、组件标注、切图规范的数据集做微调它在图层拆分任务上的表现一定比通用模型强很多。第二个机会是把UI自动化测试里的元素树accessibility tree引入进来。很多App页面在运行时有完整的控件树里面每个元素的坐标、类型、文本都是精确的。如果能用截图和元素树联合训练模型让模型学会“看到这个图标就知道它对应的元素是什么”那未来就不只是切图了整个UI自动化测试的元素定位效率都会提升。第三个方向是把设计系统本身做成可检索资产。设计系统的价值不只是“命名规范”还包括组件层级关系、颜色变量、交互状态。如果这些都能作为RAG数据注入那么LLM生成的不只是静态切图而是带状态说明的组件级资源这比单纯切图高一个层次。另外我测过几个本地部署的模型效果比云端模型差不少但考虑到部分UI设计稿的保密性本地模型还是值得持续关注的尤其是那些专门针对视觉理解做量化压缩的版本。如果能在本地拿到接近云端的定位精度这个方案离生产环境就已经不远了。我个人在这个实验里最大的收获其实不是搞出了一套切图方案而是搞清楚了“把一个人看起来很简单的任务拆给AI做”时真正的分工逻辑。切图这个活人做的时候是“看结构定边界起名字”三个动作一体完成的而AI做的时候必须拆开让不同的子模块负责各自适合的动作。把这一点想明白了以后落到任何“LLM专业工具”类项目里都会少走很多弯路。如果你也想复现这个实验建议从最简单的单卡片截图开始跑通管线再逐步加复杂度中间遇到坐标偏了先检查缩放命名乱了再上RAG一步步来很快就能看到效果。