用 AI 给米家插件做一段炫酷的开锁动画

给米家插件做一段像样的动效，以前通常得这么来：设计师在 After Effects 里搭形状、调颜色和光影、打关键帧，导出 Lottie 文件，再交给开发接进插件。哪里不满意，就再走一轮。没有设计师配合，插件开发者自己很难做出来。

以智能门锁的开锁动画为例，这次换了一种做法。金属机身、玻璃反光、镜头外的香槟金细环，还有把手压下去再弹回来的那一下，都是 AI 画的。生成脚本由它写；截帧、放大 4 倍找瑕疵、改完再验证，也是它跑完的。

页面排版和播放时的按钮状态，它一并做了；另一个 AI 只负责设计评审。整个过程没打开过 After Effects，也没有手写关键帧，最后得到一个 119 KB 的 Lottie 文件。文件已经接进插件。

人在这套流程里主要负责两件事：把要求说具体，以及在看到画面时指出哪里不对。以前做动效，门槛在工具上，得会 AE，懂关键帧和缓动曲线。现在工具交给了 AI，难的是说清楚要什么、看出哪里不对；这两件事不一定要由设计师来做。不会 AE 的人，也能把一段动效从想法做到能跑起来。

下面这段过程，基本就是一轮一轮改出来的：先有个设想，做出第一版；再看着画面挑问题，改一版；新问题又冒出来，再改。

提出设想：一把扁平的锁

开头那段 4 秒动画，前后改了很多轮。最早的版本，只是一把扁平的锁。

一开始没想着一上来就画实物。先有的是几个动作：锁屏亮起来，锁图标亮一下，进度环走满，把手压下去。至于门锁长什么样，反倒放在后面——先按图标的思路画一版，至少能把“收到指令—验证—开门—上锁”这条线讲清楚。

分镜就是这样：门锁是一个圆角矩形，中间一块深色玻璃，下面是把手。收到指令，锁图标亮起，蓝色进度环走一圈；验证通过，锁变成对勾，把手往下一压，门开一条缝。颜色也只留两种：蓝色是正在处理，绿色是成功。整套动作压在 4 秒里，每个阶段只有一秒左右，稍不留神就会变成一堆同时乱动的零件。

当时对“炫酷”的理解还很表面，觉得光越多、波纹越多、每个部件都在动，才叫炫酷；至于门锁是什么材质、光从哪来、把手有多重，都没顾上想。分镜只有几行字，但已经觉得差不多了，剩下的交给 AI 去画。

那版出来，锁是画出来了，也能动，但看起来更像一个会动的图标，不像一把门锁。自己看着总觉得不行，但又说不清到底缺什么。于是我给 AI 写了一段修改提示词：

现在这版太像图标了。保留“收到指令—验证—开门—上锁”这条线，但门锁要做得像产品宣传图：金属机身、玻璃反光、镜头和把手都要有实体感，整体再炫一点。

这时目标才收窄：不光要动，还要有一把像产品宣传图那样有质感的门锁。动手之前，先得解决两个问题：米家的播放器能力有限，动画文件也不适合让 AI 直接写。

初步完成：先解决能不能画

要让 AI 画出实体门锁，先得把两个限制说清楚：播放器能显示什么，以及动画文件怎么写。

为什么用 Lottie

先说播放器。Lottie 是 Airbnb 在 2017 年开源的动画格式。一段 Lottie 动画通常就是一个 JSON 文件，里面记着画面里有哪些形状、用什么颜色，以及每个形状在第几帧到了什么位置。App 里的播放器读这个文件，每一帧实时把画面画出来，有点像一份“会动的矢量图纸”。这个文件通常由设计师在 After Effects 里做好动画，再用 Bodymovin 插件导出。

App 里常见的加载动画、点赞时的小动效、引导页上会动的插画，很多都是用 Lottie 做的。和 GIF、视频相比，它文件小；这段动画又是纯矢量，在任何屏幕上都清晰。它还能用代码控制：停在任意一帧，或者把进度交给页面，只走其中一段。

import LottieView from 'lottie-react-native';// 最简单的用法：自动循环播放<LottieView source={require('./loading.json')} autoPlay loop />// 由页面控制播放进度：progress 是一个从 0 到 1 的 Animated.Value<LottieView source={require('./lock.json')} progress={this.progress} />

