企业官网建设流程全解析

从入行做前端到带团队，我一直觉得写功能逻辑不算难受，真正磨人是"拼 UI"。栅格对不齐、间距差一像素、hover 态漏了、空状态没做、不同屏幕下按钮飘了——这些破事每一个单独看都不难，攒在一起就特别消耗士气。直到这两年 AI 编程工具变得能打之后，很多过去要花大半个晚上对付的界面活，变成了"提需求 + 改细节"。这篇文章我就想把自己实际用下来的工作流、提示词模板、还有踩过的坑完整分享一下，算是给自己做一个阶段总结，也希望能给还在被 UI 拼搭折磨的朋友一点参考。

1. 从"拼积木"变成"提需求"，是这几年最值的一次工作方式更新

1.1 拼 UI 的旧时光：真正苦的不是写代码

先说清楚，我说的"拼 UI"，不是指拿设计稿做还原这种手艺活，而是指那种"没有设计稿、只有产品一句话需求、但你还得把界面做得能看能用"的开发场景。

比如后台管理系统，运营告诉你"给我一个用户列表页，要有搜索、筛选、批量操作、分页，状态用标签展示"。听起来不复杂，但真上手你会发现，光是一个列表页就藏着不少工作量：

• 表格列怎么定，宽窄怎么控制，内容超长怎么截断；
• 搜索区几个字段、筛选用什么控件、下拉框数据从哪来；
• 批量操作用复选框还是行内按钮，选中态怎么高亮；
• 分页组件要不要带总数，当前页跳转怎么处理；
• 空数据、加载失败、无权限这些"边角状态"谁来做。

过去做这种事，我的常规路径是打开一个组件库（Ant Design、Element Plus 之类），找到现成组件，然后开始调样式、写状态逻辑、处理各种边界。表面看是在"组装"，实际上大量的时间花在理解组件的 props、把需求翻译成组件的配置、再用 CSS 把默认样式磨成想要的样子上。这种活干久了会觉得自己像个翻译器：把人类语言翻译成 UI 框架的语言，而且每换一个项目，组件库的方言可能还不一样。

组件库还有个问题：它只提供单点组件，不提供整页结构。页面布局、栅格系统、响应式断点、层级关系，全都得靠人脑拼。真正累的不是某个按钮怎么写，而是所有东西在同一个页面上互相协调的那层"胶水"。

1.2 一句话生成页面的反差感，为什么让我改变了习惯

我第一次认真用 AI 生成完整页面，是因为当时接了个活儿：给内部工具做一个"数据看板"首页，十几个图表卡片要排布，每个卡片还要有标题、筛选下拉、刷新按钮、上次更新时间。

按过去的习惯，我得先想布局方案，再手写一版 HTML 结构，接着套样式，把卡片一张张填进去。大概需要大半天。那次我试着把需求写成一段文字扔给 AI，让它"生成一个响应式的数据看板页面，使用 Tailwind，包含 6 个统计卡片和一个折线图区域"。三十秒钟，它给了一版结构工整、间距合理、甚至带了图标占位的页面。

我当时的感受不是"哇，好厉害"，而是"完蛋，这玩意把我最会干的部分干完了"。以前我能理直气壮地说"UI 工作量就是大，得加时间"，现在这个理由站不住了。你让 AI 出基础稿，它真的是又快又稳，不太会漏掉栅格和间距这种基础问题。

用了一段时间之后，我把自己的定位从一个"UI 拼装工"重新调整成了"UI 架构师加质检员"：AI 负责把需求转成初稿，我负责定方向、提约束、改细节、卡质量。主力工作从"从零到一搭建"变成了"从一个能跑的东西上做减法"。心态完全不一样，效率也高了一个量级。

2. AI 不是魔法，但它确实抓住了 UI 开发的痛点

2.1 AI 擅长像什么：把自然语言翻译成组件结构

