企业官网建设流程全解析

1. 这个实验到底在解决什么问题

先说说我为什么要做这个实验。

做了十几年UI开发，切图这件事一直很“反人类”。设计师交付的设计稿通常是一个完整的PSD或Figma文件，开发要自己把图标、按钮、背景、插画一张张导出，还要按1x、2x、3x适配。十年前是这样，十年后还是这样。哪怕现在Figma Dev Mode已经能直接看标注、下载切图，但我们依然需要手动操作——选中一个图层，按导出，选格式，塞进项目对应的目录里。

如果图层有几百个呢？如果只改了某个按钮的hover态呢？如果设计师没分组、命名混乱呢？我敢说，任何一个干过前端或客户端开发的人，都动过“能不能自动把图层全给我切出来”的念头。

于是就有了这次实验的主题：直接用LLM（大语言模型）理解UI设计稿的图层结构，并自动完成切图工作流。

听起来挺魔幻对吧？LLM又不是设计软件，怎么操作图层？怎么导出图片？怎么知道哪个图层是哪个组件？这些问题我一开始也是存疑的，但做完一轮实验之后，我得说——这条路不是“能不能走得通”的问题，而是“怎么走才能走得稳”的问题。

我会在下面把这套方法从原理到实操完整拆开，包括我踩过的坑、重构过的方案、模型真正擅长和完全不擅长的地方。如果你也在研究“LLM Agent + UI设计稿自动化”，这篇应该能给你省下至少两天的试错时间。

2. 我搭的第一版流程：为什么很快就被推翻

第一版方案其实很直觉：用MCP（Model 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、几张图、哪几个按钮需要切。这个过程的本质是一个“语义提取 → 匹配规则 → 批量操作”的三段式工作流：

1. 语义提取：理解页面的布局层次，知道哪里是卡片、哪里是按钮组、哪里是营销位。
2. 规则匹配：根据项目已有的切图规范（比如导航栏图标统一用24pt、颜色用单色可tint），判断每个组件该导出什么尺寸、什么格式。
3. 批量操作：在设计工具里把对应的图层一个个找出来，套用导出设置，批量跑完。

传统切图的另一个隐藏信息是：设计师其实已经把页面“结构化”了。Figma的Frame、Auto Layout、Component Instance，一层层往下嵌套，这本身就是一种带有业务语义的层级树。我党得传统开发切图真正费时间的，不是“找到一个图层并导出”，而是“在几千个节点里快速过滤出需要导出的节点，同时理解它们之间的关系”。

所以LLM的正确用法，不是让它精确计算坐标，不是让它直接操纵设计软件，而是让它处理**“语义提炼 + 规则匹配”**这一段——也就是传统代码里最难写死、最依赖人来判断的部分。真正需要像素级精度的那一步，应该交给程序用设计工具的API去直接处理。

这三段式想清楚之后，我彻底重构了方案。新架构的核心变化就一句话：LLM只做“看懂和决策”，图纸上的精确操作全部交给代码。

4. 第二版方案：LLM只做动脑的部分，精确操作交给代码

第二版的完整链路长这样，我先搭一个总览，后面每一个环节单独拆开细说：

1. 从Figma API拉取文件的节点树，过滤掉无用节点，生成一个精简后的“图层拓扑描述”；
2. 把“图层拓扑描述”用文本序列化的方式喂给LLM，让它输出需要切图的节点列表 + 每个节点的语义标签（是图标、插画、Logo还是背景纹理）；
3. 程序拿到这些节点ID之后，再用Figma API批量设置导出参数并执行切图；
4. 最后把切出的图片按语义标签自动归类放进项目的 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、语义标签、尺寸、色彩模式的记录。同一批节点，我用英文标签和中文标签分别测了一轮，结果还挺意外的。

中文识别率更高，可能是模型在中文语料上的语义联想更强，也可能是中文标签更接近UI设计语境里的默认表达。如果你的目标是高精度，建议先用中文标签，后面再把标签映射成英文文件名。

5.2 耗时与token消耗

处理2600个节点的设计稿，完整跑一次大概需要：

• 拉取节点树 + 压缩：3到5秒
• LLM分析（第一轮 + 自检）：40到60秒
• 批量导出（Figma API）：20到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 2，LLM有能力把二者关联起来，甚至直接替你生成符合工程规范的导出文件名。

6.4 相比传统切图方案的“最后一公里”对比

为了说清楚LLM方案的位置，我做了一个很粗粒度的对比：

表格里“切图精度”指的是首次输出完全满足要求的比例。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?ids=YOUR_NODE_ID"

不过这个原始返回体量极大，不能直接拿去喂LLM。我写了一个压缩脚本，核心逻辑只保留这些字段：

• id—— 节点的唯一标识，最后要通过这个ID调用导出接口
• name—— 节点名，有时本身携带语义
• type—— FRAME、TEXT、RECTANGLE、COMPONENT等
• absoluteBoundingBox—— 只保留里面的width和height
• children—— 递归保留

同时全局过滤掉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 - semanticType（icon / image / illustration / logo / background） - colorMode（singleColor / multiColor） - exportFormat（png / 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子节点，默认不要导出”，这句规则能过滤掉一半以上的误判。这是我反复试出来的性价比最高的一句话。