最终的门锁动画用的就是第二种写法。

但米家插件 SDK 自带的 lottie-react-native 是 2.5.5 版，iOS 侧内核是 lottie-ios 2.5.3，版本比较老。模糊、投影、发光这些图层特效都不支持，文字和图片也用不了。能用的基本只剩形状、颜色、渐变和线条。

那这 4 秒里到底要发生什么？先按最终要交付的样子，把动作拆开看。第一版不会一次做到，但后面的每一轮都拿它当对照。

这 4 秒要发生什么

页面没有标题栏，门锁占满屏幕上半部分，下文把这块区域叫作“头图”。头图下方是“点击开门”按钮和“门状态”等卡片。平时动画停在“已上锁”这一帧，头图右上角的大标题也写着“已上锁”。

点下“点击开门”，三道蓝色信号波从下方按钮的方向升起，一路传到门锁。锁屏上的时间淡出，锁图标亮起，指纹环和灯带变成蓝色。波纹碰到门锁的那一刻，锁图标外荡开一圈，像“叮”的一声。

接下来是安全验证：锁图标外的蓝色进度环一点点走满。

走满的那一下，环变绿，锁变成对勾。两道绿光沿着门锁边框跑一圈，把手压下去又弹回来，门缝里透出一道暖光。页面也在同一时刻变了：大标题变成绿色的“门已打开”，下方“门状态”卡片变成“已打开”。

最后，光一点点暗下去，门锁自动上锁，回到待机。整段正好 4 秒。

用叠层画出实物质感

这些动作要落在只有形状、颜色、渐变和线条的播放器里，先得把门锁画出来。拿这几样东西画金属和玻璃，只能一层一层往上叠：

第一层是形状，先把比例摆对：胶囊形的面板，上面是玻璃区，中间是指纹，下面是把手。

第二层是材质，用渐变来“画”材料。面板左侧加一道亮色，看起来就成了一个受光的弧面；下半部分换成浅一档的钛色，机身就有了两种颜色。

第三层是光影：倒角高光、玻璃反光、头顶的一束灯光，还有投影。没有投影特效，就把同一个形状一圈圈往外扩，每圈只给百分之几的透明度，叠在一起就是一片柔和的阴影。

第四层是细节：镜头、锁屏时间、指纹纹路、扬声器开孔、滚花纹、香槟金饰圈。它们单个都很小，可少了它们，门锁就只是一个圆角矩形。

最后才轮到动效。

用脚本生成动画文件

这份 Lottie 动画的源文件是一个 JSON。这把门锁的 JSON 最后有 12 万个字符，几乎全是数字。让 AI 直接写，很容易写错，出错后也很难定位。

所以 AI 不直接写动画文件，而是写一段“画图步骤”的脚本，运行脚本再生成动画。脚本里每个部件、每个时间点都有名字，读起来像一份设计说明：

时间点：收到指令 = 第 2 帧，开始验证 = 第 50 帧，门已打开 = 第 114 帧，自动上锁 = 第 205 帧门锁面板 = 胶囊形，填充石墨色金属渐变玻璃区   = 圆角矩形，填充近黑色渐变，加一道斜向反光进度环   = 圆环，从“开始验证”到“门已打开”由 0% 画到 100%把手     = 收腰的长条，从轴头向右伸出           到“门已打开”时下压 16°，再用弹簧弹回

这样改起来也方便。想让门早一点开，改一个时间点；要做浅色、深色两版，同一套步骤换一组环境颜色。

脚本解决了写法问题，但 AI 仍然不知道米家的播放器能显示什么。如果不加约束，它很可能写出一段在手机上渲染不出来的效果。与其画完再返工，不如一开始就只给它画得对的“画笔”，也就是生成脚本里能调用的一组画图函数：

• • 没有投影、模糊、发光特效，就提供 softShadow()（柔和投影）和 glow()（柔光）这样的函数，内部用多层半透明形状和透明度渐变来实现。
• • 不能显示文字，锁屏上的 09:41 就用线条一笔一笔画出来。
• • 渐变描边、合并路径、图片、表达式这些播放器不支持的能力，画笔里干脆不提供。
• • 有些写法在 iOS 和 Android 上效果不一样，画笔统一换成两端一致的写法。

