1. 从手搓像素到对话生成UI 工作流的真实转折点“自从有了 AI我就再也不想拼 UI 了”——这句话我第一次在团队群里看到时正对着一个 200 多个 prefab 的 Unity 工程发呆。那天下午的任务是把一套活动弹窗从旧版视觉规范迁移到新版涉及按钮圆角、投影层级、字号阶梯、间距栅格四大类改动粗算下来要动 60 多个界面。放在两年前这就是一个标准的“三天起步、五天收尾”的体力活切图、量间距、对锚点、改九宫格、导出 PSD 标注、再一个个拖进引擎里摆位置。而现在我把需求描述、参考截图和设计规范丢给 AI十几分钟就能拿到一版可用的布局骨架剩下的时间全花在交互细节和动效打磨上。这个转变不是“AI 帮我画了张图”这么简单它真正改变的是 UI 生产的分工结构。过去 UI 实现是一条单向流水线设计出稿 → 标注 → 前端/引擎还原 → 走查 → 返工。AI 介入之后这条线变成了一个循环描述意图 → 生成结构 → 人工校准 → 再描述微调。设计师和开发者的角色从“像素搬运工”变成了“意图描述者”和“质量把关人”。我带的几个新人现在上手一个陌生项目的 UI 框架第一件事不是打开 Figma 数像素而是先把设计稿截图喂给 AI让它输出一份组件树和布局参数表再对照引擎里的实际 prefab 结构做映射。这篇文章想聊的就是这套新工作流到底怎么落地。不管你是做 Unity UI、Web 前端界面、还是移动端原生控件只要你的日常和“拼界面”打交道下面这些经验都能直接抄。我会把 AI 在 UI 生产中的四个关键环节拆开讲意图转结构、PSD/截图转代码、prefab 批量生成与校验、以及那些 AI 搞不定必须人工兜底的坑。全程不吹概念只讲我实际跑通过的流程和踩过的雷。2. 意图转结构把“感觉”翻译成可执行的布局参数2.1 为什么直接让 AI“画个界面”大概率会翻车很多人第一次用 AI 做 UI习惯性输入“帮我设计一个登录页要好看”。结果拿回来的东西要么是通用模板味极重要么是元素堆砌、层级混乱。问题不在 AI 能力而在于输入的信息密度太低。“好看”是一个主观评价不是可执行指令。AI 需要的是约束条件屏幕尺寸、栅格系统、组件库、间距规则、字号阶梯、颜色 token。我自己的做法是在让 AI 生成任何界面之前先准备一份项目上下文包。这份包不需要多复杂但必须包含四样东西画布规格目标分辨率、安全区、是否适配刘海屏或折叠屏。栅格与间距比如 8pt 栅格、页面左右边距 16、卡片内边距 12、模块间距 24。组件清单项目里已有的按钮、输入框、标签、弹窗等组件的命名和变体。视觉 token主色、辅助色、圆角半径、投影参数、字号与行高对应表。把这四样东西整理成一段结构化描述再让 AI 输出布局命中率会从“抽盲盒”变成“基本可用”。我实测下来同样的需求带上下文包生成的布局人工调整量能减少 60% 以上。2.2 用“组件树 参数表”代替自然语言描述AI 对自然语言的理解有天然模糊性但对结构化数据的还原能力很强。所以我在描述界面时会刻意把需求写成组件树 参数表的形式而不是一段散文。举个例子要生成一个“活动奖励弹窗”我不会写“顶部有个标题下面一排奖励图标底部一个领取按钮”。我会写成弹窗容器: 宽 640, 高 480, 圆角 16, 背景 #1A1A2E ├─ 标题栏: 高 64, 内边距 左右24 上下16 │ ├─ 标题文本: 字号 24, 字重 Bold, 颜色 #FFFFFF, 内容每日奖励 │ └─ 关闭按钮: 40x40, 右上角偏移 -12,-12 ├─ 奖励区: 高 280, 内边距 24, 横向排列 5 个奖励项 │ └─ 奖励项: 96x120, 间距 16, 包含图标 64x64 数量文本 字号14 └─ 底部按钮: 宽 240, 高 56, 圆角 28, 主色 #FF6B35, 文本立即领取这种写法看起来啰嗦但它把 AI 的“创作空间”压缩到了合理范围同时保留了布局逻辑的完整性。生成出来的结构可以直接映射到 Unity 的 RectTransform 层级、Web 的 flex 容器、或者 Android 的 ConstraintLayout。我试过用这套方法让 AI 生成一个包含 12 个模块的复杂设置页第一版就有 80% 的布局可以直接用剩下的主要是间距微调和个别组件的变体选择。2.3 提示词里必须写死的三类约束在 UI 生成场景里有三类约束如果不写死AI 几乎一定会自由发挥导致返工第一类是锚点与对齐规则。AI 默认会按“视觉居中”来摆元素但实际项目里很多元素需要贴边、拉伸或按比例定位。比如列表项的高度需要随内容自适应底部按钮需要固定在安全区上方。这些必须在提示词里明确写“左对齐、右对齐、水平拉伸、垂直居中”等锚点行为。第二类是层级与遮挡关系。弹窗、Toast、下拉菜单这类浮层元素z 轴顺序错了整个交互就废了。我通常会在描述里加一行“层级顺序背景 内容 浮层 引导遮罩”让 AI 按这个顺序组织节点。第三类是命名规范。如果生成出来的节点叫“Panel1”“Text2”“Button3”后续维护就是灾难。我会在提示词里要求“节点命名遵循项目前缀规范如dlg_表示弹窗、btn_表示按钮、txt_表示文本”这样生成的 prefab 结构直接就能进版本管理。提示上下文包和组件树描述建议存成项目里的一个 Markdown 文件每次让 AI 生成界面前先贴进去。这个文件本身就是一份活的 UI 规范文档新人接手时比看 Figma 还快。3. 从 PSD 和截图到可运行代码图像转 UI 的实操链路3.1 截图转布局AI 视觉理解的实际精度边界现在主流的多模态模型对界面截图的识别能力已经相当可用。我拿一张 1080x1920 的移动端页面截图做测试让 AI 输出组件树和坐标参数结果大致是这样的主要区块的识别准确率在 90% 以上按钮、输入框、卡片这些标准组件基本不会漏但细粒度的问题集中在三处——图标与装饰元素的区分、文本行高与字号的精确还原、重叠元素的层级判断。所以我的实际流程是先用 AI 把截图转成结构化的布局描述然后人工过一遍重点修正上面三类问题。修正完之后再让 AI 把这份描述转成目标平台的代码或 prefab 结构。这个“两段式”流程比直接让 AI“截图转代码”要稳得多因为中间那层结构化描述是可审查、可修改的出了问题能定位到具体节点而不是面对一坨生成的代码猜哪里错了。3.2 PSD 分层文件的处理策略PSD 比截图多了一层信息图层结构。但 PSD 的图层命名往往很随意“图层 1”“副本 3”“形状 27”这种命名对 AI 来说等于没有信息。我处理 PSD 的步骤是这样的先做图层清洗把隐藏图层删掉把编组按功能重命名比如“顶部导航”“内容列表”“底部操作栏”。导出为分层 PNG 或直接读取图层树如果工具链支持直接把图层树导出成 JSON包含每个图层的名称、位置、尺寸、可见性。让 AI 做图层到组件的映射把图层树 JSON 和项目的组件清单一起给 AI让它输出“图层 → 组件类型 → 布局参数”的映射表。人工校验映射结果重点看按钮、输入框、列表项这些交互组件有没有被正确识别装饰性图层有没有被误判为组件。这套流程跑下来一个中等复杂度的页面约 30 个图层从 PSD 到可用的布局描述大概 20 分钟。纯手工的话光量间距和标注就要一个多小时。3.3 生成代码的落地形态prefab、组件还是样式表AI 生成的 UI 代码最终以什么形态落地取决于你的技术栈。我分别在 Unity、Web 和 Android 三个场景下跑过落地形态差别很大平台推荐落地形态原因Unityprefab RectTransform 参数引擎内可视化调整方便AI 生成结构后人工微调成本低WebJSX/HTML 结构 CSS 变量样式与结构分离AI 生成后可直接接入现有构建流程AndroidXML 布局 ConstraintLayout原生布局体系成熟AI 对约束关系的描述能力足够以 Unity 为例我让 AI 输出的不是 C# 代码而是一份prefab 结构描述包含节点层级、RectTransform 的 anchor/pivot/offset、以及组件引用关系。然后用一个编辑器脚本把这份描述实例化成真正的 prefab。这样做的好处是AI 不需要理解 Unity 的序列化格式只需要输出结构化的布局数据转换环节由确定性脚本完成出错概率大幅降低。// 简化的 prefab 生成脚本核心逻辑 [MenuItem(Tools/Generate UI Prefab)] static void GenerateFromDescription() { var desc JsonUtility.FromJsonUINodeDescription(jsonText); var root new GameObject(desc.name, typeof(RectTransform)); BuildNode(root, desc); PrefabUtility.SaveAsPrefabAsset(root, Assets/UI/Generated/ desc.name .prefab); } static void BuildNode(GameObject go, UINodeDescription node) { var rt go.GetComponentRectTransform(); rt.anchorMin node.anchorMin; rt.anchorMax node.anchorMax; rt.pivot node.pivot; rt.anchoredPosition node.anchoredPosition; rt.sizeDelta node.sizeDelta; // 按 node.type 挂载 Image/Text/Button 等组件 }这个脚本我用了大半年配合 AI 生成的结构描述批量产出 prefab 的效率比手动拖拽高一个数量级。关键是它把“AI 生成”和“引擎落地”解耦了AI 那边换了模型或提示词这边脚本不用动。4. prefab 批量生成与校验把重复劳动交给流水线4.1 为什么 prefab 是 UI 自动化的最佳切入点在 Unity 项目里prefab 是 UI 的最小复用单元。一个活动页面可能由 20 个 prefab 拼成一个列表项 prefab 可能在十几个界面里被引用。这种“结构固定、参数可变”的特性正好是 AI 擅长的场景。我统计过自己经手的一个项目UI 相关的 prefab 有 400 多个其中超过一半是“同一结构换不同内容”的变体。这些变体如果手动复制粘贴再改参数不仅慢还容易漏改导致线上事故。AI 介入后我的做法是先定义好基础 prefab 模板然后用 AI 批量生成变体描述最后用脚本实例化。比如一个奖励列表项基础结构是“图标 名称 数量 状态标记”AI 根据配置表生成 50 个变体的参数描述脚本一次性产出 50 个 prefab。整个过程从半天压缩到十几分钟。4.2 批量生成时的参数校验清单批量生成最怕的是“生成了但不对”。我在脚本里加了一套校验规则每次生成后自动跑一遍不通过的直接标红锚点校验检查所有节点的 anchorMin/anchorMax 是否符合预设的布局规则比如全屏背景必须是 (0,0)-(1,1)底部按钮必须锚定底部安全区。尺寸校验检查关键节点的宽高是否在合理范围内比如按钮高度不能小于 44触控最小热区文本宽度不能超过容器宽度。引用校验检查所有需要绑定的组件引用是否为空比如按钮的 onClick 事件、文本的字体资源、图片的 Sprite 引用。命名校验检查节点命名是否符合项目规范不符合的自动重命名并记录日志。这套校验跑下来能拦掉 80% 以上的低级错误。剩下的 20% 主要是视觉层面的问题比如间距看起来不协调、颜色对比度不够这些还是得靠人眼过一遍。4.3 用 AI 做 UI 走查自动发现布局异常除了生成AI 在 UI 走查环节也能帮上忙。我的做法是把运行时的界面截图和设计稿截图一起给 AI让它对比输出差异报告。AI 能识别出的问题包括元素错位、间距不一致、字号偏差、颜色偏差、缺失元素、多余元素。实测下来对于结构性的差异比如某个按钮位置偏了、某个文本被截断AI 的识别率很高对于细微的视觉差异比如 1px 的圆角差别、轻微的色差还是得靠工具做像素级对比。我通常把 AI 走查作为第一道筛子先把明显的布局问题修掉再用像素对比工具做精细校验。这样人工走查的时间能省下一大半而且不容易漏掉那些“看起来没问题但其实偏了”的细节。注意AI 走查报告里的“建议修改”不要无脑采纳。它有时候会把设计稿里的特殊处理当成错误比如设计稿里故意做的视觉补偿、为了适配做的非标准间距。每一条修改建议都要对照设计意图判断。5. 那些 AI 搞不定、必须人工兜底的坑5.1 交互逻辑与状态管理AI 的盲区AI 能把界面画出来但界面背后的状态流转、事件响应、数据绑定它基本帮不上忙。我试过让 AI 生成一个“带展开收起功能的设置项”它给出的布局结构没问题但展开收起的动画曲线、状态切换时的布局重算、以及和外部数据源的同步逻辑全是错的或者缺失的。这类问题不是 AI 能力不够而是交互逻辑高度依赖具体项目的架构和约定AI 没有足够的上下文去推断。所以我的分工原则很明确AI 负责“长什么样”人负责“怎么动”。布局、样式、静态结构交给 AI交互逻辑、状态管理、性能优化留给自己。这样既享受了 AI 的效率又不会在关键逻辑上埋雷。5.2 性能敏感场景UI 层卡顿的排查与优化UI 卡顿是移动端和游戏项目的老大难问题。AI 生成的布局如果不加约束很容易踩性能坑过多的 Overdraw、不必要的 Layout Rebuild、频繁的 SetActive 切换、以及过深的节点层级。我在项目里定了几条硬规则AI 生成的布局必须满足节点层级不超过 6 层超过的话Layout 计算和渲染批次都会受影响。同一界面内 Image 组件不超过 30 个超过就要考虑图集合并或改用其他渲染方式。避免在 Update 里做布局计算所有布局变更集中在初始化或状态切换时完成。列表项必须用对象池AI 生成的列表结构默认是直接实例化需要人工改成对象池管理。这些规则我会写进提示词里让 AI 生成时就尽量遵守。但最终的性能验证还是得靠 Profiler 实测AI 没法替你做这件事。5.3 设计规范与品牌一致性AI 的“审美漂移”AI 生成界面时有一个隐蔽的问题审美漂移。同一个提示词不同批次生成的结果可能在圆角、间距、颜色上都有细微差别。单看每个界面都没问题但放在一起就会发现不统一。这在品牌要求严格的场景里是致命的。我的解决办法是把设计 token 固化到提示词模板里每次生成都带上完整的 token 表并且生成后跑一遍 token 校验脚本检查实际使用的颜色、字号、圆角、间距是否都在 token 表范围内。超出范围的自动标记出来人工确认是特例还是错误。这套机制跑下来品牌一致性基本能保住。5.4 常见问题速查表问题现象可能原因排查方向解决手段AI 生成的布局元素重叠锚点描述缺失或冲突检查提示词里的 anchor 定义补全锚点规则重新生成prefab 生成后引用为空组件映射表不完整对照组件清单检查映射补充映射规则重跑脚本界面在不同分辨率下错位使用了绝对定位而非锚点检查 RectTransform 参数改为锚点偏移的响应式布局批量生成的 prefab 命名混乱提示词未指定命名规范检查生成描述里的 name 字段加命名校验脚本自动重命名AI 走查报告误报率高设计稿有特殊处理未说明对照设计意图逐条判断在提示词里补充特殊处理说明生成代码无法编译平台 API 版本不匹配检查目标平台和版本在提示词里指定平台和版本号6. 我实际跑通的一套完整工作流6.1 从需求到 prefab 的六步流程把上面这些经验串起来我现在处理一个 UI 需求的完整流程是这样的整理上下文包从项目规范里提取画布规格、栅格、组件清单、视觉 token存成 Markdown。描述界面结构用组件树 参数表的形式写出目标界面的布局描述带上锚点和命名规范。AI 生成结构描述把上下文包和界面描述一起给 AI让它输出结构化的布局 JSON。人工校验与修正对照设计稿检查生成的布局重点看锚点、层级、命名、组件映射。脚本实例化 prefab用编辑器脚本把布局 JSON 转成 prefab自动跑校验规则。交互逻辑与性能优化手动接入事件、状态管理、对象池用 Profiler 验证性能。这套流程我跑了大概三个月处理了 200 多个界面。平均下来一个中等复杂度界面的从需求到可用 prefab时间从原来的 4 小时压缩到 1 小时左右其中 AI 生成占 10 分钟人工校验和修正占 30 分钟交互和优化占 20 分钟。效率提升主要来自“结构生成”和“批量实例化”这两个环节交互逻辑那部分该花的时间还是得花。6.2 工具链选型不追新只求稳工具选型上我的原则是稳定优先、可替换。AI 模型迭代太快今天好用的明天可能就变了所以整个流程里我把“AI 生成”做成了一个可替换的环节输入是上下文包和界面描述输出是结构化 JSON。换模型只需要改这一环后面的校验和实例化脚本不用动。具体到工具我用的是结构描述生成任意支持长上下文的多模态模型重点是能稳定输出 JSON。prefab 实例化自己写的 Unity 编辑器脚本不依赖第三方插件。校验规则纯 C# 脚本跑在编辑器里生成后自动执行。性能验证Unity Profiler 真机测试AI 替代不了。这套组合的好处是每一环都透明可控出了问题能定位到具体环节不会出现“AI 黑盒生成了一堆东西但不知道哪里错了”的情况。6.3 团队协作中的注意事项如果这套流程要在团队里推广有几件事必须提前定好上下文包由谁维护建议由 UI 规范负责人统一维护每次规范更新同步更新上下文包。生成结果的审核责任AI 生成不等于可以直接用必须有人对最终结果负责。我的做法是生成者自检 走查者复核。版本管理策略AI 生成的 prefab 和手写的 prefab 放在同一个版本管理里但要在提交信息里标注来源方便追溯。提示词模板的沉淀把跑通的提示词模板存成团队共享文档新人直接复用不要每个人从头摸索。最后分享一个我踩过的坑早期我让 AI 生成 prefab 时没有加命名校验结果生成了几百个叫“Panel”“Text”“Button”的节点后来做本地化和主题切换时根本找不到要改哪个节点只能全部返工重命名。从那以后命名规范校验成了我流程里的强制环节宁可生成时多花两分钟也不要后期花两天去补。