开源动效品味skills：AI生成界面终于不用改了

Emil Kowalski 是知名前端开发者，曾任职于 Vercel 和 Linear，也是广受欢迎的 Toast 组件库 Sonner 的作者。该项目基于他多年的实践经验，将领域专长编码为可供 AI 调用的技能文档。

核心理念：AI 不会取代领域专长，而是放大你从中获得的成果。

设计哲学

项目的底层哲学贯穿于所有技能文档中：

• 品味是训练出来的，而非天生的——通过大量接触优秀作品、深入思考"为什么感觉好"来培养。
• 看不见的细节叠加成卓越——用户不会刻意注意的细节，恰恰是让产品"感觉对了"的关键。
• 美是一种杠杆——优秀的外观和动效是真正的差异化因素。

为什么需要这些技能？

Emil 指出，AI 代理（Agent）往往缺乏"品味"：

• 入场动画用了 ease-in 而不是 ease-out
• 用实线边框而不是半透明阴影
• 所有这些小细节累积起来，决定了界面是"出色"还是"还行"

GitHub这个skills的仓库，仅凭一堆Markdown文本文件，不到半年斩获超过18万颗星标。仓库作者是曾任职Vercel和Linear的设计工程师Emil Kowalski。这个仓库不做任何代码编译，不输出任何可执行文件，只是用文字告诉AI编程助手：动效应该怎么做、按钮反馈应该多快、弹窗应该从哪里冒出来。

AI写代码的能力突飞猛进，唯独在界面动效这件事上，像个审美缺失的实习生——选错缓动曲线、用错边框样式、把弹入动画做成弹出动画。这堆Markdown文件，正在试图解决一个连顶尖AI公司都没搞定的问题：机器能不能学会“让界面感觉对”？

一个设计工程师，凭什么教AI做动效？

Emil Kowalski不是随便写写博客的设计师。他先后在Vercel和Linear担任设计工程师，这两家公司以极致的UI打磨闻名行业。他本人还创建了两个开源库：Vaul和Sonner。Sonner是一个toast通知组件库，在GitHub上被大量前端项目使用。

这个skills仓库的核心文件叫emil-design-eng，是一个26.6KB的Markdown文档。文档开篇只有一句话：“我准备好了帮你构建感觉对的界面，我的知识来自Emil Kowalski的设计工程哲学。”

这句话的潜台词值得玩味。一个Markdown文件说自己“有知识”，而且这个“知识”来自一个真实的人类设计师。把一个人的设计决策方式编码成文本，然后塞给AI当操作手册——这件事本身就在挑战一个根本问题：设计决策能不能被形式化？

文档正文分成三个支柱：品味可以训练、看不见的细节会叠加、美感是杠杆。这三个支柱不是鸡汤，而是可操作的规则框架。品味被定义为“训练出来的直觉，是看清显而易见之外东西的能力”。这个定义把品味从玄学拉回到工程领域——就像肌肉可以通过训练增长，审美判断力也可以通过刻意练习获得。

当一个动效被写成代码规范

emil-design-eng最狠的部分不是哲学宣言，而是强制性的审查格式。文档规定：审查UI代码时，必须使用Markdown表格，分三列——修改前、修改后、为什么。

举个例子。一个弹窗的动画，修改前是transition: all 300ms，修改后是transition: transform 200ms ease-out。为什么？因为all会让浏览器动画所有属性，包括那些不该动的属性，浪费性能且可能产生视觉抖动。指定具体属性，只让transform动，200毫秒配合ease-out缓出曲线，弹窗出现时干脆利落。

再比如按钮的按下反馈。修改前没有:active状态，修改后加上transform: scale(0.97)。为什么？因为物理世界里的按钮被按下时会有一点点下沉。没有这个微缩效果的按钮，摸上去“没有灵魂”。

还有弹窗的缩放原点。修改前是transform-origin: center，修改后变成transform-origin: var(--transform-origin)。为什么？因为弹窗应该从触发它的那个按钮位置“长出来”，而不是从屏幕正中央凭空冒出来。

