AI 生成 UI 的 Review 清单：从“能跑”到“能交付”

先找重复卡片、无意义渐变、过大标题、均匀圆角和所有元素同权重的问题。AI 的默认倾向是把每一个区域都做得像展示区。

给页面一个主任务，然后删掉不服务它的视觉装饰。高级感常来自少做，而不是多加。

检查 Loading、Empty、Error、Disabled、Permission 和 Partial data 是否存在。多数生成结果只画了理想路径，真正上线会在边缘状态失去可用性。

表单、删除、付费、外部跳转等操作要有明确后果与恢复路径。

把两行假文案换成 80 字真实文案，把一个标签换成十个，把桌面窗口缩到小屏。布局是否仍然清楚，才是组件设计是否成立的证据。

最后再检查对比度、键盘焦点、触控目标和动效降级；这些不是上线后的补丁。

AI UI 最危险的问题往往不是不好看，而是把错误操作做得很顺。Review 第一问应是页面服务谁、要完成什么、主路径是否闭环、数据和操作是否符合业务规则。

逐个检查按钮是否真的有结果，状态是否来自真实数据，空态能否开始任务，错误后能否恢复。漂亮的假筛选、无效导出和永远成功的 Toast 都是不可交付的交互债务。

要求生成代码使用真实字段和接近生产的文案。Lorem ipsum、整齐等长的卡片标题和完美数字会掩盖布局、权限和异常处理问题。

截图只能覆盖一个时刻。对 Button、Input、Select、Dialog、Table、Tool Card 等核心组件建立状态矩阵，检查 default、hover、focus、disabled、loading、error、empty 和 overflow。

复杂页面再叠加数据维度：零条、一条、上千条；短文本、长文本、多语言；管理员、普通用户、无权限用户。AI 常能生成主状态，却不会主动补齐这些组合。

矩阵可以变成 Storybook、fixture 或路由参数，让设计、开发和测试围绕同一组状态 Review，而不是每次靠口头提醒。

“看起来很 AI”需要翻译成具体问题：每个区块都是同权卡片、标题全部居中、紫色渐变没有语义、圆角和阴影无层级、图标被放进统一色块、内容没有真实长度差异。

整改顺序先结构后装饰：重新建立信息优先级，减少容器，固定对齐和操作位置，再调整字体、色彩和细节。只换配色与字体无法修复模板化的信息架构。

最后让每个显眼选择回答 why：为什么是三列、为什么这个数据最大、为什么此处需要动画、为什么是 Modal 而不是 inline。无法回答的设计通常只是模型默认值。