一个能将顶级设计经验转化为Agent可执行规则的“设计外挂”，让你的界面从平庸变得惊艳。

项目概述：它是什么？

emilkowalski/skills是一个专为“设计工程师”打造的AI辅助知识与工具集，由曾在Vercel和Linear工作的 Emil Kowalski 开发。一些巨头，比如 SpaceX 的软件设计也是参考 Apple 的风格，这个库的核心理念很简单：把顶尖设计工程师的隐性知识，转化为AI可以理解和执行的显性规则。

该项目在GitHub上已获得14.4k Star，并持续活跃维护中。

解决的核心痛点

这个工具包精准击中了当前AI辅助UI开发中的三大核心痛点：

痛点一：AI“有脑子，没审美”

问题表现：AI能写代码，但无法区分设计上的“好”与“差”。例如，为入场动画错误地使用ease-in而非ease-out，或用生硬的实线边框代替精致的半透明阴影。这些细微差别累积起来，让界面从“惊艳”滑向“平庸”。

解决方案：将专家的审美知识转化为可执行的规则集。AI调用这些技能，相当于内置了一位设计顾问。

痛点二：改进建议“泛泛而谈，难以落地”

问题表现：AI常给出“让动画更流畅”这类模糊指令，缺乏系统性审计和可执行方案。

解决方案：通过improve-animations提供系统化工作流：

  • 扫描整个代码库，从8个专业维度诊断所有动画
  • 生成存放在 plans/目录下的详细计划文件，明确指定改哪个文件、哪一行、换成什么值
  • 分离“决策”与“执行”，允许用强大模型做审计，经济模型做修改

痛点三：设计与开发“语言不通，决策无据”

问题表现：只能用“柔和一点”、“丝滑一些”等模糊词汇描述效果，AI难以精准理解。

解决方案：

  • animation-vocabulary：提供精确的动画术语表
  • apple-design：将苹果WWDC的权威设计原则提炼为Web可用标准

技能包详解

项目包含以下核心技能：

技能名称 功能描述
emil-design-eng 主技能包，包含动画及设计建议
review-animations 基于作者规则严格审查动画
improve-animations 审计代码库所有动画，生成优先级排序的执行计划
find-animation-opportunities 搜索适合添加动效的地方，并指出不应添加的区域
animation-vocabulary 提供精确动画术语，方便与AI沟通
apple-design 提炼苹果WWDC设计原则，适配Web

其中improve-animations的工作流程最为完整：

  • 全面审计：扫描整个代码库，从目的、缓动、时长、物理性、可中断性、性能、可访问性、连贯性八个维度诊断
  • 生成报告：输出带优先级的发现表格
  • 制定计划：在 plans/目录生成自包含的详细计划文件
  • 执行计划：由其他AI智能体直接执行，无需额外上下文

安装与使用方法

安装

在你的项目终端中运行：

npx skills@latest add emilkowalski/skills

各AI工具安装差异

工具 安装方式 技能存放路径
Claude Code /plugin 命令或手动克隆 .claude/skills/
OpenCode 插件工具如 opencode-skills .opencode/skill/
Codex 对话引导AI安装 遵循通用规则

调用方式

安装完成后，在对话中直接调用即可：

  • 显式调用（推荐）：“使用 apple-design 构建一个iOS风格的底部弹窗。”
  • 隐式触发：AI根据任务描述自动判断调用。

实际使用效果

效果一：生成有“高级感”的界面

通过emil-design-eng或apple-design技能，AI生成的UI在细节上更精致。例如生成弹窗时，会自动应用ease-out缓动、控制在300ms以内的时长、从scale(0.96)开始展开，避免动画生硬。

效果二：系统化“体检”和修复动画

当你审查一个弹窗动画时，AI会输出清晰的Before / After / Why表格。例如：

/* Before */
transition: all 300ms ease-in;

/* After */
transition: transform 180ms ease-out, opacity 180ms ease-out;

Why：all会误伤属性，ease-in让进入动画开头变慢。

效果三：统一团队与AI的设计语言

animation-vocabulary解决了“知道效果但说不出来”的问题。例如，你可以问“iOS那种拖到边界有阻力再弹回的效果叫什么？”，它会告诉你术语是rubber-banding。

背后的方法论

这个项目把大师的经验转化成一套可判断的规则，核心逻辑是：

  • 动画有没有必要？看使用频率：高频操作（如命令面板）建议删除动画，低频操作（如引导页）可使用丰富表现力
  • 动效对不对？看物理感受：审查是否使用 transform和 opacity保证性能、是否考虑 prefers-reduced-motion设置等

使用建议与限制

推荐工作流

分阶段使用效果更佳：

  • 先用 animation-vocabulary找到准确术语
  • 再用 emil-design-eng生成或优化组件
  • 最后用 review-animations审查质量

注意事项

  • 建议显式调用技能名称，保证审计的严格性
  • 分阶段使用比一次塞入所有技能的效果更稳定