1. 从一次“翻车”说起：AI 生成页面为什么总是差一口气
先说个经历。我让大模型帮我搭一个数据看板的前端页面，需求描述写得很详细：顶部是筛选区，中间是图表区，左侧是指标卡，右侧是操作日志。模型不到三十秒就给了我一个 React 组件，结构完整，状态管理齐全，图表库也封装得漂漂亮亮。我满怀期待地跑起来，发现按钮悬浮在页面正中央，间距像是用脚写的，主色和辅助色放在一起像西红柿炒蛋配蓝莓酸奶。最离谱的是，一个“空状态”的插画，居然是被拉变形的一只猫。
这不是个例。我长期用各类 AI 辅助开发，一个残酷的事实是：AI 在 Web UI 上的表现，跟它在代码生成、文档撰写上的表现完全不在一个量级。后端接口、算法逻辑、SQL 查询，AI 能给你写个八九不离十；但只要你让它设计一个登录页、一个表单、一个 Dashboard，它就开始“迷之自信”地输出一堆看似合理、实则反人类的界面。
这篇内容，我从自己的实际项目经历出发，说说 AI 写不好 Web UI 的真正原因，顺带聊聊我们这些靠“提示词”吃饭的人，能怎么跟这个短板共处，而不是跟它较劲。
2. Web UI 的本质不是“写代码”，而是“做决策”
2.1 布局、间距、层级：这些“小事”决定了 UI 是否可用
很多人以为 UI 开发就是把设计稿转换成代码。如果仅仅是这样，AI 应该早就胜任了——把 Figma 切图、导出 CSS、生成 JSX，这类机械工作模型做起来确实不差。但真正的 Web UI 开发难在“决策”：这个按钮该放在哪一列？表单是两列排布还是一列到底？文字和图标之间的留白是 8px 还是 12px？首屏该突出主操作还是先展示数据？这些决策写不出来具体的规则，更多靠的是经验、审美和用户同理心。
大语言模型本质上是一个“接龙游戏”玩家——它预测下一个 token 最可能是什么，而不是判断这个 token 放到页面上是否好看、是否好用。你让它生成一个按钮，它知道按钮的语法，知道按钮的样式属性，但它不知道这个按钮在页面上的“分量”几何。视觉层级、节奏感、对比度，这些 UI 设计师天天挂在嘴边的词，对模型来说只是语料库里的高频词汇，不是可计算、可校验的视觉经验。
我自己经常用一个判断标准：把 AI 生成的页面截图，给一个完全不懂技术的人看，如果对方一眼找不到“这个页面主要让我干什么”，那这个设计就是失败的。这个判断标准对 AI 非常苛刻——但它恰恰是 UI 设计的真实目标。
2.2 “看起来不错”和“真的好用”之间，隔着用户认知
更棘手的是，AI 有时生成的页面乍看并不差——配色统一、卡片排列整齐，信息层级也清晰。但一旦进入真实交互，问题就暴露了：点击区域太小、键盘 Tab 顺序乱跳、弹窗没有焦点锁定、移动端和桌面端断点错乱。这些属于“可访问性”和“交互可用性”，需要真实用户、真实设备去验证，模型在生成时对这些信息一无所知。
我做过一个测试：让两款主流 AI 各自生成一个带筛选条件的表格页面。从静态截图看，两者都算及格。但实际操作时，其中一个的筛选器在点击之后，下拉菜单直接被表格遮住，甚至没法选中选项。另一个更离谱，点击“下一页”之后，整个表格区域滚动位置没有重置，用户会觉得自己点了个假按钮。这种问题不是“设计风格”的问题，而是对交互细节的理解缺失。
这就引出核心矛盾：大模型处理的是文本序列，而 UI 的可用性存在于空间、时间、设备、行为组成的多维环境里。模型看不到、没摸过、没点过，自然写不出来那种“顺手”的界面。
3. 拆解一下 AI 写 UI 时最常犯的几类错误
3.1 对“像素级精确”天然免疫
大模型处理的是 token，不是像素。它看到的是“margin: 12px”这个 token 序列，而不是屏幕上那 12 个物理像素到底长什么样。所以当你要求 AI 精确还原一个视觉稿时，你会发现它在数值层面“差不多”，但组合起来的视觉效果差很多。
举个例子，你给 AI 一句话：“做一个卡片，标题、描述、按钮三部分，看起来像 Stripe 官网的风格。”它大概率会给你一个圆角卡片、一个加粗标题、一段灰度文字，以及一个蓝色按钮。每个元素单独看都合理，但组合起来就是一股“模板味”。原因很简单：Stripe 官网的精致感，来自渐变颜色微调、边框阴影的层次、字体渲染的细节排布、元素间的节奏呼应。这些都是百亿级参数模型无法从文字提示中还原的——因为它从未真正“看过” Stripe 官网的像素。
我在实际项目中采取了一个折中策略：不要求 AI 直接产出终极视觉稿，而是让它先产出结构骨架，我再手工调样式。这相当于把 AI 当作“初稿生成器”，而不是“成品交付者”。
3.2 高度依赖训练数据，缺乏“设计品味”
大模型最好的能力是模仿高频模式。在 UI 领域，高频模式就是各种 Bootstrap、Material Design、Ant Design 模板。于是，AI 生成的界面总是逃不开三个套路：白色背景、蓝色主按钮、圆角卡片。没有说这三个元素不好，但这样的界面放在 2024 年，真的毫无辨识度，用户打开页面三秒就知道“这是不是套模板做出来的”。
“设计品味”这个词听起来很虚，但它其实有迹可循：好的设计通常具备克制的用色、清晰的层级、意外的细节、统一的节奏。这些很难用语言量化为指令——它们是看的、感受的、对比出来的。大模型没有“看过”足够多的优秀设计作品，也没有能力把视觉美感转化为像素输出，所以它给出的答案永远是“安全但平庸”。
我常跟团队里新手说的一句话：AI 可以帮你把问题想清楚，但它很难帮你把界面做好看。后者需要的是积累——刷优秀案例、存灵感库、练手抄稿，这些功课谁都替代不了。
3.3 缺少“用户旅程”思维，生成的只是页面不是产品
UI 开发的大背景是“用户在做一件事”。这个背景看起来简单，但拆分出来极其丰富：用户从哪个入口进来？ta 此刻的目标是什么？遇到错误时怎么引导？操作完成后的反馈是什么？页面和页面之间的流转顺畅吗？新用户第一次看到这个界面，会不会懵？老用户能不能更快完成操作？
AI 没有这些理解。它只是针对你给的需求，生成一个静态页面。结果就是：每个页面单独看都还行，但串起来之后，用户流程支离破碎——从列表页点进详情页，没有返回路径；表单提交成功后，没有跳转反馈；数据为空时，用户面对一个孤零零的空白页面不知所措。
我记得有一次让我让 AI 做一个订单管理页面，它给出了一个非常完整的表格界面，但我用一个真实用户的视角去审视时发现：表格最右边是“操作”列，里面有“查看”“编辑”“删除”三个按钮。这看起来没问题，但 AI 没有考虑到“删除”是一个破坏性操作，用户误点的风险极高，页面里也没有二次确认的机制。这种“用户保护机制”不是写代码的问题，是产品思维的问题。
3.4 对响应式布局、跨端适配的理解流于表面
现代 Web UI 早已不是“一个页面走天下”的时代。同一套界面，可能要跑在 1440px 的桌面浏览器、768px 的平板、390px 的手机竖屏上。响应式设计需要一套完整的断点策略：小屏哪些元素收纳进汉堡菜单？表格在窄屏是横向滚动还是隐藏次要列？字体和间距是否等比缩放？图片是裁切还是缩放？
AI 对响应式的理解通常停留在“加一个 media query”的层面。它知道语法，但不知道决策。结果是：它能写出在小屏下“不会崩”的界面，但谈不上好用。比如，AI 可能会在小屏下把五个筛选条件竖直堆叠，用户光填筛选条件就要滑动三屏；正常的做法应该是把高频筛选条件保留、低频条件折叠进弹层。这些决策需要理解用户场景，AI 做不到。
在移动端优先的项目里，我的经验是：别让 AI 自由发挥。把断点的设计决策写死在提示词里，明确告诉它“平板宽度下将筛选器改为横向滚动”，它才能输出你想要的布局行为。否则它只会给你一个“不错但意外频发”的结果。
4. 为什么“术”上做不到：技术限制决定 AI 永远隔着一层纱
4.1 从“输入”到“输出”：AI 看不见真实渲染结果
很多人忽视了一个关键技术细节：大模型在生成 UI 代码时，并没有在执行环境中“运行”那行代码。它不知道渲染出来的页面长什么样、交互是否流畅、有没有横向滚动条、字体有没有被裁掉。它是在纯文本空间里做“下一个 token 的预测”。
这意味着 AI 的 UI 生成过程是“盲写”：它在写一段它自己无法验证的代码。就像一个人闭着眼睛画画，画得再熟练，也很难画出准确的结构比例，更别提细节美感了。
我见过有团队尝试通过“AI 生成代码 → 浏览器渲染截图 → 把截图喂回视觉模型 → 调整代码”的闭环方式来提升 UI 质量。这个思路是对的，但它有一个致命前提：视觉模型的判断标准是什么？是“截图上有没有明显错误”（比如溢出、重叠、空白异常），还是“这个设计是否美观”？前者可以通过 CV 算法初步实现，后者则极其困难——审美评价是高度主观的，根本无法用统一的损失函数来定义。
这就是 AI 写不好 UI 的技术根源：它没有闭环验证能力。后端代码写错了会报错，AI 可以依据报错信息修复；前端 UI 写“丑”了，AI 收不到任何报错。界面丑、交互差，在系统层面不会产生异常日志，AI 因此永远不知道自己做错了。
4.2 Token 化的世界：页面被压缩成“字符流”后，空间关系已经丢失
语言模型处理的一切都是 token。当我们把一段 UI 代码喂给模型时，空间上的关系——这个元素在那个元素的左边、这个卡片高度比那个卡片高三倍、这个文字和旁边文字有 16px 的间距——全部被压缩成了“margin-left: 16px”这样的文本序列。模型能看到“16px”这个数字，但它无法直观感知 16px 是一个舒服的距离还是一个拥挤的距离。
这就像你通过文字描述去回忆一个朋友的长相：你知道他有鼻子有眼睛，但你说不出眼睛具体的距离、鼻子的弧度，因为文字描述无法完整还原视觉信息。语言模型天生生活在文字的“失乐园”里，它离视觉世界的物理感受天然隔了一层。
这也是为什么 AI 在生成代码逻辑时表现很好——逻辑本身就是语言结构，模型在文字层面可以自洽；而 UI 美学本质上不是语言结构，它是视觉结构，模型只能在文字符号层面“隔靴搔痒”。
4.3 评估难题：UI 质量根本无法用“下一个 Token 概率”来衡量
大模型的训练目标是最大化下一个 token 的预测准确率。后端代码、算法逻辑，这些任务都有比较明确的确定性答案——函数返回什么、边界处理怎么做、异常怎么捕获，好的标准相对客观，模型可以通过大量代码语料学习到“正确写法”。
UI 设计没有唯一的正确答案。同一个功能，用浅色主题还是深色主题？标签放在顶部还是左侧？弹窗用居中还是侧滑抽屉？这些问题没有对错之分，只有适合的场景、用户偏好和产品气质。模型在训练中看到过“margin: 24px”，也看到过“margin: 8px”，从统计概率看，它可能会倾向输出最常见或最平均的值——但最平均值往往不是最优解，而是平庸解。
更麻烦的是，如果我们要专门训练一个模型来“写好 UI”，我们需要一个可靠的奖励信号（reward signal）。代码生成领域可以用单元测试、编译通过率来作为奖励，UI 生成领域呢？截图是否能通过某种“审美评分模型”？这种模型的训练数据从哪来？人类的审美共识有多大程度可以被编码？目前这些问题的答案都很模糊。
我个人的判断是：在“AI 的审美评估”这一关突破之前，AI 写 Web UI 的上限就是“可用，但不惊艳”。它可以把界面做得功能完备、结构清晰，但很难做出那种让人眼前一亮、忍不住分享的设计。
5. 破局思路：不完美的 AI，也能成为 UI 开发的好搭档
5.1 把 AI 当“实习生”，不当“主设计师”
我现在的态度非常明确：AI 是 UI 开发流程里的实习生，不是主设计师。实习生可以帮你做初稿、查资料、写基础组件代码，但最终的设计决策、关键视觉调整、交互细节把关，必须自己来。
落到实操层面，我给团队定的流程是这样的：
第一，设计先行。在让 AI 生成代码之前，先手工画出页面的框架——不要求精致，哪怕是手绘草图、白板上的方块图，只要把信息层级、布局结构、关键交互明确下来就行。这个动作看起来反效率，但实际上能帮 AI 大幅收敛生成空间，避免它自由发挥。
第二，代码生成放在样式设计之后。当你已经把设计意图明确到“左侧 280px 侧边栏、右侧主内容区、顶部 64px 导航栏”这种程度时，AI 生成的代码才会真的可用。它擅长的是把你的设计意图翻译成代码，而不是替你想设计意图。
第三，把修改反馈写进提示词。如果 AI 生成的效果不理想，不要笼统地说“不好看”，要有针对性地反馈：“按钮颜色对比度不够，改成深蓝色”，或者“卡片间距太密，统一改为 16px”。越具体的反馈，AI 的修正效果越好。这就像带实习生，你把需求讲得越清楚，他做出来的东西越接近你想要的。
5.2 从“让它生成”到“让它迭代”：Prompt 工程的进阶玩法
还有一种更进阶的用法，让我在实际项目中大大受益：把 AI 当作“UI 评审员”，而不是“UI 生成器”。
具体做法是：先让 AI 生成一版 UI 代码，然后我把界面截图、用户场景描述、目标用户特征一起喂回给它，让它以“资深产品设计师”的视角提出修改建议。这时候，AI 反而能给出不少有价值的反馈——因为它没有视觉体验能力，它的“批评”大多来自通用的设计原则和常见模式，但作为“检查清单”来用是足够了。
举个例子。我做一个面向老年人的健康管理页面时，让 AI 审查了第一版设计。它提出了这样几个建议：增大正文字号、提高按钮点击区域高度、在完成重要操作后给出明确的文字反馈、避免过多弹窗打断操作流程。这些建议不算惊世骇俗，但对一个“宽泛的健康管理页面”来说，确实是有效的可用性提醒。
这个方法的核心是：AI 对“功能完整性”的判断比“视觉美感”的判断靠谱得多。你让 AI 识别一个页面“是否缺少必要的元素、流程是否顺畅”，它能胜任；但你让它判断“这个页面的配色是否高级”，它大概率给不出有价值的答案。
5.3 选对工具和方法，效率不会差太多
不同的 AI 工具在 UI 生成上的表现差异很大，但我试下来的总体感受是：没有哪个模型真正解决了“审美”问题。它们可能在某一方面稍有改善——比如上下文理解更长、生成复杂组件更稳定——但视觉输出的核心短板依然存在。所以与其纠结“哪个模型最适合写 UI”，不如在流程和方法上多投入精力。
我的工具组合是：设计阶段用 Figma 手动搭框架，chat 类大模型负责出初始代码和交互逻辑，浏览器里用自动截图工具实时查看效果，不满意就根据截图反馈给模型迭代。这套组合能保证每个环节都有“人”把关键决策，而不是把宝都押在一个模型上。
如果你愿意再进一步，可以试试“多 Agent 协作”的思路：让一个 Agent 负责写页面结构，另一个 Agent 专门负责写 CSS 样式，再让第三个 Agent 充当“测试员”，打开页面检查布局溢出、颜色对比度、响应式断点等问题，把结果反馈给前两个 Agent 修改。实质是把一个“全能的 AI”拆成多个“专精的 AI”，让它们在互相纠错中逼近一个更好的结果。实测做简单页面时效率提升很明显，复杂页面仍需要人工兜底。
5.4 接受现状，更要理解 UI 的“不可完全自动化”
最后想说的是：UI 设计的“不可完全自动化”并不是 AI 的失败，而是这个领域本身的特质决定的。好的 UI 不是公式的产物，它是关于“人”的理解——人如何看、如何想、如何操作、如何感受。一个页面真正做到“好用”，意味着设计师把自己代入到用户的脑回路里，替用户把操作路径走了一遍。这种共情能力，别说是 AI，连很多初级设计师都不具备。
我这几年越来越深的一个体会是：AI 在很多领域是“替代者”，但在 UI 设计这个领域，它更多是“放大镜”——放大你的想法，也放大你的懒惰。如果你脑子里没有清晰的设计意图，AI 不会帮你凭空变出一个好设计；但如果你胸有成竹，AI 可以帮你快速把想法落地成可用的代码，省掉大量重复劳动。
6. 给同路人的实操建议与避坑清单
6.1 写 UI 提示词时，把这四件事说清楚
想让 AI 输出更接近可用的 UI，提示词里不能只写“帮我做一个登录页”。你需要交代清楚这四件事：
页面用途和用户场景。这是登录页还是支付页？用户是第一次来的访客还是有账户的老用户？TA 当前的设备偏好是什么？场景不同，页面的信息密度、操作引导完全不同。
信息结构优先级。页面上有哪些元素？谁是主操作？谁是次要操作？哪些信息需要突出展示，哪些可以折叠？把这些用列表写清楚，AI 就不会把主次搞混。
视觉风格参考。直接告诉它“参考 Linear 应用风格”，比写“要极简、要高级”有效得多。业界有名的产品本身就是最好的风格锚点。
交互行为期望。按钮点击后的反馈方式、表单校验规则、错误提示文案、加载状态、空状态，这些交互细节在提示词里说一句，AI 生成的效果会明显上一个台阶。
6.2 UI 代码生成后的五个默认检查项
无论 AI 生成的界面第一眼看起来多好，我建议你跑一遍这五个检查：
- 在 1920px、1440px、768px、390px 四种宽度下截图预览，重点看布局是否崩坏、字体是否过小、点击区域是否局促。
- 检查所有按钮和链接的键盘可访问性：Tab 键能否顺序聚焦？聚焦后的可见样式是否明显？
- 检查表单的完整流程：从输入到提交到结果反馈，每一步是否有明确提示，报错信息是否友好。
- 检查空数据和加载态：接口返回为空时页面显示什么？数据加载中是骨架屏还是转圈？这两个状态常被 AI 忽略。
- 检查最终页面是否有多语言预留空间：文字溢出、日期格式、货币符号，这些细节在国际化场景下极容易被 AI 写出“本地化事故”。
我自己在项目里就是把这五个检查项做成了一个 checklist，每次 AI 生成页面后逐项过一遍。虽然需要额外花十来分钟，但能省掉大量返工时间——包括 AI 返工和自己在浏览器里调试的时间。
6.3 对待 AI 的正确心态：工具终归是工具
唠叨了这么多，最后说点心态层面的体会。经常有人问我：AI 能不能完全替代前端 UI 开发？我的感受是，至少目前不能——不是技术不够，而是“产品审美”和“用户共情”这两件事，大模型在架构上还没有找到有效的建模方式。
但这不代表 AI 对 UI 开发没有价值。恰恰相反，我在日常项目中，AI 帮我完成了大量重复性工作，把我从繁琐的布局代码里解放出来，能腾出更多精力去思考真实的设计问题：这个界面对用户来说是否友好？信息呈现是否自然？操作流程是否顺畅？这些问题的答案，AI 给不了，但我可以在它的帮助下更快地找到。
如果你也是每天跟 AI 协作做 Web UI 的开发者和设计师，我的建议是：别急着否定它，也别盲目依赖它。把它当成一个执行力尚可、审美平庸、逻辑偶有漏洞但速度极快的“初级协作伙伴”。把设计决策权握在自己手里，把重复劳动丢给它——这样的配合方式，是我目前实践下来最高效、也最不内耗的姿势。
AI 写不好 UI 这个事实，短期不会改变。但有了清醒的认知和正确的协作方法，它反而能成为推进项目的一把好手，而不是拖后腿的那个人。