这些细节单独拎出来，每一个都小到用户不会主动注意到。但文档引用Paul Graham的一句话：“所有那些看不见的细节叠加在一起，产生了令人惊叹的效果，就像一千个几乎听不见的声音在齐声歌唱。”

问题来了。如果用户注意不到，这些细节还重要吗？文档的回答是：正是因为你注意不到，它们才重要。一个界面感觉“顺滑”或“高级”，用户说不出为什么，但那种感觉来自几十个这样的小决策的叠加。

动效决策的四步框架：为什么AI每次都选错？

emil-design-eng文档里藏着一个动效决策的四步框架。AI在写任何动画代码之前，必须先回答四个问题。这个框架本身就是一个认知工具，把模糊的“感觉”拆解成可验证的选择。

第一步：这个元素应不应该动？文档里专门有一个find-animation-opportunities技能，它的任务是搜索UI中“真正能从动效中受益的地方”，同时明确告诉你“什么地方不该动”。不该动的包括加载状态、页面切换等需要即时反馈的场景——动效会拖慢感知速度。

第二步：动的时机是什么？进入动画用ease-out，退出动画用ease-in，持续动画用linear。AI经常搞反——进入动画用了ease-in，结果元素像被什么东西拖住了一样慢慢出现，而不是干脆利落地滑入。

第三步：动多久？持续时间不是随便填的数字。按钮微交互100-200毫秒，弹窗入场200-300毫秒，页面转场300-500毫秒。超出这个范围，用户会感觉界面“迟钝”或“飘”。

第四步：用什么物理模型？弹簧动画（spring）和缓动曲线（easing）的选择决定了动效的“质感”。弹簧动画有弹性和阻尼，适合卡片、面板这类有物理感的元素；缓动曲线适合透明度、颜色这类不需要物理模拟的属性。

这个框架的价值不在于它有多深奥，而在于它把动效决策从“凭感觉”变成了“选参数”。AI擅长在参数空间里搜索最优解，前提是参数空间被明确定义。这堆Markdown文件做的正是这件事——把设计决策重新表述为AI能理解的约束系统。

苹果设计语言的蒸馏：从WWDC到一行配置

skills仓库里还有一个叫apple-design的技能。它的来源是苹果WWDC的演讲——《Designing Fluid Interfaces》（2018）和《The Details of UI Typography》（2020）。Emil Kowalski把这些演讲里的设计原则“蒸馏”出来，翻译成适用于Web的规则。

这个蒸馏过程本身就是一次语言哲学操作。苹果的设计语言是高度语境化的——它在iOS的触屏交互场景里成立，在macOS的鼠标键盘场景里又有所不同。把“半透明Header”“列表reveal”“按钮微交互”这些概念从原生平台剥离出来，再翻译成React和CSS能实现的代码规范。

蒸馏的结果是什么？一个AI编程助手拿到这个技能后，生成深色Apple风格界面时，会自动添加半透明毛玻璃效果、正确的圆角半径、以及带有velocity handoff和interruptible spring的拖拽交互。

这是一个知识压缩的典型案例。一个人花几年时间积累的设计判断力，被压缩成几千行Markdown文本。然后AI解压这些文本，在代码生成时自动应用这些判断。压缩过程中丢失了什么？语境、直觉、对“不对”的敏感度。但保留了什么？可复现的、可验证的决策规则。

品味的悖论：越是想教，越是教不会？

skills仓库提出的核心主张是：品味可以被编码、被传授、被自动化。这个主张站在了一个危险的斜坡上。

如果品味可以被完整编码，那么设计工程师这个职业的不可替代性在哪里？如果AI拿着emil-design-eng就能生成和Emil Kowalski同等水平的界面，那“设计工程”就变成了一本食谱——照着做就行。

但事情没这么简单。emil-design-eng文档本身有一段话：“好的品味不是个人偏好。它是一种训练出来的直觉：看清显而易见之外东西的能力。”这句话里藏着自指——文档试图教会AI“看清显而易见之外的东西”，但“显而易见之外的东西”恰恰是那些无法被显式编码的判断。

