企业官网建设流程全解析

我在做视频这条路上绕了不少弯。前阵子有朋友看了我分享的AI绘画工作流，跑来问能不能做那种“一支笔在白板上写字画画、边讲边出现”的短视频。他说得简单，但我清楚这东西的坑有多深——市面上大部分白板视频都是录屏加剪辑出来的，画错一笔就得重录，字幕和图形对不齐更是家常便饭。后来我干脆把这个需求拆成了一套skill，交给AI去执行，核心就一句话：白板视频里的每一笔，都是代码画的。这里的skill不是指某个单一插件，而是一套把“文案拆解、分镜规划、SVG图形生成、笔画动画计算、视频渲染”全部串起来的自动化流程。这篇文章就聊聊我是怎么把这条流水线跑通的，以及你照着做时最容易踩的五个坑。

1. 这个skill到底解决了什么问题

1.1 传统白板视频制作有多痛苦

先说说没有skill之前，我是怎么被白板视频折腾的。最早我用真实的白色桌面加俯拍镜头录制，手持马克笔一笔一划写，一个两分钟的视频要录两个小时。笔迹出了画面就得重来，抬头看提词器会穿帮，录音和画面不同步更是常事。后来改用录屏软件加鼠标手绘，稍微好一点，但鼠标画出来的线条歪歪扭扭，观感很差——这种视频放到知识科普、企业培训这类场景里，观众一眼就能看出粗糙。

再后来有人推荐用动画软件做。白板动画在After Effects里叫Trim Paths，用起来也不省心：每一条路径都要手动添加修剪属性，K帧要一帧帧调，改一个文字就得重新对齐时间轴。一次做五六个分镜基本就要加班到深夜。最让我崩溃的是，客户中途要求把某个图形的颜色从黑色换成蓝色，我花了半小时把所有图层逐个改了一遍，最后发现其中一个路径忘了选，成品里就混进一段黑线。

这个痛点其实很普遍：白板视频的核心不是“画得好”，而是“流程可控”。只要流程是手工的，就永远面临改稿灾难。当时我就在想，如果能把“一支笔画出来的过程”变成一串可编辑的数据，改颜色、改顺序、改时长都是改参数的事，那该多省心。这就是我把白板视频做成skill的出发点。

1.2 “每一笔都是代码画的”意味着什么

标题里“每一笔都是代码画的”这句话，在实操层面指的是：画面中的每一条线、每一个图形、每一段文字，都以SVG路径的形式存在，路径的起点、终点、弯曲程度、描边宽度全部由数据描述。动画阶段，系统根据路径长度计算“画笔”的运动速度，逐帧控制线条的可见长度，最终渲染出一个连续的视频。

这里有个关键点：代码画和手工画有着本质区别。手工画是模拟信号，画完之后只留下结果，过程不可逆；代码画是数字信号，既是结果又是过程。你可以随时让某条线从画面上消失，也可以单独把某个图形放大缩小，还可以让完全相同的动画在一百个视频里重复使用。这种可复用性，正好弥补了普通视频制作里最昂贵的那部分成本——返工成本。

另外，代码画还有一个隐蔽优势：它天生自带“生成逻辑”。文案里提到的概念、数据、结构，可以直接映射成对应的图形代码。比如文案里讲“增长曲线”，你就能在脚本里生成一条指数曲线的SVG路径；讲“时间轴”，就能生成一条带箭头的横线。整个过程一套流程跑完，不需要设计师手工绘制，效率和一致性都碾压传统方式。

1.3 这个skill适合谁

我做完这套skill之后，回头复盘了一下适用人群，大致有三类。

第一类是知识科普类博主，他们需要高频产出图解视频，用这套流程可以把“选题-文稿-成片”压缩到半小时以内。第二类是培训师和企业内部内容团队，经常要做课程讲解、产品说明类的视频，改稿需求多，代码画的方式能让他们在演示前30分钟还来得及改样式。第三类是AI工具玩家和技术从业者，他们可能对SVG、Python、FFmpeg本身就有基础，把skill当成一个学习样本，可以改造成属于自己的视频自动化工坊。

