企业官网建设流程全解析

1. 从“拼 UI”到“说 UI”：一个前端老兵的效率拐点

“自从有了 AI，我就再也不想拼 UI 了”——这句话我第一次在团队群里看到时，差点以为是哪个刚入行的新人在发牢骚。结果点开一看，是组里干了八年的老前端。他以前是那种连 1px 偏差都要跟设计稿死磕的人，现在居然主动说不想拼 UI 了，这反差让我决定认真研究一下他到底在用什么工作流。

先说清楚这里说的“拼 UI”到底指什么。它指的是把设计稿（PSD、Figma、Sketch 导出图）手动翻译成 HTML/CSS、Vue/React 组件、Unity UGUI 或 Android XML 布局的整个过程。这个过程的核心特征是：重复、机械、极度依赖视觉还原度、且几乎不产生业务价值。一个按钮的圆角、阴影、hover 态、禁用态、响应式断点，写起来动辄几十行样式，但产品经理根本不会因为这个按钮写得好而给你加绩效。

AI 介入这件事之后，变化是结构性的。它不再是“帮你补全一个 CSS 属性”这种小打小闹，而是直接吃设计稿、吐组件代码，甚至能理解“这个卡片列表要支持虚拟滚动”这种隐含需求。我实测下来，一个中等复杂度的后台管理页面，从设计稿到可运行组件，纯手工大约需要 4 到 6 小时，用 AI 辅助后压缩到 40 分钟以内，而且还原度反而更高——因为 AI 不会像人一样在连续工作三小时后开始“差不多就行”。

这篇文章适合三类人看：一是每天被 UI 还原折磨的前端和客户端开发；二是想搞清楚 AI 到底能帮团队省多少事的技术负责人；三是做 UI 设计但想理解下游实现逻辑的设计师。我会把整个工作流的原理、工具选型、实操步骤、参数配置、踩过的坑全部摊开讲，不藏私。

2. 为什么“拼 UI”这件事注定要被重构

2.1 手工拼 UI 的三个隐性成本

很多人觉得拼 UI 只是“费时间”，其实真正的成本远不止工时。我把它拆成三层：

第一层是显性工时成本。一个典型的中后台系统，假设有 30 个页面，每个页面平均 15 个 UI 元素（按钮、输入框、表格、弹窗、标签页等），每个元素从写结构到调样式平均 8 分钟，光这一项就是 30 × 15 × 8 = 3600 分钟，也就是 60 个小时。这还没算响应式适配、暗色模式、无障碍属性这些“加分项”。

第二层是一致性成本。手工拼 UI 最大的问题不是慢，是不一致。张三写的按钮圆角是 4px，李四写的是 6px；这个页面的主色是 #1890ff，那个页面变成了 #1677ff。这种不一致在项目初期看不出来，等到要统一换肤或者做设计系统时，改起来就是灾难。我经历过一次品牌色升级，全站 200 多个页面，光找硬编码的颜色值就花了两天。

第三层是沟通成本。设计师说“这个间距再大一点”，前端问“大多少”，设计师说“你看着调”。这种对话每天要发生几十次。AI 介入后，设计师可以直接把标注图丢给 AI，AI 按 8px 栅格系统自动计算，前端只需要 review 结果，沟通链路缩短了一半以上。

2.2 AI 拼 UI 的底层逻辑：从“像素映射”到“意图理解”

早期的一些工具尝试过“设计稿转代码”，思路是像素级映射：识别到矩形就生成 div，识别到文字就生成 span。这种方案的问题是，它不理解“这是一个卡片列表”，只知道“这里有一堆矩形”。生成的代码结构混乱，类名是 div-1、div-2 这种，维护性极差。

现在的 AI 方案（比如基于 Codex 类模型的工作流）走的是另一条路：先理解意图，再生成结构。它会分析设计稿的层级关系、命名规范、组件复用模式，然后生成带有语义化类名和合理组件拆分的代码。举个例子，设计稿里有一个带图标的搜索框，AI 不会生成<div><img/><input/></div>，而是生成<SearchInput icon="search" placeholder="请输入关键词" />这样的组件调用。

这个转变的关键在于模型对 UI 模式的理解能力。它见过足够多的真实项目代码，知道“搜索框”通常长什么样、“表格分页”通常怎么实现、“弹窗确认”通常有哪些状态。这种模式识别能力，是手工拼 UI 永远追不上的。

2.3 哪些场景最适合 AI 接管

不是所有 UI 工作都适合交给 AI。我总结了一个简单的判断标准：

我的建议是：先把标准页面交给 AI，把省下来的时间投入到复杂交互和业务逻辑上。这样团队的整体产出会提升，而不是让 AI 去啃它不擅长的硬骨头。

3. 工具链选型：别被“一键生成”忽悠了