说个稍微技术的角度。现在的 AI 编程工具，本质是一个基于海量代码训练出来的大模型，它的强项在于做自然语言到代码结构的映射。你告诉它"三列布局，左 200px，中间自适应，右边 300px"，它知道去找 flex 或者 grid 的写法；你说"表格要有斑马纹和悬浮高亮"，它知道对应的样式属性是什么。这个过程和我们人看需求文档写代码是同一个信息处理路径，只是它不用一页一页翻文档，也不用记组件库的 API。

所以 AI 在 UI 领域最强的场景，恰恰是那些"套路化但细节多"的需求。比如后台的 CRUD 页面、表单页、列表页，几乎每个平台长得差不多，AI 见过大量的样本，输出的东西非常稳定。反过来的弱项则是那些真正有原创设计感、需要审美判断的界面——这种活它目前还是在模仿，容易给你一个"看起来还行但没什么气质"的结果。

想通这件事之后，我给自己的原则是：凡是重复度高、结构清晰、有明确组件范式的 UI，全部交给 AI 起底；凡是需要审美锚点、品牌调性、交互创新的界面，AI 只用来出想法草图，主稿还是自己来。这样两边都能干得舒服。

2.2 三种主流 AI 辅助路径：代码生成、图生代码、组件拼接

现在工具很多，但归纳下来就三条路，选哪个取决于你的起点是什么。

第一类是文本直接生成代码，代表是各类 AI 编程助手和对话式开发工具。你给我一段需求描述，我直接吐出 React/Vue 组件，附带样式文件。适合需求已经比较清楚、你又需要把它落成真实项目代码的情况。

第二类是图片转代码。你有一张界面截图或设计稿，AI 负责把像素还原成结构。这类工具对于"照着设计稿实现页面"的场景特别省力，但实际效果取决于图片清晰度、布局复杂度和代码风格要求。目前对简单页面能做到接近九成的还原度，复杂页面还是需要人工去收拾。

第三类是在设计工具里用 AI 做组件拼接，比如在 Figma 里用 AI 插件生成界面，再配合设计转代码工具导出。这条路径更适合设计师主导的团队，开发拿到的已经是设计好的图层，直接进入实现环节。

我自己是主力走第一条路，因为我们的输出物就是代码。第二条路偶尔用来快速给一个老项目页面做重构参考。第三条路我和设计师配合的时候体会过，效率的提升是明显的，但它的前提是团队的设计流程本来就比较规范。

2.3 为什么 AI 做基础稿比大多数新手还稳

很多人会觉得奇怪，AI 没有审美，为什么基础稿反而比刚入行的新人稳？我的理解是，UI 的基础稿质量，多数时候不是审美问题，而是完成度问题。

新手容易犯的毛病，不是不知道卡片要圆角，而是写了布局之后忘了加 hover 态、忘了空数据提示、忘了小屏下的换行。AI 不一样，它训练数据里那些高质量页面的完整度太高了，所以它天然会把这些"边角料"带上。你让它生成一个大表单，它大概率会给字段加上 label、必填星号、校验提示、提交和重置按钮；你让它写一个列表页，它大概率会处理 loading 态和空状态。

这恰恰是过去最消耗精力的部分。我自己写的时候也不是不会，而是要刻意去列一个状态清单，写着写着还是可能漏。AI 在"全面性"上确实像个经验丰富的老手——它不会因为写到第三个小时脑子糊了就漏掉一个 disabled 状态。

当然，这个"稳"也有限定范围：它只在它见过的模式内稳。一旦需求里有强烈的业务规则，比如某字段根据用户身份显示不同控件、某些操作只有特定角色能看到，它就容易出错，这部分的逻辑约束还得靠人来补。

3. 我用 AI 起底 UI 的完整做法

3.1 工具侧：我的主力与备选

先说结论，没用那种特小众的神器，主力其实就几个常见工具，关键是把它们用在合适的环节。