每次画完，再跑一遍兼容性检查：图层类型、形状类型、关键帧连续性、图片和文字，命中不支持的特性就报错。只要不超出这套画笔的能力，生成的文件就不会碰到播放器不支持的特性。

两个问题解决后，第一把实体门锁出来了。它用的是刷脸开门，动画自动循环播放，页面顶部还有标题。

第一轮优化：先解决什么时候播

第一版出来后，问题很具体：标题还压在页面上，动画一自动循环，页面和动画各演各的。我把修改要求整理成两条提示词：

去掉页面顶部标题，改成沉浸式头图。动画不要自动循环，改成点击“点击开门”后播放一次。

另外重点看一下把手，那里看起来有点不对，但我说不清是形状还是光影的问题。先放大检查，别急着改。

把手那条先记下，后面截图时再处理。先看第一条：它看着简单，其实带出了一个新问题——动画播放的时候，页面上的标题、按钮和卡片怎么跟着变？

做法就是前面提到的第二种写法：页面自己掌握进度，动画跟着进度走，逻辑如下：

点击“点击开门”：    进度从 0 开始，用 4 秒匀速推到 1每一帧：    动画画面 = 第（进度 × 240）帧    页面文字 = 这一帧所在阶段的文字      // 例如第 114 帧起显示“门已打开”

这样画面和文字就能对上拍子：锁变成对勾的那一帧，标题正好变成“门已打开”。以后接入真实门锁，也可以按设备回传的状态只播对应的那一段。换成视频，进度就没这么好控了。

这一轮改的是“什么时候播”，画面里演的仍是刷脸；下一轮才把开锁方式也换掉。

播放时按钮不能还写着“点击开门”。最早它变成半透明灰色，看起来像坏了；后来改成状态胶囊，显示“正在开门”“门已打开”。

至于把手上的“瑕疵”，提意见时也说不清具体是什么，只是觉得那里不对劲。它是后来放大截图才找到的。

第二轮优化：补细节，加浅色

第一轮改完，能按按钮播放了，但画面里演的仍是刷脸，门锁本身也不够有质感，头图上方还显得空。第二版之前，我重新写了一段提示词，把要改的地方一条条列出来：

开锁方式从刷脸改成点击开门。

门锁外形还是有点单调：机身可以做成双色，加香槟金饰圈和滚花把手座；插件上方区域有点空，可以加从按钮方向升起的信号波、顶灯和门缝。状态文字也挪到头图的空白处。

这一段基本就是第二版的清单。改完之后，门锁有了双色机身和几处金属细节，信号波从按钮方向升到门锁，顶灯和门缝把上方区域撑了起来；状态文字也挪进了头图的空白处。

后来补浅色版，我只补了一句提示词：

门锁本身不变，只换墙面、灯光和阴影；白墙上的彩色光晕要淡一点。

现在两套都有，默认跟随系统，底部也能手动切换。

真正难办的是这一段。我把原话整理成了一版提示词，但还是不够具体：

整体再看一遍：现在更像一个功能演示，还不像一个有设计感的插件。把动效、排版和状态变化放在一起想，要尽可能炫酷，能直接拿出去展示。

于是我又把它拆成了几条能检查的要求：每个阶段只留一个焦点；信号、验证、开门、上锁要一眼看懂；颜色只表达状态；首尾画面一致。接下来的工作，就是拿这几条反复生成、截图、评审、再改。

第三轮优化：让 AI 自己找问题

第二轮改完，整体像样了，但细节还经不起放大看。这一轮开始，我不再只靠自己的眼睛。每次生成完，AI 先自己截图检查；再请另一个 AI 做评审。

截图和放大检查

AI 看不了连续播放，只能看截出来的静帧。每次生成完，它会把动画按时间均匀截成一排画面，再对照需求检查：信号波是不是从下方来的，对勾是不是在验证之后才出现，最后有没有回到待机。

整张图看不出问题，放大后就不一定了。很多瑕疵要放大了才看得见，前面那个说不清的把手“瑕疵”就是这么找到的：把局部放大 4 倍后，能看到把手根部露出一道月牙形的缝。改法是让轴头单独占一层，正好盖住把手根部。

截图还暴露过两个光读代码发现不了的问题。一次是某个波纹在截图里往里收，和预期正好相反。原因是关键帧的起止值写法不一致：iOS 和网页预览用的 lottie-web 按下一帧的起始值插值，Android 按当前帧的结束值，两端方向就反了。

