AI 写的界面,为什么总有一股「廉价感」?

https://github.com/ibelick/ui-skills

拆解开源项目 ui-skills：把设计工程师的经验，打包成 AI Agent 能读懂、能路由的技能

用 AI 生成一个页面，今天已经不难；难的是，它常常「跑得通，却不好看」。按钮没有点击反馈、动画生硬、间距随意、配色像十年前的模板——这些细节单独看都不致命，叠在一起，就成了扑面而来的「廉价感」。

这不是模型不够聪明，而是它缺少一套「设计工程」的判断路径。前端 UI 的训练数据里，「能跑就行」的示例远多于精心打磨的生产级代码；当生成速度越来越快，界面质量的「平均线」反而被拉低了。

开源项目 ui-skills（GitHub 上已获得 9.5k Star），看看它如何把资深设计工程师的经验，打包成 AI Agent 能读懂、能按需加载的技能。

图 1同一类产品界面：左边是典型的 AI 生成界面，右边是加入约束后的专业界面

廉价感从哪里来：四个高频「翻车点」

把这类界面拆开看，问题往往高度雷同。它们都很琐碎，却正是资深设计工程师每天在把关的地方：

·视觉：渐变、发光、多彩滥用，层级没有主次；

·排版：标题折行难读，数据列里的数字没有对齐；

·交互：反馈时长超过 200 毫秒，动效不断触发重排重绘；

·无障碍：图标按钮没有可访问名称，键盘焦点不可见。

海外社区甚至为这种现象起了个名字：AI slop（AI 糊作）。模型输出的是训练数据里的「统计平均值」——紫色渐变、Inter 字体、三个圆角卡片、一模一样的 Hero 布局。它不是在设计，而是在「自动补全」。

图 2一个典型的「AI 生成界面」：渐变、发光、圆角卡片堆砌，层级混乱

图 3同一页面加入约束后的专业界面：黑白灰为底、单一强调色、层级清晰

从提示工程到技能工程：Skill 是什么

2025 年 10 月，Anthropic 在 Claude 中推出 Agent Skills 功能；同年 12 月 18 日，把它发布为开放标准，供跨平台复用。一个 Skill 的最小形态，就是一个文件夹加一个 SKILL.md：YAML frontmatter 里写 name 和 description，正文写具体指令。它把「如何完成某类任务」的知识，从每次对话里的临时提示词，变成一份持久的、可复用的能力声明。

Skill 与提示词最大的不同，在于渐进式披露：启动时只加载每个技能的 name 和 description（第一级）；Agent 判断任务相关后，才读取 SKILL.md 正文（第二级）；必要时再按需翻阅技能附带的参考文件（第三级）。上下文占用被压缩到最小，技能数量因此可以不受限制地增长。

ui-skills 是什么：不是组件库，是一层规则

在这个背景下，开发者 ibelick（Julien Thibeaut）开源了 ui-skills，采用 MIT 许可，定位是「Skills for Design Engineers」（写给设计工程师的技能包）。

它不是组件库，不提供现成的按钮和卡片；也不是前端框架。它更像一层「规则层」：把界面实现与审查中的经验约束，转化为 AI 编码智能体可以理解和执行的规则。仓库里明确写到，它服务于 Codex、Cursor、Claude Code 等主流 AI 编程工具。截至 2026 年 10 月，仓库已获得 9.5k Star、433 次 Fork，并多次登上 GitHub 趋势榜。

更难得的是，它不是一个孤立的仓库，而是一个不断生长的注册表：目前已收录 343 个技能，来自 93 位出版者——既有 antfu、emilkowalski、mattpocock 这样的知名开发者，也有 Figma、Remotion、Vue 官方团队。

表 1ui-skills 注册表概览（数据来自仓库代码实测，2026 年 10 月 8 日）

代码拆解：三个入口与一个路由层

读完仓库代码，它其实由三样东西组成：一个网站、一个命令行工具、一个 MCP 服务。三者共用同一份技能注册表。

入口一：网站

站点用 Astro 7、React 19 和 Tailwind CSS 4 构建，部署在 Cloudflare 上，用 Shiki 做代码高亮，用 marked 解析 Markdown。

入口二：命令行

CLI 的核心命令只有四条，全部通过 npx 直接运行：

