ai-design-skills

把设计系统装进 AI 的上下文：ai-design-skills 深度拆解

项目背景与痛点

AI 编程助手已经能在一分钟内吐出一个"看起来能跑"的页面，但绝大多数产出停留在 Bootstrap 时代的审美水位：间距全靠 p-4 硬怼、颜色随手写 #3b82f6、组件没有状态矩阵、暗色模式形同虚设。问题不在模型不够聪明，而在于设计知识从来没有进入模型的上下文。

传统解法是把设计规范写成一份几千字的 DESIGN.md 塞进仓库，靠人肉提醒"请遵循规范"。这条路几乎必然失败：规范文本太长会挤占上下文预算，太短又信息量不足；而且设计规范是分层的——色彩 token、间距刻度、组件 API、交互状态、无障碍约束，不同任务只需要其中一层。

elayadesign/ai-design-skills 切入的正是这个缝隙。从仓库的命名与目录约定看，它采用 Agent Skills 的形态：把一套设计方法论拆成若干可被按需加载的"技能单元"，让 Agent 在处理 UI 任务时动态装载相关知识，而不是一次性背诵全文。它解决的核心问题是设计知识的分发与检索，而不是"再写一份设计规范"。

核心技术揭秘

这套东西的技术含量不在代码量，而在上下文工程的设计。它的骨架通常是这样：每个技能一个目录，根目录放 SKILL.md，头部用 YAML frontmatter 声明 name 与 description，正文写方法论；同级再挂 references/（细分规范、token 表、组件清单）、assets/（模板、示例代码）、scripts/（校验或生成脚本）。

关键在于渐进式披露（progressive disclosure）：Agent 启动时只把每个技能的 name + description 常驻在系统提示里，成本只有几十个 token；只有当用户任务与某条 description 语义匹配时，才把 SKILL.md 正文读进上下文；正文里再用相对路径指向 references/ 下的深水区文件，需要时才二次读取。这是一个三级缓存的思路，只不过缓存的是知识，命中率取决于描述文本写得够不够精准。

数据流大致如下：

真正难的地方有三处。第一是描述的语义边界：description 写得太宽，任何任务都会命中，等于没有分层；写得太窄，Agent 根本不会去读。这本质上是在做提示词级别的召回率与准确率权衡。第二是知识与代码的一致性：规范里写着"间距使用 4/8/12/16 刻度"，但模型生成的代码里是否真的引用了 token 变量，需要 scripts/ 里的静态检查来兜底，否则技能只是"读了但没执行"。第三是多技能冲突：当"品牌视觉"与"无障碍合规"两个技能同时被加载，谁覆盖谁，必须靠优先级约定或合并策略明确下来。

功能亮点与差异

与把整本设计手册喂给模型的粗暴做法相比，它的差异点很实在：

• 可组合而非单体。技能按"色彩体系 / 排版 / 组件模式 / 交互状态 / 无障碍"切分，任务只需要色彩时可以只唤醒一个技能，上下文开销可控。
• 知识随仓库走。规范与代码同仓，设计 token 改了，references/ 跟着改，天然获得版本一致性——这是 Figma 导出文档做不到的。
• 面向 Agent 而非面向人。写作目标是"让模型能执行"，因此每条规范倾向于给出可判定的约束（“圆角只用 4/8”）而非审美描述（“圆角应当优雅”）。
• 自带反馈闭环。带脚本的技能可以把"生成→校验→重生成"变成 Agent 的自主循环，而不是交给人类 code review。

应用场景与落地建议

它最适合已有设计系统、但缺乏强制执行手段的团队：设计 token 已经沉淀在 CSS 变量或 Tailwind 配置里，缺的是让 AI 别乱造轮子。其次是中后台产品线——表单、表格、弹窗这些高频组件的模式高度重复，写成技能后收益立竿见影。

落地时有几点必须注意：

1. 先治理 token，再写技能。没有单一事实来源时，技能只会把混乱固化。
2. description 当成 API 契约来打磨。建议为每个技能准备 5–10 条真实任务的触发语料做回归测试，观察误触发与漏触发。
3. 控制上下文预算。SKILL.md 正文最好压在几百行以内，深水内容一律外置到 references/，否则分层就白做了。
4. 别指望它替代设计评审。技能能把"下限"抬起来——消灭硬编码色值和随意间距；但"上限"，比如信息层级与交互叙事，仍然要人来判断。

综合评价

优点：思路正确得近乎朴素——设计规范的本质是知识分发问题，而不是文档长度问题；结构轻量、没有运行时依赖，接入成本极低；渐进式披露把上下文成本控制在一个可接受的水平，这一点比大多数"提示词工程"方案更工程化。

短板：效果强依赖模型对 description 的语义匹配质量，路由层没有确定性保障；缺少跨技能的优先级与冲突仲裁机制，技能多了之后容易互相打架；配套的校验脚本如果覆盖不全，规范会退化成"模型读过但没听"的软约束。另外，这类项目目前普遍缺乏可量化的评测集——没有"生成 UI 的 token 合规率"这类指标，改进就只能靠感觉。

一句话结论：它不是一个工具，而是一种把设计系统编译进 Agent 上下文的方式。值得抄的不是文件内容，而是分层加载这个结构本身。