前端页面怎么不像 AI 生成？这份 4.68 万安装的验收单能直接用

前端页面要改到第几版，才不会一眼看上去像 AI 拼出来的？

很多人的办法是继续加形容词。克制一点，高级一点，别那么像模板。然后 Agent 很听话地把紫色渐变收一点、卡片圆角换小一点，再端上一盘新的卡片。

页面还是那张页面，只是换了一层滤镜。

这两天看到 Addy Osmani 的 frontend-ui-engineering，我觉得它值得记下来，不是因为它又发明了一套审美，而是因为它把 UI 的完成定义得很工程。skills.sh 当前显示它有 4.68 万次安装，所属仓库在 GitHub 有 9.97 万 Star。安装入口和原始规则都在 skills.sh 与 GitHub。

它要解决的不是「做一张好看的图」，而是让一个用户界面在真实使用时别露怯。

图为抓取的官方仓库页面。本文不声称在真实业务项目中跑过完整对照，后面的 Before／After 只用来说明公开规则在看什么。

先别问配色，先问这个组件到底负责什么

AI 最容易把一个页面写成一坨看似能跑的 JSX。数据请求、筛选逻辑、空态、删除动作、展示样式全塞进一个 300 行组件。初看没毛病，改第二次就开始拔插头。

这份 Skill 给出的第一道线很朴素，组件要单一职责，优先用组合，不要靠越来越长的 props 把一切塞进一个万能卡片。数据请求交给容器，列表和单项只负责展示。好家伙，这个判断不花哨，却是很多 AI 页面后来越改越疼的起点。

它还提醒了一件容易被忽略的事，状态不是越集中越专业。只在一个控件里用的状态留在本地，两个兄弟组件共享再往上提，需要分享和回退的筛选条件放进 URL，远端数据交给缓存层。能少搬一次状态，就少给未来留一个问号。

你可以把这理解成 UI 的拆分账。不是代码拆得越细越好，而是每个边界都能说出它为什么存在。说真的，Agent 很会补代码，它不擅长替你发明清晰的责任边界。

静态图过了，用户还没进场

一张有标题、有卡片、有按钮的截图，往往最会骗人。

真实页面刚打开时在加载，查不到数据时是空态，请求坏掉时要给恢复路径，保存成功时需要反馈，权限不够时不能只留一块空白。官方的完成清单把这些状态和键盘访问、屏幕阅读器、控制台告警放在同一层级，意思很明确，少任何一项都不算交付。

这也是它比「给我做个 SaaS 仪表盘」这类提示词更有用的地方。后者只描述最终画面，前者描述用户会怎样走进、撞上、离开一个页面。

另一个很实用的细节是断点。它要求至少在 320、768、1024、1440 像素看一遍。别小看 320，这个宽度能把许多看似精致的双栏布局直接打回原形。图没问题，按钮没问题，只有文字被挤成三行，主操作漂到屏幕外面。嗯，页面终于开始像真的有人会用它了。

它反对的不是紫色，是默认答案

官方列了一串很眼熟的红旗，满屏紫色或靛蓝，渐变太多，每个东西都 rounded-2xl，大 Hero，均匀卡片阵列，留白大得像刚租了新办公室，阴影重得像悬浮在空气里。

这些手法单独拿出来都没罪。问题在于，它们经常是模型没拿到产品信息时的默认答案。产品是什么、用户来做什么、什么信息应该先看、什么状态最危险，全被一套讨喜的视觉包装盖住了。

真正该让 Agent 遵守的是项目已有的颜色语义、间距刻度、字体层级和圆角规则。一个列表密度高的内部工具，未必需要营销落地页的呼吸感。一个高风险删除动作，不能只靠红色提醒。一个无文字的叉号，也不是天然就能被辅助技术理解。

厉害了，到了这一步，UI 才不只是漂亮，而是有判断。

把它装上，再把审美翻译成验收

安装命令很短。

npx skills add https://github.com/addyosmani/agent-skills --skill frontend-ui-engineering

别把它当成自动生成高级页面的按钮。更像一位在你身后不停问「这个空态去哪了」「Tab 能不能走到这里」「窄屏怎么收」的前端同事。

我把原始规则收成了一段可以直接塞进编码 Agent 的验收 brief。它不是官方模板，只是按公开规则做的中文压缩版。

为「页面名称」实现可上线的用户界面

先写清页面唯一的主要任务和主要操作
沿用现有设计 token，不新造颜色、间距和圆角
组件各自只负责一件事，数据请求和展示分开
给加载、空、报错、成功和权限不足设计下一步
原生按钮和标签优先，键盘可完整操作
不要只用颜色表达状态，无文字图标要有名称
按 320、768、1024、1440 像素检查布局
交付前检查控制台、无障碍告警和视觉完成度

这里最关键的一句其实是「页面唯一的主要任务和主要操作」。如果这句话说不清，后面再怎么挑配色也只是装饰。很多 Agent 生成的 UI 显得用力过猛，不是 CSS 写差了，是它根本没收到页面为什么存在。

哪些时候先别急着搬它

如果团队已经有一套成熟设计系统，这份 Skill 不该变成另一个强势规范。它更适合做 finish gate，拿来找缺失状态、响应式漏洞和可访问性漏网之鱼。现有 token、组件库和产品约束还是优先级更高的事实。

它也不会替代真实的设计研究。用户到底看得懂什么，表单字段该不该存在，权限说明放哪里，这些答案不在 9.97 万 Star 里。Star 只能证明很多人关注，不能替你做产品判断。

不过，当你下一次想对编码 Agent 说「页面高级一点」时，不妨换成那 8 条验收线。少一点玄学形容词，多一点可验证的边界，生成出来的东西会稳得多。

你最近最受不了 AI 生成页面的哪种默认套路，紫色渐变、夸张圆角，还是缺空态？