企业官网建设流程全解析

1. 从"拼界面"到"说界面"：一个前端老手的真实转变

我做了八年多前端和客户端界面，从最早的切图仔时代一路走过来。那时候拿到一张设计稿，第一件事是量像素、切图、导出资源，然后在编辑器里一层一层地摆控件、调间距、对颜色。一个中等复杂度的页面，光是"还原"就要耗掉大半天，改一版设计稿意味着重来一遍。后来组件化、设计系统普及了，效率提升不少，但本质上还是"手拼"——你脑子里得先有一棵控件树，再手动把它搭出来。

真正让我改变工作方式的，是这两年 AI 在界面生成上的成熟。现在我的流程变成了：把需求描述清楚，让 AI 先出一版结构，我再在它给的骨架上做精修。标题里那句"再也不想拼 UI 了"，说的不是完全不碰界面，而是不再从零手搓控件树。这个转变背后有几个关键点：一是 AI 对布局语义的理解已经足够好，二是它能直接产出可运行的代码或工程结构，三是迭代成本极低——不满意就重新描述，而不是手动删了重搭。

这篇文章我想聊的不是"AI 有多神"，而是一个真实从业者怎么把 AI 接进自己的界面工作流。我会讲清楚：AI 生成界面到底能到什么程度、哪些环节它靠谱、哪些环节必须人来兜底、怎么把设计稿和自然语言喂给它、生成之后怎么落地到真实工程里。适合已经有一定界面开发基础、想提效但不想被 AI 带偏的同行，也适合刚入行、想少走弯路的新人。核心关键词就几个：AI、UI、PSD、Codex、prefab——这几个词基本覆盖了从设计输入到工程产出的完整链路。

先说结论，免得你带着错误预期往下读：AI 不是替你"设计"，它是替你"实现"。设计判断、交互逻辑、品牌调性这些仍然得人来定；但把判断翻译成结构、把结构翻译成代码，这部分 AI 已经能扛下七八成。想清楚这个边界，后面的所有技巧才有意义。

2. AI 生成界面的能力边界：哪些它能干，哪些别指望

2.1 布局与结构生成：这是它最强的地方

AI 在界面生成上最稳的能力，是把语义化的描述转成合理的布局结构。比如你说"一个顶部导航栏，左边 logo，中间三个菜单项，右边一个头像下拉"，它给出的结构基本不会错——容器怎么嵌套、用什么布局方式、元素之间怎么对齐，这些它理解得很到位。原因也不复杂：主流界面框架的布局模式高度收敛，无非就是弹性布局、网格、绝对定位那几套，训练数据里这类模式海量且规律性强。

我实测下来，对于信息层级清晰、组件类型常见的页面，AI 一次生成的结构可用率能到七成以上。什么叫"常见"？列表、卡片、表单、弹窗、标签页、侧边栏这些。什么叫"不常见"？高度定制的可视化、复杂的拖拽交互、带物理动效的转场——这些它给的结构往往只是"看起来对"，实际跑起来一堆问题。

这里有个经验：描述里带上布局意图，比只描述内容效果好得多。你只说"一个商品列表"，它可能给你网格也可能给你单列；你说"商品列表，两列网格，每个卡片上方图片下方标题和价格，卡片间距 12"，它给的结构就非常接近成品。多花三十秒把布局说清楚，能省掉后面十分钟的返工。

2.2 视觉还原：颜色和间距是重灾区

结构之外，视觉细节是 AI 的弱项。颜色它经常"差不多但不对"——你给个品牌色，它可能给你一个相近但色值不同的颜色；间距它倾向于用一套它自己觉得"和谐"的数值，而不是你设计稿里的精确值。这不是它笨，而是视觉精确还原需要的是查表能力，而生成模型擅长的是模式补全，两者机制不同。

所以我的做法是：让 AI 管结构，视觉参数我自己接管。生成完之后，我会把颜色、字号、间距、圆角这些统一抽成变量，对着设计稿逐个校准。这一步不能省，省了就是给自己埋雷——上线后设计走查一堆问题，返工成本比一开始校准高得多。

2.3 交互逻辑：能搭骨架，细节必须人补

交互是另一个分水岭。简单的显隐切换、状态变化、表单校验，AI 能写得像模像样；但涉及状态机复杂、边界条件多的交互，比如多步骤表单的联动校验、列表的虚拟滚动加选中态管理、拖拽排序的落点计算，它给的代码往往"能跑但经不起推敲"。我遇到过生成的代码在正常路径下没问题，一到异常路径（网络失败、数据为空、快速连点）就崩的情况。

我的处理原则是：AI 生成的交互代码，一律当成"初稿"对待。正常路径跑通只是第一步，异常路径、边界条件、性能表现都得自己过一遍。尤其是防抖节流、请求竞态、内存泄漏这些，AI 经常忽略，必须人工补。

2.4 一张表看清能力边界

这张表是我踩了几个月坑总结出来的，你可以直接拿去当预期管理工具。把 AI 用在"高可靠度"的环节，把人力集中在"低可靠度"的环节，整体效率才是正的。

3. 把 PSD 和自然语言喂给 AI：输入决定输出质量

