接手一套新 UI 的时候最让人头疼的往往不是设计稿看不懂而是同样的还原工作每次都要重做一遍。打开 PSD对着图层挨个创建 Image、Text、Button调整 Anchor 和 Offset再把所有节点拖进脚本里绑定字段。一个中等复杂度的界面光是把“图”变成“能跑的预制体”就要花掉大半天。Unity ETYIUI 这类 PSD 转 UI 工具瞄准的正是这个环节。但用下来我更想强调一个判断它真正改变的不是“导出图片”这一步的速度而是设计和代码之间那层翻译从纯手工变成了半自动化的工程问题。如果只把 ETYIUI 当成“自动导出工具”你大概率会失望因为设计稿不规范时生成的结果一样要手动改。但如果把它理解成“把设计稿结构化、再把结构变成预制体和代码”的流水线你会发现值得花时间研究的点非常多。1. 它真正要解决的问题是把设计稿翻译成代码这件事1.1 UI 还原工作为什么总是重复且容易出偏差手工还原 UI 的过程看起来只是一些机械操作把图片拖进场景、设置尺寸、摆放位置、绑定脚本。但实际操作中每个人都遇到过同样的偏差PSD 里一个按钮的圆角背景到 Unity 里位置对不上设计稿上的字号和实际运行效果差一截以为对齐了打包到不同分辨率上又偏移了。这些偏差不是某个人粗心造成的而是手工翻译本身就不稳定。每张图、每个节点、每个锚点都是人眼判断、手动填数项目越大偏差积累越多。更麻烦的是这类工作特别消耗注意力却不产生新的认知。一个做了三年 UI 的开发者和一个刚入职的实习生在“还原 PSD”这件事上的效率差距可能只有一倍但出错率却差不多——因为它本质上是一道“照着抄”的题抄得再熟练也还是会抄错。1.2 从 PSD 到 Unity UI本质是一场结构化翻译如果你把 PSD 文件拆开看它其实不是一张“图片”而是一棵完整的图层树分组、子图层、坐标、尺寸、透明度、混合模式全都写在文件结构里。Unity 的 UI 系统同样是一棵树Canvas 下的节点、RectTransform 的锚点和偏移、Image 的贴图引用、Button 的点击事件。两棵树的形态高度相似。为什么 PSD 转 UI 工具能成立因为它不是在跑图像识别而是在做树结构映射。LoginPanel/ Canvas/LoginPanel ├── bg/ ├── bg │ └── img_bg.png │ └── Image (bg) ├── center_panel/ ├── CenterPanel │ ├── input_account/ │ ├── InputAccount │ │ ├── bg │ │ ├── Image │ │ └── txt_hint │ │ └── Text (Hint) │ ├── btn_login/ │ ├── BtnLogin │ └── txt_title │ └── Text (Title)ETYIUI 这类工具做的事情核心可以概括为四步解析 PSD 的图层层级、分组和坐标信息。把每个图层导出为独立的图片资源。按图层树的结构生成对应的 UI 节点树。根据命名约定给节点挂上组件、绑定字段、生成脚本。一旦你理解了这个逻辑就会明白为什么这类工具对“输入”的要求这么高PSD 的图层结构越接近 Unity 想要的节点结构映射就越顺利。这也解释了为什么同样一个工具有人觉得能省半天有人觉得生成的预制体根本没法看——差别往往不在工具本身而在输入的设计稿。2. 理解 PSD 转 UI 的核心流程才能正确使用工具2.1 完整链路解析、导出、映射、生成、绑定以 ETYIUI 为例具体菜单名称可能随版本变化但链路基本是同一个顺序PSD 解析工具读取 PSD 文件分析图层树、图层坐标、分组关系、是否有九宫格切片标记。资源导出对每个图层或分组导出图片。有的工具会先把 PSD 的分层信息生成到一个中间数据文件里再在 Unity 侧读取。层级映射在 Unity 编辑器里生成对应的 UI 节点。普通图层变成 Image文本图层变成 Text 或 TMP命中命名约定的图层变成 Button、Slider、InputField 等可交互组件。预制体生成把映射好的节点树保存为 Prefab。代码生成根据命名约定生成脚本把需要访问的节点声明成字段并在初始化时自动绑定。这跟手工做一遍的逻辑是一样的区别在于每一步都是确定性的、可重复的。同样的 PSD 输入每次生成的结果一致这就为团队协作和版本管理提供了基础。手工搭建时十个开发者能搭出十种节点结构用工具生成大家拿到的是同一种结构。2.2 命名约定是这套流程的“约定优于配置”如果你去看 ETYIUI 的说明文档或者社区里的使用经验会发现所有教程都在强调同一件事图层命名要规范。常见约定通常是btn_前缀开头的图层 → Button 组件txt_前缀 → 文本组件img_前缀 → Image 组件input_前缀 → 输入框组件带_9后缀或特定切片标记的 → 九宫格图为什么命名这么关键因为工具不知道“这个图层到底代表什么语义”。工具只能看到坐标、尺寸和图片内容它唯一能用来推断语义的信号就是名字。这看起来像技术限制实质上是一种工程取舍。命名约定让设计师和开发者在文件层面就完成了沟通设计师在设计稿里写清楚“这个元素是按钮”还是“只是个背景图”开发者拿到生成结果后不需要再猜。我见过一个团队的做法很值得参考他们给设计侧提供了一份命名规范文档只有十几条每条都配了示例截图。设计师照着规范出图开发者用工具生成返工率明显下降。先和设计师达成一份简单的命名约定再去追求更多自动化配置。图层命名混乱的情况下任何自动化工具都只能忠实地把混乱复制到 Unity 里。2.3 图层到组件的映射规则不同工具的映射规则有差异但大体可以理解为下面这张表PSD 图层命名或类型生成的 Unity 组件说明btn_开头的图片图层Button Image点击区域由图片尺寸决定txt_开头的文本图层Text / TextMeshPro字体、字号尽量从 PSD 读取但常需适配img_开头的图片图层Image普通背景或图标input_开头的图层组InputField / TMP_InputField通常需要额外的占位文本无前缀的普通图层纯 Image 或空节点作为父节点组织层级带九宫格标记的图层Image Slice拉伸时保持圆角和边框注意这种映射不是百分之百准确。工具能自动识别的是“图片资源”和“基础组件”但交互逻辑、点击后的跳转、动画状态、列表循环这些仍然需要开发者在生成后补充。自动生成的只是骨架血肉还是得人来填。3. 实操从一份 PSD 到可运行的 UI 预制体3.1 前置准备设计稿规范和 Unity 工程环境在打开工具之前先把输入搞干净。设计稿方面需要确认PSD 文件可以正常打开图层结构完整。图层没有大量未命名的“图层 1 副本”之类命名。设计稿尺寸和 Unity 的 Canvas 设计分辨率匹配例如都是 1920x1080 或 750x1334。涉及圆角、渐变、投影的 UI最好能提供独立切图不要依赖 PSD 图层的复杂混合模式。Unity 工程方面确认 Unity 版本和插件版本兼容。如果项目里使用 UGUI但插件默认生成的是 TMP 组件就需要提前导入 TMP 基础资源。这些前置条件如果不满足后面生成的每个环节都有可能出问题而且你会搞不清楚问题到底出在哪一层。3.2 最小可用流程按步骤走第一次使用不要急着拿一个复杂的战斗结算界面来测试。我的建议是先做一个只有背景、一个按钮、一行文本的小 PSD把整条链路跑通。大致的步骤如下在 Unity 中导入 ETYIUI 插件确认编辑器菜单里出现工具入口。把 PSD 文件放到 Unity 项目的某个目录下例如Assets/UI/PSD。在工具面板中选择该 PSD 文件设置设计分辨率。设置输出路径分别指定图片资源、预制体、脚本的生成目录。点击生成。检查输出目录里是否生成了对应的图片、预制体和脚本。把预制体拖到场景的 Canvas 下运行确认显示正常。这个最小流程的目的不是立刻得到完美结果而是先确认工具在你的环境下能完成整条链路。链路只要通了后面的事情都是参数和细节调整。先跑最小用例再上真实界面。工具能正常生成一个小面板不代表它能处理一个带几十个图层、多种组件的大界面。控制变量才能知道问题出在工具还是出在设计稿。3.3 绑定代码是怎么生成的应该怎么看生成出来的代码常见结构大致是这样public class LoginPanel : MonoBehaviour { public Button btnLogin; public TMP_InputField inputAccount; public Image imgLogo; private void Awake() { Bind(); } private void Bind() { btnLogin transform.Find(Center/BtnLogin).GetComponentButton(); inputAccount transform.Find(Center/InputAccount).GetComponentTMP_InputField(); imgLogo transform.Find(Header/ImgLogo).GetComponentImage(); } }这段代码不是给你直接改业务逻辑用的它是“初始状态”。你可以在 Bind 之后继续写初始化逻辑但尽量不要去改自动生成的那部分查找路径。一旦设计稿更新、重新生成改动就会被覆盖。更好的做法是自动生成的脚本只负责“绑定和基础初始化”业务逻辑写在之外。如果项目不打算让生成的代码参与长期迭代也可以把它当作一次性生成的样板代码生成后手动梳理一遍再提交。关键是团队要明确一点后面会详细说。4. 关键参数和配置边界条件比默认参数更影响结果4.1 设计分辨率、锚点与缩放的对应关系PSD 里的每个图层都有绝对坐标和尺寸而 Unity UI 的布局是基于锚点的。这两个体系之间需要一个转换策略。常见策略有两种绝对坐标模式把所有节点放在同一个锚点下比如居中锚点直接按设计坐标摆放。这种模式简单直接但不同屏幕比例下的适配性较差。相对布局模式根据图层在设计稿中的位置推断它可能属于哪个锚点区域。靠近右下角的按钮锚点就设为右下角。这更符合 UI 适配需求但依赖工具对位置的判断准确性。如果生成出来的 UI 在 1920x1080 下正常换到 1280x720 就乱了先检查锚点策略不要急着手动调每个节点的坐标。手动调能解决单个界面解决不了整个项目的适配体系。4.2 图片导出、九宫格与图集PSD 里的图片资源默认导出结果通常是独立 PNG。独立图片没问题但要注意需要拉伸的按钮背景在 PSD 里可能只是一张带圆角的图。Unity 里要用九宫格Slice才能保证拉伸时圆角不变形。工具是否能从图层名或切片信息识别九宫格需要在配置里确认。独立贴图数量多时DrawCall 会升高。生成之后要考虑是否打入图集Sprite Atlas尤其是有大量小图标的界面。同一张图被多个界面复用时要留意输出目录里是否产生了重复资源。重复贴图会白白增加包体和内存。这些不是 ETYIUI 独有要注意的点所有 PSD 转 UI 工具都会面临。生成只是把资源落地资源策略的优化仍然是开发者的工作。4.3 文本组件的选择Legacy Text、TextMeshPro 还是自定义Unity 的文本组件一直存在新旧切换的问题。旧的 Unity UI Text 简单但渲染质量和动态字体效果一般TextMeshPro 质量更好也是 Unity 官方推荐的默认方案。使用工具时要注意生成的文本组件类型取决于你的配置如果生成 Legacy Text但项目已经全面迁移到 TMP生成完需要手动替换。如果生成 TMP要确保 PSD 里的字体能映射到工程里的 TMP Font Asset。这一步通常不能完全自动化需要提前配置字体映射。更核心的问题是PSD 里的文本图层记录的是设计软件里的字体名Unity 工程里未必有对应的字体资源。所以文本这块生成后几乎总需要二次调整。这不是工具偷懒而是设计环境和运行环境里的字体本来就是两套体系。5. 实际落地时最容易踩的坑5.1 PSD 图层混乱工具能运行但结果不可用这是最常见的情况。工具没有报错预制体也生成了但打开一看节点层级平铺了一堆“图层 1”“组 3”图片互相叠在一起根本没法用。问题不在工具在输入。PSD 的图层树如果没有合理的分组语义工具就没有依据做层级映射。你在 Unity 里看到的一团乱麻和 PSD 里的一团乱麻是完全对应的。一个简单的判断标准如果设计师把 PSD 里的所有图层平铺开这张设计稿在技术上“能用”但对工具来说“没有信息量”。生成工具需要的不只是图还有图的组织结构。图层命名规范这件事越早和设计师确认后面整个流程越顺利。5.2 字体缺失、版本兼容和许可证状态这里说几个实际项目中经常遇到的环境问题TMP 基础资源缺失新开的工程没有导入 TMP Essential Resources生成 TMP 组件时会出现引用异常。Unity 大版本不兼容有些插件只支持特定的大版本。升级 Unity 后插件的编辑器代码可能编译报错。Unity 许可证未激活如果编辑器本身没有正常激活启动时会直接报 “No valid Unity Editor license foundplease activate your license”。这类错误容易让人误以为是插件问题其实先检查许可证状态就行。环境问题有个共同特点它们不在业务代码里也不在生成结果里而是发生在编辑器层面。建议先把 Unity 空工程跑通再导入插件再进正式项目。每步分开验证出问题才知道是哪个环节。5.3 自动生成的代码在长期维护中的边界工具生成的代码最大的维护风险是“二次生成覆盖手改”。UI 更新很频繁换个背景、调个字号、按钮挪个位置。设计师更新 PSD 后开发者重新生成之前手写在生成代码里的业务逻辑就可能被覆盖。怎么处理几种可行方案分离方案生成的脚本和手写脚本分开手写脚本通过 Inspector 引用生成的预制体不直接修改生成文件。隔离区间把业务逻辑抽到独立方法里不写在自动生成的区间内。一次性生成把 PSD 转换当作初始搭建工具后续 UI 修改直接在 Unity 里手工调整不再回到 PSD 重新生成。三种方案没有绝对优劣。团队规模小、界面迭代快的项目第三种反而更省心。关键在于团队要明确这个工具是“每次修改都走一遍”还是“只在初始搭建时用一次”。这个决策要写进协作规范不然每个人的用法不同后患会很多。重新生成前先确认自动生成的脚本目录里没有手写改动。没有版本管理兜底的生成工具比不用工具更容易制造线上事故。6. 生成结果不对时按什么顺序排查6.1 先看现象再定位是“没做出来”还是“做错了”排查的第一步不是打开日志而是定现象。大致分三类完全没有输出没有生成任何预制体、脚本或图片。有输出但界面错乱图片缺失、位置错乱、层级不对。有输出但功能不对按钮绑定失败、脚本报空引用、文本显示异常。这三类问题的原因范围完全不同。第一类更可能是环境、路径、插件配置的问题第二类更可能是设计稿结构、坐标转换、资源导出的问题第三类则要重点看命名约定和组件类型映射。6.2 从输出一层一层往回查一个比较稳妥的排查顺序看输出路径先确认生成的文件写到了哪里。有时候生成了但 Unity 资源数据库没有刷新导致引用丢失。看中间文件有些工具会先生成中间数据文件记录图层信息和坐标。中间文件有问题后续生成一定有问题。看输入 PSD用 Photoshop 打开原始 PSD检查图层命名、分组结构、是否有异常图层。看环境配置Unity 版本、插件版本、许可证状态、TMP 资源是否导入。看参数设置设计分辨率、锚点策略、输出格式是否和工程一致。看工具边界如果 PSD 里用了工具不支持的图层样式比如复杂混合模式、高级滤镜结果不符合预期是正常的。这个顺序的核心逻辑是从结果往输入、从输出往环境逐层排除。不要一上来就怀疑工具坏了大多数情况下工具只是忠实地把输入里的问题复现了一遍。7. 适用边界不是所有 UI 都适合“一键生成”7.1 什么样的人和项目适合用它从实际经验看以下情况用 PSD 转 UI 工具收益最大项目有大量信息展示型界面背包、设置、签到、排行榜结构规整交互不复杂。设计师愿意按命名和分层规范出图开发与设计之间有明确交接流程。团队希望把 UI 从“每次手工搭”变成“模板化生成”并愿意为此投入时间制定规范。你的重复劳动主要花在“搭结构”上而不是“调交互”上。如果是个人开发者做小游戏界面数量不多手工搭建可能更快。因为学习规范的沟通成本可能高于直接手动搭一次界面的成本。工具节省的永远是“重复”而不是“第一次”。7.2 什么样的情况不建议用反过来这些情况不建议硬用设计稿几乎没有分层规范所有元素都是合并图层。界面包含大量复杂交互动效比如拖拽、捏合、自定义布局。不同分辨率下控件需要完全不同的布局行为单纯靠锚点解决不了。团队里没有人愿意维护命名规范、工具配置和生成流程。一个很现实的判断标准如果一份 PSD 连设计师自己都要临时说明“哪里是按钮、哪里是背景”那工具也读不懂它。工具能够自动化的前提是输入本身已经有了稳定的结构。7.3 长期工程化版本控制、复用和团队规范最后回到工程层面。工具能自动生成意味着生成物是确定性的但这同时要求生成物必须被规范管理PSD 原始文件、中间数据、生成的预制体和脚本都建议提交到版本库并明确谁负责更新。生成的预制体和脚本要放在独立目录不要和手写代码混在一起否则后期分不清哪些是手写的、哪些是重新生成会覆盖的。写一份“UI 生成流程说明”文档至少包含命名规范、输出目录、重新生成步骤、生成后的检查清单。这套流程看起来像在给团队加规矩但它是这类工具能长期发挥价值的真正前提。工具自动化程度越高规范带来的收益就越大。因为少了人的临场判断输入的规范性就直接决定了输出的质量。回到最开始那个判断ETYIUI 这类 PSD 转 UI 工具真正改变的不是“节省了几个小时”而是把 UI 还原从一项依赖个人熟练度的手工活变成一条可以定义输入、验证输出、反复执行的流程。而流程的价值从来不在第一次跑通时体现而是在项目迭代到第三个月、第五个月的时候你还能清楚地知道界面是从哪份设计稿来的生成的代码能不能安全重建改动会不会被覆盖。这才是它值得进入你工具链的真正原因。