企业官网建设流程全解析

说实话，两年前我接到一个内部管理后台的需求，光是把数据表格的表头提示、空态、加载态、悬浮说明这些"拼 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-selection，Form 要处理校验规则和布局。

这些样板代码正是 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 里的 AI：Unity、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"了。