资讯动态

用代码画白板视频:AI Skill驱动的手绘动画自动生成全流程解析

发布时间:2026/10/15 7:43:27 来源:尧图企业网站定制
做了大概两年内容工具方向的项目我越来越觉得一个靠谱的做视频的 skill比多数剪辑软件都好用。标题里写得很明确这条白板视频每一笔都是代码画的。也就是说视频里出现的每一根线条、每一段文字、每一条分镜背后都不是人拿着鼠标去描而是由程序按着路径编排一笔一画渲染出来的。整个过程核心是skill——一个可以被 AI 智能体随时调用的技能包。这篇文章我会把它的设计思路、核心原理、完整实现路径和踩过的坑都摊开讲适合做 AI 工具、做内容自动化、或者想用代码替代重复视频制作的朋友参考。先说结论白板视频用代码画不是炫技而是解决手绘感视频难以批量生产这个真问题。传统做法要么请人画要么用现成模板改成本高且不可控。用 skill 之后给一段文案AI 自动拆解成画面元素生成带笔迹顺序的绘图指令再交给渲染管线按帧输出最终合成为视频。整个过程可复用、可微调、可版本管理这才是代码化生产的价值所在。1. 这个 skill 到底是什么它解决的是哪类问题1.1 白板视频在生产端的核心痛点白板动画视频白色背景上用彩色笔迹边画边讲解的那类视频之所以受欢迎是因为直观、有亲和力尤其适合科普、知识讲解、产品介绍。但真正做过的人都知道制作门槛一点都不低。市面上的白板视频制作工具大部分还是在模拟画的过程素材库里的手绘图标、动画笔迹都需要人工配置时间轴稍微改动文案就要重新调整画面。如果是批量产出几十条视频这项工作会把人活活耗死。用代码画白板视频本质上是把视频制作变成程序渲染。视频里的一支笔、一根线背后都是代码在控制路径的长度、方向、速度和停顿。这个思路最早的灵感其实来自 SVG 动画——用 stroke-dasharray 和 stroke-dashoffset 两个属性模拟画笔从起点画到终点的效果。如果你在浏览器里见过线条自己画出来的动效基本原理就是这个。把它延伸到视频输出就是让每一个元素都按脚本定义好的时间轴依次画出来。1.2 代码画视频的两个关键优势首先可控性完全不同。手绘视频最怕的就是这一笔画得不够流畅这里停顿不对但在代码世界里路径就是贝塞尔曲线方程线宽就是数值参数快慢就是时间函数。想要笔迹有笔锋、有停顿、有力度变化完全可以靠算法表达式控制不需要反复手工试错。其次是批量生产成为可能。只要写好一套文案转画面的规则AI 负责把文案拆分成视觉元素和讲解顺序渲染程序负责把这些元素画出来中间几乎不需要人工介入。我自己的实测数据是一条 90 秒白板视频脚本确定后渲染耗时大概 5 到 8 分钟和以前动辄半天的制作周期完全不是一个量级。所以这个 skill 最适合的场景就是内容团队做规模化知识类视频、教育产品做课件动画、以及个人博主做固定形式的系列内容。1.3 先弄清楚每一笔都是代码画的具体含义这句话不是比喻而是事实描述。视频里的每个可见图形在计算机里都有一个对应的绘图指令。画一个矩形是rect x... y... width... height...画一条曲线是一串点坐标连同控制点坐标写一个字是一连串描述笔画走向的轮廓路径。所谓每一笔就是这些路径数据。渲染引擎每秒钟重绘三十次画面画笔位置、已绘制路径长度、墨水颜色都是逐帧计算出来的。所以你做出来的不是一个图形文件而是一套可以被任意调整和重放的绘图程序。这样设计带来的额外好处是只要绘图指令不变改变视觉风格只需要改渲染参数。今天想要黑色细笔明天想要蓝色粗笔后天想要蜡笔质感——同一套指令换一个渲染后端就搞定了。这种灵活性也是我坚持走skill 代码生成路线而不是录制画板操作路线的根本原因。2. 核心设计拆解skill 的架构与绘图载体选型2.1 skill 在 AI 智能体里的实际形态这个 skill 不是一段一次性代码而是一组结构化文件加一个可执行流程。在 Agent 的工作目录里它长这样whiteboard_video_skill/ ├── SKILL.md # 技能描述告诉 AI 什么时候用、怎么用 ├── schema.json # 绘图指令的数据结构定义 ├── generator.py # 把脚本转成绘图指令可集成大模型调用 ├── renderer.py # 把绘图指令渲染成 PNG 序列 ├── encode.sh # 调 ffmpeg 合成视频 └── examples/ ├── demo_script.md └── demo_output.jsonSKILL.md是给 AI 看的说明书里面写明该技能适用于生成白板讲解视频输入是一段口播文案输出是一个 mp4 文件启用时需要调用generator.py的某个函数渲染时调用renderer.py的某个参数组合。这样当你在对话中把文案丢给 AgentAgent 读到 SKILL.md 之后就会自动跑到对应的目录下执行流程。这和我自己早期把代码贴在 prompt 里的做法相比最大的进步是可复用性同一个 skill 可以被多个 Agent 场景共享也可以被其他项目一键引用。真正写起来的时候你会发现schema.json是整个环节中最关键的文件。因为它决定了 AI 能不能稳定输出规范化的绘图指令。如果 schema 定义得松AI 就会给你各种奇怪的字段定义得紧AI 反而容易理解并遵守。这个原则跟跟人打交道一样边界越清晰协作越顺畅。2.2 为什么选择 SVG 而不是 Canvas 或视频模板做动画渲染第一反应可能是 HTML Canvas它在浏览器里画图确实方便但有一个致命伤Canvas 的对象是无状态的像素结果很难精确控制哪条线画到哪了。你要做一笔一画的效果必须自己维护所有图形的绘制状态代码量会非常庞大。SVG 则不同它是声明式的矢量结构每个元素都可寻址、可操作、可单独控制动画进度。在代码生成的场景下AI 输出 SVG 内容比输出一段 Canvas 绘制函数要容易得多因为 SVG 的语言更接近描述结果而不是描述步骤。另外SVG 自带了一个对白板视频极其友好的特性stroke-dasharray和stroke-dashoffset。前者定义虚线段的长度模式后者定义虚线段的起始偏移量。把 dasharray 设为等于路径总长、dashoffset 也设为等于路径总长时整条线是隐形的逐步减小 dashoffset线就长出来。配合getTotalLength()方法读取实际路径长度可以做到毫米级精确的笔迹动画。Canvas 想做同等效果就必须自己算每帧的线段插值工作量和复杂度成倍上升。如果拿视频模板对比差距更明显。AE 和 Pr 的模板本质上是人工配置的产物改一处逻辑就要重新拖拽素材、调整关键帧。SVG 是纯文本代码可以放进 Git 做版本管理每一次改动都有记录可以 diff、可以回滚、可以多人协作。对内容团队来说这等于把做视频变成了写代码整个流程都可以纳入工程化管理。2.3 整体数据流的四个阶段整个 skill 的运行过程我把它分成四个阶段文案拆解把输入的口播文案切分成一个个视觉焦点规划场景顺序、旁白时间和画面切换点。构图生成为每个视觉焦点生成 SVG 绘图指令包括图形类型、位置、路径、线宽、颜色和绘制时长。时间轴编排把所有元素的绘制起点、绘制时长、暂停时长、擦除时机编排成一条连续的时间轴。逐帧渲染合成按时间轴逐帧绘制 SVG 快照再用 ffmpeg 把 PNG 序列合成带旁白的视频。这四个阶段互相独立意味着你可以单独替换任何一环。比如文案拆解做得不够好可以换更强的语言模型渲染速度慢可以优化 renderer 的截图效率风格不满意可以换一套颜色系统和笔触模拟参数。每部分都能单独演进这也是工程化架构的好处。3. 核心机制详解笔迹、路径与时间如何配合3.1 模拟真实手写感的基础原理白板视频如果只是让线条匀速画出来观感会非常僵硬。真实人手写字是有加速度变化的起笔时慢中间加快收笔时又慢下来有时还有轻微的抖动和笔锋。代码要模拟这种感觉就必须控制绘制进度与时间之间不是线性关系。具体到实现层就是用 easing 函数来修正某一时刻的绘制进度。举个例子路径总长是 1000 像素绘制时长是 2 秒线性进度是每秒 500 像素。但真实笔迹应该用 easeInOut 曲线让前 10% 的时间只画 3% 的路径中间 50% 的时间完成 80% 的路径最后 20% 的时间收尾。这样看起来就像有人真的在画而不是有一条线自己被拉了出来。我常用的一个参数组合大概是这样的前 5% 的路径 - 耗时 10% 总时长加速度从 0 缓慢增加 中间 70% 路径 - 耗时 55% 总时长保持较高速度 剩余 25% 路径 - 耗时 35% 总时长逐渐减速至 0这个比例不是什么标准答案但它解决了匀速绘制最大的问题——假。你不需要精确还原每只手的手感只要让观感上这笔画得真像回事就够了。实际测试下来90% 的观众根本不会盯着看每一笔的速度曲线他们只会感知到整体流畅或整体机械。适当地加入极轻微的抖动甚至能让画面更有手绘味。3.2 如何计算每一条路径的绘制时长路径有长有短最短的一笔可能只有几十像素最长的一笔可能有上千像素。如果给它们分配相同的绘制时长短的会快得像闪过去长的会慢得让人着急。所以绘制时长必须跟路径长度和内容重要性挂钩。我的做法是默认基础速度是每秒 120 像素然后根据元素类型做加权。文字类的比图形类的稍微快一点因为观众需要快速读完装饰类的比主体类的慢一些因为它是氛围补充。权重系数并不复杂但这套逻辑放在schema.json里让 AI 生成指令时参考出错的概率会小很多。另外需要设置一个最短绘制时长和最长绘制时长的夹取范围。即使一个句号那么小的圆也要画 0.3 秒以上否则看起来就像闪了一下即使再长的复杂路径也不要超过 4 秒否则观众会失去耐心。这样限制之后渲染出来的动画节奏基本都在合理区间。3.3 笔锋、停顿和擦除带来的节奏感白板视频好不好看除了线条流畅程度还取决于节奏。真实讲解时讲到重点会在画面上停留一会儿让观众消化换场景时会把前面画的内容擦掉腾出新空间。这些阶段都需要在时间轴上明确编排。画完一个元素之后我通常会预留 0.5 到 0.8 秒的停顿模拟讲解者的自然换气。碰到重点强调的内容停顿时间会拉到 1.5 秒。擦除动作则用反向的 dashoffset 动画实现速度比绘制快 1.5 倍因为擦除时的手势通常更快视觉上也更有翻篇的感觉。整套节奏跑通后视频会形成画一笔——停顿——再画一笔——整屏擦除——进入下一场景的循环观感非常接近真实的白板讲解。有一个细节值得专门提醒旁白和画面的同步误差必须在 0.3 秒以内。人眼对音画不同步的容忍度很低一旦超过这个阈值就会明显觉得画面和声音对不上。所以我渲染完视频之后一定会做一次对齐检查如果画面进度比旁白快就在时间轴上插入更大的空白帧而不是去拖动音轨。4. 实操全过程从文案到成片的具体实现4.1 定义 skill 的输入输出协议我把 skill 的输入定义为三个部分口播文案必填、视觉风格参数可选、画布尺寸可选默认 1920x1080。输出是三个产物绘图指令 JSON、逐帧 PNG 序列、合成之后的 MP4 视频。协议里的 JSON 结构是核心它决定了后续能不能稳定渲染我直接贴出精简版 schema 供参考{ canvas: {width: 1920, height: 1080, bg: #FFFFFF}, scenes: [ { id: scene_1, duration: 8.0, elements: [ { type: path, id: line_1, d: M120,540 C180,480 220,600 300,520, stroke: #2C3E50, strokeWidth: 6, drawStart: 0.5, drawDuration: 1.2, easing: easeInOut, zIndex: 1 }, { type: text, id: text_1, content: 核心原理, x: 420, y: 520, fontSize: 48, fontWeight: 700, drawStart: 2.0, drawDuration: 1.5, easing: easeOut, zIndex: 2 } ] } ] }这套结构里每个元素都有独立的drawStart和drawDuration编排时可以精确到 0.1 秒。这里建议画布尺寸一定设置偶数分辨率因为ffmpeg合成时奇数宽高会导致编码器报错这个坑我踩过好几次。4.2 提示词设计如何让 AI 稳定输出绘图指令最开始我把生成 SVG 的任务直接丢给大模型输出内容五花八门有的模型喜欢把所有图形塞进一个path有的喜欢用rect和circle混排还有的会在d属性里写错坐标。后来我把任务拆成两步稳定度明显提升。第一步让 AI 把文案拆解成场景分镜表只输出描述性内容比如场景一画一个水杯旁白讲水的形态变化。第二步再让 AI 根据分镜表生成具体的绘图指令 JSON并且严格告诉它每个图形必须有独立id路径数据必须精简到控制点数量合理drawStart必须和旁白句子的起始时间对应。最重要的是要求先列出所有元素清单再填入坐标和时间参数这种先规划后填充的思维能显著降低 AI 的错误率。我在 prompt 里还加了一条硬性约束所有路径只能是连续的禁止用多个子路径拼成一个复杂形状。这主要是为了笔迹动画的准确性。一个复杂图形如果用断开的路径拼起来逐笔绘制时观众会看到明显的跳跃很破坏手绘感。如果画面需要复杂形状我宁可让它多画几笔让 AI 把形状分解成多个有重叠关系的子图元。4.3 从 SVG 到视频帧的渲染管线绘图指令 JSON 生成之后真正的渲染环节我建议用 Puppeteer 做因为它能在无头浏览器里精确回放 SVG 动画并逐帧截图。整体流程是这样的加载 SVG - 应用时间轴动画 - 每 1/30 秒截一张 PNG - 全部输出核心的动画控制代码用requestAnimationFrame配合strokeDashoffset修改。每一帧更新所有激活元素的绘制进度然后调用截图接口保存当前画面。用 Puppeteer 的好处是可以直接复用浏览器的排版引擎文字渲染效果和浏览器一致不需要额外维护字体库。如果渲染时长过长可以考虑一个优化技巧先按 1280x720 输出预览序列确认整体节奏和构图没问题后再用最终版 prompt 重新渲染 1920x1080。因为视觉调整阶段不需要高清素材先跑快速预演能省掉大量时间。我自己的流程里预演渲染速度大约是最终版的 3 倍用 5120 字以上的脚本测试时效率提升非常明显。4.4 ffmpeg 合成音视频的最终封装帧序列渲染好之后最后一步是合成。把 PNG 序列编码成视频再合并旁白音频用 ffmpeg 一条命令就能搞定ffmpeg -framerate 30 -i frames/%04d.png -i audio.mp3 \ -c:v libx264 -pix_fmt yuv420p -c:a aac -shortest \ -crf 18 -preset slow whiteboard_video.mp4这里-crf 18是视觉无损级别的质量参数-preset slow会显著提升压缩效率但时间会长一些。如果你只做网络传播-crf 23搭配preset medium就够了体积和画质的平衡更好。注意-shortest参数它能让视频和音频长度对齐避免其中一方过长或过短。合成之后我还有一个习惯动作抽帧检查首尾和中间三个时间点确认画面和旁白内容对得上。这个检查 30 秒就能完成但能避免大多数翻车事故。如果旁白没有提前录好我会先用文本转语音合成一条临时音轨用来对齐时间轴最后再替换成正式配音。5. 常见问题与排查技巧实录5.1 笔顺乱掉整段视频像多支笔同时乱画这个问题最早困扰了我很久。排查下来根源几乎都是drawStart参数排布不合理。AI 生成的元素列表如果顺序和画面呈现顺序不一致渲染时就会出现后面该先画的元素反而先出现。解决方法是加一道排序校验在绘图指令生成后按照所有元素的drawStart排序并检查是否和用户视角的从左到右、从上到下一致。如果不一致直接重跑生成或手动调换drawStart。另外还有一种情况是多个元素重叠导致视觉顺序异常。比如一个圆环上加一个圆心点如果圆心点先画完但圆环还在绘制中观众会看到先出现一个孤零零的点很突兀。这类问题需要在元素层面设置zIndex并且通常核心图形的骨架部分要先画装饰部分后画。我在 schema 里增加 zIndex 字段之后这个问题基本彻底解决了。5.2 画线速度时快时慢看起来很不自然造成这个问题的原因一般有两个一是路径长度和绘制时长严重不匹配短路径被分配了过长的时长长路径被分配了过短的时长二是 easing 曲线选择不合理导致整段路径的前半段几乎不动后半段又突然加速。前者的排查方式很直接把路径长度和时长打印出来看比例异常的单独修正。后者则需要对比不同 easing 函数下的表现我个人经验是不要所有元素都用easeInOut官方讲解视频里的装饰性图标用linear反而更干净利落文字主体再用easeOut模拟手写落笔的感觉节奏会更有层次。还有一个细节容易忽略d属性里如果包含大量冗余节点绘制时速度曲线会出现肉眼可见的卡一下。这个问题在北路路径尤其明显。按我后来优化后的方案路径点之间的间隔尽量控制在 2 到 8 像素范围内太密了曲线平滑但计算量增大太疏了会看到明显折角。这个经验值在 1280 宽的视频里亲测有效如果是 4K 输出需要适当增加节点密度。5.3 AI 生成的 SVG 不满足渲染要求最常见的失败模式是坐标超出画布边界、颜色值不符合十六进制格式、路径缺少闭合或者该用贝塞尔曲线的地方用了大量直线段。我用一个自动校验脚本来拦截这类问题它检查每个元素的边界框是否在画布范围内、检查d属性能否被解析、检查颜色格式是否为#RRGGBB。凡是校验不通过的直接把错误信息回传给模型要求重新生成最多重试两次如果还不通过就把这个元素从场景中剔除并标记为待人工处理。这里有一个值得养成的习惯在 schema 里明确定义必填字段列表并在校验时逐项检查。比如d、stroke、drawStart是必填的opacity和rotation是可选的。如果模型漏掉了必填项校验脚本能在第一时间发现而不是等渲染完了才发现画面空了一大块。这类问题解决后我整个管线的成功率从 70% 提升到了 95% 左右。5.4 长视频渲染慢到不可接受一个 5 分钟的视频如果逐帧截图大约需要 9000 张图。Puppeteer 逐张截图的速度虽然不慢但频繁的页面操作会导致内存增长最终让渲染越来越慢甚至卡死。我的解决方案是分批渲染把时间轴切分成多个段落每个段落单独渲染 500 帧左右最后用 ffmpeg 把所有片段按顺序拼接。这样内存占用稳定渲染速度几乎可以保持恒定。还有一个更高效率的思路如果视频里大部分内容是静止的比如一个复杂的图表画完之后停留了 20 秒那么不必每秒 30 帧地输出全过程可以先把连续动画部分渲染成 30 帧每秒的序列静止部分用一张图生成时长对应的重复帧。或者更粗暴一点动画部分只渲染完整帧静止部分用 ffmpeg 的-loop 1参数来延展。这个方法在输出超长讲解视频时几乎必用能在不损失画质的前提下把渲染时间缩短 40% 以上。6. 实战中总结的经验与后续扩展方向这套 skill 从最初的手工脚本演进到现在的 AI 可调用模块中间经历了无数轮迭代技术上的心得可以写很长但最值得分享的是三个认知层面的体会。第一个体会代码画视频的难点不在画图而在编排。画面好不好看取决于路径数据但视频像不像真人讲解取决于时间轴、停顿节奏和动作顺序。我后来把 40% 的精力都花在调时间轴上画图本身反而简单。如果你的 AI 生成的视频看起来不够像一个真人画的优先检查每个元素之间的停顿和重叠时间而不是路径平滑度。第二个体会schema 设计决定 AI 协作的上限。最开始我试图让 AI 自由发挥最后收到的是大量不可用的数据。后来我狠心把 schema 的每个字段都做了硬性约束AI 的输出反而稳定了。这就像一个清晰的任务清单给员工分配任务边界越清晰执行越到位。第三个体会这个 skill 的扩展空间非常大。我目前正在做的方向包括把静态图形升级为带分层着色的复杂示意图把笔迹模拟从单一黑色细笔扩展到彩色马克笔甚至粉笔质感把单场景解说升级成多镜头切换的白板演示视频。后续完全可以接入语义理解让 AI 根据讲解内容的逻辑关系自动选择图形布局那就从画出来进化到设计出来了。这套思路不仅适用于白板视频任何需要逐笔呈现过程感的画面都可以复用——流程图、手绘风格数据可视化、教学板书动画本质上是同一套代码架构。如果你们正准备做内容自动化工具建议先拿白板视频练手因为它元素简单、流程清晰、反馈直接是最容易做出成果的入门方向。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