企业官网建设流程全解析

1. 从"手写像素"到"描述意图"：UI 生产方式的拐点已经到来

如果你做前端、做客户端、做小程序，甚至只是偶尔帮朋友搞个后台管理页面，你一定经历过这样的夜晚：为了一个按钮的圆角、阴影、hover 态，反复调 CSS；为了一个列表的间距，在 Figma 和 IDE 之间来回切换；为了适配一个移动端断点，把同一套布局重写三遍。这种工作不是没有价值，但它的价值密度极低——你花 80% 的时间在"翻译"设计稿，只有 20% 的时间在真正解决问题。

"自从有了 AI，我就再也不想拼 UI 了"这句话之所以能引起共鸣，不是因为它夸张，而是因为它精准地描述了一种生产方式的变化。过去我们拼 UI，本质上是把"视觉意图"手工翻译成"代码结构"；现在 AI 把这个翻译过程压缩成了一次对话、一段描述、一次生成。你不再需要记住flex: 1和min-width: 0的配合关系，也不需要背box-shadow的四层参数顺序，你只需要说清楚"我要一个什么样的界面"。

但这里有一个巨大的认知陷阱：很多人以为 AI 拼 UI 就是"一句话生成一个页面"，然后复制粘贴就完事了。实测下来，这种用法只能做出 Demo，做不出产品。真正高效的用法，是把 AI 当成一个"懂代码的 UI 实习生"——你负责定义结构、约束边界、验收结果，它负责快速产出第一版、批量替换重复劳动、在你卡住的时候给出备选方案。

这篇文章适合三类人：第一类是被 UI 细节拖慢进度的全栈开发者，第二类是想用 AI 提效但不知道怎么落地的独立开发者，第三类是带团队的技术负责人，想搞清楚 AI 在 UI 生产链路里到底能插在哪一环。我会从"为什么 AI 拼 UI 会翻车"讲起，拆解提示词的结构化写法、组件库的配合策略、多轮迭代的收敛技巧，最后给出一套可以直接抄作业的工作流。全程不吹不黑，只讲我实际跑过、踩过、修过的经验。

2. 为什么你让 AI 生成的 UI 总是"差点意思"

2.1 不是模型不行，是你给的信息维度不够

大多数人用 AI 生成 UI 的流程是这样的：打开对话框，输入"帮我生成一个登录页面"，然后看着输出结果皱眉——布局太丑、间距不对、颜色奇怪、没有响应式。于是得出结论：AI 拼 UI 不靠谱。

问题出在哪？出在信息维度缺失。一个真实的 UI 页面，至少包含六个维度的信息：布局结构（几栏、什么对齐方式）、组件类型（按钮、输入框、卡片、表格）、视觉规范（主色、圆角、阴影、字体层级）、交互状态（默认、hover、focus、disabled、loading）、响应式断点（移动端、平板、桌面）、技术栈约束（React 还是 Vue、Tailwind 还是 CSS Modules、组件库用哪个）。

你只给了"登录页面"四个字，AI 只能靠猜。它猜的默认值可能来自训练数据里最常见的风格，但那个风格大概率不符合你的项目规范。所以第一版输出"差点意思"是必然的，不是模型的问题，是输入的问题。

我自己的做法是：把提示词当成一份微型设计规范来写。不需要写很长，但六个维度里至少要说清楚四个。比如：

生成一个登录页面的 React 组件，使用 Tailwind CSS。 布局：居中卡片，最大宽度 400px，垂直排列。 组件：标题、邮箱输入框、密码输入框、登录按钮、忘记密码链接。 视觉：主色 #2563eb，圆角 8px，卡片阴影柔和，字体用系统默认。 状态：按钮有 hover 变深、disabled 变灰、loading 显示旋转图标。 响应式：移动端卡片宽度 100%，内边距 16px。

这段提示词不到 100 字，但生成结果的可用率会从 20% 提升到 70% 以上。原因很简单：你把"猜"的空间压缩了，AI 把精力放在"实现"上，而不是"决策"上。

2.2 组件库是 AI 拼 UI 的"作弊器"，但很多人没用对