3.1 PSD 到结构化描述：先做一次"翻译"

很多人以为可以直接把 PSD 丢给 AI 就完事，实测下来效果并不好。原因在于 PSD 是图层堆叠的表达，而界面是结构树的表达，两者之间隔着一层语义鸿沟。AI 拿到一堆图层，很难判断哪些图层属于同一个逻辑组件、哪些是装饰、哪些是状态。

我的做法是先人工做一次"翻译"：把 PSD 里的图层按逻辑组件归组，标注出每个组件的类型、层级关系、关键尺寸。这一步听起来麻烦，但其实很快——一个页面十几分钟就能理清。理清之后再喂给 AI，生成质量会有质的提升。

具体怎么翻译？我一般会产出一份这样的结构化描述：

页面：商品详情页 - 顶部导航栏（固定） - 返回按钮（左） - 标题文本（中，居中） - 分享按钮（右） - 商品主图区 - 轮播图（高度 375，圆角 8） - 指示器（底部居中） - 商品信息区 - 价格（大号，品牌色） - 标题（两行截断） - 标签行（横向排列，可换行） - 规格选择区 - 规格组（多个，每组一个标题加若干选项） - 底部操作栏（固定） - 客服、购物车、加入购物车、立即购买

这份描述里，层级用缩进表达，组件类型用括号补充，关键约束（固定、居中、截断）明确写出。AI 拿到这个，基本能一次生成对的结构。这比直接丢 PSD 靠谱太多。

3.2 自然语言描述的写法：具体、有序、带约束

如果你手上没有 PSD，纯靠自然语言描述，那写法就更讲究。我总结了一个"三段式"模板：

1. 整体定位：这是什么页面、给谁用、核心目标是什么
2. 结构清单：从上到下、从外到内列出所有区块和组件
3. 约束条件：尺寸、间距、颜色、交互、适配要求

举个例子，同样是"做个登录页"，两种描述效果天差地别：

差的写法："帮我做个登录页。"

好的写法："做一个移动端登录页。整体垂直居中，顶部是 logo 和欢迎语，中间是手机号输入框和验证码输入框（带获取验证码按钮，60 秒倒计时），下方是登录按钮（品牌色，圆角 8，高度 48），底部是用户协议勾选和第三方登录入口。输入框聚焦时边框变品牌色，按钮在未勾选协议时置灰不可点。"

第二种描述里，每个组件的状态和交互都点到了，AI 生成出来的东西基本能直接用。这就是"输入决定输出"最直观的体现。

3.3 用 Codex 类工具做代码级生成

说到把描述转成代码，Codex 这类代码生成工具是绕不开的。它的价值在于直接产出可运行的工程代码，而不是伪代码或结构图。我一般会这样用它：

• 先用自然语言或结构化描述生成组件骨架
• 再针对每个组件单独让它补全样式和逻辑
• 最后人工做一轮代码审查和参数校准

这里有个关键技巧：分而治之，别一次性让它生成整个页面。一次性生成大页面，它容易在细节上偷懒，而且出错后很难定位。拆成组件逐个生成，每个组件质量可控，组装起来也清晰。

另外，给 Codex 的提示里最好带上技术栈和规范约束，比如"用函数组件加 hooks""样式用 CSS 变量""遵循项目的命名规范"。不带这些约束，它可能给你一套和你项目风格完全不搭的代码，改起来比自己写还累。

3.4 输入环节的常见坑

• 坑一：描述里混用中英文术语导致歧义。比如"卡片"和"card"混着说，AI 可能理解成两种东西。统一术语，或者第一次出现时标注清楚。
• 坑二：省略了"显而易见"的约束。你觉得"按钮肯定要能点"是废话，但 AI 不一定默认加点击态。该说的都得说。
• 坑三：一次给太多页面。信息过载会让 AI 顾此失彼，一次一个页面或一个组件最稳。

4. 生成之后：prefab 化与工程落地的关键动作

4.1 为什么要把生成结果 prefab 化

在游戏和客户端开发里，prefab（预制体）是复用界面的基本单位。AI 生成的界面如果只是散落的代码或节点，复用性很差；把它封装成 prefab，才能进入正常的工程流程——被多个场景引用、被不同页面组合、被版本管理追踪。

我现在的习惯是：AI 生成结构后，第一件事就是按逻辑边界拆 prefab。一个列表项、一个卡片、一个弹窗，各自独立成 prefab。拆的时候遵循一个原则：能被独立复用、有明确输入输出的，就拆出来。这样后面无论怎么组合，都不用重复劳动。

拆 prefab 还有个隐性好处：它逼你把接口想清楚。一个 prefab 需要哪些外部传入的数据、暴露哪些事件，这些在拆的时候就得定下来。定清楚了，AI 后续生成的代码也更容易对齐。

4.2 从生成代码到工程规范的"最后一公里"

AI 生成的代码和你的工程规范之间，永远隔着"最后一公里"。这公里怎么走，决定了你是真提效还是假提效。我的做法是建一套后处理清单：