我的主力是：

• AI 编程助手（例如装进 IDE 以后可以对话生成和改写代码的工具）——日常写页面的主力，直接在项目上下文里生成组件，不需要复制粘贴，风格的连贯性也更好。
• Chat 型的通用 AI——用来做方案探讨和代码解释，比如"这段布局在窄屏下怎么优化""这个组件库有没有更好的表单布局方式"。它不需要接入项目，我把它当高级同事用。
• 网页端的 AI 界面生成工具（类似 v0、bolt 这类从文本生成可运行前端项目的）——适合做原型验证和一个独立小页面的快速产出。
• 设计图转代码的工具——遇到有设计稿的活，丢进去打底。

这里多说一句工具选型的逻辑。在 IDE 里用 AI 编程助手和在外面用对话式 AI 生成代码，体验最大的区别是上下文。前者能看到你项目里已有的组件、依赖和风格，生成的代码会更贴合实际情况；后者更像是"无中生有"，适合从零搭一个独立页面。所以我的习惯是：在已有项目里开发，就尽量用 IDE 里的 AI；只有做原型、Demo 或者临时小页面，才去用网页端工具。

备选工具方面，其实各家能力已经差距不大了，主要看适配的语言和框架熟不熟。我评判一个 AI 工具值不值得换，看三点：生成代码是否直接用我的技术栈、能不能引用项目里的现有组件、改动时是整体重写还是局部 patch。只要这三点满足，它对我来说就是合格了。

3.2 提示词里必须说清楚的信息

很多朋友说 AI 生成 UI 效果不稳定，我看了下他们的提示词，问题通常是太模糊。"给我一个用户管理页面"这种关键词，AI 只能凭默认印象发挥，发挥出来的自然不贴需求。

我总结下来的提示词要素，按重要程度排序大概是：

• 页面类型与核心模块：是列表页、表单页、详情页还是看板？核心模块有哪些？导航、内容区、侧边栏、底部这些结构先说清楚。
• 技术栈与样式方案：React + Tailwind？Vue + Element Plus？小程序原生？注意，这句一定要写，不写 AI 默认按它训练数据里最常见的来，可能不是你项目里的框架。
• 组件偏好：用我用得起的组件库还是纯手写样式？我一般指定"使用 @arco-design/web-react"或者"所有样式用 Tailwind 的工具类实现，不引入额外组件库"。
• 关键交互与状态：需要哪些交互逻辑？加载、空、错误状态要不要处理？有没有弹窗确认、折叠面板、拖拽排序这些特殊交互？
• 布局与风格倾向：栅格结构、间距风格、配色方向，能用一句准确的描述就别省。"整体风格偏紧凑、信息密度高"和"希望留白多一些、风格偏轻量"产出的结果天差地别。
• 参考坐标：可以给一个参考页面或参考设计图，让 AI 对照做，质量会大幅提升。

这里有一个非常重要的认知：提示词不是越详细越好。你要给的是约束条件，不是把每一块 UI 长什么样都描述一遍。比如你说"搜索区放四个字段：用户名、手机号、状态、时间范围"，这是有效约束；但你说"那个输入框宽度要 240px，按钮放右边，间距 16px"，这种过于琐碎的描述反而会挤占 AI 的注意力，最后它可能在小地方纠结，把整体布局给漏了。

3.3 从 AI 稿到接盘，需要我亲手改什么

AI 给的初稿，我一般默认是"可用但需要验收"。到手之后我不会直接去看小细节，而是按一个固定顺序做检查：

第一层，看结构。页面的信息层级对不对，头部、内容区、操作区是不是合理。这层错了，其他都不用看，直接让它重出。常见的问题是把表单按钮放在页面底部而不是右下角——这种属于结构级偏差，要在第一轮就打回去。

