做白板视频这件事过去我一直觉得很“重”。要么开个几百块的付费工具要么用AE一帧一帧K动画最后出来的效果还容易撞车。所以我干脆动手做了一个skill——一个可以让AI Agent按我的命令用代码逐笔画出白板动画的技能包。现在这条视频里每一笔运动轨迹都是SVG路径动画跑出来的没有手动K过任何关键帧。这篇文章我把整个思路、原理、代码和踩过的坑完整拆开想自建这套流程的人可以直接抄作业。先介绍一下这个skill到底做了什么你给它一段文案它会自动把文案拆成几个白板场景每个场景生成对应的SVG图形然后通过路径动画让图形按照“手绘”顺序出现在画布上最后渲染成视频。整个过程从图形到动画再到视频文件没有一个人工手绘步骤完全由代码驱动。适合独立开发者、内容创作者以及那些想把AI Agent用到实际生产链路里的人。1. 为什么我要用代码“画”白板视频1.1 白板视频的痛做内容的人应该都懂白板动画视频whiteboard animation在知识科普、课程讲解、产品介绍里出镜率极高但真做起来处处是坑。市面上的主流方案无非这几种用VideoScribe这类白板动画工具、买AE模板改、或者用手绘板配录屏软件一帧帧画。这些方案我基本都试过。VideoScribe类的工具确实上手快但素材库就那几百个图标风格也一眼就能被认出来AE模板改起来不灵活换一个图形就要重新调一遍动画曲线手绘板录屏虽然质感最好但画一个成片10分钟的视频我这样的非美术专业选手至少要折腾一晚上中间错一笔就得重来。这背后其实是一个老问题白板视频的核心不是“画”而是“把文案转成分镜再把分镜画出来”。前者需要理解能力后者需要执行稳定性。人来做累旧工具做模板化。所以我一直在想能不能把“理解”交给AI把“绘制”交给代码让两者无缝接起来。1.2 让AI Agent学会“画视频”Skill是什么先说结论这个skill并不是一个新软件而是一套给AI Agent使用的“技能包”。你可以把Agent理解成一个新来的实习生能力很强但不知道自己该用什么流程干活skill就是你把一套标准作业流程、工具脚本、注意事项写到一张纸上他照着这张纸就能稳定产出。具体到AI Agent的skill生态里它通常是一个目录里面有一份SKILL.md作为入口说明配几个可执行脚本或者提示模板。当Agent被触发到相关任务时它会先读SKILL.md了解这个技能是干什么的、先做哪一步再做哪一步然后调用配套脚本去执行。为什么我要用这种方式做视频而不是让AI直接生成视频因为现在的大模型对“视频级”的画面控制能力还很弱你让AI画一幅图可以但让它保证连续几秒里每个画面的元素位置一致、顺序一致几乎做不到。而SVG是结构化数据路径、位置、层级全部可编程AI生成SVG的准确率要高得多。所以这个skill的设计思路很明确AI只负责理解需求并生成SVG场景代码负责把SVG变成逐笔动画再渲染成视频。各干各擅长的事结果稳定还省Token。1.3 一套方案的整体流程整个白板视频生成链路我自己跑顺之后是这么走的第一步文案输入。可以是一段讲解词也可以是几个关键词。第二步AI根据SKILL.md里的分镜规则把文案拆成N个场景每个场景对应一个白板画面。第三步AI输出每个场景的SVG代码并给每条path标注绘制顺序、耗时、停顿时间。第四步一个HTML模板读取SVG用路径动画模拟手绘笔画。第五步Playwright无头浏览器逐帧截图。第六步FFmpeg把帧序列合成MP4或者直接输出GIF。这套流程里最出效果的部分其实是第三步到第四步之间的衔接。AI生成的SVG质量直接决定动画的手绘感。我在SKILL.md里花了很大篇幅去约束AI怎么组织SVG先画外轮廓再画内部细节先画主体再画装饰每一条线的起笔方向也要考虑到不能出现“画到一半跳线”的违和感。2. 白板视频的核心原理SVG路径动画是怎么让笔画动起来的2.1 为什么选SVG而不是其他方案我在早期调研时其实先考虑过Lottie也试过Canvas逐帧手写动画。Lottie的动画能力很强但它的素材来源是AE插件导出的JSON不符合“AI直接生成”的场景Canvas手写虽然灵活但AI生成代码的出错率会明显上升随便一个坐标算错整条线就飞了。SVG的好处在于它天生就是为矢量图形准备的。AI擅长生成结构化的XML节点一条path就是一个笔画d这个属性里带着完整的坐标轨迹浏览器对SVG有原生支持绘制、缩放、动画都不需要额外依赖。更关键的是SVG里的每一条路径都有长度值这个长度值是做笔画动画的关键。2.2 stroke-dasharray把“线”变成“画出来的线”白板动画的核心技术其实只用了SVG的路径描边属性。这个原理我在第一次跑通的时候觉得挺妙的但讲清楚也就一句话让一条线“看起来像被画出来”本质上是在控制这条线的可见长度。假设有一条线它本身有100个单位的长度。我先把它设置为一段虚线虚线的每段长度设置成100、间隙也设置成100那么屏幕上就只能看到线头那一小段被画出来的痕迹再让这段虚线向右偏移stroke-dashoffset偏移量为100时第一段虚线段正好完全移出视野范围整条线看起来就是“出现”了。实操里更常用的做法是从stroke-dashoffset等于线条总长度开始慢慢把它减到0线条就会从头到尾逐渐显示出来跟手绘的观感几乎一样。这里的关键代码非常短但原理值得多花点笔墨。SVG原生提供了getTotalLength()方法JS里调一下就能拿到任意路径的总长度值不需要你去算贝塞尔曲线的周长const path document.getElementById(line1); const length path.getTotalLength(); path.style.strokeDasharray length; path.style.strokeDashoffset length;设置好初始状态之后你只需要改变strokeDashoffset的值再加上CSS过渡或者requestAnimationFrame条线就会平滑地“画”出来。用学画画的类比就是你手里有一根被窗帘遮住的绳子慢慢拉开窗帘的过程绳子就一段一段露出来了。这个窗帘拉开的速度、停顿的节奏就是手绘感的第一层来源。2.3 多笔画的时间线控制单线条动画很简单但白板视频里一个画面往往有十几条甚至几十条path。这时候最大的问题就变成了调度先画哪条、后画哪条、每条画多久、笔画之间停多久。我的做法是在SVG里给每条path加上两个自定义属性data-order表示绘制顺序data-duration表示这条线的绘制时长秒。AI生成SVG的时候会严格按照画面逻辑来排这两个值。加载动画的时候脚本扫描所有带data-order的path按顺序给它们设置初始dashoffset然后用setTimeout依次触发过渡效果。每条线之间留一个0.2到0.5秒的空隙视频看起来就有真人画画时那种“想一想再下笔”的节奏感。一个典型场景的时序长这样svg viewBox0 0 1280 720 xmlnshttp://www.w3.org/2000/svg path dM300,500 C400,350 500,350 600,500 >ffmpeg -y -framerate 30 -i frames/frame_%05d.png -c:v libx264 -pix_fmt yuv420p -crf 18 output.mp4-pix_fmt yuv420p是兼容性关键不加这个参数视频在不少播放器和剪辑软件里会花屏-crf 18是用高质量画质档位如果视频要发到网上被平台二次压缩建议保持这个值。3. 手把手做一个“白板视频生成Skill”3.1 Skill的目录结构与SKILL.md写法起步第一件事是把Skill的目录结构搭好。我这里用的是AI Agent社区里比较通用的一种组织形式whiteboard-video-skill/ ├── SKILL.md ├── scripts/ │ ├── svg_to_html.py │ ├── capture.py │ └── render_video.sh └── templates/ ├── board_template.html └── scene_examples/SKILL.md是整个sbill的大脑。它的前面有一段YAML格式的frontmatter用来声明这个skill的名字和触发描述。这段描述我吃过很大亏刚开始写得太泛AI碰到什么任务都想调用它反而拖慢主流程。后来我把描述改成了“仅当用户需要制作白板动画视频或手绘风格演示视频时使用”触发准确率立刻上来了。SKILL.md的正文部分我每次都会重点强调三件事分镜规则、SVG输出规范、渲染命令用法。分镜规则告诉AI怎么把文案切成场景SVG输出规范里写明必须给每个path标注data-order和data-duration并且按“外轮廓优先、细节靠后”的顺序输出节点渲染命令则告诉AI最后调哪个脚本把HTML渲染成视频。写SKILL.md的一个心得这件事不要去追求辞藻直接把“怎么做”一条条写清楚。AI不是人它不会意会只有白纸黑字的操作步骤才能真正约束它的行为。写得越机械产出越稳。3.2 核心脚本把SVG变成逐笔动画页面AI生成好SVG之后需要一个桥梁把这些节点变成可播放动画的HTML页面。这个桥梁我用一个简单的Python脚本实现职责单一读入SVG文件把里面的path、circle、rect等图形标签原样保留然后注入到HTML模板中再补充一段动画控制脚本。模板里最关键的是动画调度逻辑。我的做法是在页面加载时收集所有带data-order的节点根据order排序然后依次执行“把线缩短”、“停顿”、“露出”这个循环。实现上我用的是requestAnimationFrame配合Promise而不是setTimeout这样多个笔画之间的衔接更精确也不容易被其他任务阻塞。!DOCTYPE html html head style body { margin: 0; background: #faf8f2; display: flex; justify-content: center; align-items: center; height: 100vh; } svg { width: 80vw; height: auto; background: #fff; box-shadow: 0 4px 24px rgba(0,0,0,0.08); } path, circle, rect, ellipse { fill: none; stroke: #2b2b2b; stroke-linecap: round; stroke-linejoin: round; } /style /head body svg idboard viewBox0 0 1280 720 xmlnshttp://www.w3.org/2000/svg !-- SVG内容由脚本注入 -- /svg script function animateBoard(svgEl) { const drawables svgEl.querySelectorAll([data-order]); const items Array.from(drawables).sort((a, b) (a.dataset.order) - (b.dataset.order)); let chain Promise.resolve(); const totalDelay parseFloat(document.body.dataset.totalDelay || 0.6); items.forEach((el, i) { const len el.getTotalLength(); el.style.strokeDasharray len; el.style.strokeDashoffset len; const duration parseFloat(el.dataset.duration || 1); const gap i items.length - 1 ? 0 : totalDelay; chain chain.then(() new Promise(resolve { requestAnimationFrame(() { el.style.transition stroke-dashoffset ${duration}s ease-in-out; el.style.strokeDashoffset 0; setTimeout(resolve, duration * 1000 gap * 1000); }); })); }); return chain; } window.__animPromise animateBoard(document.getElementById(board)); /script /body /html画一个关键细节动画结束后的停顿会让末尾一个图形保持完整但如果你希望画面最终呈现为“勾勒完的成品图”记得不要把ease-in-out加在最后一笔上否则最后那段会拖出假手感的减速。动起来之后我还会在页面留一个全局对象供外部调用把动画推进到一个指定进度。比如我需要截第120帧就调用那个全局函数把动画跳转到4秒的位置。为了保证跳转稳定我直接用循环扫描的方式推进每一条path的dashoffset而不是依赖过渡事件。3.3 渲染脚本Playwright截帧 FFmpeg合成动画页面准备好之后就可以用Playwright把画面变成视频帧了。这个过程我只用了大概50行Python代码核心逻辑分三步启动浏览器、加载本地HTML文件、循环截帧。这里有一个重要的约束本地文件路径在Windows和macOS下的写法和无头浏览器里的兼容性不一样。为确保在服务器上也能跑我全部用file://协议并做了一次路径规范化避免反斜杠带来的麻烦。我的截帧脚本骨架大致长这样import asyncio from pathlib import Path from playwright.async_api import async_playwright async def capture_frames(html_path: str, total_seconds: float, fps: int 30, out_dir: str frames): html_path Path(html_path).resolve().as_uri() out_dir Path(out_dir) out_dir.mkdir(exist_okTrue) total_frames int(total_seconds * fps) async with async_playwright() as p: browser await p.chromium.launch(args[--headlessnew]) page await browser.new_page(viewport{width: 1280, height: 720}) await page.goto(html_path) await page.wait_for_selector(#board) for frame_index in range(total_frames): progress frame_index / (total_frames - 1) await page.evaluate(fwindow.__seek({progress})) await page.screenshot( pathf{out_dir}/frame_{frame_index:05d}.png, clip{x: 0, y: 0, width: 1280, height: 720} ) await browser.close() if __name__ __main__: asyncio.run(capture_frames(rendered_animation.html, total_seconds8, fps30))窗口里对应那个__seek函数就是模板里暴露出来的跳转入口。它接收0到1之间的数值把动画推进到对应位置。我实现的时候用的是基于总时长的比例换算避开了复杂的动画暂停机制速度也快。帧截完了最后用FFmpeg一秒钟合成就搞定。整个过程如果你只做一个10秒场景从AI输出SVG到得到MP4大概1分钟出头比手工画完再录屏压视频快上十几倍不止。3.4 让AI自动完成“从文案到动画”处理好底层渲染之后真正的提效点在“让AI自动完成分镜设计”。这部分是SKILL.md里我花最多心思的地方。我给了AI一套很明确的分镜模板它读完文案就会按这个模板输出SVG场景列表。一个直观的例子我给AI的提示长这样节选你是一个白板动画分镜师。任务将给定文案拆分为不超过5个场景。 对每个场景输出 1. scene_summary: 一句话说明画面内容 2. svg_content: 一个SVGviewBox固定为1280x720包含该场景所有图形节点 3. draw_notes: 简要说明该场景为什么采用当前绘制顺序 规则 - 所有图形必须带data-order从1递增和data-duration范围0.6-1.8秒 - 外轮廓先画内部细节后画 - 同一语义组的线条顺序相邻 - 不要使用fill填充除非该图形需要表现色块跑一轮测试的时候我会让AI生成一个“灯泡在黑板前亮起”的小场景。它生成的SVG里会先画黑板外框再画灯泡外轮廓、灯丝最后把灯泡点亮填充淡黄色。这些信息输出完后渲染脚本自动运行一条完整的白板视频就出来了。整个过程我的参与度很低基本上只负责审核画面逻辑和最后调一下调速参数。从实际测试来看AI生成的分镜能力比我预期好不少。它确实会偶尔把路径画歪但九成情况下逻辑是通顺的手工微调的成本远低于从零开始做动画。4. 踩坑记录与效果调优实录4.1 常见问题速查表开发这个skill的过程中我遇到的大坑小坑能写一本小册子。先上一张速查表给想直接入坑的人提个醒现象原因解决办法画笔在画面里突然跳位SVG里有多个子路径共用一个path节点dashoffset对整条路径生效拆成多个path每个子路径一条线动画速度忽快忽慢给不同path设置了不同的duration但总时间太长统一基于场景总时长反算每笔duration截图边缘发虚浏览器缩放了页面固定viewport尺寸不要依赖CSS缩放中文文字完全消失或显示为方块无头浏览器里没有中文字体服务器安装fonts-noto-cjk或用图片代替文字合成视频体积太大帧数太多且CRF太低frame率降到24CRF提到近20或输出前加一次压缩动画不会爬到最后完整画面最后一条path的dashoffset没有归零动画结束时强制将所有路径dashoffset设为0这些问题的共性其实在于SVG的渲染行为和你脑中“一条线”的直觉并不完全一致。多路径、填充规则、描边宽度的叠加效果只有跑一遍真实动画才会暴露。所以别怕出问题把问题当成调试素材就好。4.2 让人一眼“手绘感”的微调技巧要让白板动画不显得“塑料”核心在于笔画的速度曲线和停顿节奏。市面上大部分工具都是全程匀速看着就很机械。我用ease-in-out做默认曲线这样一笔画从慢到快再变慢很像人手“落笔重、中间快、收笔缓”的用力习惯。另一个容易被忽视的点是画线方向。人的手在画一条从左到右的线时很自然地会带一点上弧直接怼出一条直线会很不真实。不过这属于SVG路径设计层面的事AI生成的路径往往比较直白我现在的处理方法是在SKILL.md里明确要求AI给非直线元素加少量控制点曲线二次贝塞尔弯一点点就行效果立竿见影。还有一个小经验真正的手绘是有轻微抖动的。完全平滑的路径反而假。在写模板时我给所有path加了一个很轻的filter用feTurbulence做一点微抖动偏移让线条看起来像是手画而不是打印机打出来的。幅度不能大否则会糊。4.3 性能与工程化优化刚开始做这个方案时渲染一个30秒视频光截帧就要好几分钟因为这个过程本质上是CPU渲染加磁盘写文件。我后来做了两个优化速度提升非常明显。第一个优化是降帧率。白板手绘动画其实不需要60fps24fps就够30fps是上限。帧数少三分之一渲染时间直接少三分之一。第二个优化是分场景渲染再拼接SVG场景多的时候不要试图在同一个HTML页面上渲染所有场景的动画那样页面会越来越大截帧速度指数级下降。按场景编号分别渲染出片段最后用FFmpeg把所有片段拼成一条完整视频顺畅很多。还有一个工程化层面的建议就是把SVG生成和动画渲染分离成两个独立步骤中间用文件作为接口。AI先产出所有场景的SVG文件人审一遍确认细节没有大问题再触发渲染。这样一旦AI画得不好你不需要重跑整条动画链路。4.4 从“能跑”到“好用”的扩展当这条链路稳定跑通之后我顺手加了两个很实用的扩展整个方案的生产力又上了一个台阶。第一个是接入TTS配音。我用SVG场景的分镜时长作为参考把文案逐段切片对应到TTS生成的音频然后再用FFmpeg把音频和视频拼到一起。这样出来的视频已经能直接用作课程讲解了。同步对齐的做法不复杂就是每个场景时长和对应音频时长做一次线性缩放误差控制在几百毫秒内白板动画对同步的容错度很高。第二个是批量生成。我把分镜结构抽成了一个JSON SchemaAI一次可以生成多个视频的SVG分镜包渲染时用脚本一个个跑配合一个简单的本地任务队列整套手搓的小型“视频工厂”就成型了。我现在日常做公众号配图和短视频素材基本就是往这个skill里丢一个关键词过几分钟就有成品。最后分享一个我实操中的体会这套skill我前后迭代了快一个月。刚开始总执着于让AI一次就把所有画面画完美后来发现完全没必要。真正稳的做法是给AI喂一个常用的SVG场景素材模板库让它基于库里已有图形做组合和微调而不是从零去画。库里准备一些像灯泡、书本、箭头、人物轮廓、对话气泡这类高频元素成功率会大幅提升。毕竟这个时代能跑通的功能永远不是最大的瓶颈把体验做到“像人画出来的”才是最有价值的那部分功夫。