3.1 主流方案对比与选型逻辑

市面上打着“AI 生成 UI”旗号的工具很多，但真正能进生产环境的没几个。我按输入类型把它们分成三类：

第一类：设计稿输入型。你给它 Figma 链接或 PSD 文件，它输出代码。代表思路是“设计即代码”。这类工具的优势是还原度高，劣势是对设计稿的规范性要求极高——图层命名混乱、分组随意、用了大量绝对定位的设计稿，生成结果会惨不忍睹。

第二类：文字描述输入型。你用自然语言描述“一个带搜索和分页的用户列表”，它生成代码。这类工具适合快速原型，但生成结果的视觉细节需要大量调整，适合“先跑起来再优化”的场景。

第三类：截图输入型。你截一张图，它识别并生成代码。这类工具最灵活，但准确率波动大，适合参考竞品快速搭建类似界面。

我实际用下来，生产环境首选第一类，原型阶段用第二类，竞品分析用第三类。三者不是互斥的，可以组合使用。

3.2 Codex 类模型在 UI 生成中的角色

Codex 这类代码生成模型在 UI 工作流中的定位，不是“替代设计师”，而是“替代重复劳动”。它的核心能力有三个：

一是结构推断。给它一个设计稿的层级描述，它能推断出合理的 DOM 结构或组件树。比如看到“标题 + 副标题 + 操作按钮”的组合，它会生成 header 区域而不是三个独立的 div。

二是样式生成。它能根据设计稿的间距、颜色、字体信息，生成符合项目规范的 CSS 或样式对象。关键是它可以被约束——你告诉它“所有间距用 8 的倍数”，它就会自动对齐。

三是组件映射。如果你有一个已有的组件库，它可以识别设计稿中的元素并映射到对应组件。比如识别到“带图标的按钮”，自动调用<IconButton>而不是重新写一个。

注意：Codex 类模型的输出质量高度依赖提示词的质量。同样的设计稿，提示词写得好和写得差，生成结果可能差三倍以上的返工量。提示词的具体写法我在第 4 章详细展开。

3.3 与现有工程体系的衔接

AI 生成的代码不能是“孤岛”，必须能融入现有工程。我在项目里定了三条硬规则：

规则一：生成的组件必须走项目的 ESLint 和 Prettier。我们在 CI 里加了检查，AI 生成的代码如果不符合规范，直接打回。这倒逼我们在提示词里就带上规范约束。

规则二：样式必须用项目的设计 token。不允许出现硬编码的颜色和间距，必须引用$primary-color、$spacing-md这类变量。AI 提示词里会明确列出可用的 token 列表。

规则三：生成的组件必须有 Storybook 入口。每个 AI 生成的组件都要能在 Storybook 里独立预览，方便设计师和测试验收。这一步看似麻烦，实际上省了大量“在页面里找组件”的时间。

4. 实操全流程：从设计稿到可运行组件

4.1 设计稿预处理：AI 能不能看懂，全看这一步

AI 生成 UI 的质量，70% 取决于设计稿的“可读性”。我见过太多设计师交上来的稿子，图层叫“矩形 123”“编组 45”，这种稿子给 AI 就是灾难。预处理的核心是让设计稿的结构和命名符合 AI 的理解习惯。

具体操作步骤：

1. 图层重命名。把“矩形 123”改成“search-input-container”，把“编组 45”改成“user-card-list”。命名用英文小写加连字符，这是 AI 最容易理解的格式。

2. 组件化整理。重复出现的元素（按钮、标签、头像）在 Figma 里做成 Component，AI 识别到 Component 实例后，会优先复用而不是重新生成。

3. 标注间距和颜色。用 Figma 的 Inspect 面板导出标注，或者用插件生成 spacing 和 color 的 JSON。AI 拿到这些数据后，生成的样式会精确得多。

4. 导出结构描述。我习惯用 Figma 插件导出一份 JSON，包含图层树、样式属性、文本内容。这份 JSON 就是喂给 AI 的“设计稿说明书”。

实操心得：预处理这一步花 10 分钟，能省后面 1 小时的返工。我试过跳过预处理直接生成，结果 AI 把搜索框识别成了普通输入框，把卡片列表识别成了一堆独立矩形，改起来比重写还累。

4.2 提示词工程：让 AI 按你的规矩来

提示词是 AI 拼 UI 的“方向盘”。我总结了一个五段式提示词模板，实测下来生成质量最稳定：

第一段：角色和任务。“你是一个资深前端工程师，擅长将设计稿转换为 Vue 3 + TypeScript 组件。请根据以下设计稿描述生成代码。”

第二段：技术栈约束。“使用 Vue 3 Composition API，样式用 SCSS，类名遵循 BEM 规范，所有颜色和间距必须引用设计 token。”