另一次是截图整张发黑。预览用的网页播放器对字段更敏感，文件里最后一个关键帧少写了 s 字段，渐变直接读不出来。这两个问题后来都写进了画笔和检查脚本，同类写法不会再生成。

用另一个 AI 做设计评审

自己画的东西，自己很难挑出毛病。所以项目里另外安排了一个 AI 当设计评审：只给它截图和设计要求，不给代码，让它逐条说上一轮的问题修好没有，标出新问题的位置，最后打分。

设计评审前后做了七轮。它挑出来的不少问题，人眼很容易漏掉。

有一轮，它说锁屏上的时间整体偏左。把截图放大后数一下，确实偏了 3 像素。原因是“1”比其他数字窄，居中时得按每个数字的实际宽度来算。

还有一轮，它指出的是故事上的毛病。当时收到指令后，锁屏上会亮起一个数字键盘。评审说这看起来像是要输入密码，和“点击开门”对不上。单看画面，每一笔都没画错，错在逻辑。后来去掉了键盘，换成锁图标亮起、“叮”一下。

画面里原本还有一些飘浮的微尘，想用来烘托氛围。评审连着两轮说它们像污点、像屏幕坏点，最后整个删掉了。

其他几处问题和改法：

设计评审做到第七轮，画面上的小毛病基本清完了。最后剩下的，是构图。

第四轮优化：最后调构图

细节清完，最后的问题是构图。快收尾时，提示词很直接：

把手和“已上锁”文案都挪到右边。左上角的关闭按钮被一条竖线挡住了，把那条线让开。

于是整个构图左右对调：门锁放在左边，把手向右伸出，状态文字放到右上角。挡住关闭按钮的那条竖线是门缝，也挪到了按钮左边。

每次改完，AI 都会重新截图、放大检查，确认没有引入新问题。

收尾：细节、数据和边界

改到这里，门锁的细节基本都能经得起放大看：

镜头外有一圈香槟金细环，锁屏上的 09:41 是用线条一笔一笔画出来的。进度环下面垫着一条淡淡的底轨，走满时会轻轻弹一下。开门成功时，指纹环和玻璃下方的分缝灯带一起变绿，绿光向外晕开。把手座外圈有一圈细密的滚花纹；把手压下去时，一点高光沿着杆身从根部滑到圆头。

头图部分的高清视频在这里：

页面有浅色、深色两套，默认跟随系统，底部也能手动切换。

前面从“有设计感”里拆出来的检查项，最后落成了这几条约束：

• • 每个阶段只有一个焦点。发信号时看波纹，验证时看进度环，开门时看对勾和把手，其他元素都保持安静。
• • 快出慢停。元素出现时起步快、收尾慢，收尾留一点缓冲。
• • 有物理感。把手像装了弹簧，弹回时会稍微冲过头，再回到原位。
• • 颜色只表达状态。蓝色表示进行中，绿色表示成功，其余都是中性色。
• • 首尾一致。最后一帧和第一帧完全相同，播完归零时不会跳一下。

文件规格：375×520，60 fps，240 帧，15 个图层。整段动画的 JSON 是 119 KB，gzip 后 9.7 KB；同样只算头图的一张单帧 PNG 约 0.44 MB，4 秒 60 fps 的视频约 0.32 MB。

文件小，不等于运行时开销小：Lottie 每帧都要实时画，图层多、面积大时仍会吃 CPU；这个头图控制在 15 个图层，发布前还要在 iOS 和低端 Android 机上确认帧率和显示效果。

Lottie 适合这种纯矢量、状态明确、几秒内讲完的头图；真实视频、复杂粒子效果和模糊效果，还是交给视频或序列帧更合适。

这套流程能复用什么

回头看，这套流程其实一直在重复同一个循环：提出设想，初步完成，发现问题，优化一版；再发现，再优化。真正决定方向的，往往是下一条修改要求写得够不够具体。

这几轮改下来，方向基本都是被几句话改掉的：“太像图标了”“页面和动画各演各的”“门锁有点单调”“关闭按钮被挡住了”。这些判断最后还是人做的。AI 擅长的是把一句话拆成画图步骤，再一遍遍截图、放大、确认。

如果要在插件里复刻这套流程，下面几条最值得先定下来：