npx ui-skills start

npx ui-skills categories

npx ui-skills list --category motion

npx ui-skills get baseline-ui

图 4一条命令，就把合适的技能上下文交到 Agent 手上

入口三：MCP 服务

它还暴露了一个 MCP 服务（https://www.ui-skills.com/mcp），提供 list_skills 与 get_skill 两个工具。任何支持 MCP 的客户端，都能像调用本地工具一样检索这套技能库。

路由层：ui-skills-root

最关键的是 ui-skills-root 这个技能——它的自我描述是「你是 UI Skills 的路由层」。它定义了七步协议：先判断任务是否与 UI 相关；不是就直接返回「不需要技能」；是则识别类别、用 CLI 查看、选出最小可用的技能集合、只加载选中的技能，再基于这些上下文去实现。

选择规则同样克制：优先用 1 个技能，最多不超过 3 个；按「主题、技术栈、具体度」路由，并且优先选择更具体的技能。

技能体系：路由、基线、审计与设计语言

仓库里直接维护了 7 个技能，构成了整套体系的核心。

表 2仓库内置的 7 个技能

以 baseline-ui 为例，它给出了一串非常「反直觉」的硬约束：

·除非明确要求，否则不加动效；交互反馈不超过 200 毫秒；

·只动 transform 和 opacity，不动 width、height 等布局属性；

·禁止渐变、发光，以及紫色或多色渐变；

·空状态必须给出一个明确的下一步操作；

·强调色每个视图最多只用一个。

improve-ui 更严格：它只读不改，要求每条结论同时满足「契约、运行时、修正」三重证据，否则宁可报告「没有发现」。这种「证据门」思维，正是设计工程与「随手改改」的分水岭。

演示案例：三步把技能装进你的 Agent

如果你在用 Claude Code、Cursor、Codex 这类工具，接入成本几乎为零：

·在项目里运行 npx ui-skills start，拿到路由技能；

·用 npx ui-skills categories 或 npx ui-skills list --category motion 查看可用技能；

·用 npx ui-skills get baseline-ui 拉取完整技能文档。

以图 5 为例：左半边是典型的「无障碍欠债」界面——占位符当标签、错误只靠红色传达、按钮没有焦点环；右半边按照 fixing-accessibility 的规则修正后，每个字段都有可见标签，错误信息用「文字加图标」双重传达，按钮有清晰的焦点环。这些改动都很小，却决定了界面能不能被键盘用户、读屏用户正常使用。

图 5一个真实的修复演示：左为无标签、无关联错误提示的表单，右为加上可见标签、错误文案与焦点环后的版本

它给自己定的设计语言

有意思的是，项目自己也有一份 DESIGN.md。它的自我要求是：安静、编辑感、代码优先——「应该像一件精确的开发者工具，而不是一个营销网站」。

·界面字体用 Inter Variable，代码用 JetBrains Mono；

·颜色以黑白灰为主，只保留一个强调色 #1F78FF；

·并明确禁止发光、渐变，以及为装饰而使用的颜色。

这种自洽本身就是最好的示范：它要求 AI 遵守的规则，自己先遵守了一遍。

图 6技能目录界面示意：话题分类加技能卡片，黑白灰与单一蓝色强调

冷静看待：价值与两个权衡

需要说清楚：ui-skills 解决的是「判断路径」问题，而不是「替你写界面」。它把专家经验变成可复用、可路由的上下文，但最终产出仍然取决于模型能力和你项目自身的约束。

·指令冲突：项目约定、框架规则与技能建议可能互相矛盾，最好先定好优先级；

·上下文开销：不要把所有技能一次性塞进去，把它当作按需加载的模块。

社区里也有类似的反馈：先把自己的设计系统锁定，Agent 才更可能给出真正可交付的代码，而不是需要重写一半样式的半成品。

结语：AI 写界面的上限，取决于你给的约束

AI 写界面的上限，往往取决于你给它多少「约束的质量」。ui-skills 的价值不只是多了一个工具，而在于它示范了一种思路：把设计工程师脑子里的经验，变成一份可以被 Agent 读取、复用和路由的工程资产。

下次再抱怨「AI 写的界面很丑」之前，不妨先问一句：你给它的约束，够不够专业。