第三段：设计稿描述。把预处理导出的 JSON 或结构化描述贴进去，包括层级、尺寸、颜色、文本。

第四段：组件映射规则。“遇到按钮请使用<BaseButton>，遇到输入框请使用<BaseInput>，遇到表格请使用<BaseTable>。组件库文档见附件。”

第五段：输出格式要求。“输出完整的 .vue 文件，包含 template、script setup、style 三部分。不要省略任何代码，不要用注释代替实现。”

这个模板的关键在于约束前置。很多人习惯先让 AI 生成，再提要求改，这样效率很低。把约束写在前面，AI 一次就能生成 80% 可用的代码。

4.3 生成结果的验收与微调

AI 生成的代码不能直接合并，必须经过验收。我的验收清单有四条：

• 结构是否合理。有没有多余的嵌套 div？组件拆分是否合理？有没有把本该复用的部分写成了重复代码？
• 样式是否规范。有没有硬编码颜色？间距是否对齐栅格？响应式断点是否正确？
• 交互是否完整。hover、focus、disabled、loading 状态是否都有？边界情况（空数据、超长文本）是否处理？
• 可访问性是否达标。按钮有没有 aria-label？表单有没有关联 label？键盘导航是否可用？

微调阶段，我通常用“局部重生成”而不是“整体重写”。比如某个表格的列宽不对，我会选中那段代码，让 AI 只重写表格部分。这样比整体重生成快得多，也不会破坏已经正确的部分。

4.4 一个完整案例：用户管理页面

我拿一个真实的用户管理页面走一遍完整流程。设计稿包含：顶部搜索栏、用户表格、分页器、新增用户弹窗。

预处理阶段，我把设计稿整理成如下结构描述：

{ "page": "user-management", "sections": [ { "name": "search-bar", "components": [ {"type": "input", "placeholder": "搜索用户名", "width": "240px"}, {"type": "select", "options": ["全部", "启用", "禁用"], "width": "120px"}, {"type": "button", "text": "查询", "variant": "primary"}, {"type": "button", "text": "重置", "variant": "default"} ] }, { "name": "user-table", "columns": ["用户名", "邮箱", "角色", "状态", "操作"], "actions": ["编辑", "禁用", "删除"] }, { "name": "pagination", "total": 100, "pageSize": 10 } ] }

提示词阶段，我把这个 JSON 加上技术栈约束和组件映射规则，一起发给 AI。生成结果大约 200 行代码，包含完整的 template、script 和 style。

验收阶段，我发现三个问题：一是表格的“操作”列没有做权限控制，二是分页器的每页条数切换没实现，三是弹窗的关闭动画缺失。这三个问题我分别用局部重生成解决，总共花了 15 分钟。

最终结果：从预处理到验收完成，总共 40 分钟。如果纯手工写，这个页面我估计需要 4 小时以上。

5. 跨端场景的差异化处理

5.1 Unity UGUI 与 Prefab 生成

Unity 的 UI 工作和 Web 前端差异很大，核心概念是 GameObject 和 Prefab。AI 在 Unity 场景下的用法，主要是生成 Prefab 的结构描述和 C# 绑定代码。

我的做法是：先用文字描述 UI 结构，让 AI 生成一个 Prefab 的层级描述（类似 YAML 格式），然后在 Unity 里用 Editor 脚本自动创建。比如一个“数字滚轮”效果，AI 会生成这样的结构：

ScrollWheel (RectTransform + ScrollRect) ├── Viewport (RectTransform + Mask) │ └── Content (RectTransform + VerticalLayoutGroup) │ ├── Item_0 (Text) │ ├── Item_1 (Text) │ └── Item_2 (Text) └── Scrollbar (可选)

然后 AI 会生成对应的 C# 脚本，处理滚动吸附、数值计算、边界回弹。我实测下来，一个数字滚轮组件从描述到可运行，大约 20 分钟，手工写至少 2 小时。

注意：Unity 的 Prefab 生成要特别注意锚点（Anchor）和轴心（Pivot）的设置。AI 默认生成的锚点可能不符合你的适配需求，需要在提示词里明确“锚点设置为居中拉伸”或“锚点固定在左上角”。

5.2 移动端与响应式布局

移动端 UI 的 AI 生成，核心难点是多分辨率适配。我的策略是让 AI 生成基于 Flex 或 Grid 的弹性布局，而不是固定像素。提示词里会明确：“使用 rem 或 vw 单位，避免固定 px 宽度，断点设置为 375px、768px、1024px。”

对于 iOS 和 Android 的原生 UI，AI 可以生成 SwiftUI 或 Jetpack Compose 代码。我试过用 AI 生成一个设置页面，SwiftUI 的生成质量相当高，基本可以直接用。Android 的 XML 布局生成质量稍差，主要是 ConstraintLayout 的约束关系容易出错，需要人工调整。