当然，如果你只是偶尔做一条视频，或者设计技术底子比较薄，这套方案开始会有一些学习成本。但哪怕你只在本地跑通最小的demo——让一条SVG线条从无到有地成长为一幅简笔画——你也会对“代码驱动视频”这件事上瘾，因为改方案的效率实在太爽了。

2. 白板视频skill的整体设计思路

2.1 skill的本质：把AIGC流程固化成流水线

先说清楚“skill”在我这里的定义。它不是一个程序文件，也不是一个严格的算法框架，我把它理解为一套“告诉AI该怎么按顺序干活”的约束规则集合。你把脚本文案丢给这个skill，它会按既定步骤来：第一步拆文案，提取核心表达；第二步画分镜草稿，确定每个镜头里的视觉元素；第三步生成SVG文件，并给每个元素配好书写顺序；第四步计算结果并用渲染工具合成视频。每一步的输出恰好是下一步的输入，中间不需要人反复干预。

这种设计思路其实借鉴了工厂流水线。在没有流水线之前，一个工人要完成从原料到成品的所有工序，效率低且品质不稳定；有了流水线，每个工位只干一件事，接口标准清晰，瓶颈一眼就能看到。Skill的价值也一样，把“创意”和“执行”拆开：AI负责创意层面的脚本拆解与画面设计，你只负责检查、调参、审核，枯燥的重复劳动全部交给代码。

2.2 为什么用SVG而不是逐帧手绘或Canvas画布

选SVG作为“画每一笔”的载体，是我踩了几次坑之后才确定的方案。

最开始我试过纯Canvas手绘：在JavaScript里写一个画笔移动函数，按时间把线条画在画布上，然后录屏导出。听起来挺顺，但有两个致命问题。一是每一条线的轨迹都得用代码维护大量坐标点，数据冗长且不好读；二是Canvas没有原生的“路径长度”概念，你得自己积分算长度才能做匀速动画，这个计算在复杂图形上误差很大。

后来我又尝试过用After Effects手动做Trim Paths，效果倒是很接近白板笔触，但前面我说了，它不适合批量化和改稿。

最终选了SVG，原因很实在。首先，SVG的path元素本来就是为“路径”而生的，d属性里用M、L、C、Q这些命令能描述任意复杂曲线，人类可以直接编辑。其次，SVG节点的getTotalLength()方法能够精确获得路径的总长度，这个值是做描边动画的锚点。再次，SVG可以被浏览器原生解析，用Playwright这类工具就能把动画逐帧截出来，不需要安装任何专业动画软件。总结起来就一句话：SVG既适合人读懂，也适合程序计算，天生兼容两套宇宙。

2.3 整体流程：文案到分镜到动画到成片

这套skill的整体流程，我一般拆成五个环节。

第一环是“拆文案”。把输入的长文本切分成3到8个主题块，每个主题块对应一个分镜。分镜数量是可控的：太少会显得视频空洞，太多会让制作时间成倍增长，我通常建议3分钟视频对应5到6个分镜。

第二环是“画分镜草稿”。这一步不是真的画图，而是把每个分镜的文字描述转化成“画面元素清单”，比如“标题文字+箭头流程图+数据标注”。这个清单越具体，后面生成SVG的时候越省力。

第三环是“生成SVG”。这里可以用AI辅助，也可以手写，更可以把简笔画位图转成SVG。后面我会详说这三种手段的取舍。

第四环是“计算动画参数”。我写了一个Python脚本，读取SVG文件里每条路径的length()，然后设定总动画时长，按比例分配每一笔的绘制时长和延迟启动时间。这一步是整个流程里最有成就感的技术细节，因为它让“手写感”变成了可量化的参数。

