你用 Cursor 或 Claude Code 让 AI 写了个登录页。功能全对，表单能提交，按钮能点。但你盯着屏幕看了五秒，总觉得哪里不对。字距飘忽，按钮大小不统一，灰色有七八种，弹窗的 z-index 飙到了 9999。能跑，但看起来像个刚学会拼积木的人把所有零件随意堆在一起。
这不是你的 Prompt 写得不好。是 AI 编码 Agent 缺了一套设计约束。它见过几百万个网页，知道卡片要有圆角，导航要在顶部，但它完全不懂那些藏在表面底下的设计经验。为什么标题和正文之间必须空 24 像素，为什么动画超过 200 毫秒就会让用户觉得卡顿，为什么 z-index 需要一套固定尺度而不是每次加大数字。这些经验从来没有被写进代码语法里。
ibelick/ui-skills 做的事很直接：把设计师脑子里的隐性经验，一条一条翻译成 AI 能读懂的硬性规则。它不是组件库，不是 UI 框架，是一套给 AI Agent 加载的标准化技能规则层。截至 2026 年 8 月，项目在 GitHub 上积累了约 6800 个 Star，298 个 Fork，185 次提交，MIT 协议开源，维护者 ibelick（Julien Thibeaut）几乎每周都有新提交。
说白了这篇文章就想讲明白一件事：在 AI 写前端越来越快的今天，ui-skills 这套规则层能不能真的让 AI 产出的界面从不忍直视变成可以交付，还是它只是把问题从”AI 写不好 UI”换成了”Prompt 调不好 UI”。
为什么值得关注
ui-skills 的核心设计思路就四个字：任务路由。它不是让你一次性把所有规则加载给 Agent（那样上下文早炸了），而是通过 npx ui-skills start 命令，让 Agent 根据当前任务自动选择最合适的技能集。比如你在做一个带复杂动画的仪表盘，系统自动加载 fixing-motion-performance；你在重构表单组件，自动加载 fixing-accessibility。按需加载，不冗余。
这个路由系统的底层是一个技能注册表，包含 7 个本地技能和多个社区贡献技能。本地技能由 ibelick 亲自维护，覆盖了从基础 UI 基线到无障碍、动效性能、SEO 元数据的全链路。社区技能来自 Anthropic、shadcn、emilkowalski 等知名开发者和组织，质量经过了筛选。
真正让我觉得这项目有区分度的是 baseline-ui 这个技能的设计深度。它不是那种”颜色要协调”“布局要合理”的泛泛建议，而是精确到具体 CSS 属性和 React 组件选择的硬性约束。比如强制用 h-dvh 替代 h-screen（避免移动端视口溢出），强制用 text-balance 处理标题换行、text-pretty 处理正文，禁止动画 layout 属性只能用 transform 和 opacity，交互反馈动画绝对不超过 200ms。每一条规则都有明确的”为什么”——不是为了好看，是为了避免 AI 最容易犯的低级错误。
improve-ui 是另一个值得单独拎出来的技能。它不做代码修改，只做审计和出方案。流程很严谨：选定一个产品界面 → 追溯它的设计系统（DESIGN.md + 实际渲染路径中的 tokens/variables/components）→ 找出违反系统规则的实现 → 按证据强度排序报告，最多输出三个发现。这种”读而不写”的边界设计很聪明，避免了一个常见问题：AI Agent 自以为在优化 UI，实际上把设计系统的一致性毁掉了。
社区注册表也是这项目的一个隐藏优势。目前收录了 Anthropic 官方的 frontend-design 技能、emilkowalski 的 improve-animations、millionco 的 improve-react、shadcn 的 shadcn/ui 工作流技能等。这些都是各自领域的专家贡献的，质量不输本地技能。这种”核心维护者自研 + 社区大牛贡献”的双轨模式，让 ui-skills 的覆盖面比单个开发者能维护的宽得多。
亮点说完了，但规则写得再好，Agent 能不能用起来是另一回事。
上手什么感觉
ui-skills 的安装门槛低到几乎没有。不需要 clone 仓库，不需要配环境变量，一行命令搞定：
npx ui-skills start
这个命令会启动交互式路由，Agent 根据你的任务描述自动匹配技能。如果你想先看看有哪些技能可用：
npx ui-skills categories
npx ui-skills list --category motion
npx ui-skills get baseline-ui
实际用起来的体验取决于你用的编码 Agent 本身。在 Claude Code 里，技能文件作为上下文加载后，Agent 会严格按规则审查代码。比如你让它根据 baseline-ui 检查一个新建的登录组件，它会逐条对照：h-screen 改 h-dvh，z-index 有无超出固定尺度，动画是否只用了 compositor 属性。输出格式是”违规代码行 + 为什么重要 + 修复建议”三段式，不废话。
但有个实际卡点得说清楚。这些技能本质上是一堆 markdown 文件，Agent 能不能严格执行完全取决于它本身的理解能力和上下文窗口大小。如果你的 Agent 本身对 Tailwind 的类名不太熟，baseline-ui 里那些”必须用 cn 工具管理类名合并””必须用 tabular-nums 处理数据”之类的规则，它可能理解得打折扣。这不是 ui-skills 的问题，是整个”Prompt 即规则”范式的天然局限。
另一个值得注意的点是，improve-ui 生成的修复方案是给另一个 Agent 执行的，不是给你直接看的。这意味着你需要一个”两人工作流”：一个 Agent 跑审计，另一个 Agent 读方案做修改。对个人开发者来说有点重，但对团队来说这个隔离反而有价值，审计和修改分开降低了越改越乱的风险。
从实际效果看，baseline-ui 最显著的作用是减少了四类高频 UI 低级错误。z-index 滥用几乎归零，h-screen 导致的移动端溢出问题大幅下降，动画因 layout 属性触发的 jank 也有明显改善。
这个数据是从社区反馈和实际使用案例中汇总的估算。准确数字因人而异，取决于你原本的代码质量和 Agent 本身的能力，但趋势是一致的：规则层确实能把翻车率压下来，只是压不到零。剩下的问题通常不是规则能解决的，属于设计品味和交互逻辑的范畴。
体验能说明它怎么用，但更关键的问题还没回答：什么人该用，什么人用了也是白用。
适合谁，不适合谁
| 场景 | 典型用户 | 优势 | 局限 |
|---|---|---|---|
| AI 前端开发质量管控 | 用 Cursor/Claude Code 写前端的开发者 | 一行命令加载，自动路由匹配 | 依赖 Agent 本身能力，弱 Agent 效果打折 |
| 设计系统一致性审计 | 有 DESIGN.md 或设计 tokens 的团队 | improve-ui 严格证据驱动，不乱改代码 | 需要已有设计文档，从零搭建成本高 |
| 无障碍合规检查 | 需要 WCAG 合规的产品团队 | fixing-accessibility 覆盖表单/弹窗/键盘导航 | 不替代专业无障碍测试工具，是辅助层 |
| 动画性能优化 | 前端动效重度项目 | 迪士尼 12 原则 + compositor-only 硬约束 | 只覆盖 web 动画，不涉及 Native/Flutter |
不适合的情况也很明确。如果你只是偶尔用 AI 写个小页面，手动改改就完事了，加载一套规则层的开销不划算。如果你的项目已经有一套成熟的 lint 规则和设计系统文档，ui-skills 的价值更多体现在无障碍和动效审计上，基线规则部分会和现有工具重叠。
ui-skills 最佳的使用姿势是把它的核心规则融入你的 CI 流程：Agent 生成代码 → baseline-ui 规则自动审查 → 不符合的直接打回。但目前它还没有提供 API 或 CI 集成，全靠 Agent 手动加载。这是当前版本最大的工程化缺口。
场景分析能告诉你适不适合用，但项目能不能活得久，还得看维护侧的真相。
社区怎么样了
| 指标 | 数据 | 说明 |
|---|---|---|
| Stars | ~6,800（截至 2026 年 8 月） | 1 月创建，6 个月冲到近 7k，增速在技能类项目中属于第一梯队 |
| 核心维护者 | 1 人（ibelick） | Bus Factor 高风险，项目对单一维护者的依赖极重 |
| 提交频率 | 185 次提交，最新 7 月 31 日 | 维护节奏扎实，几乎每周有更新 |
| 协议 | MIT | 商业友好，可自由使用修改分发 |
社区贡献方面，注册表里的社区技能贡献者名单是个亮点。Anthropic 官方的前端设计技能、shadcn 的组件工作流、emilkowalski（Sonner 作者）的动画改进入口都在里面。这些人在 UI 工程领域的声望本身就是一种质量背书。
HackerNews 上有人评价：“ui-skills is the first project that actually made me trust my agent’s UI output. Not perfect, but the z-index rules alone saved me hours of cleanup.” 这个评价抓住了核心价值：不是让 AI 写出完美的 UI，而是让清理成本从”重写”降低到”微调”。
不过 Bus Factor 是个真问题。185 次提交全是 ibelick 一个人的，没有其他活跃贡献者。如果这个项目对你团队的日常流程变得关键，你最好对它有合理的 fork 和自维护预期，而不是指望它能像 React 一样有大团队持续迭代。
我的真实看法
我对 ui-skills 的判断不是”好”或”不好”，而是”它把对的事做了，把难的事留给了你”。
对的事在哪里？它在 AI 前端开发这个链条上找到了真正缺的一环。过去两年，AI 生成代码的能力提升了几个数量级，但 AI 生成”好看且规范”的 UI 的能力几乎没有本质进步。ui-skills 抓的就是这个 gap。它的 baseline-ui 规则不是拍脑袋写的，每一条都能对应到 AI 最常犯的具体错误：z-index 暴走、h-screen 在移动端溢出、动画布局属性导致的 jank。这些规则的设计者显然真的在日常用 AI 写前端。
但”难的事”也很清楚。整个项目的价值锚定在”技能文件被正确加载和执行”这个前提上。Agent 能不能理解规则、能不能准确应用、遇到规则冲突时怎么决策，这些全在 ui-skills 的控制范围之外。本质上，ui-skills 是一套很好的说明书，但执行这本说明书的工人（Agent）水平参差不齐。
和同类项目比，UI UX Pro Max（92k Stars）走的是”给 AI 装上一整套设计系统生成器”的路子，更重更全但也更重上下文。Taste Skill（13.7k Stars）的独特卖点是可调旋钮式的设计强度控制。ui-skills 的差异化在于”后置打磨”这个定位，不试图教 AI 怎么做设计决策，只教它怎么不犯低级错误。这个定位更务实，也更难被替代。
趋势判断：项目在上升期。6 个月从零到近 7k Star，社区技能注册表在持续扩充，维护节奏稳定。但它的天花板取决于两件事：一是编码 Agent 本身的能力进化能不能让规则执行更可靠，二是 ibelick 能不能把 CI 集成和自动化工作流做出来。如果这两步走通，ui-skills 有可能从”个人开发者的辅助工具”变成”团队前端质量管控的基础设施”。如果走不通，它会停留在”用 AI 写前端的开发者都会收藏但只有少数人认真用的仓库”这个层级。
资源地址
| 资源 | 地址 |
|---|---|
| GitHub | https://github.com/ibelick/ui-skills |
| 官网 | https://ui-skills.com |
聊完了判断，最后说说实际该怎么上手。
先用 npx ui-skills start 试试
如果你几乎每天用 AI 写前端，并且对 AI 生成界面的”廉价感”已经忍了很久，给你的 Agent 装一个 baseline-ui 是最低成本的改进方案。只加载这一个技能的收益就足够明显，z-index 规则和动画约束两条几乎能覆盖 80% 的常见 UI 翻车场景。
如果你在带一个用 AI 辅助前端开发的团队，当前版本更适合作为个人工具的试点，不建议直接写进团队 CI 流程。等 CLI 有了自动化调用接口或者在 GitHub Actions 里能直接跑规则审查的时候，再考虑团队级集成。
盯住两个信号：一是社区贡献者的数量有没有突破 1，二是 CHANGELOG 里有没有出现 “CI integration” 或 “API mode”。这两点决定这个项目能不能从好用的个人工具变成靠谱的团队依赖。