• • 让 AI 写画图步骤，别让它直接写动画文件。步骤读得懂、改得动，换主题、调节奏只是改几个参数。
• • 提前把平台限制封装进画笔。AI 手里只有画得对的笔，就不会画出播放器显示不了的东西。
• • 用设计师的语言提需求。“做一个炫酷的开门动画”只能让 AI 自由发挥；说清构图、材质、每个阶段的焦点、时长和颜色的含义，它才知道该画什么。
• • 模糊的要求先拆成可检查的项。“有设计感”没法直接执行，拆成“每个阶段一个焦点、颜色只表达状态、首尾一致”之后，AI 才知道下一版改什么。
• • 让 AI 看见自己的作品，再请另一个 AI 来挑毛病。截图、放大、评审，比读代码更容易发现画面上的问题。
• • 这类设备头图很适合用 Lottie。文件小、画面清晰，进度交给页面控制，画面就能和设备状态、页面文字一一对上。

文中的生成脚本、兼容性检查和截图工具都在 projects/com.xiaomi.lottiedemo/tools；在 SDK 根目录执行 npm start com.xiaomi.lottiedemo 可以跑起插件。

附录：提示词模板

下面三段提示词可以直接拿去改。第一段把需求写到了构图、材质、节奏和颜色含义这一层，后两段对应上文的“放大检查”和“AI 评审”。

模板 1：生成实体质感的设备头图

你是一名熟悉 Lottie 格式和产品动效的工程师。请为米家插件制作“智能门锁”首页头图动画，浅色、深色各一版。【画面】画布 375 x 520。门锁在左侧，把手向右伸出，最左边是门缝，右上角留空给状态文字，上方有一束顶灯。门锁要像实物产品图：石墨色金属胶囊形面板，左侧受光亮边和侧面厚度；黑色玻璃区带斜向反光，顶部是香槟金圈的镜头，待机时显示锁屏（时间、锁图标、电量）；凹陷的指纹区；滚花把手座；把手根部收腰；多层柔和投影。浅色、深色两版门锁完全一样，只换墙面、灯光和阴影；白墙上的彩色光晕要更淡。【动效】60 帧每秒，共 4 秒，首尾画面一致。用户点击“点击开门”后播放：收到指令（信号波从下方传来，锁图标亮起）→ 安全验证（蓝色进度环走满）→门已打开（变绿、对勾、边框流光、把手下压后弹簧回弹、门缝透光）→ 自动上锁（淡出回到待机）。每个阶段只有一个视觉焦点；出现用“快出慢停”；蓝色只表示进行中，绿色只表示成功。【限制】米家的 Lottie 播放器较老：不用特效、文字、图片、表达式、渐变描边、合并路径；蒙版尽量不用，Android 上开销大；投影和发光用多层半透明形状、透明度渐变代替。【交付】不要直接输出动画文件。用项目提供的画图函数写一段生成脚本，运行后做兼容性检查，再截图逐帧对照上面的描述检查，不符合就改脚本重新生成。最后列出各阶段的帧号，供页面同步文字。

模板 2：让 AI 放大检查细节

请把第 0、140、150 帧输出成 4 倍大小的图片，裁出把手、轴头、指纹区、锁屏时间这几个局部，逐一检查：边缘有没有缝、亮点或多余的线；该居中的有没有居中（可以数像素）；高光和阴影的方向是否一致；浅色、深色是否都正常。发现问题直接修改，重新生成并再次截图确认，最后列出改了什么。

模板 3：让另一个 AI 当设计评审

你是一名资深产品动效设计师，正在做上线前的视觉评审。只看图片，不要修改任何文件。设计要求：<粘贴模板 1 的【画面】和【动效】>上一轮发现的问题：<逐条列出>请查看这些截图：<图片列表>输出：A. 上一轮的问题逐条判断：已修复 / 未修复 / 看不出来，附理由和位置B. 新发现的问题：只列认真的设计师会注意到的，附图片和大致位置C. 浅色、深色分别打分（10 分制），并给出能否公开展示的结论

本文基于米家扩展程序开发实战整理，仅供参考，具体请以官方最新文档为准。

如果你在米家扩展程序开发中有任何疑问，或需要插件动效、UI开发等服务，欢迎添加微信 MIJIA-IoT-TechHub 交流合作！