如果你问我 AI 拼 UI 最大的提效杠杆是什么，我会毫不犹豫地说：组件库 + AI 的组合。单独用 AI 生成原生 HTML/CSS，你得到的是"能看但不好维护"的代码；单独用组件库手写，你得到的是"规范但慢"的产出。两者结合，才是真正的效率跃迁。

但这里有个坑：很多人让 AI 生成 UI 时，不告诉它你用的是哪个组件库，或者告诉了但没给版本。结果 AI 按自己的记忆生成了一套"看起来像 Ant Design 但实际 API 对不上"的代码，你复制进去一堆报错，修 bug 的时间比手写还长。

正确的做法是：在提示词里明确组件库名称、版本、以及你要用的具体组件。比如：

使用 Ant Design 5.x 生成一个用户管理页面。 包含：Table（带分页、排序、筛选）、Search 输入框、新增按钮、编辑/删除操作列。 Table 的 columns 定义要完整，包含 dataIndex、title、key。 操作列用 Space 包裹 Button，删除按钮用 Popconfirm 二次确认。

这样生成的代码，基本可以做到"复制即用"，因为 AI 知道Table的columns怎么写、Popconfirm的onConfirm怎么绑。你省掉的不是打字时间，而是查文档、对 API、调样式的时间。

我实测过一个对比：同样一个带搜索和分页的表格页面，纯手写（含查文档）大约 40 分钟，AI + 组件库（含微调）大约 12 分钟。差距不在生成速度，而在返工次数。手写是一次性写对，AI 是快速生成 + 少量修正，后者的心理负担小得多。

2.3 "生成"只是起点，"收敛"才是真正的功夫

很多人对 AI 拼 UI 的期待是"一次生成完美结果"，这个期待本身就是错的。AI 生成的第一版，价值在于给你一个可运行的起点，而不是终点。真正的功夫在"收敛"——通过多轮对话，把第一版逐步逼近你的目标。

收敛的关键是每次只改一个维度。我见过有人一次性丢给 AI 十个修改意见："把按钮改蓝、间距调大、字体换掉、加个 loading、表格改成卡片、颜色再深一点、圆角小一点、阴影去掉、加个图标、移动端适配一下。"结果 AI 改了三项，忘了七项，你还得重新说一遍。

正确的收敛节奏是：

1. 第一轮：确认布局结构对不对。
2. 第二轮：调视觉规范（颜色、间距、圆角、阴影）。
3. 第三轮：补交互状态（hover、focus、loading、disabled）。
4. 第四轮：做响应式适配。
5. 第五轮：接真实数据、处理边界情况。

每一轮只聚焦一个维度，AI 的注意力不会被分散，你的验收也有明确的检查点。这套节奏看起来慢，实际上比"一次性提十个需求然后反复返工"快得多。

3. 把提示词写成"微型设计规范"：结构化输入的实操方法

3.1 一个可复用的提示词骨架

经过大量实测，我总结出一个提示词骨架，适用于绝大多数 UI 生成场景。你不需要每次都从头写，把这个骨架存下来，改几个关键词就能用：

[技术栈] 生成一个 [页面/组件名称]。 布局：[整体结构，如居中卡片/左右分栏/顶部导航+内容区] 组件：[列出所有需要的组件及其层级关系] 视觉：[主色、圆角、阴影、字体、间距规范] 状态：[需要哪些交互状态] 响应式：[断点行为] 约束：[不要做什么，如不要用内联样式、不要引入额外依赖]

这个骨架的核心逻辑是：先定结构，再定细节，最后定边界。结构错了，细节再美也没用；边界不清，AI 会自由发挥引入你不想要的依赖。

举个实际例子。我要生成一个"数据概览卡片"，提示词是这样写的：

使用 React + Tailwind CSS 生成一个数据概览卡片组件。 布局：卡片内顶部是标题和图标，中间是大号数字，底部是环比变化。 组件：标题用 text-sm text-gray-500，数字用 text-3xl font-bold，变化用带箭头的 span。 视觉：白色背景，圆角 12px，阴影 shadow-sm，内边距 20px。 状态：数字加载时显示骨架屏，变化为正显示绿色，为负显示红色。 响应式：卡片在移动端占满宽度，桌面端固定 280px。 约束：不要引入 chart 库，不要用内联样式。

生成结果直接可用，我只改了一个间距值。这就是结构化输入的价值。

3.2 视觉规范怎么描述才不抽象