第二层，看状态。把所有交互状态过一遍：hover、focus、active、disabled、loading、empty、error。AI 虽然会比新手全，但涉及业务状态的时候还是漏，比如"某个角色看不到导出按钮"，这种条件渲染它写不准。我会重点审查这些有业务逻辑的状态。

第三层，看细节和规范。间距是不是成体系的、圆角阴影是不是符合团队规范、颜色有没有直接用默认蓝、字体大小层级是否合理。我会拿团队的设计规范对着改，把 AI 的"通用审美"调整成"团队风格"。

四层，看极端情况。文本超长、数字特别大、屏幕特别窄、浏览器缩放。我见过 AI 生成的日期范围选择器在窄屏下把页面撑裂了，这种问题它测不出来，只有人会用真实的边界数据去试。

这个顺序我严格执行，大概率能在一两轮之内把 AI 初稿收拾到可上线状态。比从零写还是省太多了。

4. 提示词是关键：把 UI 需求写明白的基础模板

4.1 一个实用提示模板

我把自己常用的一套提示词模板固定下来了，分享出来直接能套用。它不一定是最优解，但至少能让 AI 稳定输出符合预期的初稿。

请为一个[后台管理系统/移动端应用/数据展示平台]生成[页面名称]页面。 技术栈：React 18 + TypeScript + Tailwind CSS，组件基于 @arco-design/web-react。 布局要求：顶部为页面标题和主要操作按钮区；内容区采用 12 列栅格；卡片风格保持圆角 8px、无阴影或极浅阴影；间距以 16px 为基准，通过空格间隔而不是 margin 分散控制。 页面结构： - 数据概览区：4 个统计卡片，图标在左，数值和环比变化在右； - 筛选区：包含关键词输入框、状态下拉、创建时间范围选择器，以及"查询"和"重置"按钮； - 表格区：展示用户列表，字段包括用户ID、昵称、手机号、用户状态、注册时间、最近登录时间、操作列； - 操作列：提供"编辑""禁用"两个按钮，禁用按钮在用户已禁用时置灰。 状态处理：表格需要有 loading、空数据、加载失败三种状态；禁用操作前要弹出二次确认。 样式倾向：信息密度中等，留白适中，主色使用品牌蓝 #2B5CE6，次要文字统一 #8A94A6。

你看看，这里面几乎没有模糊词，全是可执行的信息。AI 拿到这样的提示，生成的页面基本不会跑偏。如果你对布局有自己的想法，就在布局要求里把结构写清楚；如果你只想看 AI 自由发挥，可以删掉布局要求，只留页面结构和状态处理。

我有一个心得：提示词里的"状态处理"是性价比最高的一行。很多时候我们拿到 AI 生成的页面，觉得"不错但总缺点东西"，缺的往往是状态。你明确写了要 loading、空、失败三种状态，它就会给表格加 loading 属性、给空数据加一个占位插画、给失败加一个重试按钮。这些东西你自己后来补，是要花不少时间的。

4.2 如何让 AI 注意到状态、间距和边界

光有模板还不够，实操里还有几个让 AI 输出更稳定的技巧。

一个技巧是使用"必须包含"句式。直接写要求，不要说"希望""可以的话"，因为 AI 对模糊限定词会打折处理。"必须包含删除时的二次确认弹窗""必须处理 360px 宽度下表单的换行"这种明确指令，会显著提升输出质量。

另一个技巧是给 AI 提供"反例"。比如"不要使用 alert() 实现交互提示""间距不要到处用 margin:auto""不要设置固定高度，让内容自然撑开"。AI 的问题往往不是不会，而是默认走了成本最低的路线，你给它划好红线，它就能往正确的方向走。

还有一个技巧是分隔依赖。如果页面里有两个独立模块，可以分两次生成，而不是一次生成整个页面。一次对话里上下文太长，AI 容易顾此失彼——前半部分精心设计，后半部分随便凑。我遇到那种复杂的看板页，都是先让 AI 生成布局骨架，再分别生成统计卡片区、图表区、列表区，最后合在一起。这样每个部分都能保证质量，代价只是多几次输入，但比反复返工快多了。