5.3 中后台系统的批量生成

中后台系统是 AI 拼 UI 的“主战场”，因为页面模式高度重复。我的做法是建立一个“页面模板库”，把常见的页面类型（列表页、详情页、表单页、仪表盘）做成提示词模板。新页面来了，只需要替换字段名和接口地址，AI 就能批量生成。

这里有个技巧：让 AI 先生成页面骨架，再填充细节。比如先让它生成“搜索栏 + 表格 + 分页器”的三段式结构，确认结构无误后，再分别生成每一部分的详细代码。这样比一次性生成整个页面更可控。

6. 踩坑实录与排查手册

6.1 生成代码“能跑但不对”的典型症状

AI 生成的代码最常见的问题不是报错，而是“看起来对，用起来不对”。我整理了五个高频症状和对应的排查思路：

6.2 提示词失效的三种情况及补救

情况一：AI 忽略了技术栈约束。比如你说了用 Vue 3，它生成了 Vue 2 的 Options API。补救方法是在提示词开头和结尾各强调一次技术栈，并且在示例代码里体现。

情况二：AI 过度设计。你只要一个简单按钮，它生成了一个带 loading、disabled、icon、tooltip 的完整组件。补救方法是在提示词里明确“只生成最小可用版本，不要添加未要求的特性”。

情况三：AI 生成的代码有安全漏洞。比如直接把用户输入拼接到 innerHTML。补救方法是在提示词里加上“所有用户输入必须转义，禁止使用 innerHTML 或 v-html”。

6.3 团队协作中的规范落地

AI 拼 UI 要进团队，必须解决“每个人生成的代码风格不一样”的问题。我的做法是：

• 统一提示词模板。把提示词模板放进项目仓库，所有人用同一份，只改设计稿描述部分。
• 统一验收清单。把第 4.3 节的验收清单做成 PR 模板，每个 AI 生成的组件都要过一遍。
• 统一组件库。AI 生成的组件必须映射到现有组件库，不允许新建重复组件。我们每周做一次组件库 review，把 AI 生成的新组件合并进去。

实操心得：刚开始推行 AI 拼 UI 时，最大的阻力不是技术，是习惯。有同事觉得“AI 生成的代码我不放心”，坚持手工写。我的做法是让他先用手工写一个页面，再用 AI 写同样的页面，对比时间和质量。数据摆出来之后，抵触情绪自然就消了。

7. 效率账与边界感

7.1 真实项目中的时间对比

我在过去三个月里记录了 12 个页面的开发时间，对比手工和 AI 辅助的差异：

平均节省约 78% 的时间。但要注意，这个数据的前提是设计稿规范、组件库完善、提示词成熟。如果设计稿一团糟，AI 辅助的节省比例会降到 30% 以下，甚至可能因为返工而更慢。

7.2 AI 搞不定的 UI 场景

有几类 UI 工作我坚决不交给 AI：

一是品牌感极强的页面。比如官网首页、活动落地页，这些页面的视觉细节需要设计师反复打磨，AI 生成的“标准答案”反而会失去品牌辨识度。

二是复杂动效。比如页面转场、元素编排动画，这些涉及时序、缓动曲线、物理模拟，用文字描述极其低效，不如直接写代码。

三是与业务逻辑深度耦合的组件。比如一个带实时校验、联动、异步加载的表单，AI 生成的代码往往只覆盖了 happy path，边界情况需要大量人工补充。

四是需要像素级还原的设计稿。有些设计师对还原度要求极高，1px 的偏差都要打回。这种情况下，AI 生成的代码需要大量微调，反而不如手工写快。

7.3 我的个人体会

用了大半年 AI 拼 UI，最大的感受不是“省了多少时间”，而是工作重心的转移。以前我 70% 的时间花在写样式和调布局上，现在这部分时间压缩到 20%，省下来的时间我用来做三件事：一是优化组件库的抽象层次，让 AI 生成的代码更简洁；二是研究复杂交互的实现方案，这是 AI 暂时替代不了的；三是写文档和做 code review，提升团队整体的代码质量。

还有一个意外收获：AI 生成的代码成了团队的学习材料。新人入职时，我会让他们先看 AI 生成的组件代码，理解项目的组件拆分逻辑和样式规范。这比看文档快得多，因为代码是活的，能直接跑起来。

最后分享一个小技巧：如果你也在用 AI 拼 UI，建议建一个“提示词版本库”，把每次效果好的提示词存下来，标注适用场景和注意事项。我现在的提示词库里有 30 多条，覆盖了列表、表单、弹窗、图表等常见场景。新页面来了，先翻提示词库，找到最接近的改一改，比从零写提示词快得多。这个习惯坚持三个月，你会发现 AI 生成的质量越来越稳定，返工越来越少。