1. 这不是设计批评，是AI时代的产品体检指南
“粗制滥造的用户界面”——这八个字一出来，很多设计师会下意识皱眉，产品经理可能立刻点开自己刚上线的H5页面截图，而前端工程师大概已经默默打开了控制台。但今天说的不是某家公司赶工交付的烂稿，也不是实习生交上来被退回三次的Figma文件；说的是当AI开始批量生成UI组件、整页布局甚至完整应用原型时，那些高频复现、肉眼可辨、逻辑断裂、体验窒息的共性缺陷。我过去两年深度参与过7个AI辅助设计工作流落地项目，从用MidJourney出视觉概念图，到用Galileo、Galai、Uizard生成可交互原型，再到用Vercel v0直接输出React代码——越用越发现：AI生成的UI不是“不够美”，而是“根本没在思考人怎么用”。它不理解悬停状态为何要加0.2秒缓动，不知道错误提示必须绑定焦点，更无法判断一个按钮该放在左上角还是右下角才符合当前用户的操作路径。这10个迹象，是我和团队在真实项目中一条条标红、打标签、归因、反向训练模型时沉淀下来的“AI UI病理切片”。它们不是主观审美吐槽，而是可测量、可复现、可拦截的技术信号。比如“所有文字都用同一字号和字重”，背后是AI对视觉层级（Visual Hierarchy）缺乏建模；“表单提交后无任何反馈”，暴露的是AI对状态机（State Machine）概念的彻底缺席。如果你正在用AI做产品设计、做运营落地页、做内部工具搭建，或者正考虑把UI生成纳入开发流程——这10个迹象就是你的第一道质量防火墙。它不教你如何调参数，而是告诉你：看到什么，就该立刻叫停、人工介入、重新校准提示词或切换生成策略。这不是给AI挑刺，是在帮它学会真正“看见”用户。
2. 核心设计逻辑崩塌的10个硬性指标
AI生成UI不是“画得不像”，而是“逻辑没装进去”。它像一个背熟了所有设计规范手册却从没亲手做过一次用户测试的人——知道“应该有加载态”，但不知道加载态该在哪个节点出现、持续多久、失败后如何降级。下面这10个迹象，每一个都对应一个被AI系统性忽略的核心交互原则。它们不是风格偏好，而是可用性底线。我按实际影响权重排序，前3项一旦出现，基本意味着该页面无法进入用户测试环节。
2.1 所有文本元素字号/字重完全一致，无视觉层级区分
这是最典型、最高频、也最容易被忽视的“死亡信号”。你打开一个AI生成的登录页，标题、副标题、输入框占位符、错误提示、底部链接，全部使用16px Regular字体。表面看“很干净”，实则彻底摧毁信息优先级。人类阅读网页不是线性扫读，而是靠视觉重量（font weight）、字号对比、留白节奏快速锚定关键信息。F型阅读热区研究早已证实：用户首屏注意力80%集中在顶部左侧区域，而标题必须比正文大至少1.8倍才能触发“这是主信息”的认知反射。AI为什么做不到？因为它训练数据里大量网页截图缺乏语义标注——模型看到的是像素块，不是“这是h1”“这是label”“这是error message”。它没有学习到“标题需要强调→所以加大加粗→所以字号设为28px Bold”，而是机械复刻训练集中最常见的“统一16px”模式。我们曾用同一组提示词让5个主流UI生成工具输出注册页，100%出现此问题。解决方案不是后期手动调样式，而是在提示词中强制注入层级指令：“Use clear typographic hierarchy: H1 at 32px Bold, input labels at 14px Medium, error messages at 14px SemiBold in red, helper text at 12px Regular in #666”。
提示：别信“AI会自动理解语义”。它不会。你必须把“标题比正文大两号”这种人类常识，翻译成它能执行的像素级指令。
2.2 交互控件无状态反馈：悬停、聚焦、禁用、加载态全部缺失
一个按钮，鼠标移上去毫无变化；点击后既无loading动画，也无成功toast；表单验证失败时，错误信息飘在空白处，与出错字段毫无视觉关联。这是AI UI最危险的槽点——它制造了“功能存在但不可感知”的幻觉。用户点击无反应，第一反应是“页面卡了”“网络断了”“我手抖点了两次”，而不是“这个按钮还没做好”。背后是AI对交互状态机（Interaction State Machine）的零建模。真实UI开发中，一个按钮至少包含5种状态：default、hover、focus、active、disabled，每种状态对应不同样式、不同可访问性属性（aria-*）、不同键盘导航行为。而AI生成的代码里，你只会看到一个<button>标签，class名可能是btn-primary，但里面没有任何:hover伪类，没有任何aria-busy="true"，没有任何disabled属性的条件渲染逻辑。我们审计过32个AI生成的电商商品页，100%缺失加载态，92%缺失焦点轮廓（focus ring），导致键盘用户根本无法操作。修复方案不是补CSS，而是在生成阶段就要求AI输出带状态的完整组件树。例如在提示词中明确：“Generate a submit button with full state variants: include CSS for :hover (background darken 10%), :focus (blue outline 2px), :active (scale 0.98), and disabled state (opacity 0.5 + cursor not-allowed)”。
2.3 表单字段与标签分离，且无显式关联（missingfor/id绑定）
这是可访问性（a11y）的死刑判决书。AI生成的登录表单里，你看到一个<label>邮箱</label>紧挨着一个<input type="email">，但label没有for属性，input没有id，屏幕阅读器无法将两者关联。用户用VoiceOver浏览时，只会听到“编辑文本”，完全不知道这是邮箱还是密码字段。更糟的是，点击label无法聚焦input——因为缺少for/id绑定，点击label毫无作用。这并非AI“偷懒”，而是它从未被训练去理解HTML语义结构。它的训练数据是海量网页DOM快照，但这些快照里大量存在“视觉正确但语义错误”的写法（比如用div模拟label）。AI学到了“看起来像表单”的外观，却没学到“让表单真正可用”的底层规则。我们用axe-core工具扫描AI生成页面，表单关联缺失率高达97%。解决方法极其简单但必须前置：在提示词中强制要求“Every label must have a 'for' attribute matching the 'id' of its corresponding input. No exceptions.”。同时，在生成后立即用自动化脚本校验：document.querySelectorAll('label').forEach(l => { if (!l.htmlFor || !document.getElementById(l.htmlFor)) console.warn('Unbound label found') });
2.4 图标与文字信息重复，且图标无语义（无alt、无aria-label）
AI似乎迷恋图标。一个“设置”按钮旁放齿轮图标，再配“设置”二字；“搜索”框里塞放大镜图标，再写“搜索”。表面看“图文并茂”，实则违反WCAG 2.1核心原则：当图标仅起装饰作用时，必须移除其语义；当图标承载关键信息时，必须提供等效文字替代。AI的问题在于：它把图标当装饰画处理，既不加aria-hidden="true"，也不提供aria-label。结果是屏幕阅读器先读“齿轮图标”，再读“设置”，信息冗余且混乱。更严重的是，它生成的SVG图标常无viewBox、无role="img"、无focusable="false"，导致键盘焦点意外落入图标内部。我们测试发现，AI生成的导航栏中，35%的图标会劫持Tab键焦点。修复逻辑分三层：第一层，在提示词中禁用纯装饰图标：“Do not use icons for decorative purposes only. If an icon is used, it must be semantically meaningful and paired with aria-label.”；第二层，生成后用脚本批量注入：document.querySelectorAll('svg:not([aria-label])').forEach(svg => svg.setAttribute('aria-label', 'icon'));；第三层，对功能性图标（如“删除”按钮），必须强制生成带语义的完整结构：<button aria-label="Delete item"><svg>...</svg></button>。
2.5 颜色对比度全面踩线，关键信息可读性低于WCAG AA标准
AI对颜色的理解停留在“好看”，而非“能看清”。它生成的浅灰文字（#999）放在白色背景上，对比度仅2.8:1，远低于WCAG AA要求的4.5:1；成功提示用绿色（#4CAF50）配白色背景，对比度7.1:1看似合格，但色盲用户（尤其是红绿色盲）根本无法识别。这不是配色品味问题，是合规红线。AI模型训练时，色彩数据多来自高保真设计稿，但这些稿子本身未必通过可访问性检测。更麻烦的是，AI无法动态计算对比度——它不会因为背景变深就自动调亮文字。我们用axe-core扫描AI生成页面，平均每个页面有12处对比度违规，其中7处涉及核心操作按钮。解决方案必须双管齐下：一是生成前锁定安全色板，“Use only colors from this accessible palette: primary #2563EB (AA on white), text #1E293B (AAA on white), success #10B981 (AA on white), error #EF4444 (AA on white)”；二是生成后强制校验，用@deque/axe-coreAPI实时检测，不达标自动替换为合规色值。记住：对比度不是设计师的选修课，是法律要求的必答题。
2.6 响应式断点失效：桌面端布局直接缩放至手机，无流体网格、无媒体查询
AI生成的“响应式页面”，本质是“一张图适配所有屏”。它把1200px宽的桌面布局，用width: 100%; transform: scale(0.3)硬缩到手机上，文字小如蚂蚁，点击目标不足44px，横向滚动条永远存在。它不懂移动优先（Mobile-First）不是口号，而是工程约束：触摸目标最小44×44px、字体在移动端需≥16px、导航需折叠为汉堡菜单、图片需srcset适配。AI的失败源于训练数据偏差——它见过太多“PC端设计稿”，却极少接触真实移动端DOM结构。我们分析200个AI生成页面，100%缺失<meta name="viewport">，98%无任何@media查询，剩余2%的媒体查询只有一行@media (max-width: 768px) { body { font-size: 14px; } }，治标不治本。正确做法是在提示词中植入响应式DNA：“Generate mobile-first responsive layout using CSS Grid and Flexbox. Include media queries for 320px, 768px, and 1024px. Ensure touch targets are ≥44px, base font size ≥16px on mobile, and navigation collapses to hamburger menu below 768px.”。生成后，用Chrome DevTools设备模拟器逐屏测试，重点检查：能否单指操作？是否需双指缩放？是否有意外滚动？
2.7 动画全靠transition: all 0.3s ease，无性能优化与意义传达
AI爱用动画，但只会一种：全局transition: all。按钮悬停、卡片翻转、菜单展开，全部套用all 0.3s ease。这带来两大灾难：一是性能雪崩——all触发layout、paint、composite三重渲染，尤其在低端安卓机上掉帧严重；二是意义丧失——所有动画效果雷同，用户无法通过动效差异感知操作类型（如确认操作用淡入，撤销操作用滑出）。AI不懂CSS动画的黄金法则：只对transform和opacity做动画（GPU加速），避免触发布局重排。我们测试发现，AI生成页面平均FPS仅42（60为流畅线），主因就是transition: all滥用。解决方案是“动画契约”：在提示词中明确定义每种交互的动效规范。“Button hover: transform: translateY(-2px) only, duration 0.2s. Modal open: opacity 0 to 1 + transform: scale(0.95) to 1, duration 0.3s. Loading spinner: border-radius 50% + border 2px solid #2563EB + border-top-color transparent + animation: spin 1s linear infinite.”。生成后，用Lighthouse性能审计，重点关注“Avoid non-composited animations”警告。
2.8 错误边界模糊：表单验证错误信息位置随机、无具体字段指向、无恢复指引
用户输错邮箱，页面顶部弹出红色Toast：“格式错误！”，但光标还停在邮箱框，错误信息却飘在页面右上角。这是AI对错误处理（Error Handling）的典型失能。它生成的错误提示有三大硬伤：位置随机（不靠近出错字段）、内容模糊（“格式错误”而非“请输入有效的邮箱地址”）、无操作指引（不告诉用户下一步该做什么）。背后是AI缺乏表单验证的状态映射能力——它不知道<input type="email">的验证失败应触发特定文案，更不懂aria-invalid="true"和aria-describedby的协同机制。我们收集的156个AI生成表单中，100%错误信息未绑定aria-describedby，94%未设置aria-invalid。修复必须结构化：“For each form field, generate specific error message tied to its validation rule. Email field error: 'Please enter a valid email address like name@domain.com'. Password field error: 'Password must be 8+ characters with uppercase, lowercase, and number'. Attach error message to field via aria-describedby and set aria-invalid='true' on input when invalid.”。
2.9 导航结构断裂：面包屑缺失、当前页无视觉标识、跳转无平滑滚动
AI生成的网站，常出现“用户点进‘关于我们’，URL变了，但页面顶部导航栏高亮的还是‘首页’”；或“点击锚点链接，页面瞬间跳到目标位置，无滚动过渡，用户迷失上下文”。这暴露AI对导航状态管理（Navigation State Management）的无知。真实SPA中，路由变化需同步更新：1）导航栏激活态（active class）；2）面包屑（Breadcrumb）路径；3）滚动行为（scroll-behavior: smooth）；4）历史记录（pushState）。AI只生成静态HTML，不理解URL与UI状态的映射关系。我们测试发现，AI生成的多页网站，100%无面包屑，91%导航栏无当前页标识，100%锚点跳转无平滑滚动。解决方案是“导航契约”：在提示词中强制要求“Include breadcrumb trail showing current page path. Highlight current page in main navigation with 'active' class. Add CSS scroll-behavior: smooth to html element. For anchor links, ensure they jump to correct section without page reload.”。生成后，用window.location.hash监听+scrollIntoView({ behavior: 'smooth' })补全。
2.10 可访问性属性（a11y）系统性缺失：无语义HTML、无ARIA角色、无键盘导航支持
这是最隐蔽也最致命的槽点。AI生成的页面，<div>泛滥，<button>被<div onclick>替代，<nav>标签缺失，<main>未定义，ARIA属性（role,aria-label,aria-live）几乎为零。结果是：屏幕阅读器用户听到的是一串无序的div、span、p，无法理解页面结构；键盘用户Tab键在空白处循环，无法抵达关键操作；动态内容更新（如搜索结果）无aria-live告知，用户毫不知情。AI的失败在于：它的训练数据中，语义化HTML占比极低，而<div>+CSS的“万能写法”在网页快照中占比超60%。它学会了最省事的写法，却放弃了最基础的可用性。我们用WAVE工具扫描，AI生成页面平均a11y错误数达27个/页。根治方案是“语义铁律”：在提示词中逐条锁定，“Use semantic HTML5 elements: