一键导入
animate-prompt
从动效视频/截图反推出可直接喂给 LLM 还原动效的 Prompt 描述词。重点在「看懂运动」和「对齐你的意图」,不是搬运帧。触发词:分析动效、animate prompt、生成动效描述、动效 Prompt、animation analysis、帮我写这个动效的描述、还原这个动画
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
从动效视频/截图反推出可直接喂给 LLM 还原动效的 Prompt 描述词。重点在「看懂运动」和「对齐你的意图」,不是搬运帧。触发词:分析动效、animate prompt、生成动效描述、动效 Prompt、animation analysis、帮我写这个动效的描述、还原这个动画
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
在需要打包、签名、OTA、APK/IPA、GitHub Release、商店提交、部署、回滚或验活时使用;支持独立窄任务,也支持作为 app-flow 的当前行动。它核对具体渠道授权,可复用用户明确记录的项目级 preview OTA 持续授权并在验证通过后自动发布;未获授权只做预检。
把自然语言 App 需求、模块说明和参考截图一路推进到经验证的代码与当次授权交付;用于需要长时间自主开发、持续排障和跨上下文恢复的移动端或跨端 App 任务。它不固定技术栈、阶段或交付形式,也不会把无人值守理解为远端发布授权。
在需要与生产者分离的独立评审、复核、验收,或对 App 方案、UI、代码、体验或交付准备度做质量判断时使用;支持独立窄任务,也支持作为 app-flow 的当前行动。它只做只读评判并绑定真实证据,不创建或修改产物,也不做第一方定位根因或直接改代码。
在设计、开发或交付 App 时按需参考 Happy/Paws 经验,包括移动端架构、React Native/Expo 取舍、验证、OTA、安装包与 Release 边界。用于用户明确要求参考 Happy/Paws,或当前问题与这些真实工程经验高度匹配时;它只提供上下文,不是 App Workflow,也不强制复制 Happy 的技术栈。
在需要创建、修改、重构、修复 App 代码,或只读诊断崩溃、定位根因、给出候选补丁时使用;支持独立窄任务,也支持作为 app-flow 的当前行动。它不做产品调研、原型/设计、独立评审或打包发布,除非当前行动本身就是改代码。
作为 self-learning 的 HyperFrames 产出能力,自主学习本地教学音视频或公开视频链接,把教程讲授的方法、可观察动效和屏幕代码转成有证据、可恢复、可渲染的 HyperFrames Demo,并记录实际使用的内容、Skills、工具与可复用经验。仅在 self-learning 调用,或用户明确要求从教学素材制作 HyperFrames Demo 时使用;普通学习任务不要单独触发。
| name | animate-prompt |
| description | 从动效视频/截图反推出可直接喂给 LLM 还原动效的 Prompt 描述词。重点在「看懂运动」和「对齐你的意图」,不是搬运帧。触发词:分析动效、animate prompt、生成动效描述、动效 Prompt、animation analysis、帮我写这个动效的描述、还原这个动画 |
这个 skill 的难点不是取帧,是「看懂运动」和「对齐你到底想要什么」。流程的重量全部压在 Phase 2 和 Phase 3。
核心产物 = Prompt 文本本身(可直接复制粘贴)。README、代码、文件结构都是可选的、按需追加的,不默认生成——因为从视频里推不出文件结构和精确浏览器版本,强行输出就是编造。
第 0 步(强制,先于一切):读 references/lessons.md——这是本 skill 的持续经验日志,记录了过往"哪里没做好"。把里面每条的"下次规则"当作本次的先验检查项(尤其 L1 的四个最易漏维度)。这一步不是可选的,跳过 = 大概率重复历史踩坑。
不要拿到视频就闷头分析。一个视频可以有多种实现路线,不先对齐就会产出"不是你想要的"。 用一两句话快速确认(已在用户话里说清的就跳过,不要复读式追问):
机制明显有歧义时(例如圆形扩散可能是 clip-path 也可能是 canvas 遮罩),不要替用户拍板——在 Phase 3 给出多套变体让用户选。
| 输入类型 | 取帧方式 |
|---|---|
| 视频文件(.mp4/.mov/.webm) | ffmpeg 抽帧(见 Phase 2) |
| 截图目录 | 直接读 PNG/JPG |
| 页面 / CodePen / 本地 HTML | agent-browser 打开 + 多次截图(关键时刻各截一张),同时读源码(源码能直接看到机制,优先级最高) |
如果输入是页面或 CodePen,源码 > 截图。能读到 CSS/JS 就别只靠肉眼反推。
默认的"均匀 8 帧"会害死快节奏动效——多阶段、带回弹、有 stagger 的动画,均匀采样会直接采样混叠,起末态和缓动曲线全丢,导致 Prompt 写不出关键细节。
第一轮:粗采,建立全局节奏感
# 短动效(≤3s,单段):按"帧数/时长"算出 fps,均匀抽 10~14 帧
DUR=$(ffprobe -v error -show_entries format=duration -of default=nw=1:nk=1 video.mp4)
ffmpeg -v error -i video.mp4 -vf "fps=12/$DUR" -frames:v 12 f-%03d.png
# 或最简:固定 fps 抽几帧
ffmpeg -v error -i video.mp4 -vf "fps=2" -frames:v 12 f-%03d.png
强烈建议:抽完用
tile拼成一张 montage 一次看全,最容易"脑内播放"出连续运动:ffmpeg -v error -i f-%03d.png -vf "scale=460:-1,tile=4x4" montage.png锁定某一剧烈过渡段时再用
hstack把那几帧横排细看。
第二轮:看完第一轮后,对自己提问(这步不能省)
第三轮:针对关键时间段加密 + 空间放大
"加密"有两个维度:时间上密集抽帧,空间上裁剪放大。小主体两者都要做。
# 时间加密:锁定 0:01~0:02 这段剧烈过渡,只抽这一秒(-ss 起点 -to 终点)
ffmpeg -v error -ss 0:01 -to 0:02 -i video.mp4 -vf "fps=10" -frames:v 10 d-%03d.png
# 空间放大:把主体区域 crop 出来放大到 ≥400px 再逐帧 Read(小主体必做)
ffmpeg -v error -i d-005.png -vf "crop=300:300:130:50,scale=420:-1" big-05.png
# 长视频/多场景:用场景变化检测找断点
ffmpeg -v error -i video.mp4 -vf "select=gt(scene\,0.1)" -vsync vfr -frames:v 12 s-%03d.png
判断标准:把抽出来的帧排成序列,你能不能脑内"播放"出连续运动并说出缓动是匀速/先快后慢/回弹。 能 → 帧够了;不能 → 继续加密那一段。宁可多抽两轮,不要拿不够的帧硬写 Prompt。
| 维度 | 怎么从帧里判断 |
|---|---|
| 触发方式 | click / hover / scroll / load / auto——追踪光标轨迹:自动循环的视频常常其实是 hover 交互(光标移入容器→播放,移出→立即复位)。别把"反复进出"的录屏当成 autoplay 时间循环去硬套 @keyframes infinite——那会导致过渡被整段缓动拖糊。看光标是在容器内还是容器外,进出时刻与动效起止是否对齐 |
| 容器/载体自身的状态 | 最容易被当背景忽略的一项:被点/悬停时容器本身有没有按压凹陷、阴影翻转(拟物 outset↔inset)、缩放回弹、外发光收放。看容器边缘的阴影方向有没有反转——有就是按压态,必须单独建模(通常 hover 触发 + ~120-180ms ease-out 短 transition,而非长缓动) |
| 初始态 → 结束态 | 第一帧和最后一帧分别长什么样,用一句话各描述 |
| 变化的维度 | 对比帧序列,到底是 position / scale / opacity / color / clip-path / rotate / blur 里的哪几个在动(常是组合) |
| 多趟绘制 | 同一图形是否分两趟完成:先描出轮廓/刻痕/白线,颜色/填充滞后跟上覆盖(任一时刻 = 顶部已上色、中部仅线条、底部还没出)。只做一趟着色会丢掉"先成形再上色"的质感——这点和空间锚点一样最常被漏。写进 Prompt 时滞后量必须给硬数字:趟间相位差 ≥ 单趟时长的 50%~65%(不能写"略微滞后"),且未上色那趟要有自身对比度(略灰 stroke / 雕刻阴影),否则两趟会塌缩成一趟、闭环里看不到三段共存(见 L5) |
| 缓动判读 | 看相邻帧的位移差:等差→linear;先大后小→ease-out;末尾反向小幅→回弹/spring;中间最快两头慢→ease-in-out |
| 时序结构 | 单段 / 多段串行 / 元素错落(stagger,多个元素依次启动)/ 循环;多趟之间的相位差(如颜色趟比刻痕趟整体滞后约 0.5s) |
| 空间锚点 | 缩放/扩散的中心在哪——元素自身中心?点击坐标?固定角落?(这点最常被漏,导致还原出来"动是动了但位置不对") |
| 推断实现机制 | 由可观测特征反推:圆形揭示 →clip-path: circle() 或 View Transitions;逐像素/网格 → Canvas drawImage;平滑延迟跟随 → GSAP quickTo;DOM 整体过渡 → View Transitions API |
区分清楚三类信息,不要混:
对标 tile-grid-reveal 那段约 180 字的 Prompt——它能被还原,正是因为塞满了 s = 1 - clamp01(d / canvasSize / dynamicScale)、GSAP quickTo expo duration 2、drawImage 9 参数形式。一段好 Prompt 该多具体就多具体:
clip-path: circle()、document.startViewTransition、drawImage 9 参数、GSAP quickTo)expo / ease-out / 带回弹)和量级(0 → 170vmax、duration ≈ 0.55s)❌ 禁止"实现一个流畅的渐变动画" 这种喂了等于没喂的话。
如果一个动效有多条合理实现路线,不要替用户选,并列输出,每个标注它的假设与取舍:
方案 A · 纯 CSS(clip-path + @keyframes)
假设:单层揭示,无需截图旧 DOM;零依赖、最轻
Prompt:……
方案 B · View Transitions API
假设:需要新旧主题整体交叉,浏览器较新
Prompt:……
方案 C · Canvas 逐帧
假设:揭示边缘有噪声/粒子等 CSS 难做的细节
Prompt:……
让用户挑,或让用户说"就要 A",再继续。
触发条件:动效主体是一张肉眼无法用几条贝塞尔还原的复杂图形——指纹 / 手写签名 / logo / 复杂插画。这种情况下手画路径 = 出来的形状一定不是用户要的(哪怕动效逻辑对,用户第一句就是"形状差太多")。必须从一帧干净的图里矢量化。
| 动画需求 | 用什么 | 关键取舍 |
|---|---|---|
| 形状静态 / 可接受「遮罩自上而下擦除」揭示 | potrace(描成闭合填充路径) | 跟随像素噪声 → 易毛刺;重平滑位图 + -t turdsize 去碎点;potrace 默认输出带 scale(.1,-.1) 的 Y 翻转,渐变方向要反向补偿;闭合填充无法 stroke 自绘 |
需要「逐条描出」的自绘效果(stroke-dashoffset) | 开放中心线 stroke 路径 | potrace 给不了;autotrace --centerline 是名义工具但 brew 安装极脆弱(装完二进制可能损坏)。可靠路线见下 ↓ |
一句话决策:静态 / 擦除揭示 → potrace 填充;逐条自绘 → skeleton 中心线。本质区别 = 闭合填充轮廓 vs 开放折线——这决定了能不能
stroke-dashoffset。选错了再做动画会全盘推翻重来。
remove_small_objects + binary_closing/opening 清噪点毛刺skimage.morphology.skeletonize → 1px 骨架scipy.ndimage.gaussian_filter1d 平滑 + RDP 简化 → 去毛刺的干净折线fill:none; stroke:url(#grad); stroke-linecap:round + 每条加 pathLength="1"(归一化,长短线同速自绘)+ animation-delay:calc(var(--i)*Xs) 做自上而下 stagger产出对比:potrace 版 34KB 带毛刺填充、只能做擦除;skeleton 中心线版 ~7KB 干净真矢量、完美
stroke-dashoffset自绘。
这是质量上限所在,不是默认步骤:
index.html(单文件)闭环跑通后,这段 Prompt 才算"验证过",而不是"应该能用"。
仅当用户在 Phase 0 要了才生成。只填能从分析中得到的小节,推不出来的(文件结构、浏览器版本)要么省略,要么标注"待代码生成后补全",不要编。格式对齐 jacky-css 现有 README:
# {动效名称}
{一句话效果描述}
## 效果预览
{交互行为,2-3 个要点}
## Prompt
> {Phase 3 产出的 Prompt}
## 关键术语
| 术语 | 说明 |
|------|------|
| {英文术语} | {中文说明} |
## 技术方案
{运动 → 机制的流程描述,只写推断得出的部分}
## 文件结构 ## 浏览器支持 这两节等 index.html 真生成后再补,分析阶段不写。
默认只需 ffmpeg(含 ffprobe):brew install ffmpeg。抽帧、montage、hstack 全部用 ffmpeg 原生命令完成(见 Phase 2),无需任何额外 CLI 或 API key。
仅当走 Phase 3.5 矢量化时才追加:potrace(填充描摹)、imagemagick(位图处理)、Python numpy/scipy/scikit-image(骨架中心线)。
环境坑(已踩过,省时间):
brew install与 Playwright 浏览器下载都可能因公司网络静默停滞(命令挂在后台 0 输出)。先export HTTP_PROXY/HTTPS_PROXY/ALL_PROXY=<本机代理>再前台带timeout重试,通常立刻成功。- 闭环截图优先复用系统已缓存的 Chromium(
~/Library/Caches/ms-playwright/chromium_headless_shell-*/...),用 Playwrightlaunch({executablePath})指过去,别等playwright install重新下载。magick若没装 rsvg/ghostscript,渲染 potrace/SVG 不可靠(出全白图)→ 改用已缓存 Chromium 截图来预览 SVG。
"看懂运动"这步由你(Claude)直接
Read帧图来做——你就是视觉模型,逐帧推断运动/缓动/锚点(即 Phase 3),这比任何一把梭的自动分析都精细。不要去找或安装第三方分析工具。
设计参考
references/experience-sedimentation-design.md《站点经验沉淀机制》:写入 = Prompt 驱动的 AI 自主行为,读取 = 规则强制。本 skill 没有也不需要写入脚本——靠下面这些规则驱动你自己在恰当时机读和写,从而每次运行都比上一次少踩一个坑。
存储:references/lessons.md,单文件流水账,一条经验一段,含 类别/日期 与三段式结构。能固化成 Phase 清单/完成标准的同步并入 SKILL.md 正文;本文件保留带日期的"别再犯"先验。
读取时机(强制):每次进入 skill,Phase 0 第 0 步必须先读 references/lessons.md,逐条把"下次规则"作为本次检查项。
读取回退:每条标了日期,是"提示而非保证"。若某条经验与当前视频/用户意图矛盾,以当前事实为准,并在本文件更新/修正该条(注明新日期),不硬套旧经验。
写入时机(主动):一次任务结束、尤其本轮被用户纠正过 ≥1 次、或闭环比对暴露过遗漏之后,主动追加新经验。顺利无新发现则不写(不灌水)。
写入约束:
自检闭环:本轮若被用户纠正过 ≥1 次而 references/lessons.md 未更新,则任务未完成,不得交付。
references/lessons.md,Phase 0 把历史"下次规则"逐条当检查项过了一遍references/lessons.md 旧经验时,先独立判读当前帧再拿旧经验对照,矛盾以当前事实为准,禁止拿旧结论直接套(见 L6)references/lessons.md 已追加对应「现象→根因→下次规则」并标注是否并入正文——否则任务未完成