边界情况的处理也同理。你可以在提示词里直接说"请额外考虑以下边界：较长的用户昵称截断显示，手机号按 3-4-4 格式展示，列表在最右侧显示操作列但窄屏下自动前置"。这些边界约束写进去，是不需要额外多花你写代码的时间的，但 AI 记住之后，产出的代码会稳很多。

4.3 多轮迭代的关键：从"重新生成"到"局部修改"

我见到很多朋友用 AI 写页面，第一轮不满意，就问 AI"重新生成一个"，然后得到一个同样不太对的新页面，恶性循环。正确的做法是指着一个点，让 AI 改一个点。

比如 AI 把搜索区放在了表格的右上角，而你希望它在标题下方。你直接说："搜索区移到页面内容区顶部，横向排列，不要放在表格工具栏里。"它会很精准地改这一块。你说"重新生成"，它可能会把整个页面布局推倒重来，那你前面的微调全白做了。

记住，好的迭代方式是在上一版的基础上做增量修改，而不是反复推倒重来。一个好用的做法是：把第一次生成的代码保留下来，后续每个需求都基于这个代码去提"帮我改这里"的需求。这样 AI 是在一个稳定的基线上做调整，越改越接近你想要的效果。这点我和团队新人反复强调过，也是最容易踩的坑。

5. 踩过的坑和一点偷懒但靠谱的迭代方法

5.1 AI 生成的 UI 最常见的几种翻车

讲几个我实际遇见的翻车案例，给大家参考这个行业的真实情况。

第一个坑是样式方案大杂烩。有一次我让它生成一个页面，提示词写了"使用 Tailwind"，但结果里它混进了一段手写 CSS，两边权重打架，样式表现完全不可控。原因是 Tailwind 的工具类和自定义 class 叠加时，有时 AI 偷懒就直接写了一段<style>。现在我的提示词里固定加一句"所有样式必须使用 Tailwind 工具类，禁止额外书写 CSS"，这个坑基本就绝迹了。

第二个坑是组件导入来源混乱。在已有项目里用 AI，一定要在提示词里指定组件库和导入来源。不指定的情况下，AI 可能会给你写一个不存在的组件 props，或者从错误的路劲导入组件——比如同时引入了 Element Plus 和 Ant Design，仅仅因为它们都对某个组件有定义。AI 不会觉得这事不对，因为它在训练数据里见过去两套库的代码，拼在一起对它来说很正常。你需要盯住一问："这个项目依赖里到底有没有这个组件？"

第三个坑是假数据写死进代码里。AI 生成列表页时，为了方便展示，经常直接写死一个数组让页面看起来像有数据。我在代码评审的时候抓到过很多次：接口还没接，但页面已经用const data = [...]撑出了完整效果，后期联调的时候，忘记删掉假数据导致页面一直展示不了真实内容。每次接管 AI 写的前端代码，我都有一个习惯性动作：搜索所有写死的模拟数据，确认删干净或者挪到 mock 目录里。

第四个坑是脱离真实项目结构。AI 生成的组件，有时候会自己创造一个新的数据结构，跟你后端的接口对不上。比如后端返回userList，AI 在页面里写的是data.records，等到联调才开始难受。所以我的做法是：给 AI 提示的时候，直接附上接口返回的数据结构样例，让它按这个结构去写页面。省掉后面一大轮的返工。

5.2 我的三轮迭代法

用久了之后，我总结了一套"三轮迭代法"，每次都按这个节奏来，稳定且省时间。

第一轮叫结构轮。只跟 AI 确认页面的整体结构：有几块区域、顺序是什么、栅格怎么排、主操作在哪。这一轮不改样式、不抠细节，结构对不上就打回去重建。为什么先这一轮？因为结构是后面所有微调的地基，地基歪了，别的都是白费。