再看文档对“看不见的细节”的定义：“大多数用户从未有意识地注意到这些细节。这正是关键所在。”如果AI严格按照文档规则生成界面，用户确实不会注意到那些细节——因为细节“正确”到不需要被注意。但问题在于，设计决策的正确性判断，在边界案例中往往依赖无法被规则化的直觉。

review-animations技能试图用“严格的方式”审查动效。但“严格”的标准本身是人为设定的。一个动效是“太慢”还是“刚好”，取决于界面类型、用户预期、甚至文化背景。这些变量无法被穷举。

十条不可妥协的标准

skills项目里有一个专门干一件事的技能模块，叫review-animations。它的任务只有一个：用一套极高的工艺标准来审查动效代码。这套标准被写成了一份清单，叫做“Ten Non-Negotiable Standards”——十条不可妥协的标准。

第一条：每一个动效都必须回答“这个东西为什么要动”。不是为了好看而好看，不是为了动而动。
第二条：频率适配。一个月才触发一次的操作，可以做得有惊喜感。一天触发几十次的操作，只能用极其细微的动效。一天触发几百次的操作，根本不该有任何动效。键盘触发的操作，永远不能加动效。
第三条：响应式缓动。不能用浏览器自带的ease-in-out糊弄事。
第四条：UI动效低于300毫秒。180毫秒的动效比400毫秒的感觉上快了一倍不止。拿不准的时候，往快了走。
后面还有六条：变换原点要正确、动效要能被中断、只用GPU属性（transform和opacity）、考虑无障碍（prefers-reduced-motion）、入场和退场用不对称的时长、整套系统的动效要有连贯性。

这份清单背后有一个默认立场：批准是挣来的，不是默认给的。任何一段动效代码，在证明自己符合这十条标准之前，默认是不过关的。

一个技能仓库的生态扩张

skills仓库不是孤立存在的。围绕它形成了一个快速扩张的生态系统。

2025年12月，Anthropic发布了Agent Skills规范，为跨AI编程工具的SKILL.md文件建立了开放标准。2026年3月16日，emilkowalski/skills创建。一个月后，GitHub推出了gh skillCLI命令，支持技能的版本锁定和供应链完整性保障。

第三方注册表开始收录这个技能。衍生技能开始出现——delphi-ai/animate-skill基于Emil的课程内容做了二次开发。dot-skills仓库里有一个emilkowal-animations技能，专门处理React、CSS和Framer Motion中的动效实现。

pick-ui-library技能展示了一个更激进的思路。它给AI提供了一份“有品味的库清单”——做toast用Sonner、做拖拽用dnd-kit、做数字动画用NumberFlow。AI不再需要自己去npm上搜库、比较star数、判断维护状态。直接告诉它用哪个，省去所有试错成本。

这个生态的扩张速度暗示了一件事：开发者迫切需要一种方式，把“好品味”从少数人手里复制给无数AI助手。skills仓库不是终点，而是一个起点——它证明了一件事可以用纯文本完成，那么其他领域的设计知识也可以用同样的方式编码。

一个动效的对与错，谁来定义？

回到最根本的问题。emil-design-eng说“进入动画应该用ease-out”。这个判断基于一个物理直觉：东西出现时应该先快后慢，像从某个地方滑出来。但这是唯一正确的答案吗？

Material Design的进入动画用的是ease-in-out，先慢后快再慢，强调元素的“出现”而非“滑入”。苹果的许多转场动画用的是自定义cubic-bezier曲线，介于ease-out和ease-in-out之间。没有哪个是“错的”，只有哪个更适合特定语境。

skills仓库的真正贡献不是给出了“正确答案”——它给出了一套可执行的决策框架。AI拿到这个框架后，至少不会犯“进入动画用ease-in”这种低级错误。从“错得离谱”到“基本正确”，这中间的距离，正是这堆Markdown文件试图填补的。

但“基本正确”和“令人惊叹”之间，还有一段无法被编码的距离。那段距离里藏着设计工程师的真实价值——在规则失效的边界处，做出让界面“感觉对”的决策。

Anthropic的Agent Skills规范、GitHub的gh skill命令、18万颗星标——所有这些都在指向一个事实：软件行业正在试图把“品味”工业化。但品味能不能被工业化，这个问题本身，可能比任何技能文件都更值得追问。