昨天晚上十一点产品给我发了条消息说“这个列表滚起来有点掉帧你明天看一下”。放在以前这句话意味着我又要打开项目顺着层级去找那个嵌套了三层的 ScrollView一个一个排查阴影、圆角、动画和列表复用大概率一查就是大半天。但这次我没有慌。因为现在我的 UI 生产链路里AI 已经承担了绝大部分“拼界面”的体力活从一句话需求到可运行的前端骨架从控件摆放到基础样式收敛AI 都能在几十秒内给我一份“及格”的初稿。我需要做的是把它生成的代码当成一个新同事交上来的代码去 review而不是从零开始敲。这篇文章我想认真聊聊AI 到底是怎么改变“拼 UI”这件事的。它适合前端、Android/iOS 客户端、Unity 开发者也适合被 UI 细节反复折磨的全栈和独立开发者。我会讲清楚 AI 能做哪一段、做不了哪一段然后把我的完整流程和踩坑记录全部分享出来。主要内容不是理论分析全是实操我用 AI 做过后台管理系统也用 AI 改过 Unity 的界面还踩过跨线程更新 UI、列表卡顿这些经典的坑。1. 拼 UI 的痛苦不在手指而在反馈回路先亮一个观点写 UI 累不是因为敲代码本身累而是因为“写代码 → 看效果 → 调整 → 再看效果”这个反馈回路太长、太碎。AI 真正改变的不是替你把按钮生成了而是把这条回路里最耗时的前半段砍掉了。1.1 表面是摆控件实际是在跟像素和状态搏斗我见过太多刚入行的朋友以为写界面就是把控件拖到画布上。等真到项目里面对一个业务页面他们才发现真正的噩梦是按钮的位置看起来不对但又说不出不对在哪样式改了一处另一个完全不相关的页面也跟着变形深色模式下某个文字颜色对比度不合格产品在群里直接点名。这些问题的共性是什么它们都不是“不会写”的问题而是“反馈太慢”的问题。你每调整一次都要经过编辑、编译、运行、肉眼比对、再调整一轮下来五到十分钟是常态心态差一点的来回五轮就已经想摔键盘了。我做过一个后台管理系统页面逻辑不复杂但设计稿要求每个卡片间距 12px、列表行高 32px、按钮在 768 和 1440 两种宽度下都要对齐。这些需求用代码表达不难难的是它们互相牵连左边距一改右边的占比就要动字体缩放一调按钮的固定宽度就让文字溢出。我经常为了一个“差 2 像素”的问题把整个布局重排一遍。更折磨人的是状态。同一个按钮要有默认、悬停、按下、禁用、加载中、成功、失败七种样子同一个列表要有空态、加载态、错误态、正常态。手工拼 UI 的时候这些状态全靠人肉记忆漏一种测试就能给你提一个 bug。1.2 不同技术栈折磨人的方式各有各的花样很多人以为只有前端才被 UI 折磨真做起来才发现每个技术栈都有自己的“特色惩罚”。我说几个最常见的场景。在 C# 的 WinForms/WPF 项目里你开一个 Task 去查询数据查到之后想顺手把 Label 的 Text 改掉十有八九会收到那句经典报错跨线程操作无效。在 Unity 里一个 UI 数字滚轮效果看起来简单真做起来要同时处理 ScrollRect 的惯性、文本滚动的复用和遮罩一套代码下来能折腾半天。在 Android 的 Activity 里想要用原生控件堆出一个好看的筛选面板布局层级稍微深一点五年前的老机器跑起来就开始掉帧。这些场景的技术细节完全不同但背后是同一个东西反馈回路太长。每个小改动都要经过“代码 → 编译 → 运行 → 验证”的一次循环而这类 UI 细节问题偏偏需要在真实环境里反复验证不能靠脑补。1.3 当反馈回路被压缩写 UI 的心态就变了现在我用 AI 的方式是把需求写成一两段话让大模型直接给出一版符合技术栈的页面代码。大部分场景下它给出来的已经不是“伪代码”了而是能直接跑起来的 Vue 组件、Android 的 XML 加 Activity、Unity 的 UI 构建脚本都不在话下。我拿到之后进入的不是“从零搭建”模式而是“review”模式。我会看它生成的骨架逻辑对不对、组件用没用对、边界情况有没有漏而不是亲手把一个一个标签敲出来。这个转变的魔力在于同样的反馈回路还在但每一轮循环里我的精力只花在判断和修改上而不是花在生成和猜测上。心态完全不同效率也是两个量级。2. AI 接管的是“从描述到骨架”不是“从业务到体验”很多人一听 AI 能写 UI就问“那我是不是不用学前端/客户端了”。我的回答是AI 接管了“从描述到骨架”这一段但“从业务到体验”这段它目前只能当参谋当不了决策者。2.1 把 AI 当“会写代码的设计师”十有八九会失望我一开始也干过这种事给 AI 发一张设计图让它“照着做一个登录页”。它做出来的东西远看挺像放大看细节全崩间距不统一、圆角数值随手写、空态和加载态完全没有、颜色用的也不是设计系统里的色板。后来我想明白了大模型是通过海量代码和设计模式“学”出来的它更擅长把你描述的需求映射成一种主流的、常见的实现方式而不是像一个资深设计师那样理解品牌调性、理解业务优先级、理解无障碍规范。你可以把它当成一个经验丰富但记性很差的高级实习生——你得把需求讲得足够清楚还得在它交作业之后认真检查。2.2 AI 真正擅长的三件事第一自然语言转代码骨架。你说“左侧筛选栏、右侧结果列表、顶部条件栏”它能快速生成一个布局合理的页面结构。这个能力非常能打省掉的是你最不想干的“摆框架”阶段。第二组件拼装。在指定了组件库之后比如 Vue 配 Element Plus或者 Android 配 Material 官方的那些常用控件AI 很擅长把这些组件按你的描述组合起来省去你查文档、记属性名的时间。尤其适合快速搭一个信息密集型页面。第三风格收敛。你给几张参考图或者一段“颜色随主色、圆角统一 8px、间距用 4 的倍数”描述它能比较稳定地把这种风格带到整个页面。这相当于把一个“懂一点视觉规范”的人塞进了开发流水线。2.3 AI 的边界业务语义、交互状态、隐性约束边界也很明显。AI 不会知道你那个表单里的“手机号”字段要不要做运营商动态校验不会知道列表在弱网环境下要显示骨架屏还是缓存旧数据不会知道某个按钮在特定权限条件下应该直接隐藏而不是禁用。这些业务语义只能靠人来补。交互状态也一样。AI 生成的页面往往是“静态美”按钮好看、布局对称但你一点发现没有点击波纹、没有加载提示、没有提交后的防重复逻辑。当场能用一接入真实数据流就露馅。所以我的判断是AI 是 UI 生产流水线的“初稿车间”而不是“质检车间”。初稿的生产成本降到接近零之后真正拉开差距的变成了你对业务的判断和代码审查能力。3. 我把一套日常在用的 AI 生成 UI 流程搬到了这里理论说完了给一套能直接用的流程。我现在做一个普通业务页面基本就走四步写任务书、出骨架、接工程、穿规范。这套流程不是某个工具特有的只要你的 AI 工具支持文本对话和代码生成就能直接套用。3.1 把需求翻译成指令提示词不是越多越好很多人的 AI 提示词写不好不是写得太少而是写得太泛。我给 AI 交代 UI 需求时固定包含六类信息角色、技术栈、页面用途、组件清单、交互要点、约束条件。我自己常用的模板长这样你是一名资深前端/客户端工程师。请用 [Vue 3 TypeScript Element Plus] 实现 [后台系统的用户列表页]。 页面需要包含顶部筛选区关键字输入框、状态下拉、搜索按钮、重置按钮、中间数据表格列用户ID、昵称、手机号、状态、创建时间、操作、底部操作按钮新增、批量导出。 交互要求搜索时表格展示 loading空数据时显示空态插画状态列用 tag 展示且不同状态配色要区分。 约束间距统一按 4 的倍数圆角统一 8px主色使用 Element Plus 默认主题色不要引入额外依赖代码输出为单文件组件。这段模板看起来简单但每一条都有用“角色”让 AI 选择合适的技术水平“组件清单”避免它自由发挥“交互要点”补上静态页面最容易缺的状态“约束”则把它的设计自由度关在笼子里。实测下来同样的需求不加约束和加约束生成结果的可用天差地别。3.2 先骨架后精修一个表单页的生成实例我最近做一个用户反馈表单需求是左侧信息预览、右侧填写区提交前有二次确认。我先让 AI 生成整体骨架拿到的是这种结构去掉样式后的核心示意template div classfeedback-page aside classpreview-panel.../aside main classform-panel el-form :modelform label-width80px.../el-form /main /div /template script setup langts const form reactive({ type: bug, content: , contact: }) const submit () { /* TODO */ } /script骨架出来以后我不会让它直接出“最终版”而是分段精修先生成布局再让它补交互最后补校验。每一轮只交代一个重点比一次性要一个完美页面稳定得多。实测下来分段迭代的成功率比一次性生成高非常多尤其是涉及状态管理和异步逻辑的时候拆开做基本不会跑偏。3.3 接进工程AI 看不见的线程、生命周期和资源约束AI 生成的代码跑在“理想环境”里接进真实工程之后各种环境约束就出来了。最典型的例子就是 C# 里用 Task 更新 UI 的问题。AI 经常生成这样的代码看着逻辑没问题private async Task LoadDataAsync() { var data await FetchDataAsync(); textBlock.Text data.Summary; // 跨线程访问运行到这儿直接异常 listBox.ItemsSource data.Items; }看起来挺正常但 UWP/WinForms/WPF 里await 之后的上下文能不能回到 UI 线程取决于你从哪边发起调用。项目一旦用了 ConfigureAwait(false)或者由后台任务驱动这里就会抛“调用线程无法访问此对象”的异常。真实的修法通常是用 Dispatcher / SynchronizationContext 把更新切回 UI 线程private async Task LoadDataAsync() { var data await FetchDataAsync().ConfigureAwait(false); Application.Current.Dispatcher.Invoke(() { textBlock.Text data.Summary; listBox.ItemsSource data.Items; }); }所以 AI 生成的代码进工程我一定会逐行检查线程、生命周期、资源释放这几个点。它写的是“逻辑正确”而我们的工程需要“环境正确”。这一条最容易劝退新人因为 AI 生成的代码可以编译、可以运行唯独在你的特定环境里跑起来才出问题。3.4 让 AI 照着你们的规范来组件库是我最后的底线AI 自由发挥最容易导致的问题是页面长得和团队其他页面不像一家人。我的解决办法很简单在提示词里把组件库列为硬性约束不允许它自己造轮子。Android 就用 Material 的官方控件把常用控件列清楚Vue 项目就锁 Element Plus 或 Ant Design VueUnity 里就限定 UGUI最多加一个团队已经引入的第三方插件。我在 3.1 的模板里加了一条“不要引入额外依赖”就是在逼 AI 用现有组件。它要是搞了一堆网上流行的宽组件接进团队设计系统时你会哭的。这条约束看着很不起眼实际能帮你省掉一场大重构。4. 落地时我踩过的五个坑从“伪绿色编译”到“真卡顿现场”AI 写 UI 不可能一帆风顺。这五个坑都是我真金白银踩过的每一条后面都跟着一个具体的修复思路而不是一句“大家要注意”。4.1 坑一AI 会自创一套“同时还挺好用”的设计语言第一次用 AI 做一套完整后台页面时我发现三个页面出现了完全不同的按钮圆角、两套阴影变量、深浅两套灰。单看每个页面都挺精致拼在一起就是精神分裂。原因也很简单AI 在生成第一个页面时选了一套风格在生成第二个页面时不会记得第一个页面选择了什么。我后来的做法是所有页面用同一个 project-level 的提示词抽出全局的设计 token颜色、间距、圆角变量让所有生成结果引用同一套变量。AI 不记得上下文我们就用“提示词里的设计规范”帮它记。4.2 坑二编译是绿的运行是崩的这个坑在新手区特别常见AI 生成了一段代码编译直接通过但运行到一半崩了。我碰到过 Android 里 Theme 资源引用写错、资源 ID 用了不存在的名字、Unity 里引用了尚未导入的第三方 UI 插件比如某款 Curved UI 的命名空间一进场景就空引用。排查这类问题我的思路是先把 AI 生成的代码拆开只看“资源引用”和“依赖注入”部分因为它们是最容易和环境错位的。其次不要直接全量替换原有页面把 AI 生成的代码放进一个沙盒层级或者一个隔离的 Activity 里去跑确认没问题再集成。这套隔离验证的习惯能帮你省掉一大堆“为什么一接进去就崩”的排查时间。4.3 坑三跨线程更新 UIAI 默认不会帮你兜底这一条 3.3 已经详细举过 C# 的例子但值得从坑的角度再强调一次AI 生成的代码基本上不会考虑线程上下文因为它训练数据里大量代码是发生在 Main 线程假设下的。Unity 里更明显。非主线程访问 GameObject 的任何属性编辑器模式下直接报“get_gameObject can only be called from the main thread”。AI 生成角色移动、数据加载这类逻辑时几乎必然会漏掉这个约束。所以凡是涉及异步数据的 UI 更新我在验收清单里一定会加一行确认更新 UI 的代码运行在正确的线程上必要时显式切线程。4.4 坑四AI 生成的页面卡顿往往从一开始就注定了AI 对性能不敏感这是它最让我头疼的地方。它喜欢生成层级很深的嵌套布局、大面积的阴影和模糊、ListView 里不用复用直接 new View、Canvas 里塞满不必要的重建。结果就是页面是漂亮了手机一滑就掉帧。排查 UI 界面卡顿我按三个顺序来先看列表是否复用再看布局层级有没有没必要的外套最后查阴影、模糊、半透明这些高成本效果有没有滥用。对应到 AI 生成的代码90% 的卡顿都逃不出这三条。修完之后页面可能没那么“华丽”了但用户滑起来舒服多了。性能优化这种事AI 目前真的干不了还得靠人盯着。4.5 坑五把 AI 的自由度当成设计能力这个坑最隐蔽。AI 有时候会给你一个意想不到的布局方案看着还挺惊艳。但你要知道那大概率是它在某个开源项目里见过的模式不代表它理解你为什么需要这个页面。我之前让它做一个数据大屏它给了一套很炫的带轨道动画的卡片布局结果真实数据一接进来信息密度低得离谱业务方看了直接摇头。从那以后我给自己定了一条规矩AI 输出里的“意外惊喜”先问三个问题——它符合我的业务目标吗它符合团队设计规范吗维护成本我能接受吗三个问题有一个不达标就宁可回到保守方案。5. 关于“再也不想拼 UI”我的真实想法说了这么多回到标题这句话。5.1 从“拼 UI”到“验收 UI”工作重心的转移“再也不想拼 UI”不是“再也不写 UI”。我现在每天早上最常做的事情是拿着产品的一句话需求花两分钟写一段任务描述然后把 AI 吐出来的代码当成新同事的 PR 来 review。我会看它的布局逻辑、状态管理、可读性而不是亲手去拼每一块控件。UI 还在但“拼”这个过程确确实实已经从我的日常里退场了。写到这里有一件事我越来越确定在 AI 生成能力普及之后团队里最缺的不是“会写控件的人”而是“能准确描述需求、能识别 AI 生成结果好坏、能补救业务语义”的人。这也是为什么我现在会花一部分精力去研究提示词工程和 AI Agent 的编排说白了就是学着更好地给 AI 当项目负责人。5.2 哪些人现在就该把 AI 放进 UI 流程我把人群粗分成三类给个基于个人经验的建议前端/客户端写业务页面的同学强烈建议现在就把 AI 放进日常流程哪怕只是让它生成初稿。你省下来的时间可以拿去研究交互细节和性能优化这两样才是未来真正的竞争力。独立开发者或全栈这波人受益最大。我以前一个人做小项目最怕就是页面的视觉细节没人把关。现在 AI 至少能给你一个及格线以上的界面你已经比“裸写”时代强太多了。设计转开发或“正在犹豫要不要学代码”的朋友我的建议是别怕AI 把 UI 开发的门槛又压低了一大截。但基础原理还是要补至少要看得懂组件、状态、布局这三个概念不然连验收都做不了。5.3 我目前最顺手的提示词框架直接拿去改最后把我在 3.1 模板基础上迭代到现在的“完整版”框架分享给大家。它比上一版多出一个“评审段”我甚至会让 AI Agent 先把生成结果自评一遍相当于在人类 review 之前先让 AI 自己过一遍最常规的检查【角色】你是一名严格的 UI 代码审查员同时也是一名 [技术栈] 高级工程师。 【任务】生成并自审一个 [页面类型]需求如下[两到三个自然段包含页面用途和核心问题]。 【组件清单】只能用以下组件[列出组件库和常用组件名称]。 【交互要求】[列出关键交互比如 loading、空态、防重复提交]。 【约束】[间距、颜色、圆角、依赖限制、性能要求]。 【自审】代码生成完成后请自查以下四点 1. 是否存在跨线程直接修改 UI 的问题 2. 列表是否进行复用是否存在不必要的深层嵌套 3. 是否遗漏了 loading / 空态 / 错误态 4. 是否引入了清单之外的第三方依赖。 【输出】直接输出可运行的完整文件不要解释思路。这段提示词我实测用了很久稳定性明显比第一条那种“自由发挥版”高。你把它拿回去只要把【技术栈】【组件清单】【约束】三段换成你自己的就能直接用。我个人在这段时间最深的体会是AI 没有让 UI 开发变得无聊反而让“审美”和“工程规范”这两个维度的价值变得更大了。以前你想认真调一个页面得先付出大量敲代码的成本现在初稿成本归零你终于可以把精力放在真正该放在的地方——判断这个界面好不好用、有没有业务价值。所以拼 UI 这件事我是真的不想再拼了但设计 UI、打磨 UI、优化 UI我会一直做下去。