1. 命名规范化：AI 起的名字往往随意，统一改成项目规范
2. 样式抽离：把硬编码的颜色间距抽成变量或主题 token
3. 状态管理对齐：AI 可能用局部状态，项目要求全局状态的要改
4. 异常处理补全：空数据、加载失败、超时这些补上
5. 无障碍属性补充：语义标签、焦点管理、读屏支持
6. 性能检查：不必要的重渲染、大列表未虚拟化这些排查一遍

这套清单我每次都会过，一开始觉得繁琐，做熟了其实很快。关键是别跳过——跳过任何一项，后面都会以 bug 的形式还回来。

4.3 版本管理与协作：AI 生成内容怎么进仓库

AI 生成的内容进版本库，有几个现实问题：一是来源标注，二是审查流程，三是责任归属。我的做法是：

• 提交信息里注明哪些部分是 AI 生成、哪些是人工修改
• AI 生成的部分同样走代码审查，不因为"是 AI 写的"就放松标准
• 明确一点：AI 是工具，提交代码的人对代码负责

这三点看着是流程问题，其实是团队协作的底线。我见过团队因为"AI 生成的没人细看"导致线上事故的，教训很实在。

4.4 一个完整的落地示例

假设要做一个"设置页"，我的完整流程是这样的：

1. 描述输入：写出设置页的结构清单和约束
2. 结构生成：让 AI 生成页面骨架和分组结构
3. prefab 拆分：把"设置项""分组标题""开关行"拆成独立 prefab
4. 样式校准：对着设计稿调颜色、间距、字号
5. 交互补全：开关切换、跳转、二次确认这些补上
6. 异常处理：加载态、空态、错误态
7. 规范对齐：命名、状态管理、无障碍
8. 审查提交：走正常审查流程进仓库

这套流程走下来，一个中等复杂度的设置页，从描述到可提交，大概两三个小时。纯手写的话，一天起步。效率提升是实打实的，但前提是每个环节都不偷懒。

5. 踩过的坑与实战心得

5.1 坑一：过度信任生成结果，跳过校准

这是我最早踩的坑。刚开始用 AI 生成界面，看结构对了就直接用，结果上线后设计走查一堆问题——颜色偏了、间距不对、圆角不一致。返工的成本比一开始校准高好几倍。后来我强制自己：生成结果一律当草稿，视觉参数必须逐个校准。这个习惯救了我很多次。

5.2 坑二：描述太笼统，反复返工

"做个好看的页面"这种描述，AI 只能靠猜。猜错了你就得重来，来回几次比一开始说清楚还费时间。我现在的原则是：宁可描述多花五分钟，也不让返工多花五十分钟。描述里把结构、约束、状态都写清楚，一次到位的概率高很多。

5.3 坑三：忽略响应式和适配

AI 生成的界面经常是"单尺寸思维"，在它假设的那个尺寸下好看，换个屏幕就崩。我现在的做法是：生成时就明确要求响应式，或者生成后自己补断点逻辑。尤其是移动端和桌面端共用的组件，适配必须单独过一遍。

5.4 坑四：把 AI 当设计用

有段时间我偷懒，直接让 AI"设计"界面，结果出来的东西千篇一律，没有品牌感。后来想明白了：AI 是实现的工具，不是设计的工具。设计判断、视觉调性、交互创意这些，仍然得人来定。AI 负责把你的判断高效落地，这个分工不能乱。

5.5 几条压箱底的经验

• 建立自己的描述模板库：把常用的页面类型（列表页、详情页、表单页、设置页）的描述模板存下来，下次直接改，效率翻倍。
• 维护一份"AI 常犯错误清单"：每次遇到 AI 生成的问题就记下来，下次生成前主动规避。
• 生成结果先跑通再优化：别一上来就追求完美，先让结构跑起来，再逐步精修。
• 保留人工审查环节：无论 AI 多强，进仓库前的人工审查不能省，这是质量底线。
• 定期回顾生成质量：每隔一段时间统计一下 AI 生成内容的可用率，看看描述方式有没有改进空间。

6. 关于工具选型和心态的几句实在话

工具这块，Codex 这类代码生成工具适合做代码级产出，设计稿解析工具适合做 PSD 到结构的转换，两者配合用效果最好。但工具不是关键，关键是你的工作流有没有围绕"人定方向、AI 做实现"这个分工来设计。工具会换，分工逻辑不会。

心态上，我见过两种极端：一种是把 AI 当万能神，什么都丢给它，结果质量失控；另一种是抵触 AI，觉得它抢饭碗，结果效率被同行甩开。这两种都不可取。我的态度是：AI 是放大器，放大你的判断力，也放大你的懒惰。你用得好，它让你事半功倍；你用得糙，它让你返工到怀疑人生。

最后说个我自己的体会：自从把 AI 接进界面工作流，我花在"拼"上的时间少了大概六成，但花在"想"上的时间多了——想结构怎么拆、接口怎么定、边界怎么处理。这其实是好事，因为"拼"是重复劳动，"想"才是真正的价值所在。AI 把重复劳动接走了，人就能腾出手来做更值得做的事。这大概就是标题里那句"再也不想拼 UI"的真正含义——不是不做了，而是把精力放到了更该放的地方。