第二轮叫细节轮。结构定了之后，开始抠状态、间距、交互、提示文案。这轮我会把业务状态和边界条件告诉 AI，让它把 loading、禁用、二次确认这些补上。这个阶段也是我跟 AI 对话密度最高的时候，可能连续发七八条"这里加个 hover 阴影""那里字段超长截断加 title 提示"。

第三轮叫验收轮。我会把生成的代码拉回项目里，看真实运行效果，重点看响应式、组件的实际表现、有没有引入未安装的依赖。到这一步，AI 的代码其实已经完成了百分之八十，剩下的都是人接手做最后把关。

这三轮，各一轮不会超过半小时。整个页面从需求到上线，半天时间是很正常的。以前这个流程至少要两天，而且心理上觉得是纯苦力活。

5.3 什么时候不该用 AI 拼 UI

虽然标题写的是"再也不想拼 UI"，但我不建议所有 UI 都甩给 AI。有几类场景，AI 确实是帮倒忙的。

第一种是对性能要求极高的页面。AI 生成的代码，为了可读性，可能会产生大量重复渲染、没有用 useMemo、组件拆分不够细，这些问题在高频交互页面会被放大。你可以让 AI 出第一版，但性能优化部分还是得懂行的人来亲自操刀。

第二种是高度定制的复杂交互。比如拖拽生成器、画布编辑器、复杂树形表格联动，这些不只是 UI 拼搭，还涉及状态管理和算法，AI 目前生成的代码很容易在边界条件里崩。我的做法是交互核心逻辑自己写，UI 外壳可以交给 AI。

第三种是设计资产要求严格的品牌页面。C 端活动页、官网首页、营销专题，这些对视觉气质和品牌一致性要求极高，AI 生成的"通用好看"是不够的。它懂"好看"，但不懂"为什么这个品牌要这么好看"。这种页面我宁可自己慢慢磨，也不会用 AI 出基础稿。

最后一种，也是我没少踩的坑：当你自己都不知道需求是什么的时候。需求模糊时用 AI，它会把 AI 自己的想象当成需求给你，最后你拿着一版"AI 想要的页面"去跟产品对需求，效率其实更低了。AI 适合在有明确需求之后做加速，不适合在需求混沌时帮你做勘探。

6. 从"不想拼"到"拼得更好"，AI 改变的是工作方式

回到标题的感叹。说真的，我现在确实在绝大多数场景下"不想拼 UI"了——准确说是不想用之前那种低效方式去拼。AI 让我把注意力从像素和组件的层面解放出来，放回到用户需求和页面结构本身。

以前我在项目里花在"搭页面"上的时间，现在被压缩到很短。多出来的时间，我用来做更值得的事：和产品讨论清楚交互逻辑、打通接口的数据形态、观察用户实际使用时的行为、优化最核心的几条操作路径。这些事以前不是不想做，是真的没时间。

有一点我特别想强调：AI 并没有让我变成一个"不写代码的人"。恰恰相反，因为要评审 AI 的产出、要给 AI 明确的需求、要在项目真实环境里兜底，我对技术栈的理解、对设计规范的把握、对边界情况的敏感度，反而被逼着提高了。AI 是放大镜，它放大的是你自己的能力和判断力。

如果你也想给自己省点力气，我的建议是从小处开始：找一个你明天就要做的普通列表页，把它当成测试用例，用上面提到的模板生成一遍，再按三轮迭代法收尾。你会立刻感受到差别。等这一套流程跑顺了，再往更复杂的页面迁移。

别怕 AI 生成的代码不够精细，也别怕它犯错。把它当成一个基础扎实但缺少项目经验的实习生，你的工作不是替它干活，而是告诉它方向、帮它把控质量、接手它搞不定的部分。这样你会发现，"拼 UI"这件事，确实可以从你的待办清单上长时间划掉了。