上个月我接了一个内部数据看板的活儿，接口和权限两天就串完了，真正让我头疼的反而是那个登录页。让 AI 重写了三版，每一版都带着明显的"AI 味"：深蓝渐变背景、白色玻璃卡片、发光按钮。同事路过瞄了一眼说，这界面一看就是机器生成的。这句话让我突然意识到一个问题——为什么 AI 写接口、写 SQL、写业务组件都挺利索，一到 Web UI 整体效果就露馅？
这篇文章准备把这件事掰开揉碎讲清楚。我会先拆解 AI 生成界面"难看"的具体配方，再聊底层根因，接着复盘哪些场景 AI 其实能做得不错，以及我现在是怎么把 AI 纳进前端设计流程的。如果你也被 AI 生成的页面折磨过，或者正打算用 AI 批量产前端页面但被视觉质量卡住，这篇文章应该能帮上忙。
1. 现象：为什么 AI 生成的页面总有一种"硅基味"
1.1 三个真实的小例子
先说我亲手跑出来的三个例子。
注册页。我让 AI 生成一个 SaaS 产品注册页，要求是"简洁、现代、可信"。它给出的结构完全没问题：左上角 Logo，右侧表单，底部条款。但配色是深蓝到靛蓝的渐变背景，主按钮加了很重的投影，输入框圆角一律 16px，信息密度也不对。这个页面单独看还能用，但放进一套产品界面里，立刻显得像 2018 年的后台模板。
仪表盘。数据卡片、折线图、排行榜都齐了，可卡片与卡片之间的间距毫无规律，有的 16px，有的 32px，有的 24px。图表颜色不是来自品牌色板，而是模型自由发挥的一套蓝色系。hover 效果要么没有，要么只是在半透明底色上再叠一层，层级关系很乱。
博客首页。文章列表的标题字号只比正文大了 2px，这直接让整个阅读层级失效。卡片之间没有呼吸感，所有元素都挤在一个 1200px 的容器里。最尴尬的是内容，满满当当的 Lorem ipsum 英文占位，配上中文界面，违和感拉满。
这三个例子其实很有代表性。它们的问题不是"代码写错了"，而是整体观感不对，专业点说，是缺乏视觉层级和统一节奏。这也是为什么很多开发者看 AI 生成的页面总觉得"能用但不好看"，又说不清楚具体坏在哪。
1.2 "硅基味"的具体配方
如果把"AI 味"拆开，其实就是一组固定配方。
间距没有体系。模型倾向用 margin 硬顶，而不是基于统一的 spacing token 来规划。于是页面经常出现 8、16、22、30 这种乱七八糟的间距序列，看起来每个元素都"刚好对上"，但整体没有对齐节奏。
颜色没有主次。它喜欢把所有元素都上一遍色，或者全部压成灰色。按钮是蓝色，链接是另一种蓝色，标签是第三种蓝，背景又是第四种。单个元素都有道理，放一起就花。
字体大小没有阶梯。h1、h2、body、caption 之间没有明确的比例关系。很多模型会把标题写得太小，正文写得太淡，注释又不够弱，最终页面的视觉焦点就崩了。
状态缺失。这是工程层面最致命的。AI 生成的表格默认只有"有数据"的完美状态，loading、empty、error、disabled 这四类状态经常被忽略。页面在理想数据下看起来还行，数据一空、权限一收，界面立刻塌陷。
"AI 味"的本质，是模型把互联网上最常见的设计模式平均化之后的结果。它不丑，但平庸；完整，但没有记忆点。用户说不清哪里不对，只会觉得"有点廉价"。而这股廉价感，恰恰是 Web UI 与普通代码任务最大的不同——它不是一个逻辑正误问题，而是一个感知质量问题。AI 在代码任务里可以靠 90 分的平均输出被接受，但在 UI 任务里，90 分和 60 分的差距，用户一眼就能看出来。
2. 根因：下一词预测接不住像素级审美需求
现象有了，下面往根上挖。
2.1 审美需求无法量化成损失函数
先想一个问题：机器学习里，模型怎么知道自己的输出好不好？答案是损失函数。代码任务特别适合这套逻辑：编译通过就是好，单测通过就是好，接口请求正确就是好。这些标准能写成明确的数学目标，模型可以沿着反馈优化。
但 UI 任务里，"好不好看"没法写进损失函数。你没法给一张界面截图计算一个"好看值"，更没法给"这个按钮比那个按钮好看 0.03"这样的梯度。模型在训练时见过海量界面，但它学的是文字和代码的对应关系，而不是视觉层面的美学偏好。用户说"要有质感"，这个需求在训练数据里出现了一万次，对应的视觉特征却是五花八门的：有的靠大留白体现质感，有的靠细字体，有的靠精致图标。模型只能选一个统计学上最可能出现的答案——最后往往就是那个平均值，也就是我们看到的"AI 味"。
这还不是全部。需求本身是模糊的，不同群体的审美权重完全不一样。金融客户觉得深蓝和金色是大气，年轻创业团队觉得大留白和细字体才是高级。你对模型说"做一个大气点的登录页"，它没法问你是哪类用户、在什么场景下用。它只能赌。所以结果经常在"正确"和"合适"之间差了一口气。这也是为什么产品经理给 AI 提需求，往往要反复打磨 prompt 很久，最终还是要设计师出手收尾。
2.2 上下文窗口装不下整个设计系统
第二个根因，是模型的工作记忆太短。成熟产品的 UI 从来不是单页面的好看，而是全站一致性。真实项目里会有设计系统文档、组件库源码、主题变量、几十个页面的历史样式。这些东西加起来远超模型上下文窗口能容纳的信息量。
具体说，模型生成一个页面时，往往只看到你喂给它的那几个 prompt。它无法知道你项目里主色是#0A84FF还是#2563EB，不知道你所有按钮圆角统一是 8px，不知道弹窗底部按钮应该左次右主。于是它把手伸进训练数据，取出频率最高的默认值。几个页面分别生成出来，单看都还行，拼成一个产品就露馅——仿佛五个不同设计师各做了一个页面，谁也没跟谁对过参数。
这里还有一个更隐蔽的技术坑：CSS 的层叠与继承。模型在局部生成代码时，很难推算一个 class 在整站继承链上会被谁覆盖。它经常输出看似合理的 style，一进真实项目就被全局样式覆盖。常见的情况是：你让 AI 把登录按钮改成品牌蓝，它给你改了个#2563EB，刷新后按钮还是原来的灰色——因为全局样式表里有一条更具体的规则把它压住了。这种"明明改了又好像没改"的体验，很多人应该都有过，这不是 AI 偷懒，而是它根本看不见你那套全局样式。
2.3 没有视觉反馈闭环，模型只能盲写
第三个根因，是反馈闭环缺失。
人做 UI 的过程永远是"写-看-改"循环：写一版，渲染到浏览器里，眯起眼感受一下层级和节奏，改，再看。AI 目前在做的事，更像文字到代码的一次性翻译。它对着 token 写代码，看不到渲染结果，更没人告诉它"这版字号小了，间距大了"。代码有编译报错、单测反馈，UI 没有。
也别跟我提多模态模型——很多模型确实能看图，但生成代码时的推理路径并不经过真实的浏览器渲染。你不知道一个 14px 的字号在小屏上的实际观感，模型更不知道。它只是在统计层面上觉得 14px 是正文的常见字号，就选了 14px。结果就是：AI 生成的页面在桌面端看着还凑合，一缩到移动端就崩。因为它推理的是 DOM 结构是否正确，而不是布局在 375px 宽度下是否可用。
这个闭环的缺失还带来一个连锁反应：AI 永远没法从自己的错误里学习。人做烂了一个页面，会记住"下次别用这么大的投影"。模型每次生成都是独立的概率采样，上一次的失败不会成为下一次的教训。除非外部有人把"这次不行"反馈给它，否则它只会装作无事发生，继续生成下一个平庸的 90 分答案。
3. 边界：哪些 UI 场景 AI 其实能做得不错
在吐槽完问题之后，我想说点公道话：AI 不是所有 UI 都写不好，它的水平高度依赖场景和约束。
3.1 范式化后台页面的"脚手架"能力
先说结论：后台上类型页面，AI 表现远超预期。
登录页、注册页、权限列表、数据表格、筛选表单、分页器、二次确认弹窗……这些界面范式极强，设计模式高度统一。你只要把组件库名字告诉它，比如 Ant Design 或 Element Plus，再给它一份接口数据结构，生成的页面可以直接当原型用。
我做过一次完整实验：让 AI 生成一套用户管理页，包含搜索框、角色过滤、用户列表、批量操作、权限标签、删除二次确认。它一次生成的可用程度在 80% 以上，我只需要改间距、补空态和 loading，再统一一下颜色。原因也很好理解：这类页面最看重功能完整和结构清晰，而不是视觉惊喜。模型在训练数据里见过几百万次这种布局，"平均化"在这里恰好是优点。
所以如果你正在做后台、中台、内部工具，大胆用 AI 搭骨架，把精力留给真正需要审美的对外页面。这里我多提一句：给 AI 的 prompt 里一定要带上"使用 xx 组件库"和"数据格式如下"，它能少犯很多结构性的错。
3.2 原子化 CSS 和组件库带来的约束红利
我发现自己让 AI 写 UI 有个清晰规律：自由度越高，输出越烂；约束越强，输出越稳。
完全自由发挥的 CSS 是 AI 的重灾区。它可以随便定义变量、起 class 名、写长度单位，于是选择太多，反而容易放飞。而把它关进一个强约束笼子里，指标立刻变好。我现在做页面时会先定义一套设计 Token：颜色、间距、字号、圆角、阴影全部做成 CSS 变量，然后明文告诉模型"只能用这些变量，不要自创"。只要不突破这个基本盘，它再怎么发挥平庸，页面至少是干净的。
这里还有一个更现实的红利：Tailwind 这类原子化 CSS。因为类名空间小、组合固定，模型对 Tailwind 的记忆力和准确性明显更高。你让 AI 用 Tailwind 重写一套界面，通常比让它写自定义 class 效果好得多。同样地，shadcn/ui、MUI 这种带明确组件的体系，AI 的输出准确率也比较可观。用一句直白的话总结：你给它的设计约束越像一道填空题，它就越接近满分；你让它自由创作，它就只能还你一个平均脸。
3.3 语义结构与逻辑拆分上的稳定发挥
视觉层之外，AI 在 UI 语义结构上表现一直很稳。它能把手写 HTML 正确重构出 header/main/footer，能补上 button 的 type、输入框的 label、错误提示的 aria 关联。让它把一段纠缠的组件拆成子组件、把接口状态抽进 hook，它也能做得不错。
这些工作可靠，是因为它们属于语言结构问题，不依赖视觉审美。HTML 嵌套规则和 ARIA 规范是明确的文本模式，模型在语料里见过海量正确与错误例子，统计规律足够强。所以我的使用习惯是：把 AI 当语义层工程师和组件结构顾问，把审美判断和视觉调整留给自己。它负责把结构搭对、状态分清，我负责让页面被看第一眼时不出戏。明确这条分工边界之后，AI 在我这里的生产力翻了一倍不止。
4. 工作流：把 AI 纳进前端设计流程的正确姿势
说清楚原因和边界，接下来是我实际在用的工作流。
4.1 先定设计 Token，再让 AI 填充
大多数人的做法是打开聊天框直接说"帮我生成一个好看的登录页"。这个 prompt 注定结果平庸，因为"好看"是一个没有边界的指令，AI 只能取平均。
我的做法反过来：先把地基给死。颜色系统、间距系统、字号阶梯、圆角规范、阴影等级，全部写成 CSS 变量，再让 AI 在这个地基上填充页面需求。下面是一个我常用的 prompt 模版，你可以直接抄：
你是这个项目的前端开发。项目使用 React + Tailwind CSS。 设计 Token 如下： --color-primary: #2563EB; --color-primary-hover: #1D4ED8; --color-text: #1F2937; --color-text-secondary: #6B7280; --color-border: #E5E7EB; --color-bg: #F9FAFB; --radius-md: 8px; --shadow-card: 0 1px 3px rgba(0,0,0,0.08); 所有颜色只能从这些变量取值，间距使用 4px 基数的倍数， 字号只能从 12/14/16/20 中选择。 请生成一个用户管理页面的 React 组件，包含搜索框、 过滤下拉、数据表格、分页器。表格数据从 props 的 data 字段获取，需处理 loading 和 empty 状态。这个 prompt 背后是一条非常朴素的经验：给 AI 的自由度越大，输出方差越大。你把变量和边界定死，它就从"想象力过剩的实习生"变成"知道所有规范的熟练工"。实测用这种方式生成出来的页面，至少不会出现那种一眼假的科技感；剩下的细节问题，人肉微调的成本很低。
4.2 组件递进比一稿全出更稳
很多人喜欢让 AI 一口气把整个页面生成出来，结果往往是大杂烩。我现在更倾向于分步生成：先基础布局，再逐个组件，最后拼装。
具体操作大概是：第一步让 AI 生成页面框架——侧边栏、顶栏、内容区；第二步生成数据卡片组件；第三步生成图表容器和数据表格；每一步都把前面生成的代码片段贴进去，告诉它"保持风格一致"。这样做的好处是，模型每一步只关注一个局部，上下文压力小，CSS 冲突概率低。整体出来的感觉比"一步到位全页输出"和谐得多。
类比一下人写页面的过程，其实也是先打框架、再填组件、最后调细节。AI 一次做太多，就容易在局部正确和全局一致性之间顾此失彼。把认知负荷拆小，模型的表现就会稳定不少。
4.3 用截图评审和多轮修订做视觉闭环
AI 没反馈闭环，我们可以替它搭一个：每生成一个大块，就跑起来截图看一眼。
看到问题后，不要笼统地说"不好看"，要给具体差量描述。比如：
- 标题和正文之间的间距过大，改成 12px；
- 卡片的投影太重，把阴影透明度从 0.16 降到 0.08；
- 主按钮 hover 时加一个从 primary 到 primary-hover 的背景过渡。
这个技巧核心在于，AI 修改代码靠的是对文字指令的理解。你给的差量越具体，它越能精确修改。"这里怪怪的"这种话，模型只会回你一个同样含糊的无效调整。
另外我还会做一件事：让 AI 一次性生成三个风格方案，再由人用眼睛挑一个，而不是跟它来回迭代。很多时候与其吵十轮，不如让它并行出三版。这个方法解决的是模型不知道什么叫好、但人眼能挑出相对优解的问题。多模型协作也是如此，不同的模型负责不同方案，最后用人的审美拍板。
4.4 实测里最值得盯的几类细节
真人评审时，我 90% 的修改都落在这五类细节上，你可以直接拿来当验收清单：
- 间距一致性：卡片之间、区块之间是否遵循同一个间距变量，有没有零散的 17px、23px；
- 状态完整度：loading、empty、error、disabled 四类状态是否都有渲染；
- 响应式断点：375px、768px、1440px 三档宽度各看一遍，重点看栅格是否崩；
- 交互反馈：hover、focus、active 的视觉区分是否明显，切换有没有过渡动画；
- 真实内容：所有 Lorem ipsum 占位文字是否替换成了业务文案，头像和图片是否真实可信，避免英文占位配中文界面。
为什么是这些？因为它们最影响"完成度"。AI 生成单页很难在艺术性上给惊喜，但只要把这些工程细节补齐，完成度就能从 60 分拉到 90 分。这里的 90 分不是审美突破，而是专业可靠。
5. 方向：Agent 化调试与多模态反馈闭环
最后聊一点我对未来的判断，以及当下可以怎么布局。
5.1 让视觉语言模型当"评审官"
前面说了，UI 生成的最大缺口是反馈闭环。闭环的第一环是"机器能看见"。现在多模态模型已经能做到这一点了。
我最近在用的一个套路：让代码模型生成页面，然后把页面截图丢给一个视觉语言模型，让它从设计师视角挑毛病。它经常能指出"标题层级不够清晰""主按钮与输入框宽度不一致""图表配色与品牌色板冲突"。这些话虽然不如资深设计师精准，但当一道初筛已经绰绰有余。拿到这些评审意见之后，再喂回给代码模型修改。三步一个循环，页面质量肉眼可见地提升。
这个思路并不复杂，本质上是把"评审"这个工序从人手里转移给了机器，让模型在生成循环里获得了"看"的能力。很多人担心视觉模型不够专业，实际上你不需要它一锤定音，只需要它帮你把明显的问题先排掉，人再集中精力处理剩下的微妙判断。
5.2 AI Agent 自己去打开浏览器调页面
再往前走一步，就是 AI Agent 自己打开浏览器看渲染结果、自己改代码。现在这类雏形已经出来了：Agent 写完代码自动截图，调用视觉模型打分，低于阈值就继续修改。这其实就是把设计师的"写→看→改"闭环移植给了机器。
我为什么说这个方向一定会成熟？因为人调 UI 从来都不是闭着眼写代码，而是反复在浏览器里看效果。AI 如果永远停留在文本 token 空间，就很难理解一个 1440px 布局在移动端为什么崩成两截。唯一可靠的解，是把渲染结果作为下一轮输入喂回去，让模型在"看到"的画面与代码之间建立关联。这是目前看下来最接近人类设计师工作方式的路径。
5.3 工具不完美时的人机分工
当然，眼下的 Agent 还不够熟练，视觉评审也远达不到资深设计师水平。工具不完美的时候，我更建议大家先把分工想清楚，别等工具成熟再动手。
我的分工原则是：AI 负责高确定性任务，比如搭布局骨架、整理状态逻辑、拆分组件、补语义标签、按设计 Token 填充；人负责审美层的最终裁决，比如色彩走向、视觉层级、间距节奏这些没法量化成指令的东西。如果团队里有设计师，最好让设计师先把组件规范和设计 Token 定义好，AI 只在这些约束里产页面，前端再把细节修到验收标准。
还有一个容易被忽视的点：不同模型其实各有长短。有人让一个模型既要出结构又要评视觉，效果往往一般。我的做法是让一个模型写结构，另一个模型当视觉评审，再安排一个模型做代码修整。这就是现在常说的"多 AI 协作"，关键不是堆模型数量，而是给每个模型定义清楚职责边界，别让它一个人又当运动员又当裁判。
选型上，我现在的策略是"宁可多花一点时间做约束和评审，也不让 AI 直接摸生产 CSS"。只要变量和边界全部限定好，AI 生成的页面质量和稳定性都是在线的。真正的瓶颈从来不是模型不会写代码，而是我们在多大程度上愿意为它建立一套工程化的约束与反馈机制。
最后说一句我的体感。我自己这几年做前端，最大的感受是 AI 正在把 UI 开发从"从零画图"推向"约束下填空"。审美归根结底还是要人拍板。再有人跟你说"AI 写不好 Web UI"，我大概会接一句：对，但你得先把边界给它画好，你才是那个决定边界的人。