第五环是“渲染合成”。用浏览器或离线渲染器把SVG动画变成PNG序列帧，再用FFmpeg把序列帧和背景音乐、旁白合成MP4。到这里，一条白板视频就完完整整诞生了。

整个链路我只需要准备两样东西：一个脚本文案，一台装了浏览器和FFmpeg的电脑。剩下的活儿，skill基本都能自动干完。

3. 核心机制拆解：SVG路径动画是怎么画出“笔迹”的

3.1 stroke-dasharray和stroke-dashoffset动画原理

很多人第一次听到“用代码画视频”会觉得很玄，实际上核心机制就是一个CSS动画属性组合：stroke-dasharray和stroke-dashoffset。

我打个比方：一条SVG路径本身是一根透明水管，stroke-dasharray决定水管的“刻度线”怎么分布。比如我设置stroke-dasharray: 1000，意思就是把这条水管分成一千像素长的一段实心、一段空心的循环。如果我把整个路径都当成一个实线段，那么“空心部分”恰好能把整根水管覆盖掉，线条就看不见了。

stroke-dashoffset就是移动这个分段窗口的偏移量。初始状态我把偏移量设成路径总长度，视觉上线条完全“藏”在空心区域里；然后让偏移量匀速减小，实线段就会一点点露出来，看起来就像一支笔正在沿着路径前进。当偏移量减小到0，整条线画完。这个过程的本质，就是用一个不断变化的数字控制一条线的“可见长度”。

你可能会问，为什么不直接用裁切蒙版？我用下来觉得dasharray的写法更简洁，而且天然支持多段虚线效果。比如你想模拟“一支笔写到一半没墨、笔迹出现断点”的质感，直接调整数组里的空心段数值就行，裁切蒙版还得做多个图层叠加，麻烦得多。

3.2 如何计算路径总长度

既然偏移量的初始值要设成“路径总长度”，那这个长度怎么拿？很简单，浏览器里一行代码就能搞定：

const path = document.getElementById('myPath'); const totalLength = path.getTotalLength(); console.log(totalLength);

这是个非常实用的原生方法，浏览器会根据SVG路径的实际几何形状算出精确长度，单位是像素。你可以把它打印出来，写在注释里备用。离线环境下，如果用Python处理SVG，也可以借用svgpathtools库来实现等价计算。

import svgpathtools paths, attributes = svgpathtools.svg2paths2('scene1.svg') for i, path in enumerate(paths): length = path.length() print(f"第{i+1}条路径长度: {length:.2f}px")

拿到长度之后，动画就好设计了。比如一条路径长500像素，你想让它2秒画完，那画笔速度就是每秒250像素。实际测试下来，手写视频的观感速度在100到300像素每秒之间比较舒服，太快没有“写”的感觉，太慢观众会不耐烦。多路径场景里，每条路径启动时间错开200到500毫秒，一笔接着一笔，就像真人写字一样有节奏。

3.3 让笔画有“手绘感”的几个细节

光有均匀速度的描边，出来的效果其实是“一条线平铺展开”，像PPT里的动画，不像手写。要让画面真正有手绘感，还需要几个锦上添花的细节。

第一个细节是笔画粗细不要完全均匀。真人用马克笔画线，起笔和收笔会略微浅淡，转折处因为停留会有轻微堆积。模拟方法也不复杂：给原始路径叠一层同样路径的半透明描边，这个复制层可以比主路径稍微偏移几个像素，透明度调低到30%左右。两层叠加之后，边缘会出现一种“墨迹晕染”的柔边感，比单层硬边真实得多。

第二个细节是路径顺序要符合书写逻辑。比如画一棵树，应该先画树干再画树冠，最后画果实；画流程图，应该从左边第一个框开始，按箭头的方向依次推进。这个顺序要在生成SVG时就在d属性里排好，渲染脚本只按文档顺序执行。为此我养成了一个习惯：每个分镜的SVG文件里，路径集合的排列顺序就是画笔的绘制顺序，路径永远不要乱塞。

