1. 从“拼 UI”到“说 UI”一场工作流的静默迁移“自从有了 AI我就再也不想拼 UI 了”——这句话我第一次在团队内部群里看到时心里咯噔了一下。因为说这话的不是刚入行的新人而是一个做了七八年 Unity 客户端、手搓过无数 PSD 切图、对 UGUI 和 NGUI 都门儿清的老兵。他说的“拼 UI”指的是把设计稿里的按钮、列表、弹窗、进度条一个个拖进场景、调锚点、设 pivot、绑事件、写 prefab 变体——这套流程我们太熟了熟到闭着眼都能干也熟到闭着眼都不想干。但这句话背后真正值得聊的不是“AI 会不会取代 UI 仔”而是一个更实际的问题当 AI 能读懂设计稿、能生成 prefab、能写绑定代码的时候我们这些做客户端的人工作重心到底该往哪挪我花了大概两个月时间把 AI 辅助 UI 生产这条链路从“玩具”跑成了“半生产可用”中间踩的坑、省下的时间、以及那些 AI 暂时还搞不定的地方都值得完整记一笔。这篇内容适合三类人看一是天天和 UGUI、prefab、PSD 打交道想从重复劳动里抽身的客户端开发二是想搞清楚 AI 到底能在 UI 环节帮上什么忙的技术负责人三是刚入行、还没被“拼 UI”毒打过、想直接走新路子的新人。我会把核心思路、关键参数、实操步骤、排查技巧全部摊开讲尽量做到你看完就能照着搭一套自己的流程。先给个结论性的判断AI 目前最擅长的不是“设计 UI”而是“把已经确定的设计意图翻译成工程结构”。它替代的是机械搬运不是审美决策。想明白这一点后面的所有取舍就都顺了。2. 整体思路拆解为什么是“设计稿到 prefab”这条链路2.1 先搞清楚“拼 UI”到底在拼什么很多人一说“拼 UI”就觉得是拖控件其实拆开看一个标准 UI 从设计稿到能跑至少包含五层工作结构层这个弹窗有几层容器、哪些是列表、哪些是固定区域层级关系怎么组织。布局层锚点、pivot、offset、sizeDelta 怎么设适配方案是等比缩放还是分档。资源层图集怎么切、九宫格怎么拉、字体和材质怎么挂。逻辑层按钮绑什么事件、列表怎么复用、数据怎么驱动显隐。变体层不同分辨率、不同语言、不同状态下的 prefab 变体怎么管理。传统流程里这五层全靠人手一层层搭。AI 能介入的主要是结构层、布局层和逻辑层的初稿生成资源层和变体层目前还是半自动。所以“不想拼 UI”不是完全不碰而是把最耗时的前三层交给 AI 出草稿人只做审核和微调。2.2 为什么选 Codex 这类工具做主力热词里反复出现 Codex、codex 安装、codex 接入 deepseek、codex 使用教程说明大家已经在拿它干实事了。我自己的选型逻辑很简单UI 生成的本质是“结构化代码生成”不是“图像生成”。你让一个画图模型去生成 UI它给你的是像素你让一个代码模型去生成 UI它给你的是可编译、可版本管理、可 diff 的工程文件。后者才是客户端要的东西。Codex 这类工具的优势在于它能吃下“设计稿描述 项目现有代码规范”然后吐出符合你项目风格的 C# 脚本和 prefab 结构描述。我实测下来只要把项目里的命名规范、目录结构、常用组件封装喂给它生成的代码可读性能到“改两行就能用”的程度。相比之下纯靠提示词让通用聊天模型写 UGUI 代码出来的东西经常连 using 都不全。2.3 一个关键取舍生成 prefab 还是生成代码这里有个很多人纠结的点AI 到底该直接生成 .prefab 文件还是生成一段构建 prefab 的编辑器脚本我的答案是优先生成编辑器脚本原因有三第一prefab 的 YAML 格式对 AI 极不友好字段多、引用杂生成出来经常丢 GUID修起来比手搭还累。第二编辑器脚本是可读的你能一眼看出它怎么设锚点、怎么挂组件出问题好定位。第三脚本可以参数化同一套逻辑换个数据就能批量生成几十个相似界面这是手拼永远做不到的。提示如果你确实需要直接产出 prefab建议让 AI 生成“构建脚本 执行入口”在 Unity 里跑一遍再保存成 prefab而不是让它直接写 YAML。这个顺序能省掉大量玄学报错。2.4 整体链路长什么样我把这条链路固化成了四段设计稿解析把 PSD 或设计稿导出成带层级和坐标的中间描述JSON 最稳。结构生成AI 根据中间描述 项目规范生成 UGUI 层级构建脚本。逻辑填充AI 根据交互说明生成事件绑定和数据驱动骨架。人工审核与变体人检查布局、补资源、做适配变体。这四段里第 2、3 段是 AI 的主场第 1 段半自动第 4 段目前还是人的活。下面逐段拆。3. 核心细节解析与实操要点3.1 设计稿怎么变成 AI 能吃的“中间描述”这是整条链路的地基地基没打好后面全是返工。PSD 直接丢给 AI 是没用的它读不懂图层语义。你需要先做一层转换把设计稿变成结构化的 JSON字段至少包含节点名、类型容器/文本/图片/按钮、相对坐标、尺寸、层级路径、以及可选的交互标记。我用的方案是写一个 PSD 导出脚本Photoshop 的 ExtendScript 或者用 psd-tools 这类库解析把图层树导成 JSON。关键字段长这样{ name: Btn_Confirm, type: button, rect: { x: 120, y: 480, w: 200, h: 72 }, children: [ { name: Txt_Label, type: text, content: 确认 } ], tags: [interactive, primary] }这里有个经验图层命名规范比什么 AI 技巧都重要。如果你的设计稿里全是“矩形 1”“图层 23”AI 再强也猜不出哪个是按钮。我们团队后来强制要求设计侧按类型_语义_状态命名比如Btn_Confirm_Normal、Img_Icon_Close转换准确率直接从六成提到九成以上。3.2 喂给 AI 的“项目规范”该怎么写很多人用 Codex 生成 UI 代码效果差不是模型不行是没告诉它你的项目长什么样。我整理了一份大概 800 字的规范文档每次生成都带上内容包括命名规范类名、字段名、方法名、prefab 名的命名规则。目录结构脚本放哪、prefab 放哪、图集放哪。常用封装我们项目有自己的UIBase、UIList、UIButton封装得告诉 AI 用这些而不是原生组件。锚点策略什么情况用 stretch什么情况用固定锚点。代码风格是否用[SerializeField]、是否走 Addressables。这份规范不用写得多漂亮但要具体到能当 checklist 用。我试过只写“请遵循项目规范”出来的代码基本没法用写清楚“按钮统一继承 UIButton点击回调命名为 OnXxxClick”生成质量立刻不一样。3.3 生成构建脚本时的关键参数让 AI 生成 UGUI 构建脚本有几个参数必须明确否则布局一定歪参考分辨率比如 1920x1080所有坐标换算都基于它。Canvas 缩放模式一般是 Scale With Screen Size匹配方式选 0.5 或按项目定。锚点规则我习惯让 AI 对容器节点统一用 stretch对叶子节点用固定锚点 相对父节点定位。九宫格标记哪些图需要拉九宫格在 JSON 里提前标好。这里有个计算细节值得说设计稿坐标是像素UGUI 里 sizeDelta 和 anchoredPosition 是相对锚点的。如果父节点是 stretch子节点的 anchoredPosition 原点在父节点中心如果父节点是固定锚点原点在锚点位置。AI 经常搞混这两套坐标系所以我在规范里明确写了“所有子节点定位一律基于父节点中心”生成完再统一校验一遍。3.4 逻辑层生成事件绑定和数据驱动结构搭好后逻辑层其实是最容易出彩的地方。我通常给 AI 的输入是“交互说明表”比如控件交互行为Btn_Confirm点击提交表单成功后关闭弹窗Btn_Close点击直接关闭不保存List_Items滚动复用 item点击某项高亮AI 会根据这张表生成事件绑定代码和列表复用骨架。实测下来列表复用这块它写得比很多新人规范因为它会老老实实按你给的UIList封装来写不会自己造轮子。注意AI 生成的逻辑代码一定要过一遍“空引用”检查。它经常假设某个组件一定存在但实际 prefab 里可能没挂。我一般会在生成的代码里加一层Debug.Assert或者空判断跑一遍再删。3.5 资源层和变体层为什么暂时别全交给 AI资源层涉及图集打包、纹理压缩格式、内存占用这些和项目构建管线强相关AI 给的建议往往太通用。变体层更复杂涉及多分辨率、多语言、多状态目前 AI 能帮你生成变体脚本的框架但具体参数还得人调。我的做法是资源层用脚本批量处理变体层用配置表驱动AI 只负责生成这两者的“胶水代码”。4. 实操过程与核心环节实现4.1 环境准备与工具链搭建先把工具链列清楚避免你到处找设计稿解析Photoshop ExtendScript或者 Python 的 psd-tools。AI 代码生成Codex 类工具本地或云端都行关键是能带上下文。Unity 侧2021 LTS 以上UGUI建议装 Odin 方便调试。版本管理Gitprefab 和脚本都要进版本库。安装 Codex 这块热词里 codex 安装、codex 安装 windows 桌面版、codex 安装 csdn 出现频率很高说明不少人在这一步卡住。我的建议是优先用官方渠道的安装包装完先跑一个最小示例验证环境别一上来就接项目。如果遇到 codex 无法加载组织设置这类问题八成是权限或网络配置的事先确认账号状态和本地配置目录是否可写。4.2 第一步导出设计稿 JSON我写了个 ExtendScript核心逻辑是递归遍历图层输出前面说的 JSON 结构。关键代码片段function walkLayer(layer, parentPath) { var node { name: layer.name, type: guessType(layer), rect: { x: layer.bounds[0].value, y: layer.bounds[1].value, w: layer.bounds[2].value - layer.bounds[0].value, h: layer.bounds[3].value - layer.bounds[1].value }, children: [] }; if (layer.layers) { for (var i 0; i layer.layers.length; i) { node.children.push(walkLayer(layer.layers[i], parentPath / layer.name)); } } return node; }guessType根据图层名前缀判断类型比如Btn_开头是按钮Txt_是文本Img_是图片。这一步的准确率直接决定后面 AI 生成的质量所以命名规范真的不是形式主义。4.3 第二步生成 UGUI 构建脚本把 JSON 和项目规范一起喂给 AI提示词大概是这样根据以下设计稿 JSON 和项目规范生成一个 Unity 编辑器脚本 在场景中构建对应的 UGUI 层级。要求 1. 容器节点用 RectTransform stretch 锚点 2. 叶子节点基于父节点中心定位 3. 按钮继承 UIButton文本用 TMP_Text 4. 输出完整可编译的 C# 代码。生成出来的脚本通常两三百行结构清晰。我一般会先在一个空场景跑一遍看层级和布局对不对再往项目里合。这里有个小技巧让 AI 在脚本里加一个“预览模式”开关开启时用纯色块代替图片这样不依赖美术资源就能验证布局效率高很多。4.4 第三步逻辑骨架生成与绑定结构验证通过后把交互说明表丢给 AI让它生成 MonoBehaviour 骨架。我要求它做三件事声明控件引用、在 Awake 里 Find 或绑定、生成事件方法空实现。这样我只需要填业务逻辑不用管绑定。实测下来一个中等复杂度的弹窗大概 20 个控件、3 个列表、5 个按钮从设计稿到可运行骨架纯手工大概 4 到 6 小时走这套流程能压到 1 小时以内而且返工率明显低因为布局是脚本算出来的不会出现手抖拖歪的情况。4.5 第四步人工审核与变体处理AI 出完草稿人的活集中在三块一是检查视觉还原度特别是间距和字号二是补资源引用把占位图换成真图三是做适配变体比如窄屏下某些容器要改布局。这三块目前 AI 帮不上太多但工作量已经从“全部”降到“三成”。5. 常见问题与排查技巧实录5.1 生成代码编译不过怎么办这是最高频的问题。常见原因和排查顺序现象可能原因解决找不到类型缺 using 或项目封装没引入在规范里写明命名空间组件为空prefab 没挂对应组件生成时加空判断布局错位锚点坐标系搞混统一基于父节点中心列表不滚动没挂 ScrollRect 或 Content 尺寸没算检查 Content 的 sizeDelta我一般让 AI 生成完先自己“静态检查”一遍把明显的空引用和缺 using 补上再进 Unity 编译。这一步能省掉一半的低级错误。5.2 Codex 接入本地模型时的坑热词里 codex 接入 deepseek、cc switch local proxy failed 这些说明不少人在折腾本地接入。我的经验是本地模型胜在隐私和成本但上下文长度和代码质量往往不如云端。如果项目对代码外泄敏感本地接入是合理选择但要接受生成质量打折扣并且要自己维护提示词模板。遇到代理或端点报错先确认本地服务是否正常响应再看配置里的 endpoint 路径有没有写错这类问题九成是配置问题不是模型问题。5.3 UI 卡顿和性能问题热词里 ui 界面卡顿、ui 层、unity ui 框架这些其实和 AI 生成有间接关系。AI 生成的层级如果嵌套过深或者列表没做复用跑起来就会卡。我的检查清单是Canvas 是否拆分合理、有没有不必要的 LayoutGroup、列表是否用了复用、图集是否合并。AI 生成的结构默认是“能跑”性能优化还得人补。5.4 几个独家避坑技巧别让 AI 一次生成整个复杂界面拆成“容器 子模块”分批生成出错好定位。生成的脚本一定要进版本库方便 diff 和回滚AI 改坏了能立刻还原。规范文档要随项目演进更新你封装了新组件就补进去否则 AI 永远用老写法。保留一份“黄金示例”把生成效果最好的一次代码存下来下次当 few-shot 样本喂给 AI质量会稳很多。6. 这套流程跑下来我的真实体会两个月跑下来最大的感受不是“AI 好强”而是“人的价值被逼着往上游走了”。以前我花大量时间在拖控件、调锚点、绑事件现在这些交给 AI 出草稿我更多时间花在设计稿规范制定、组件封装设计、性能优化和适配策略上。这些事以前也做但被重复劳动挤得没时间做深。还有个意外收获因为要写规范文档给 AI 看我被迫把项目里很多“口口相传”的约定显性化了。结果新人上手速度反而变快了因为规范终于有地方查了。这算是 AI 倒逼工程规范化的一个正面例子。至于“再也不想拼 UI”这句话我现在理解得更准确了不是不碰 UI是不想再干那些没有决策含量的搬运活。AI 把搬运接走了剩下的判断、取舍、优化才是客户端真正该花时间的地方。如果你还在犹豫要不要试我的建议是先从一个小弹窗开始把 JSON 导出和规范文档这两步做扎实跑通一次后面就是复制粘贴的事了。