★ FEATURED ARTICLE 说实话两年前我接到一个内部管理后台的需求光是把数据表格的表头提示、空态、加载态、悬浮说明这些拼 UI的活干完就花了一个周末。那时候我以为 UI 开发的核心难点是布局、配色、组件拼接直到后来 AI 工具变得能用我才发现过去浪费了大量时间在重复劳动上AI 不是帮你把界面变漂亮而是帮你把拼这个动作本身干掉。我在这篇文章里想聊的不是AI 会不会取代前端这种话题而是我实际用它重构一套充电桩运营监控大屏 UI 的完整过程。里面有真实的提示词、踩坑记录、性能排查思路也有 AI 在 Web、移动端、游戏界面这些不同形态下的表现差异。如果你也是每天在跟表格、弹窗、样式、卡顿、切图较劲的前端或全栈这篇应该能给你一点可以直接抄的作业。1. 一个充电桩监控大屏的复活AI 接手 UI 的真实场景拆解先交代一下背景。我手上这个项目是充电桩运营管理平台的监控大屏页面要展示实时充电功率、设备状态、订单流水、故障告警、充电量趋势这些数据。需求方给的原话是搞得科技感一点最好数字动起来别像传统后台那么死板。这种需求听起来不难但真做起来全是细碎活。我还得处理表格列提示文字、电量数字滚动动画、聚合地图标记、图表在数据刷新时的闪烁问题。以前我至少需要一个完整周五来搭骨架再用下一周调细节。这一次我从头到尾用 AI 辅助完成工期大约压缩到了一天半。1.1 需求里那些看似不起眼却最耗时的 UI 细节很多人以为拼 UI 就是拖控件、摆 div其实真正让人头秃的是那些小细节。拿表格来说用户鼠标移到列名上要出现提示文字列宽拖拽后要记住状态数据为空时不能白屏要有空插画网络慢时要有骨架屏而不是转圈。这些功能单个拉出来都不复杂但堆在一起就是海量样板代码。我这次跟 AI 协作的时候第一步就是把这些细节需求全部以清单形式丢给它让它按优先级输出实现方案。AI 给出来的方案比我预想的还要细比如表头 title 提示它建议用 slot 自定义渲染而不是简单塞 title 属性因为要保证长文本截断后鼠标提示才生效空状态它不是画一个图标而是建议直接复用现有组件库的空状态组件保持视觉统一。这里有个重要经验AI 本身不熟悉你的组件库但你把组件清单和设计规范喂给它之后它产出的代码贴合度会高很多。我第一次偷懒没喂规范AI 就给我生成了一套基于 Antd 的表格可我项目里实际用的是 Element Plus来回改了一个小时。后来我把组件库入口文件、几个典型页面代码、设计变量全部作为上下文丢进去准确率明显上升。1.2 我让 AI 干的第一个活把 Web 版数字滚轮做出来充电桩大屏最显眼的应该是尖峰电量数字需求方希望它有翻滚效果像老虎机那样的数字变速滚动。这个效果在游戏引擎里很常见我在 Unity 里做过数字滚轮 UI但要在 Web 上复刻还要配合大数据量的实时刷新就没那么轻松了。我先让 AI 给了一个纯 CSS 方案数字列固定高度用 transform 做偏移模拟滚动。这个方案最简单但每秒钟刷新一次数据时会产生闪烁因为数字位移和重绘不同步而且列表在快速重排时会触发大量重绘。我把它遇到的问题以及性能诉求反馈给 AI第二轮它给出了更成熟的方案把数字切成单个字符每个字符定位在固定格子内数据变化时通过 requestAnimationFrame 驱动 translateY 从 0 到 100% 再回到 0同时用一个虚拟容器限制 DOM 数量。这个方案跑起来顺滑多了CPU 占用从之前的 30% 降到 8% 左右。更让我惊喜的是AI 主动说明了两套方案之间的取舍逻辑而不是只丢代码。1.3 从AI 能出图到AI 能出代码中间发生了什么前两年我们聊 AI 做 UI更多是指 AI 出视觉稿比如生成一张大屏的 mockup 图。用 AI 生成设计图是一回事让它直接产出可运行的前端代码是另一回事。这个能力的跨越靠的不只是模型变强更靠开发方式的改变把设计稿拆成组件树、用组件命名约束生成范围、通过代码审查让 AI 自我修正。我在这个项目里的做法是先让 AI 根据大屏布局生成 JSX 组件树而不是整页代码。组件树确定后我再逐个组件对话让 AI 填充业务逻辑和样式。等于把一个大任务拆成几十个小任务每次对话上下文只有几十行AI 的出错率和代码一致性反而更高。这一步是整个工作流的核心。很多人让 AI 一次性写一个完整的页面结果生成的代码需要修半天才能用换成组件树 → 逐组件生成 → 集成自测的流程后我几乎不需要大改结构AI 的代码能直接跑起来。2. 用 AI 写 UI 的真实体验三种拼法三种感受AI 写 UI 不是一个笼统的能力它在一部分场景下强得离谱在另一部分场景下又会弱得很明显。我按自己实际做的三类工作聊一下感受分别是拼框架组件、拼数据表格、拼视觉效果。2.1 拼组件让 AI 按成熟框架写页面而不是自己从零搭我大部分后台项目都基于现成组件库比如 Vue 搭配 Element Plus、React 搭配 Ant Design。这类框架的好处是组件丰富坏处是拼装的样板代码量大。Modal 要管 visible、confirmLoading、表单校验Table 要配置 columns、pagination、loading、row-selectionForm 要处理校验规则和布局。这些样板代码正是 AI 最擅长的地方。我把需求描述成一段自然语言比如一个用户列表页支持按昵称搜索、状态筛选、分页、批量禁用禁用后弹窗确认AI 就能生成一整份符合组件库规范的页面代码甚至连 loading 状态和错误提示都给你加上。实测下来AI 在这类任务上能覆盖我八成左右的样板代码量我只需补上真实的 API 调用地址和数据格式映射。2.2 拼表格EasyUI/Element 这类数据密集组件的 AI 提速套路我一开始用的是 EasyUI 的老项目后来才逐步迁移到 Element。EasyUI 的 datagrid 配置方式跟 Vue 组件很不一样它的列定义、编辑器、格式化函数全挤在一起写起来又长又难维护。最烦的是列头的 title 提示需求方要求鼠标悬停在每一列表头时要显示一段说明文字EasyUI 里这段逻辑要靠列的 title 属性加上 CSS 覆盖来实现写多了真会吐。我让 AI 按 EasyUI 的既有写法批量生成列配置把需求里那些字段备注直接翻译成工具提示代码。AI 处理得比我预想还干净它不仅把 title 属性补上还自动加了当字段值过长时用 formatter 截断并保留 title这种细节。后来我把这类代码整理成了项目内的工具函数新人来了直接引用不用再逐个写。2.3 拼视觉效果修圆角、调渐变、对齐栅格这些眼睛活视觉细节这个东西最玄学因为好看本身很难量化。AI 在纯审美层面其实一般但它在把审美转化为代码参数这件事上很高效。比如需求方说这个渐变不够通透AI 会根据你给出的 base color 自动生成一组 box-shadow 和 background 参数你逐个试就知道哪个方向更接近想要的效果。这种工作有点像A/B 测试 参数调优。我把设计稿里截图的色值喂给 AI它生成侧边栏渐变底、发光边框、悬浮高亮这些装饰代码我再手动微调对比度。整一套下来比我自己从零配有头绪得多至少不会出现那种调了半天颜色还是很脏的局面。但我也必须承认AI 在视觉审美上依然缺乏判断力它不知道这个配色适不适合充电桩品牌的行业气质最终把关只能靠人。3. 把 AI 调教成靠谱 UI 搭档的三段式提示词法一段好的提示词远不是帮我写一个登录页这么简单。我在项目里最终沉淀出一套三段式提示词流程按这个流程来AI 的产出会稳定很多返工次数明显减少。3.1 第一段喂上下文而不是只提需求你会发现AI 对充电桩监控大屏的理解和你团队里的上下文差异很大。你不给它背景它只能给你一套通用后台模板样式、字体、按钮大小都不匹配。我一般会把以下内容作为上下文的一部分给 AI项目技术栈Vue3 Element Plus Vite ECharts。现有组件el-table, el-select, el-date-picker, el-dialog附带组件文档片段。设计约束主色、圆角、字体、间距、明暗背景防止 AI 生成风格不一致的代码。同类页面代码拆一段之前页面的模板对比告诉 AI 照着这个路子写。有一次我给 AI 看了大屏的整体截图和数据 JSON 格式再提出页面布局需求它生成的 ECharts 配置和数据结构能直接对上省了我大量做数据映射的时间。所以我的建议是上下文越接近真实项目AI 的代码越接近可直接交付的状态。3.2 第二段给 AI 规定约束与验收标准描述需求时光说需求还不够。我会明确告诉 AI 不要用什么写法、必须用什么写法。比如虚拟列表只允许通过 vueuse/core 的 useVirtualList 实现不要自己手写、表格分页必须在 URL query 中同步页码组件内部不要保存独立分页状态。这些约束的作用是让 AI 在取舍时不会自作主张。有一次我没约束状态管理AI 自作主张用了 Pinia 来保存一个只在单页内使用的筛选条件虽然也能跑但明显是过度设计。后来我在提示词里写了保持简单、无外部依赖、组件自治之后代码质量反而更高。同时我会让 AI 把自己生成的方案按功能性、性能、可维护性三个角度自评一遍再输出最终版本。它自评时往往能主动发现边界问题比如缺少 loading 态、没处理接口异常、数字滚轮在弱网下会卡死等等。3.3 第三段让 AI 自己写边界和异常态最容易被忽略的是异常态。普通开发者写 UI 时想的是数据正常时页面长什么样AI 如果只被要求写一个订单列表它也只会补正常路径。但真实系统的体验差距恰恰体现在异常处理上。所以每次生成页面代码后我会追加一条指令完整列出这个页面的所有异常态并给每个异常态实现一个可视化反馈。AI 会补充网络超时、请求失败、空数据、接口返回非法数据、权限不足这类情况。有人嫌这一步麻烦但对我来说这是让 AI 从写玩具代码过渡到写生产代码的关键一步。我还会让 AI 给每个异常态写测试用例的初始数据配合自动化测试跑一轮。这个习惯帮我提前发现了不少隐蔽 Bug比如接口返回 null 的时候el-table 的格式化函数会直接抛错。4. AI 查 UI 卡顿的实战记录从感觉有点卡到定位渲染瓶颈热词里有个ui界面卡顿这个我太有感触了。大屏项目最怕的就是数据每秒刷新时掉帧。这次我特意试了让 AI 作为排查搭档来处理卡顿问题整个过程比我自己一个人对着 DevTools 瞎猜要高效得多。4.1 卡顿问题的四种常见来源拿到页面卡顿报告后第一件事不是改代码而是定位卡顿属于哪一种。AI 帮我梳理出了四种高频来源DOM 数量过多表格渲染几百行数据不做虚拟滚动尤其大屏里同时显示多张图表时 DOM 节点轻松过万。频繁重排重绘数据每秒刷新时节点样式被反复写回触发 layout 和 paint。大数据图表更新ECharts setOption 时未做 diff或不设置 notMerge导致图例、坐标轴反复重建。意外内存泄漏计时器未清理、组件卸载后事件监听还挂着逐渐累积成卡顿。AI 在聊天里把这四类原因按从高概率到低概率排序建议我先用 Performance 面板录制 10 秒数据刷新过程看具体耗时结构再动手。比起我过去上来就改代码的方式这种先定位后处理的路子更稳。4.2 人机配合的排查链路完整的排查链路是这样的我先录制一段 Performance 数据把截图和录屏描述发给 AI它会看出一部分性能风险。然后我把它怀疑的代码片段贴给它它会指出可能的问题行并给出修改建议。我改完后再重新录制如此循环两轮基本能把问题收敛。这次卡顿的最终原因出乎意料不是图表本身而是数字滚轮组件里每个数字字符都加了一层 box-shadow。当时为了让数字更立体我给每个数字格加了很重的发光效果结果数据每秒刷新时浏览器不仅要重绘数字还要重新计算阴影层级。AI 看完 performance 截图后直接说这层 box-shadow 大概率是重绘成本主要来源建议去掉或使用合成层优化。4.3 一次实际的优化过程我按 AI 的建议把数字滚轮从逐字符实时更新改成三组滚动数字预渲染复用底色阴影改成 background 渐变模拟渲染成本立刻下来。接着表格区域上了虚拟滚动和固定列图表 setOption 加了 notMerge 和 lazyUpdate首屏加载和滚动流畅度都明显好转。这轮优化让我意识到一件事AI 作为排查搭档最大的价值不是直接给出答案而是帮你把一个模糊问题感觉有点卡转化成可以测量的技术指标。它能迫使你从问题描述一路拆解到代码可执行层这个过程中你已经把问题解决了一半。另外它不会像人一样依赖过往经验很多我没有想到的检查点它都会提出来比如 devtools 里的layers面板是否出现了大面积的层爆炸。5. 不同 UI 战场里 AI 的表现后台、移动端、游戏界面各有脾气我不只做 Web 大屏也偶尔帮朋友搞点移动端脚本和游戏 UI。AI 在这些不同形态里的表现差异非常大踩过一圈后我给大家交个底。5.1 Web 后台 UI 与大屏AI 最得心应手的区域Web 后台的规则性最强组件化程度高AI 生成代码的接受度也最高。尤其像筛选区、表格区、分页区、弹窗区这种标准化布局AI 几乎已经形成肌肉记忆了。大屏场景也比我想象中好因为 ECharts 这类图表库的配置项文档非常丰富AI 对配置项和数据结构之间的映射关系理解得很好甚至能帮你把设计稿里某个复杂交互拆成图表的下钻配置。我同事那边还接过一个需求给 KafKa 做个简单的监控面板只要有主题分区状态、消费组积压量、Broker 健康检查这些模块。这种偏运维的 UI 之前开发起来挺麻烦因为大家平时不写组件规范也不熟。换成 AI 后我同事花了半天就拼出能用的版本页面虽然简单但信息展示清楚运维同事很满意。这说明只要需求本身足够结构化AI 在 UI 开发里真的能当半个生产力。5.2 移动端 UI 与自动化回归用 Maestro 验证 AI 写的界面移动端的 UI 开发和 Web 相比多了不少设备适配和手势交互上的细节。AI 在移动端一样能生成原生视图代码但问题在于没法直观看到效果不能用浏览器 DevTools 实时调试。所以移动端用 AI 写 UI 时我额外重视自动化验证。热词里有人搜 maestro ui 自动化我正好拿它做过一个验证场景。我在 Flutter 里让 AI 生成一个充电桩详情页界面包含状态标签、滚动数字、故障记录列表和底部操作栏。然后我让 AI 先生成 Maestro 的 YAML 描述文件通过几个简单的 flow 脚本跑通滚动列表 → 打开详情 → 点击操作按钮 → 返回首页的回归流程。跑第一遍就发现故障记录列表的滚动区域高度没设置正确手势被底部操作栏遮住了一部分。如果只看代码这种问题我可能得在真机上来回调半天靠自动化回归一下就暴露了。移动端用 AI 写 UI最大诀窍就是让代码生成和自动化测试同时交给 AI让 AI 自己来回找问题效果会好很多。另外我在 PyCharm 里装了 AI 插件顺手把后端的接口返回字段拿给 AI 做了一轮前端对齐。它帮我把 Python 返回的 key 名和 Flutter 模型字段映射好了节省了不少手工核对时间。AI 在跨语言、跨端的信息同步方面价值被很多人低估了。5.3 游戏 UI 里的 AIUnity、ShaderGraph 与虚幻引擎插件游戏 UI 是另一码事。Unity 的 UGUI、ShaderGraph 的材质逻辑、虚幻引擎的 Web UI 插件这些都属于特定引擎深度绑定AI 也能帮你写 C# 脚本、帮你配置渲染管线节点但它完全不了解引擎里的实际画面表现。UE 的 UI 组件布局、锚点动画这些信息很难通过文字描述准确传达给 AI。我在 Unity 里用 AI 生成过 HUD 的血条控制脚本和数字滚轮效果的 C# 逻辑这部分挺顺手因为它本质是代码逻辑。但你要是想让 AI 帮忙调美术风格、Bloom 参数、UI 特效层级的节奏感那它给的建议就比较空泛了。我试过让 AI 给 ShaderGraph 的节点连线提供建议它能指出概念上应该用 UV 翻转还是噪声扰动但实际节点怎么连还是得自己在编辑器里一步步试。游戏 UI 这块AI 目前更适合做小零件而非大场面。6. 团队里的AI 新同事效应协作模式和我的心态变化工具用久了人会变。我现在已经不把 AI 当成一个搜索引擎或者代码片段生成器它在我的工作流里更像一个新加入的试用期前端我需要给它分活、验收、提修改意见也会偶尔被它的发挥惊艳到。这个过程改变了我对拼 UI的很多看法。6.1 我把 AI 当作第二个前端分活、验收、回退以前的协作模型是我 → 代码现在更像是我 → AI → 代码。我会把页面拆成具体的任务卡发给 AI 执行执行结果再走一遍原有的代码审查流程。AI 不需要休息但需要验证尤其是它生成代码里的边界条件、命名一致性、异常处理逻辑必须人工过目。有一次 AI 自动给表格加了一列操作按钮按钮点击后要打开详情弹窗。它写的 onClick 事件里弹窗组件参数绑定对了但忘了在关闭后重置表单数据导致二次打开时残留上次的输入。这个 Bug 如果不靠 review 根本发现不了但通过验收环节就能挡住。所以我的心态已经变成让 AI 最大程度地干活但交付责任永远在我这里代码永远要过了我的眼才能出仓库。6.2 记录 AI 对话形成团队的 UI 资产干得多我发现AI 对话本身也能成为团队资产。我会把那些效果好的提示词和 AI 给出的通用代码段整理成项目手册比如数字滚轮组件的三种方案对比、EasyUI 表格提示文字的批处理套路、大屏表格虚拟滚动配置参考。新同事加入项目后直接看这些手册比翻几千行代码更高效。这种做法还有个额外好处就是下次遇到类似需求我可以直接复制自己验证过的提示词模板省去从零调整的功夫。尤其是那些约束类提示词比如禁止使用 xxx 写法优先复用现有组件必须覆盖异常态写一次并验证过后后续项目都能复用AI 产出的基线水平就被抬高了。这比我手动写一套内部组件规范更快更落地。6.3 仍旧留给人自己的东西审美判断与交付责任虽然 AI 帮我干掉了大量拼的工作但有些东西我不会交出去。第一是审美判断。AI 可以生成一百种渐变方案但这个背景跟品牌调性是否匹配、这个交互动效会不会让用户眼花缭乱这种主观判断还是得由人来做。第二是需求理解。需求方经常话只说一半科技感三个字背后可能是要更动效、更亮眼、更数据感AI 不会追问而我会。第三是责任边界。线上出了 UI 事故客户不会找 AI只会找我。我现在最深的感受是拼 UI 这个动作变轻了但做好 UI 这件事没有变轻。省下来的时间我用来研究业务数据怎么呈现更直观、不同角色看大屏时的阅读动线、以及真实用户操作时的触点路径。这些思考比再抠一个像素有价值得多而这恰恰是 AI 暂时无法替代的部分。如果你也在尝试用 AI 重构自己的 UI 开发流程我的建议很简单从小处开始挑一个你最烦的重复性页面用我上面的三段式提示词跑通一遍然后慢慢扩大边界。你可能会在某个瞬间突然发现自己真的已经很久没有拼 UI了。
阅读完成 · 觉得有帮助？
