1. 从“拼 UI”到“说 UI”一场工作流的静默革命“自从有了 AI我就再也不想拼 UI 了”——这句话我第一次在团队内部群里看到时差点以为是哪个刚入行的新人在发牢骚。结果点开一看是做了八年客户端的老张。他发了一张截图左边是 Figma 里一张设计稿右边是 Unity 里已经跑起来的界面中间只有一段对话记录。从设计稿到可交互的 prefab前后不到十分钟。这件事对我的冲击挺大的。因为我自己就是从那个“拼 UI”的年代熬过来的。早些年做移动端和游戏客户端UI 搭建基本靠手设计师给一份 PSD我们切图、量间距、对像素、写布局代码一个稍微复杂点的设置面板能拼一整天。后来有了 Figma、Sketch 这类工具切图方便了但“把设计稿翻译成引擎里的节点树”这件事本质上还是手工活。再后来有了各种 UI 框架和可视化编辑器效率提升了一些但核心矛盾没变——设计稿和最终运行界面之间始终隔着一道人工翻译的鸿沟。AI 的出现第一次让这道鸿沟有了被填平的可能。注意我说的是“可能”不是“已经”。现在网上关于 AI 生成 UI 的内容很多但大部分要么是演示性质的玩具要么是营销号吹得天花乱坠、实际一用全是坑。我写这篇东西的目的不是告诉你“AI 万能”而是把我自己这段时间在真实项目里踩过的路、试过的方案、总结出来的参数和技巧原原本本讲清楚。它适合谁看适合那些每天还在跟 prefab 层级、锚点、九宫格较劲的客户端开发适合想把手上的设计稿快速变成可运行原型的独立开发者也适合那些对 AI 辅助工作流好奇、但不知道从哪下手的技术美术和产品同学。核心关键词就几个AI、UI、PSD、Codex、prefab。这几个词串起来就是一条从设计资产到可运行界面的完整链路。下面我按自己的实际经验把这条链路拆开讲。2. 为什么“拼 UI”这件事值得被重新设计2.1 手工拼 UI 的真实成本被严重低估很多人觉得拼 UI 就是个“体力活”没什么技术含量。这话对了一半。单个界面的搭建确实不难难的是规模化和一致性。一个中等体量的 App 或游戏界面数量动辄上百个每个界面里的按钮、列表、弹窗、状态栏加起来是几千个节点。这些节点要保证命名规范统一、层级结构合理、锚点适配正确、不同分辨率下不穿帮——这些事单看每一件都简单但乘以几千之后就是巨大的隐性成本。我做过一个粗略统计在一个五人客户端团队里纯 UI 搭建和调整的工作量大约占整个前端开发周期的30% 到 40%。这还不算设计稿改版带来的返工。设计师改一个间距开发要手动同步到所有相关 prefab漏一个就是线上 bug。这种“人肉同步”的模式本质上是在用人的注意力去对抗熵增迟早会崩。2.2 设计稿到 prefab 的“翻译损耗”从哪来设计稿是静态的、像素级的、视觉导向的prefab 是动态的、结构化的、逻辑导向的。这两者之间的转换天然存在信息损耗。设计师在 Figma 里画一个卡片他脑子里想的是“这是一个可复用的组件”但导出成 PSD 或切图之后这个语义就丢了剩下的只是一堆图层和像素。开发拿到之后得靠自己的理解去重建这个语义——哪些图层该合并成一个节点哪些该拆成子节点哪些该做成 prefab 变体。这个“重建语义”的过程就是翻译损耗的来源。它依赖开发的经验和责任心不同人做出来的结构可能完全不一样。AI 在这里的价值不是替代开发做判断而是把重复性的、有明确规则的翻译工作自动化让开发把精力集中在真正需要判断的地方。2.3 AI 介入 UI 工作流的三种典型姿势目前我实际用过、也见过同行在用的 AI 辅助 UI 方案大致分三类方案类型核心思路代表工具/技术适用场景设计稿转代码识别设计稿图层生成布局代码各类 Figma 插件、视觉模型Web 前端、简单界面自然语言生成 UI用文字描述直接生成界面结构Codex 类代码模型、AI Agent原型验证、快速迭代资产管线自动化批量处理 PSD/切图生成 prefab脚本 AI 识别游戏客户端、规模化项目这三类不是互斥的实际项目里往往是组合使用。我自己的主力方案是第二类和第三类的结合用 Codex 这类代码模型理解我的意图生成结构化的 UI 描述再用脚本把它落地成 prefab。下面重点讲这套方案。3. 核心链路拆解从 PSD 到 prefab 的自动化管线3.1 整体架构三层分离的设计我把整条管线分成三层这样每一层都可以独立替换和调试输入层PSD 文件、Figma 导出、或者直接的自然语言描述理解层AI 模型负责解析输入输出结构化的 UI 描述我用的是一种自定义的 JSON schema落地层脚本读取结构化描述在引擎里生成对应的节点树和 prefab这样分层的好处是AI 只负责它擅长的“理解”和“生成描述”不直接操作引擎 API。引擎相关的逻辑全部由确定性脚本处理出问题容易定位也不会因为 AI 的随机性导致工程文件损坏。3.2 为什么选 Codex 而不是纯视觉方案纯视觉方案直接让模型看设计稿截图生成代码听起来很酷但实际用下来问题不少。最大的问题是精度不可控模型对间距、字号、颜色的估计经常有偏差而且每次生成结果不稳定。对于原型验证够用但对于要进生产环境的 UI返工成本太高。Codex 这类代码模型的优势在于它处理的是结构化文本而不是像素。我把 PSD 的图层信息先导出成一份结构化的清单图层名、位置、尺寸、层级关系然后让 Codex 基于这份清单生成 UI 描述。这样模型的输入是确定的输出也就稳定得多。而且 Codex 对命名规范、层级逻辑的理解比纯视觉模型强很多——它能根据图层名推断出“这个叫 Btn_Close 的图层应该是个按钮”。3.3 结构化 UI 描述的设计要点这是我踩坑最多的地方。一开始我想省事直接让 AI 输出引擎能识别的格式结果发现模型对引擎 API 的理解经常出错生成的代码跑不起来。后来改成中间层设计定义了一套自己的 JSON schema问题就少多了。这套 schema 的核心字段包括{ nodeName: Panel_Settings, nodeType: Panel, anchor: center, size: {width: 800, height: 600}, children: [ { nodeName: Btn_Close, nodeType: Button, position: {x: 360, y: 260}, size: {width: 60, height: 60}, sprite: btn_close_normal } ] }关键点在于nodeType 用有限的枚举值Panel、Button、Text、Image、ScrollView 等不要让模型自由发挥。枚举值越少模型越不容易出错。另外位置信息我统一用相对父节点的坐标锚点单独声明这样落地脚本处理起来逻辑清晰。提示schema 设计时一定要留一个raw字段用来存放模型识别不准、需要人工确认的信息。这样落地脚本可以先把这些节点标记出来而不是直接报错中断。4. 实操全流程一次真实的界面生成记录4.1 环境准备与工具链我用的工具链比较朴素没什么花哨的东西Python 3.10跑 PSD 解析和落地脚本psd-tools解析 PSD 图层信息Codex 接口生成结构化 UI 描述Unity 编辑器脚本读取 JSON 生成 prefab安装依赖就一行pip install psd-tools requestsUnity 那边不需要额外装包用编辑器自带的AssetDatabase和PrefabUtility就够了。4.2 第一步PSD 图层信息提取这一步的目标是把 PSD 里的图层树转成一份扁平的、带层级路径的清单。核心代码大概长这样from psd_tools import PSDImage def extract_layers(psd_path): psd PSDImage.open(psd_path) layers [] def walk(node, path): for child in node: current_path f{path}/{child.name} layers.append({ name: child.name, path: current_path, bbox: child.bbox, visible: child.visible, kind: child.kind }) if child.is_group(): walk(child, current_path) walk(psd, ) return layers这里有个细节要注意PSD 里的图层名往往很乱什么“图层 1 拷贝 3”“矩形 12”之类的。直接丢给 AI 效果很差。我的做法是先跑一遍命名清洗把常见的无意义命名替换成占位符同时把设计师可能用的规范命名比如 btn_、panel_、txt_ 前缀保留下来。这一步能显著提升后续 AI 识别的准确率。4.3 第二步调用 Codex 生成 UI 描述把上一步的图层清单整理成一段 prompt核心是给模型明确的角色和输出格式约束。我的 prompt 模板大致是你是一个 UI 结构分析助手。下面是一份 PSD 图层清单 请把它转换成结构化的 UI 描述 JSON。 规则 1. 图层名以 btn_ 开头的识别为 Button 2. 图层名以 txt_ 开头的识别为 Text 3. 图层名以 panel_ 开头的识别为 Panel 4. 无法判断类型的nodeType 设为 Unknown并在 raw 字段说明 5. 位置信息使用相对父节点的坐标 输出格式[JSON schema 定义] 图层清单[上一步的输出]实测下来规则写得越具体输出越稳定。我一开始偷懒只写了“请识别图层类型”结果模型把一半的图层都标成了 Image。后来把命名前缀和类型的对应关系写死准确率直接上来了。4.4 第三步落地脚本生成 prefab拿到 JSON 之后Unity 编辑器脚本负责把它变成真正的节点树。核心逻辑是递归创建 GameObject设置 RectTransform挂载对应组件最后存成 prefab。void BuildNode(UIDescription desc, Transform parent) { var go new GameObject(desc.nodeName); go.transform.SetParent(parent, false); var rt go.AddComponentRectTransform(); rt.sizeDelta new Vector2(desc.size.width, desc.size.height); rt.anchoredPosition new Vector2(desc.position.x, desc.position.y); // 根据 nodeType 挂载组件 switch (desc.nodeType) { case Button: go.AddComponentButton(); break; case Text: go.AddComponentText(); break; } foreach (var child in desc.children) { BuildNode(child, go.transform); } }这里有个坑Unity 的 Text 组件在新版本里已经被 TextMeshPro 取代了如果你的项目用的是 TMP落地脚本里要换成TextMeshProUGUI。这个细节看起来小但如果不注意生成出来的文字全是空白排查半天才发现是组件挂错了。4.5 第四步人工校验与微调AI 生成的 prefab 不可能一次完美。我的习惯是生成之后先跑一遍结构校验脚本检查几个关键点有没有 Unknown 类型的节点有没有尺寸为 0 的节点有没有锚点设置异常的节点按钮节点有没有挂 Collider 或 Raycast Target校验通过之后再在编辑器里肉眼过一遍。通常需要微调的地方集中在间距的像素级偏差、字体大小、以及一些需要特殊处理的滚动列表。这些微调工作比起从零拼 UI工作量大概只有原来的十分之一。5. 踩坑实录那些文档里不会写的问题5.1 模型对“层级语义”的理解偏差这是最隐蔽的坑。举个例子设计稿里有一个卡片卡片里有一个标题和一个关闭按钮。在 PSD 里这三个东西可能是平级的三个图层。AI 如果只按位置关系判断可能会把关闭按钮识别成卡片的兄弟节点而不是子节点。结果生成出来的 prefab 里关闭按钮不跟着卡片移动一拖动卡片就穿帮。我的解决办法是在 prompt 里加一条规则如果两个图层的包围盒存在包含关系且面积比大于某个阈值则判定为父子关系。这个阈值我试下来 0.6 左右比较合适太小会把相邻元素误判成父子太大又会漏掉真正的嵌套。5.2 九宫格与拉伸适配的处理按钮和面板这类元素通常需要设置九宫格9-slice才能在拉伸时不变形。AI 生成的描述里默认不会带这个信息需要落地脚本根据 sprite 的命名约定自动处理。我的做法是sprite 名字里带_9s后缀的自动设置九宫格边框。边框的具体数值从 sprite 的 meta 文件里读这样不用手动填。5.3 字体与多语言适配的遗漏AI 生成 Text 节点时默认不会设置字体。如果项目里用的是自定义字体生成出来的文字会显示成默认字体视觉上完全不对。我的处理方式是在落地脚本里维护一张字体映射表根据节点的用途标题、正文、按钮文字自动挂载对应字体。多语言适配则是另一个话题简单说就是所有 Text 节点的内容不要硬编码统一走本地化 key。5.4 常见问题速查表问题现象可能原因排查方向生成后文字不显示组件类型不匹配Text vs TMP检查落地脚本挂载的组件按钮点不动没挂 Raycast Target 或 Collider检查 Button 节点的组件配置界面错位锚点或 pivot 设置错误对比设计稿的锚点意图层级混乱AI 父子关系判断错误检查包围盒包含逻辑生成中断JSON 格式不合法加 schema 校验和容错注意每次调整 prompt 或 schema 之后一定要用同一份 PSD 做回归测试。AI 的输出有随机性单次测试通过不代表稳定。6. 这套方案到底省了多少事说点实在的数字。我拿一个中等复杂度的设置界面做了对比测试手工搭建含切图、对像素、调锚点耗时约4 小时用这套 AI 管线从 PSD 到可运行 prefab耗时约25 分钟其中 AI 生成部分不到 3 分钟剩下的是人工校验和微调。效率提升大概在8 到 10 倍。但这个数字有个前提PSD 的图层命名要相对规范。如果图层名全是“图层 1”“图层 2”AI 的识别准确率会大幅下降人工校验的时间会成倍增加。所以我现在跟设计师协作时会提前约定一套命名规范这算是这套方案能跑起来的前置条件。另一个体会是这套方案最适合的场景是结构规整、重复度高的界面比如设置页、列表页、表单页。对于高度定制化、有复杂动效和特殊交互的界面AI 目前还搞不定还是得手工来。所以我的定位很明确让 AI 干掉 80% 的重复劳动我专注在那 20% 真正需要人判断的地方。7. 后续可以继续深挖的方向这套管线目前还是半自动的中间需要人工触发和校验。我接下来想试的方向有几个一是把校验环节也自动化用规则引擎自动修复常见的结构问题二是接入设计稿的变更检测设计师改了 Figma自动触发重新生成对应的 prefab三是把动效描述也纳入 schema让 AI 连动画一起生成。不过这些都是后话。眼下最实际的还是先把命名规范和 schema 打磨稳定让这套东西在团队里真正跑顺。工具再好也得有人愿意用、用得顺手才算数。 
长河君 · 2026/10/6 17:38:44 · 阅读 1.2k AI驱动UI自动化：从PSD到prefab的Codex实践指南
1. 从“拼 UI”到“说 UI”一场工作流的静默革命“自从有了 AI我就再也不想拼 UI 了”——这句话我第一次在团队内部群里看到时差点以为是哪个刚入行的新人在发牢骚。结果点开一看是做了八年客户端的老张。他发了一张截图左边是 Figma 里一张设计稿右边是 Unity 里已经跑起来的界面中间只有一段对话记录。从设计稿到可交互的 prefab前后不到十分钟。这件事对我的冲击挺大的。因为我自己就是从那个“拼 UI”的年代熬过来的。早些年做移动端和游戏客户端UI 搭建基本靠手设计师给一份 PSD我们切图、量间距、对像素、写布局代码一个稍微复杂点的设置面板能拼一整天。后来有了 Figma、Sketch 这类工具切图方便了但“把设计稿翻译成引擎里的节点树”这件事本质上还是手工活。再后来有了各种 UI 框架和可视化编辑器效率提升了一些但核心矛盾没变——设计稿和最终运行界面之间始终隔着一道人工翻译的鸿沟。AI 的出现第一次让这道鸿沟有了被填平的可能。注意我说的是“可能”不是“已经”。现在网上关于 AI 生成 UI 的内容很多但大部分要么是演示性质的玩具要么是营销号吹得天花乱坠、实际一用全是坑。我写这篇东西的目的不是告诉你“AI 万能”而是把我自己这段时间在真实项目里踩过的路、试过的方案、总结出来的参数和技巧原原本本讲清楚。它适合谁看适合那些每天还在跟 prefab 层级、锚点、九宫格较劲的客户端开发适合想把手上的设计稿快速变成可运行原型的独立开发者也适合那些对 AI 辅助工作流好奇、但不知道从哪下手的技术美术和产品同学。核心关键词就几个AI、UI、PSD、Codex、prefab。这几个词串起来就是一条从设计资产到可运行界面的完整链路。下面我按自己的实际经验把这条链路拆开讲。2. 为什么“拼 UI”这件事值得被重新设计2.1 手工拼 UI 的真实成本被严重低估很多人觉得拼 UI 就是个“体力活”没什么技术含量。这话对了一半。单个界面的搭建确实不难难的是规模化和一致性。一个中等体量的 App 或游戏界面数量动辄上百个每个界面里的按钮、列表、弹窗、状态栏加起来是几千个节点。这些节点要保证命名规范统一、层级结构合理、锚点适配正确、不同分辨率下不穿帮——这些事单看每一件都简单但乘以几千之后就是巨大的隐性成本。我做过一个粗略统计在一个五人客户端团队里纯 UI 搭建和调整的工作量大约占整个前端开发周期的30% 到 40%。这还不算设计稿改版带来的返工。设计师改一个间距开发要手动同步到所有相关 prefab漏一个就是线上 bug。这种“人肉同步”的模式本质上是在用人的注意力去对抗熵增迟早会崩。2.2 设计稿到 prefab 的“翻译损耗”从哪来设计稿是静态的、像素级的、视觉导向的prefab 是动态的、结构化的、逻辑导向的。这两者之间的转换天然存在信息损耗。设计师在 Figma 里画一个卡片他脑子里想的是“这是一个可复用的组件”但导出成 PSD 或切图之后这个语义就丢了剩下的只是一堆图层和像素。开发拿到之后得靠自己的理解去重建这个语义——哪些图层该合并成一个节点哪些该拆成子节点哪些该做成 prefab 变体。这个“重建语义”的过程就是翻译损耗的来源。它依赖开发的经验和责任心不同人做出来的结构可能完全不一样。AI 在这里的价值不是替代开发做判断而是把重复性的、有明确规则的翻译工作自动化让开发把精力集中在真正需要判断的地方。2.3 AI 介入 UI 工作流的三种典型姿势目前我实际用过、也见过同行在用的 AI 辅助 UI 方案大致分三类方案类型核心思路代表工具/技术适用场景设计稿转代码识别设计稿图层生成布局代码各类 Figma 插件、视觉模型Web 前端、简单界面自然语言生成 UI用文字描述直接生成界面结构Codex 类代码模型、AI Agent原型验证、快速迭代资产管线自动化批量处理 PSD/切图生成 prefab脚本 AI 识别游戏客户端、规模化项目这三类不是互斥的实际项目里往往是组合使用。我自己的主力方案是第二类和第三类的结合用 Codex 这类代码模型理解我的意图生成结构化的 UI 描述再用脚本把它落地成 prefab。下面重点讲这套方案。3. 核心链路拆解从 PSD 到 prefab 的自动化管线3.1 整体架构三层分离的设计我把整条管线分成三层这样每一层都可以独立替换和调试输入层PSD 文件、Figma 导出、或者直接的自然语言描述理解层AI 模型负责解析输入输出结构化的 UI 描述我用的是一种自定义的 JSON schema落地层脚本读取结构化描述在引擎里生成对应的节点树和 prefab这样分层的好处是AI 只负责它擅长的“理解”和“生成描述”不直接操作引擎 API。引擎相关的逻辑全部由确定性脚本处理出问题容易定位也不会因为 AI 的随机性导致工程文件损坏。3.2 为什么选 Codex 而不是纯视觉方案纯视觉方案直接让模型看设计稿截图生成代码听起来很酷但实际用下来问题不少。最大的问题是精度不可控模型对间距、字号、颜色的估计经常有偏差而且每次生成结果不稳定。对于原型验证够用但对于要进生产环境的 UI返工成本太高。Codex 这类代码模型的优势在于它处理的是结构化文本而不是像素。我把 PSD 的图层信息先导出成一份结构化的清单图层名、位置、尺寸、层级关系然后让 Codex 基于这份清单生成 UI 描述。这样模型的输入是确定的输出也就稳定得多。而且 Codex 对命名规范、层级逻辑的理解比纯视觉模型强很多——它能根据图层名推断出“这个叫 Btn_Close 的图层应该是个按钮”。3.3 结构化 UI 描述的设计要点这是我踩坑最多的地方。一开始我想省事直接让 AI 输出引擎能识别的格式结果发现模型对引擎 API 的理解经常出错生成的代码跑不起来。后来改成中间层设计定义了一套自己的 JSON schema问题就少多了。这套 schema 的核心字段包括{ nodeName: Panel_Settings, nodeType: Panel, anchor: center, size: {width: 800, height: 600}, children: [ { nodeName: Btn_Close, nodeType: Button, position: {x: 360, y: 260}, size: {width: 60, height: 60}, sprite: btn_close_normal } ] }关键点在于nodeType 用有限的枚举值Panel、Button、Text、Image、ScrollView 等不要让模型自由发挥。枚举值越少模型越不容易出错。另外位置信息我统一用相对父节点的坐标锚点单独声明这样落地脚本处理起来逻辑清晰。提示schema 设计时一定要留一个raw字段用来存放模型识别不准、需要人工确认的信息。这样落地脚本可以先把这些节点标记出来而不是直接报错中断。4. 实操全流程一次真实的界面生成记录4.1 环境准备与工具链我用的工具链比较朴素没什么花哨的东西Python 3.10跑 PSD 解析和落地脚本psd-tools解析 PSD 图层信息Codex 接口生成结构化 UI 描述Unity 编辑器脚本读取 JSON 生成 prefab安装依赖就一行pip install psd-tools requestsUnity 那边不需要额外装包用编辑器自带的AssetDatabase和PrefabUtility就够了。4.2 第一步PSD 图层信息提取这一步的目标是把 PSD 里的图层树转成一份扁平的、带层级路径的清单。核心代码大概长这样from psd_tools import PSDImage def extract_layers(psd_path): psd PSDImage.open(psd_path) layers [] def walk(node, path): for child in node: current_path f{path}/{child.name} layers.append({ name: child.name, path: current_path, bbox: child.bbox, visible: child.visible, kind: child.kind }) if child.is_group(): walk(child, current_path) walk(psd, ) return layers这里有个细节要注意PSD 里的图层名往往很乱什么“图层 1 拷贝 3”“矩形 12”之类的。直接丢给 AI 效果很差。我的做法是先跑一遍命名清洗把常见的无意义命名替换成占位符同时把设计师可能用的规范命名比如 btn_、panel_、txt_ 前缀保留下来。这一步能显著提升后续 AI 识别的准确率。4.3 第二步调用 Codex 生成 UI 描述把上一步的图层清单整理成一段 prompt核心是给模型明确的角色和输出格式约束。我的 prompt 模板大致是你是一个 UI 结构分析助手。下面是一份 PSD 图层清单 请把它转换成结构化的 UI 描述 JSON。 规则 1. 图层名以 btn_ 开头的识别为 Button 2. 图层名以 txt_ 开头的识别为 Text 3. 图层名以 panel_ 开头的识别为 Panel 4. 无法判断类型的nodeType 设为 Unknown并在 raw 字段说明 5. 位置信息使用相对父节点的坐标 输出格式[JSON schema 定义] 图层清单[上一步的输出]实测下来规则写得越具体输出越稳定。我一开始偷懒只写了“请识别图层类型”结果模型把一半的图层都标成了 Image。后来把命名前缀和类型的对应关系写死准确率直接上来了。4.4 第三步落地脚本生成 prefab拿到 JSON 之后Unity 编辑器脚本负责把它变成真正的节点树。核心逻辑是递归创建 GameObject设置 RectTransform挂载对应组件最后存成 prefab。void BuildNode(UIDescription desc, Transform parent) { var go new GameObject(desc.nodeName); go.transform.SetParent(parent, false); var rt go.AddComponentRectTransform(); rt.sizeDelta new Vector2(desc.size.width, desc.size.height); rt.anchoredPosition new Vector2(desc.position.x, desc.position.y); // 根据 nodeType 挂载组件 switch (desc.nodeType) { case Button: go.AddComponentButton(); break; case Text: go.AddComponentText(); break; } foreach (var child in desc.children) { BuildNode(child, go.transform); } }这里有个坑Unity 的 Text 组件在新版本里已经被 TextMeshPro 取代了如果你的项目用的是 TMP落地脚本里要换成TextMeshProUGUI。这个细节看起来小但如果不注意生成出来的文字全是空白排查半天才发现是组件挂错了。4.5 第四步人工校验与微调AI 生成的 prefab 不可能一次完美。我的习惯是生成之后先跑一遍结构校验脚本检查几个关键点有没有 Unknown 类型的节点有没有尺寸为 0 的节点有没有锚点设置异常的节点按钮节点有没有挂 Collider 或 Raycast Target校验通过之后再在编辑器里肉眼过一遍。通常需要微调的地方集中在间距的像素级偏差、字体大小、以及一些需要特殊处理的滚动列表。这些微调工作比起从零拼 UI工作量大概只有原来的十分之一。5. 踩坑实录那些文档里不会写的问题5.1 模型对“层级语义”的理解偏差这是最隐蔽的坑。举个例子设计稿里有一个卡片卡片里有一个标题和一个关闭按钮。在 PSD 里这三个东西可能是平级的三个图层。AI 如果只按位置关系判断可能会把关闭按钮识别成卡片的兄弟节点而不是子节点。结果生成出来的 prefab 里关闭按钮不跟着卡片移动一拖动卡片就穿帮。我的解决办法是在 prompt 里加一条规则如果两个图层的包围盒存在包含关系且面积比大于某个阈值则判定为父子关系。这个阈值我试下来 0.6 左右比较合适太小会把相邻元素误判成父子太大又会漏掉真正的嵌套。5.2 九宫格与拉伸适配的处理按钮和面板这类元素通常需要设置九宫格9-slice才能在拉伸时不变形。AI 生成的描述里默认不会带这个信息需要落地脚本根据 sprite 的命名约定自动处理。我的做法是sprite 名字里带_9s后缀的自动设置九宫格边框。边框的具体数值从 sprite 的 meta 文件里读这样不用手动填。5.3 字体与多语言适配的遗漏AI 生成 Text 节点时默认不会设置字体。如果项目里用的是自定义字体生成出来的文字会显示成默认字体视觉上完全不对。我的处理方式是在落地脚本里维护一张字体映射表根据节点的用途标题、正文、按钮文字自动挂载对应字体。多语言适配则是另一个话题简单说就是所有 Text 节点的内容不要硬编码统一走本地化 key。5.4 常见问题速查表问题现象可能原因排查方向生成后文字不显示组件类型不匹配Text vs TMP检查落地脚本挂载的组件按钮点不动没挂 Raycast Target 或 Collider检查 Button 节点的组件配置界面错位锚点或 pivot 设置错误对比设计稿的锚点意图层级混乱AI 父子关系判断错误检查包围盒包含逻辑生成中断JSON 格式不合法加 schema 校验和容错注意每次调整 prompt 或 schema 之后一定要用同一份 PSD 做回归测试。AI 的输出有随机性单次测试通过不代表稳定。6. 这套方案到底省了多少事说点实在的数字。我拿一个中等复杂度的设置界面做了对比测试手工搭建含切图、对像素、调锚点耗时约4 小时用这套 AI 管线从 PSD 到可运行 prefab耗时约25 分钟其中 AI 生成部分不到 3 分钟剩下的是人工校验和微调。效率提升大概在8 到 10 倍。但这个数字有个前提PSD 的图层命名要相对规范。如果图层名全是“图层 1”“图层 2”AI 的识别准确率会大幅下降人工校验的时间会成倍增加。所以我现在跟设计师协作时会提前约定一套命名规范这算是这套方案能跑起来的前置条件。另一个体会是这套方案最适合的场景是结构规整、重复度高的界面比如设置页、列表页、表单页。对于高度定制化、有复杂动效和特殊交互的界面AI 目前还搞不定还是得手工来。所以我的定位很明确让 AI 干掉 80% 的重复劳动我专注在那 20% 真正需要人判断的地方。7. 后续可以继续深挖的方向这套管线目前还是半自动的中间需要人工触发和校验。我接下来想试的方向有几个一是把校验环节也自动化用规则引擎自动修复常见的结构问题二是接入设计稿的变更检测设计师改了 Figma自动触发重新生成对应的 prefab三是把动效描述也纳入 schema让 AI 连动画一起生成。不过这些都是后话。眼下最实际的还是先把命名规范和 schema 打磨稳定让这套东西在团队里真正跑顺。工具再好也得有人愿意用、用得顺手才算数。