第三个细节是“停顿感”。真人在写字换行、画完一个部件后会短暂停顿，这个过程在动画里体现为“当前笔画已经画出，但下一笔还没启动”的时间窗口。我在参数脚本里特意加了最小间隔，比如单笔最低间隔200毫秒，两个分镜之间停顿600毫秒。有了这些自然的呼吸感，视频才不显得像机器吐丝。

4. 实操：从零搭一条白板视频skill工作流

4.1 第一步：准备文案和分镜脚本

废话不多说，直接跑一个实际例子。假设我要做一条讲“番茄工作法”的白板视频，时长大约90秒，目标观众是职场新人。

原始文案我先准备成小段：

番茄工作法很简单。第一步，选择一个待办任务，专注25分钟。第二步，屏蔽一切干扰，只做这一件事。第三步，休息5分钟，让大脑回血。每四个番茄钟后，休息一次长一点的，15到30分钟。

这条文案的长度在90秒内完全可以讲完。接下来按逻辑拆成5个分镜：

1. 标题画面，出现“番茄工作法”五个字和一个番茄简笔画。
2. 一个时钟图形，“25分钟”数字突出。
3. 一个手机被划掉X的图形，代表“屏蔽干扰”。
4. 一个“休息5分钟”的咖啡杯图形。
5. 一个循环箭头示意图，配上“4个番茄钟=长休息”的关系线。

分镜之间内容不能重叠，每个分镜的信息密度控制在一个视觉焦点。这一步不需要写任何代码，但却是整个视频成败的关键，因为SVG生成得再好，文案逻辑混乱也白搭。

4.2 第二步：生成SVG图形文件

分镜草稿画好之后，开始生成SVG。我常用的手段有三类，按效率排序。

第一类是直接让AI生成SVG代码。你告诉它“画一个简单的番茄轮廓，要求用连续路径描述，不要用多个矩形拼凑”，AI一般能给出可用的path。拿到手之后我会先用浏览器打开检查图形形状，满意了再进入下一步。

第二类是手写SVG。比如画一条直线箭头，代码量不大，手写反而更精准：

<svg width="400" height="300" xmlns="http://www.w3.org/2000/svg"> <path d="M 30 150 L 330 150" stroke="#333" stroke-width="6" fill="none"/> <path d="M 310 135 L 340 150 L 310 165" stroke="#333" stroke-width="6" fill="none"/> </svg>

两条路径：一条横线，一个箭头尖。这种基础的图形手写几分钟就能搞定，而且完全可控。

第三类是把位图转成SVG。如果你手头有PNG或者JPG草稿，可以用Potrace这类工具转曲线。命令行长这样：

potrace -b svg -k 0.8 input.bmp -o output.svg

参数-k控制曲线的拟合程度，值越低越接近原图的轮廓，太高会产生很多碎点。不过我会提醒一句：位图转的路径往往节点异常密集，生成的代码文件很大，除非确实需要复用某个复杂logo，否则我优先选前两类办法。

无论用哪种方式，SVG文件最终要放到一个固定目录里，命名规则是scene1.svg、scene2.svg这样。代码脚本只认文件名，规范命名能省掉后面一大半的调试时间。

4.3 第三步：用Python批量输出动画参数

SVG文件备好后，写一个小脚本来读取路径长度、生成每笔的动画参数。我用的是svgpathtools，这个库读取SVG非常方便：