"好看"是一个无法执行的指令。AI 不知道你说的"好看"是极简风、拟物风、还是玻璃拟态。你需要把"好看"翻译成可执行的参数。

我常用的翻译对照表：

这张表不是绝对的，但它能帮你把"感觉"变成"参数"。AI 拿到参数后，生成结果的确定性会大幅提升。

还有一个技巧：给参考系。你可以说"风格参考 Linear 的侧边栏"或"类似 Notion 的表格样式"。AI 的训练数据里有这些产品的视觉特征，它能理解你的意图。但注意不要直接说"抄某某网站"，而是说"参考某某产品的视觉语言"，这样更安全也更准确。

3.3 技术栈约束：说清楚"不要什么"比"要什么"更重要

AI 有一个坏习惯：喜欢"帮你加东西"。你说生成一个按钮，它可能给你加个动画库；你说生成一个表格，它可能引入一个数据处理库。这些额外依赖在 Demo 里无所谓，在真实项目里就是灾难。

所以提示词里一定要有"约束"段落。我常用的约束语句：

• 不要引入任何额外依赖，只用 [已声明的库]。
• 不要用内联样式，全部用 [Tailwind/CSS Modules/styled-components]。
• 不要生成测试代码，只生成组件本身。
• 不要用 any 类型，TypeScript 类型要完整。
• 不要用已废弃的 API，按 [版本号] 的写法来。

这些约束看起来是小事，但能帮你省掉大量"清理 AI 垃圾代码"的时间。我踩过最深的坑是：让 AI 生成一个日期选择器，它引入了一个我没听过的日期库，结果打包体积多了 200KB。从那以后，我的提示词里永远有一句"不要引入额外依赖"。

4. 组件库配合策略：让 AI 说"你项目的话"

4.1 为什么"AI + 组件库"比"AI + 原生"更稳

原生 HTML/CSS 的问题是：没有约束。AI 可以自由发挥，生成一套"能跑但和你项目风格完全不搭"的代码。你拿到后要么全盘接受（破坏一致性），要么大改（失去提效意义）。

组件库的价值在于：它提供了一套强约束。按钮只有几种 variant，间距只有几档 size，颜色只有几个 token。AI 在这个约束空间里生成，结果的确定性高得多，而且天然和你的项目风格一致。

我做过一个统计：在同一个项目里，用 AI + 原生 CSS 生成的组件，平均需要修改 6-8 处才能合入；用 AI + 组件库生成的组件，平均只需要修改 2-3 处。差距主要来自"风格对齐"和"API 正确性"。

4.2 不同技术栈的配合要点

React + Ant Design / MUI：这是 AI 最熟悉的组合，生成质量最高。关键是告诉 AI 版本号，因为 Ant Design 4 和 5 的 API 差异很大。另外，Table 的 columns、Form 的 rules 这些复杂配置，最好在提示词里给出示例结构，AI 会照着填。

Vue + Element Plus / Naive UI：AI 对 Vue 3 的<script setup>语法掌握得不错，但要注意告诉它用 Composition API 还是 Options API。Element Plus 的el-table配置项很多，建议在提示词里明确你要哪些功能（分页、排序、多选、展开行）。

React Native / Flutter：这两个领域的 AI 生成质量参差不齐。React Native 相对好一些，Flutter 的 Widget 嵌套层级深，AI 容易生成"能跑但结构混乱"的代码。建议把页面拆成多个小组件分别生成，再手动组装。

小程序 / UniApp：AI 对微信小程序的 WXML/WXSS 支持一般，容易混入 Web 的写法。建议明确说"这是微信小程序，用 WXML 和 WXSS，不要用 div 和 class 选择器"。

4.3 组件库文档的"喂法"

如果你用的组件库比较小众，AI 可能不熟悉。这时候可以把组件库的文档片段贴进提示词。但不要贴整页文档，太长会稀释注意力。我的做法是：只贴你要用的那个组件的 API 签名和示例。

比如你要用某个表格组件，就贴：

组件名：DataTable Props： - columns: Array<{ key, title, width?, render? }> - data: Array<Record<string, any>> - pagination: { page, pageSize, total } - onPageChange: (page: number) => void 示例： <DataTable columns={cols} data={list} pagination={pg} onPageChange={handlePage} />

