ui-skills

把设计判断力编码进 AI：ibelick/ui-skills 深度解析

项目背景与痛点

设计工程师（Design Engineer）处在设计与前端工程之间：既要对间距、节奏、留白有判断，也要把这套判断落进代码。日常最消耗心智的不是“不会写 React”，而是重复搭建相同的脚手架，以及在不同功能里审美标准发生漂移。

AI 编码助手本应缓解这件事，但默认表现经常令人失望：生成的是“平均水平的 UI”——间距靠猜，动效用一个 ease 走天下，配色不是灰扑扑就是饱和度爆表，可访问性基本靠运气。问题的根源不在模型不会写 CSS，而在于它没有被显式告知设计约束：没有设计系统上下文，没有品牌基调，也没有“什么算好”的判定标准。

ibelick/ui-skills 的定位就在这个缝隙里：把资深设计工程师的隐性判断，沉淀成 AI 助手可以按需加载的“技能”资产。它交付的不是组件，而是决策依据。

核心技术揭秘

从仓库形态与命名看，它采用的是 Agent Skills 的组织范式：以目录承载技能单元，每个技能以 SKILL.md 为主文件，头部通过 frontmatter 声明 name 与 description，正文承载规则、范式与反例。这套结构有三个值得拆解的设计。

元数据驱动的渐进加载。 关键点是“不一次性注入”。助手先只扫描技能目录的描述字段，语义命中后才把正文读进上下文。这是个很务实的工程取舍：直接把所有设计规范塞进 prompt，既昂贵又会稀释模型注意力；用 description 做路由，等于给知识加了一层索引。

知识的三层结构：原则—范式—反例。 有效的技能文件不会写“你应该做得好看”，而是写“间距取 4 的倍数、动效时长落在 150–250ms、正文不用纯黑”。可判定的规则远比形容词有用。反例段尤其重要，它约束的正是模型最容易出错的方向（比如滥用渐变、堆叠阴影、过度圆角）。

技能的模块化与版本化。 纯 Markdown 意味着它可以被 fork、被 diff、被 Code Review，这一点比封装成框架插件更有长期价值——设计规范本身是会演进的，可审计才能可维护。

真正的技术难点不在写法，而在三处：一是指令必须与具体模型解耦，写成厂商无关的自然语言约束，才能在 Claude Code、Cursor、Codex 之间迁移；二是把“高级感”这种主观判断拆解成可校验的量化维度（间距比例、层级数、阴影强度），这是整个项目最难的部分；三是闭环——只生成不够，还得有一份 checklist 让模型在交付前自检。

功能亮点与差异

和三类常见产物对比，它的边界更清晰。

对比散装 Prompt 库：prompt 是一段游离文本，用完即弃；skills 有路由、有作用域、有版本，是可以被工程化管理的模块。

对比组件库（如 shadcn/ui）：组件库给你的是成品代码，你改的是结果；ui-skills 给的是生成过程，它影响的是模型在写代码之前的每一个选择。

对比设计 Token：token 管“数值是多少”，skill 管“什么时候该用哪套数值”。前者是数据，后者是策略。

它的杀手锏其实是可组合性——多个技能叠加，能拼出一套接近团队真实审美的生成上下文；而且因为纯文本，任何设计工程师都能读懂并修改，不需要额外的工具链。

应用场景与落地建议

适配场景：快速原型与验证、内部工具与后台系统、设计驱动型产品的前期探索、以及给团队建立统一的生成基线。不太适合直接用于品牌约束极严的大型 to C 产品——那类项目需要把这些技能二次封装成团队私有版本。

落地时有几个坑值得提前避开：

1. 别指望开箱即用。 把它当起点而非答案，第一件事是按你的设计系统重写规则段。
2. 与设计 Token 绑定。 技能里的数值要映射到你的 CSS 变量，否则生成代码和现有系统会脱节。
3. 建立回归比对。 固定一组提示词定期跑，人工比对视觉产物，否则模型升级会悄悄改变输出风格。
4. 控制技能数量。 目录越大，路由噪声越高，宁可少而精。
5. 把事故写进反例。 团队踩过的视觉问题，是最高质量的反例素材。

综合评价

优点：方向判断准确——AI 生成 UI 的瓶颈是审美约束而非语法能力；体积轻、零依赖、与模型无关；纯 Markdown 带来可审计、可协作、可演进的长期价值。

缺点：审美规则天然模糊，效果高度依赖底层模型自身的设计素养，同一份技能在不同模型上表现差异明显；缺少自动化视觉校验，仍然是“人在环”的流程；社区处于早期，技能质量参差不齐，还没有形成事实标准。

一句话总结：它试图把设计判断力从人脑导出为可复用资产，路子是对的；但它真正的价值不取决于仓库本身，而取决于你的团队是否愿意把自己的审美认真沉淀下来。