import svgpathtools import json def analyze_scene(svg_path): paths, attributes = svgpathtools.svg2paths2(svg_path) lengths = [path.length() for path in paths] total_time = max(2.5, sum(lengths) / 160) # 默认画速160px/s，最少2.5秒 result = [] cursor = 0 for idx, (path, length) in enumerate(zip(paths, lengths)): draw_time = length / 160 result.append({ "path_index": idx, "length": round(length, 2), "start_time": round(cursor, 3), "draw_time": round(draw_time, 3), "stroke_width": int(attributes[idx].get("stroke-width", 6)) }) cursor += draw_time + 0.25 # 每笔间隔0.25秒 return {"total_time": round(cursor, 3), "strokes": result} data = analyze_scene("scene1.svg") with open("scene1.json", "w", encoding="utf-8") as f: json.dump(data, f, indent=2, ensure_ascii=False)

这个脚本跑完，我就拿到了一份包含每笔开始时间、持续时长、路径长度的JSON参数表。画面里有多少笔、每一笔什么时候动、动多久，全都变成了清清楚楚的数字。这个文件就是后面渲染动画的“指挥总谱”。

4.4 第四步：用HTML加Playwright逐帧渲染

参数就绪后，把SVG和参数组装成一个HTML页面。页面里塞入一条CSS动画，把stroke-dashoffset从路径总长度逐渐变为0，动画时长取自JSON里的draw_time，延迟取自start_time。