这样 AI 就知道该怎么写了，不会瞎猜 API。

5. 多轮迭代的收敛技巧：从"能看"到"能用"

5.1 第一轮：只验收结构，不纠结细节

第一轮生成后，你的验收标准只有一个：布局结构对不对。是不是你要的几栏？组件位置对不对？层级关系清不清楚？如果结构不对，直接说"把左侧栏改成顶部导航"或"把卡片改成两列网格"，不要在这个阶段纠结颜色和间距。

我见过很多人第一轮就开始抠细节："这个按钮颜色不对""这个间距大了 2px"。结果改完细节发现结构要推倒重来，前面的修改全白费。结构是骨架，细节是皮肤，先立骨架再贴皮肤。

5.2 第二轮：用"对比描述"调视觉

调视觉时，不要只说"改好看点"，要用对比描述：

• "把主色从蓝色改成深灰，参考 Linear 的侧边栏。"
• "间距太紧了，整体放大 1.5 倍。"
• "阴影太重了，改成几乎看不见的那种。"
• "圆角从 4px 改成 12px，更柔和一些。"

对比描述的好处是：AI 知道"从什么改成什么"，而不是"改成某个模糊的目标"。这能大幅减少来回次数。

5.3 第三轮：补状态，别等测试来提

交互状态是最容易被忽略的部分。AI 默认生成的组件通常只有"默认态"，没有 hover、focus、disabled、loading、error。这些状态如果不在生成阶段补上，后面测试提 bug 时你还得回来改。

我的做法是在第三轮专门说："给所有可交互元素补上 hover、focus、disabled 状态，按钮补 loading 状态，输入框补 error 状态。"一次性补齐，比零散补效率高得多。

5.4 第四轮：响应式适配的"断点思维"

响应式不要笼统地说"适配移动端"，要按断点说：

• 移动端（< 768px）：单列布局，卡片占满宽度，导航折叠成汉堡菜单。
• 平板（768-1024px）：两列布局，侧边栏收窄。
• 桌面（> 1024px）：三列布局，侧边栏展开。

按断点描述，AI 生成的媒体查询才准确。我实测过，按断点描述的生成结果，移动端可用率比笼统描述高出一倍以上。

5.5 第五轮：接真实数据时的边界处理

最后一轮是把 mock 数据换成真实数据。这时候要提醒 AI 处理边界情况：数据为空时显示什么？加载失败时显示什么？数据量过大时怎么分页或虚拟滚动？这些边界如果不在提示词里说，AI 默认不处理，上线后就是 bug。

6. 那些没人告诉你但一定会踩的坑

6.1 AI 生成的代码"看起来对"但"跑起来错"

这是最危险的坑。AI 生成的代码语法正确、结构清晰，但可能用了不存在的 API、传了错误的参数类型、或者逻辑上有微妙的问题。比如它可能生成一个onClick={handleClick()}（立即执行而不是传引用），或者一个useEffect缺少依赖数组。

我的应对方法是：生成后先跑一遍，再读一遍关键逻辑。不要因为"看起来对"就直接合入。特别是事件绑定、状态更新、异步请求这三类代码，一定要逐行检查。

6.2 样式冲突：AI 不知道你的全局样式

AI 生成组件时，不知道你项目里有没有全局样式、有没有 CSS reset、有没有主题变量。它可能用了一个和你全局样式冲突的类名，或者覆盖了你精心调过的间距。

应对方法：在提示词里说明你的全局约定。比如"项目使用 Tailwind，已配置自定义主题，主色是 primary-500，不要用硬编码颜色"。或者"项目有全局 CSS reset，不要重复设置 margin: 0"。

6.3 可访问性（a11y）被系统性忽略

AI 生成的 UI 几乎不考虑可访问性：按钮没有aria-label，图片没有alt，表单没有label关联，键盘导航不支持。这些在 Demo 里无所谓，在产品里是硬伤。

如果你在意 a11y，在提示词里加一句："所有交互元素要有 aria-label，表单元素要有 label 关联，支持键盘 Tab 导航。"AI 会照做。虽然不能做到完美，但比完全不做好得多。

6.4 性能陷阱：AI 喜欢"过度实现"