<style> path { stroke: #222; stroke-width: 6; fill: none; stroke-linecap: round; stroke-linejoin: round; stroke-dasharray: 100000; stroke-dashoffset: 100000; } </style> <svg id="scene" width="1280" height="720" viewBox="0 0 400 300" xmlns="http://www.w3.org/2000/svg"> <!-- 路径由脚本动态插入 --> </svg> <script> // 用JSON数据动态设置每条路径的CSS const keyframes = `@keyframes draw { to { stroke-dashoffset: 0; } }`; </script>

为了配合Playwright截图帧率，我在页面里预先展开了整个动画过程。渲染时用Playwright的自动化脚本，每50毫秒抓一帧画面存成PNG：

const { chromium } = require('playwright'); (async () => { const browser = await chromium.launch(); const page = await browser.newPage({ viewport: { width: 1280, height: 720 } }); await page.goto('file:///path/to/scene1.html'); await page.waitForTimeout(500); for (let frame = 0; frame < 120; frame++) { await page.screenshot({ path: `frame_${String(frame).padStart(4, '0')}.png` }); await page.waitForTimeout(50); } await browser.close(); })();

这里我用了一个技巧：把帧数和总时长事先算好，比如画面总长6秒，每秒24帧，就是144张PNG。如果动画比较复杂，也可以把帧率降到15帧，观感差异不大，但文件数量能减少三分之一。

4.5 第五步：用FFmpeg合成视频和音频

PNG序列帧拿到手，离最终成片只差一步：合成。FFmpeg命令比较固定：

ffmpeg -framerate 24 -i frame_%04d.png -c:v libx264 -pix_fmt yuv420p -crf 18 scene1.mp4

参数解释一下：-framerate 24表示每秒播放24帧；-c:v libx264指定H.264编码器，兼容性最好；-pix_fmt yuv420p是为了让视频在手机、剪辑软件里都能正常打开，不设的话某些播放器会显示绿屏；-crf 18是质量参数，0到51之间，越低质量越高，18这个值肉眼已经很难看出压缩痕迹。

画面合成之后，再混音。旁白我一般先用录音工具录好，然后和背景音乐一起混入：

ffmpeg -i scene1.mp4 -i voice.mp3 -i music.mp3 -filter_complex "[1:a]volume=1.0[v];[2:a]volume=0.15[m];[v][m]amix=inputs=2[a]" -map 0:v -map "[a]" -c:v copy -c:a aac final.mp4

这里音量参数很关键：人声音量保持100%，背景音乐压到15%左右。如果背景音乐盖过了旁白，整个视频的观看体验会断崖式下跌，我在前几版里都有过这种翻车。

五个分镜分别做成scene1.mp4到scene5.mp4后，用FFmpeg按顺序拼接：

echo file 'scene1.mp4' > list.txt echo file 'scene2.mp4' >> list.txt ... ffmpeg -f concat -safe 0 -i list.txt -c copy merge.mp4

到这一步，一条完整的白板视频已经出来了。整个流程从文案到成片，熟练之后可以控制在30到40分钟，其中大部分时间是等渲染跑完。

4.6 最后一步：把整套流程封装成真正的skill

做完上面这些，我只完成了一次性视频。离“skill”还差一步：把流程固化成规则，让AI只需要按指令执行就能稳定复现。

我封装的方式是写一份skill.md定义文件，包含输入格式、执行步骤和输出规范。这份文件放在特定目录下，把它接入支持自定义skill的AI框架即可。

name: whiteboard-video-skill description: 从文案生成白板手绘风格动画视频 version: 1.0.0 input: script: 用户提供的脚本文案 workflow: 1. split_script: 拆分为5-8个分镜，每个分镜一个画面主题 2. design_storyboard: 为每个分镜生成画面元素清单 3. generate_svg: 按清单创建SVG路径，保证路径顺序即绘制顺序 4. compute_animation: 读取路径长度，生成每笔的start_time和draw_time 5. render_frames: 用Playwright按帧截图，导出PNG序列 6. compose_video: 用FFmpeg合成视频、混音、拼接分镜 output: format: mp4 resolution: 1280x720 fps: 24

封装完skill之后，我再做新视频就不需要手动跑Python、手动开浏览器了。我把文案往skill入口一丢，它会自动按工作流跑完，我只需要最后审核一遍成品。如果某个分镜不满意，我只改对应的SVG文件再重跑一遍，整个链路的其他部分完全不受影响。

5. 踩坑实录与常见问题排查

5.1 中文字体变成方块或文字描边断裂

这个问题几乎每个第一次跑通SVG渲染的人都会遇到。原因是SVG默认字体不一定包含中文字形，浏览器渲染时找不到字，就会用方框代替。另外，如果文字被转换成了描边，而stroke-linejoin没有设置，笔画交汇处会出现“断头”一样的毛刺。

我的解决方法是：在SVG的<text>标签上显式指定字体：

<text x="50" y="100" font-family="Microsoft YaHei, PingFang SC, Noto Sans SC" font-size="28" fill="#222">番茄工作法</text>

同时，所有带描边的图形统一加上stroke-linejoin="round"和stroke-linecap="round"。这两个属性会让线条接合、端部变成圆角，视觉上更像马克笔，也避免断裂感。

还有一点很重要：FFmpeg合成视频时是逐帧渲染PNG，不需要依赖原系统的字体系统，它只是在截屏。但如果你用的不是Playwright而是服务器端的离线渲染库，那服务器上必须装中文字体，否则照样出方块。

5.2 动画“啪”一下全出来，没有手绘过程

如果你设置好动画后，发现画面加载完“啪”一下全部出现了，大概率是stroke-dashoffset初值没设对。很多人习惯把stroke-dasharray和stroke-dashoffset都设置成1000，以为1000是一个足够大的数。但路径一旦超过1000像素，比如一条1500像素的曲线，初值不够大，线条就会露出一截。

最稳妥的做法是像前面代码那样，把stroke-dasharray设成一个极大的固定值，比如100000，同时用getTotalLength()拿到具体长度后，把动画起始的偏移量也设为这个长度。这样任何路径都能一视同仁地“从零开始画”。

另外检查一下你的CSS动画是不是用了forwards填充模式。如果动画结束之后没有保持最终状态，画面会瞬间闪回初始状态，看起来就像“画完又消失了”。我给每条路径补上animation-fill-mode: both，问题迎刃而解。

5.3 笔画顺序不对，图形像“倒着画”出来的

SVG路径本身是有方向的。d="M 10 10 L 100 10"从左画到右，如果你把坐标反过来写M 100 10 L 10 10，动画就会从右往左画。对于横线、箭头这种方向性不明显的图形还好说，一旦涉及“树杈”、“手表指针”、“箭头流程”这类方向感强的图形，画反了会非常突兀。

我的检查办法是：在生成SVG后，先用浏览器加一个临时的高亮stroke="red"打开一次，逐个路径看方向和预览，确认没问题再跑动画脚本。如果发现方向反了，不需要改坐标，直接在SVG的transform属性里加scale(-1, 1)绕原点翻转即可：

<g transform="scale(-1, 1)"> <path d="..." /> </g>

不过要注意，翻转后文字也会变成镜像，所以单独针对路径分组翻转，文字另放一组，别混在一起。

5.4 SVG路径视频放大后模糊怎么办

SVG是矢量格式，放大边缘不糊，但一旦渲染成PNG序列帧再导出视频，清晰度就取决于PNG的分辨率了。如果你的播放器窗口只有一小块区域显示，也可以做成8K分辨率的PNG序列，但这会让渲染时间暴增。

我的经验是：制作时直接用1280720的画布渲染，同时把SVG的viewBox设为0 0 400 300。由于viewBox等比缩放，1280宽度下的线条宽度同样会放大3.2倍。比如定义stroke-width="3"，在1280画布上实际是9.6像素，在手机上观看这个粗细刚刚好。如果后期要投放高清大屏，就把画布直接设成38402160，线条的绝对像素宽度不变，但视频清晰度上限高很多。

想保留矢量到哪都能无限放大，则只能用特殊格式，比如HTML5动画或动态PDF。实际做在线视频传播，固定分辨率就够了。

5.5 AI生成的SVG路径总是有零碎断点

如果你让AI生成SVG，它有时会输出几十条小路径拼出一个大图形，每一条都有自己的描边、填充，动画时参差不齐。

我处理这类“碎路径”的方式是做一次合并预处理。Pathway合并的前提是它们首尾相接，如果是同一条连贯曲线被切成了几段，可以在Python里把相邻路径的端点进行拼接。但如果是不同图形（比如一个圆形由四条弧线组成），强行合并反而丢失了每条弧线单独书写的节奏感——这种我倾向于保留小段，并按手写顺序依次播放，效果反而更像连笔写字。

顺便提醒一句：AI生成的SVG偶尔会出现fill="#FFFFFF"把内部填成实色，导致线条笔画被遮盖。我在预处理脚本里会默认把所有路径的fill设为none，只有真正需要填充色块的图形才手动打开。这一条能避免大量渲染到一半发现画面“白板一块”的翻车情况。

6. 我最后想补充的几件事

这条skill跑通之后，我把自己常用的几类分镜图形模板也沉淀了下来。比如画流程图用的“圆角矩形+箭头”、画数据报告用的“柱状图+趋势线”、画时间线用的“节点+连接线”，都各自做了标准SVG模板。以后不管接到什么主题的视频，只要在模板里改文字、调数据，再换个配色，一条新的白板视频就出来了。这个复用思路比任何单一技术都更重要——skill最值钱的部分不是某段代码，而是可复用的流程资产。

如果你照着我这套流程做，第一次跑通可能需要两个晚上加一个下午。卡住的时候不用硬扛，回头看看我前面写的问题排查表，八成能找到对应的坑。我个人在实际操作中最大的体会是：把“画视频”改成“写视频”之后，做内容的心态完全变了。以前动画是动画，文案是文案，两者要分开维护；现在它们是一份数据的两面，改一个字和改一条线的成本一样低，表达的自由度也随之宽了很多。

最后再分享一个小技巧：做分镜时，不要贪心在一个画面里塞太多信息。白板视频的魅力在于“慢慢长出来”的过程，一个分镜只讲清楚一个点，反而让整个视频更有节奏感。等你把基础流程跑熟了，可以再试着把这一套接到更复杂的交互场景里去——比如让AI读取数据表格自动生成图表分镜，那又是另一片宽阔的天地了。