AI 有时候会"炫技"：给你加个动画、加个过渡、加个懒加载、加个 memo。这些在单个组件里没问题，但在长列表或复杂页面里可能造成性能问题。比如它可能给一个 1000 行的表格每一行都加useMemo，反而增加开销。

应对方法：在提示词里说"不要做性能优化，保持代码简单直接"。需要优化时你再手动加。

6.5 版本漂移：AI 的记忆可能过时

AI 的训练数据有截止日期，它可能不知道你用的库的最新版本。比如它可能按 React 17 的写法生成代码，而你用的是 React 18；或者按 Tailwind 2 的类名生成，而你用的是 Tailwind 3。

应对方法：在提示词里明确版本号，并且在生成后检查是否有已废弃的 API。如果发现版本不对，直接说"用 React 18 的 createRoot 写法重写"或"用 Tailwind 3 的类名"。

7. 一套可以直接抄的 AI 拼 UI 工作流

7.1 工作流全景

把前面所有内容串起来，我的完整工作流是这样的：

1. 定义页面：用一句话说清楚这个页面是干什么的。
2. 写提示词：按"技术栈 + 布局 + 组件 + 视觉 + 状态 + 响应式 + 约束"七段式写。
3. 生成第一版：只验收结构，不纠结细节。
4. 收敛视觉：用对比描述调颜色、间距、圆角、阴影。
5. 补状态：一次性补齐 hover、focus、disabled、loading、error。
6. 做响应式：按断点描述，生成媒体查询。
7. 接数据：替换 mock，处理空态、错误态、加载态。
8. 检查代码：跑一遍，读关键逻辑，检查版本和依赖。
9. 合入项目：微调后提交，记录这次提示词供下次复用。

这套流程跑熟之后，一个中等复杂度的页面（比如带搜索、分页、增删改查的管理页）从零到可提交，大约 20-30 分钟。对比纯手写的 2-3 小时，提效是实打实的。

7.2 提示词模板库的积累

提效的关键不是每次重新写提示词，而是积累模板库。我按页面类型建了几个模板：

• 列表页模板（表格 + 搜索 + 分页 + 操作列）
• 表单页模板（多字段 + 校验 + 提交 + 重置）
• 详情页模板（描述列表 + 关联表格 + 操作按钮）
• 仪表盘模板（统计卡片 + 图表 + 最近动态）
• 登录/注册模板（居中卡片 + 表单 + 第三方登录）

每个模板存好，下次遇到同类页面，改几个字段就能用。这是复利效应——你积累的模板越多，新页面的生成速度越快。

7.3 团队协作时的注意事项

如果你在团队里推广这套工作流，有几个点要注意：

• 统一提示词规范：不然每个人生成的代码风格不一致，review 成本反而增加。
• 统一组件库版本：AI 生成时版本不一致，合入时冲突不断。
• 建立 review 清单：AI 生成的代码要重点检查事件绑定、状态更新、异步逻辑、a11y。
• 记录踩坑案例：把团队踩过的坑整理成文档，新人直接看，不用重复踩。

8. 我对 AI 拼 UI 的真实看法

用了大半年 AI 拼 UI，我的结论是：它不会取代 UI 开发者，但会取代"只会拼 UI"的开发者。那些把 80% 时间花在翻译设计稿上的人，价值会被压缩；那些能定义结构、约束边界、验收结果、处理复杂交互的人，价值会被放大。

AI 最擅长的是"从 0 到 0.7"——快速产出可运行的初版。但从 0.7 到 1 的那段路，仍然需要人来走：处理边界情况、优化性能、保证可访问性、对齐业务逻辑。这段路 AI 目前走不好，也不应该由它来走。

我现在的习惯是：能用 AI 生成的部分，绝不手写；需要判断和决策的部分，绝不交给 AI。这个边界划清楚之后，效率提升是自然的，焦虑反而减少了。因为你知道自己在做什么，也知道 AI 在帮你做什么。

最后分享一个我最近的小发现：把 AI 生成的组件和手写的组件放在一起对比，前者往往在"规范性"上更好（因为 AI 严格按组件库 API 来），后者往往在"贴合业务"上更好（因为你知道业务需要什么）。最好的做法是：用 AI 生成骨架和规范部分，用手写补业务逻辑和特殊交互。两者结合，才是当前阶段的最优解。