简介：一套基于 ComfyUI + AnimateDiff + ControlNet 的线稿动画生成方案，面向 AI 绘画创作者与动画爱好者，解决动态线稿生成中帧间一致性和控制难度大的问题，既能用于短视频动态分镜，也适合插画师拓展动画素材。压缩包共 27 个文件，大小约 1.61MB，其中 22 张 PNG 序列帧展示了完整动画效果，4 个 JSON 工作流文件保存了节点连接与参数配置，1 个 TXT 说明文档提供云端运行指引。已有 523 人学习，适合初步接触 ComfyUI 工作流、希望直接复现可控动画效果的用户。从内容预览看，序列帧从 frame_00 到 frame_21，可直观检查每一帧的线稿质量；多版本 JSON 工作流按日期区分，便于对照不同参数的生成结果。配合 AnimateDiff 保持帧间动态一致，借助 ControlNet Lineart 锁定轮廓，整体是一份即拿即用的 ComfyUI 线稿动画实战参考。

1. ComfyUI+AnimateDiff+ControlNet的Lineart生成动画：这不是玩具管线，而是可控动画量产线

很多人第一次看到这串技术名词，会以为它只是拿预设工作流跑几秒动态图的小玩具。实际用过一条完整流程后，我的判断完全不同：ComfyUI 负责编排，AnimateDiff 提供逐帧运动，ControlNet 的 Lineart 模型负责把每一帧的结构锁死在指定线稿上，三者组合出来的是一条“有原画、有动态、可批量出片”的动画生产链路。它解决的核心问题不是生成一段会动的画面，而是让这条线稿变成动画之后，角色不漂、背景不糊、帧与帧之间不闪。适合两类人：一是想把手绘线稿快速变成动画短片的独立创作者，二是需要批量产出分镜预览的动画外包小团队。

2. ComfyUI工作流里的三角色：AnimateDiff负责动，ControlNet Lineart负责稳住结构

2.1 ControlNet的Lineart在动画管线里管什么：结构约束而不是运动

ControlNet 本身是一组控制生成结果的条件网络，不同模型文件对应不同控制维度。Lineart 模型接收的是黑白线稿，它会在扩散过程的每一步，把这张线稿的结构信息注入到潜在空间里，相当于给生成过程画出一条“必须沿着走”的边界。放在动画场景里，这个边界就是每一帧的构图和造型边框。

我一般会在工作流里把 ControlNet 接在采样器之前，输入有条件图像，输出带结构约束的模型条件，然后和文本条件一起送入 KSampler。控制强度由 ControlNetApplyAdvanced 节点里的 strength 参数决定，strength 越高，生成的画面越贴线稿，但运动幅度也会被压缩。实际做 Lineart 动画时，如果把 strength 拉到 1.0，角色每一帧都会死死贴在线稿上，动作几乎是线稿本身在移动；如果降到 0.5，画面自由度高，但结构很容易漂走。经验值是在 0.7 到 0.9 之间起步，然后根据动作幅度微调。

有两点容易看走眼：第一，Lineart 模型分 SD1.5 和 SD2.1 两个底子，用来匹配不同版本的基础模型，混用会直接导致控制失效；第二，Lineart 不等于 Canny，Canny 提取的是边缘线，Lineart 保留的是轮廓与阴影结构，处理动画线稿时两者效果差别很明显，别拿错模型文件。

2.2 AnimateDiff在ComfyUI里的两种接法：加载器挂载与采样器注入

AnimateDiff 做的事情是给原本只处理单张图像的 UNet 增加一个运动模块。加载运动模块之后，采样器处理的噪声张量从原来的形状 扩展成带帧维度的形状，UNet 在去噪时不再只看一张图，而是同时看一段连续帧，帧与帧之间的内容就会因为时序注意力而产生一致性。这也是 AnimateDiff 和你自己把多帧逐张生成再拼起来的本质区别。

在 ComfyUI 里，常见做法是分两种方式接入：一种是用 AnimateDiff 加载器节点把运动模块挂在基础模型链路上，模型从加载器出来后就已经带着时间维度的能力，后续送进采样器的 latent 需要带帧数信息；另一种是把运动模块接到采样器端，更精确地控制它在哪个采样阶段介入，适合做更复杂的运动控制。

对新手来说，我建议先走加载器方式，操作简单，出问题也容易排查。有一点要提前说明：AnimateDiff 的加载器和你用的 VAE 是两套东西，别把运动模块理解成“一个能直接输出 MP4 的生成器”，它只是给模型增加时间维度，真正把帧序列变成视频的是后面的视频合成节点。这个黑匣子不必深挖，只要知道帧维度的信息流是从这里开始的。

2.3 选型取舍：基础模型、Motion Module与采样器怎么配

这里没有一个万能组合，但有一个比较稳的起步配置。基础模型优先选 SD1.5 系，因为 AnimateDiff 的社区生态对 SD1.5 的支持最成熟，模型好找，Lineart 控制模型也足够丰富。SDXL 系和部分自研大模型虽然画质更细，但 Motion Module 的兼容性需要逐个验证，投入产出比不高。

Motion Module 的版本要和基础模型匹配，一般文件名里会带有训练基准与阶段信息，建议优先选同一套发布说明里标注过的组合。采样器方面，我习惯用 Euler 或 Euler Ancestral，前者稳定少出烂帧，后者能让动作更自然一点，但偶尔会跳图。步长 25 到 30 步比较合适，超过 40 步对画面提升不明显，反而增加每帧的解码时间。

分辨率要克制。Motion Module 大多在 512 分辨率下训练，直接拉到 768 往往出现结构崩坏和闪烁。我的习惯是先固定 512x512 或 512x768，生成整段动画后再做后续高清化，而不是一开始就挑战高分辨率。VAE 用标准 VAE 出片画质更好，但解码多帧很吃显存；如果显存紧张，可以先用轻量 VAE 做预览，再换回标准 VAE 渲染最终版本。

3. 把ComfyUI工作流跑通Lineart动画：最小节点链与API提交脚本

3.1 最小工作流节点连线：从线稿输入到MP4输出

第一步先搭一条能出片的最小链路，不要一上来就堆节点。我常用的节点顺序是：加载基础模型 → 加载 Lineart 控制模型 → 读取线稿并编码到 latent → 挂载 AnimateDiff 运动模块 → 进入 KSampler 采样 → VAE 解码 → 视频合成节点输出 MP4。

工作流的 JSON 结构大致是这样的，不同插件版本里部分参数名会有差异，但主链路是一致的：

{ "1": { "class_type": "CheckpointLoaderSimple", "inputs": { "ckpt_name": "sd15_base.safetensors" } }, "2": { "class_type": "ControlNetLoader", "inputs": { "controlnet_name": "control_v11p_sd15_lineart.safetensors" } }, "3": { "class_type": "LoadImage", "inputs": { "image": "动画线稿_001.png" } }, "4": { "class_type": "AnimateDiffLoader", "inputs": { "model": ["1", 0], "frames": 16, "context_length": 16 } }, "5": { "class_type": "ControlNetApplyAdvanced", "inputs": { "conditioning": ["4", 0], "control_net": ["2", 0], "image": ["3", 0], "strength": 0.8, "start_percent": 0.0, "end_percent": 0.7 } }, "6": { "class_type": "KSampler", "inputs": { "model": ["4", 0], "positive": ["5", 0], "negative": [], "seed": 10086, "steps": 28, "cfg": 7.0, "sampler_name": "euler", "scheduler": "normal", "denoise": 1.0 } }, "7": { "class_type": "VAEDecode", "inputs": { "samples": ["6", 0] } }, "8": { "class_type": "VideoCombine", "inputs": { "images": ["7", 0], "frame_rate": 12, "format": "mp4" } } }

这段 JSON 不是让你直接导入就完事的，它展示的是节点之间的数据流向。逻辑说明：模型加载器输出的 model 分别流向 AnimateDiffLoader 和 ControlNet 应用节点，线稿图像先被编码成 latent，再作为结构条件参与采样，最终采样出来的帧序列经过 VAE 解码变成图像列表，视频合成节点再按帧率打包。参数说明：frames 是总帧数，context_length 决定时序注意力能回看多少帧；start_percent 和 end_percent 控制 ControlNet 在去噪过程的前后占比，后半段放松约束有助于动作流畅；seed 固定后同一套输入可以复现。

3.2 分辨率、帧数、步长与CFG：先照这组数值跑通

很多人在第一步就想着调出完美动画，结果参数堆满，问题反而难排查。我建议第一版先照下面这组数值跑，全部能出片后再逐个动：

这组数值的核心思路是“先验证链路通不通”。分辨率限制在 512，可以避免显存和模型兼容性两个变量同时干扰；帧数限制在 16，可以快速看到整段动画效果，也便于抽帧检查。帧率在合成阶段设置，最终导出时改成 24fps 即可，不必重新采样。

一个常见的翻车点是：直接把线稿图拖进 LoadImage，但不同步设置图像尺寸，导致 latent 尺寸和 ControlNet 图像尺寸不一致，报错或者生成画面被裁剪。所以在 KSampler 前要确认 empty latent 的宽高和线稿图一致，最好在输入线稿时就统一尺寸。

3.3 用ComfyUI API把手工流程变成可复现脚本

节点连线调通之后，一直用手点界面会很浪费时间，尤其要批量出片时。ComfyUI 本身带了一套 API 接口，工作流可以在界面上通过“导出 API 格式”的方式保存成 JSON，然后提交到本地的 HTTP 接口执行。我习惯用下面这个 Python 脚本做队列提交和状态轮询：

import json import time import urllib.request SERVER = "http://127.0.0.1:8188" def queue_prompt(workflow): req = urllib.request.Request( f"{SERVER}/prompt", data=json.dumps({"prompt": workflow}).encode("utf-8"), headers={"Content-Type": "application/json"} ) resp = json.loads(urllib.request.urlopen(req).read()) return resp def wait_for_result(prompt_id, timeout=600): end = time.time() + timeout while time.time() < end: used = urllib.request.urlopen(f"{SERVER}/history/{prompt_id}").read() history = json.loads(used) if prompt_id in history: return history[prompt_id] time.sleep(1) raise TimeoutError("任务超时")

这份脚本的核心价值是把手工调节点变成程序化调用。queue_prompt 的作用是提交工作流 JSON，服务端会返回一个 prompt_id；wait_for_result 持续向后端查询执行状态，直到任务写入 history 后返回结果。注意，提交的必须是“API 格式”的工作流 JSON，而不是界面保存的完整 UI 格式，后者包含画布坐标信息，服务端不认。这个坑我踩过不止一次，导出时一定看清楚格式选项。

脚本跑通之后，后续所有换线稿、换提示词、换输出文件名的操作，都可以通过修改 JSON 里的对应字段再提交来完成。看到这里你应该能明白，动画批量化的第一步并不是写多复杂的代码，而是先让单元流程可复现。

4. 调参让Lineart动画不闪不抖：strength、上下文帧与高清化路径

4.1 闪烁的第一个来源：逐帧生成再拼接

有一类动画闪烁不是模型问题，而是生成方式错了。有些朋友会把总帧数拆开，一帧一帧调用同一个采样器，生成 16 张图之后再拼视频。这在普通图生图场景还能用，但在 AnimateDiff 里属于完全错误的做法。AnimateDiff 的运动模块是在一次采样中看到整段帧序列的，如果把序列拆开，时序注意力就失效了，每一帧实际变成了独立重绘，出来的画面在单帧看都很精，放到时间轴上就是连续闪。

确认这个问题很简单：看生成过程，单帧逐张生成时，你会发现每张图在相同位置的头发、衣服纹理都不太一样。正确做法是让 KSampler 一次输出完整帧序列，总帧数由 AnimateDiffLoader 里的 frames 参数控制，而不是在外部循环里反复调用采样器。

如果显存实在不够一次生成 32 帧，优先降低帧数到 16，或者缩小分辨率，但不要拆开单帧采样。拆帧这个习惯改掉之后，你会发现闪烁问题直接少了一半，这不是玄学，是运动模块的工作方式决定的。

4.2 真正值得反复调的三个参数：线稿强度、上下文帧与种子

闪烁排掉之后，剩下的质量问题一般集中在三个参数上，建议按顺序调。

第一个是 ControlNet 的 strength 和起止范围。当角色运动幅度大时，strength 太高会把每一帧都锁死在线稿结构上，动作变成平移；太低则结构漂移明显。我的调法是：先固定 strength 0.8，如果角色在运动中途变形，就提到 0.9；如果动作僵硬，就适当降低 end_percent，比如从 0.7 改成 0.5，让后半段去噪过程有更多自由发挥空间。start_percent 一般保持 0.0，让结构从一开始就介入。

第二个是 AnimateDiff 的 context_length 与 stride。context_length 表示时序注意力一次能看到的帧数范围，常见的启动值是 16 帧；如果生成 32 帧动画，但 context_length 还是 16，意味着后半段的帧只能依赖窗口内的信息，远端关联会丢失，动作容易突然跳变。手动把 context_length 提到 24 或 32 会改善，但显存压力同步增大。strid 控制滑动窗口的步长，值越大窗口越稀疏，能覆盖的总时长更长，但关联精度下降。先调 context_length，再动 stride，顺序不要反。

第三是种子。固定 seed 可以复现同一套结果，这是排查问题的基础；但如果你固定 seed 后画面仍然间歇性闪烁，换一个 seed 有时能直接解决。原因在于每次采样引入的初始噪声不同，某些噪声模式在时间维度上会产生更明显的帧间跳变。我自己会把 seed 固定后先跑一遍，如果动作不稳定，随机换几个 seed 各跑一次，从中挑稳定的一版。这个操作看起来像玄学，但它能快速帮你区分是模型问题还是噪声路径问题。

4.3 高清化而不是直出大图：分块重绘与线稿锁定

很多人希望直接生成 1024x1024 的高清动画，但 Motion Module 的训练分辨率摆在那里，直出大图的结果通常是角色结构时好时坏。更稳妥的路线是先按 512 生成整段动画，再把每一帧抽出来做高清化。

我一般会搭一个独立的“单帧高清化”子工作流：把动画抽出的某一帧作为输入，用同一个 Lineart 模型提取线稿，再进入图生图流程，把分辨率放大到 1024，重绘幅度 denoise 控制在 0.4 到 0.5 之间。这样做的好处是：线稿结构在放大后被再次锁定，角色不会因为重绘而换脸；同时由于每次只处理单帧，显存压力也小。

实际操作中不要对整段视频直接做 Resize，那样只会得到模糊的放大画面。正确流程是：逐帧放大 → 抽帧检查结构一致性 → 确认无跳变后，再按原帧率合回视频。放大后的帧因为来源是低分辨率动画，画质会有轻微涂抹感，可以配合一个轻量的锐化节点做最终处理。整条路线走下来，最终的动画兼顾了分辨率和稳定性。

5. Lineart动画项目常见问题排查：插件报错、显存爆与线稿翻车

5.1 节点报错No module named或找不到自定义节点

现象：加载别人给的工作流文件后，节点显示红色，控制台提示 ModuleNotFoundError 或“node type not found”。

原因：工作流里用到了 AnimateDiff、ControlNet 等自定义节点，但当前 ComfyUI 环境没有安装对应插件，或者插件版本过旧，节点类型名称对不上。

解决：先去检查插件是否在扩展目录里被正常加载。处理方式是先更新 ComfyUI 主程序，再重新安装对应插件；如果更新后仍然报错，就要看报错里的节点类型名和当前插件版本支持的节点名是否一致。很多 old 工作流用的是旧节点名，新插件改名后就找不到。最省事的做法是把工作流换成当前插件版本的官方示例文件，手动对照重新连一遍节点，这个方式虽然慢，但能彻底避开版本黑匣子。

5.2 显存爆掉与中途黑屏

现象：生成到一半进程退出，或者 ComfyUI 界面直接黑掉，控制台出现 CUDA out of memory。

原因：显存峰值出现在两个位置：一是采样阶段，模型、运动模块、ControlNet 同时驻留显存；二是后期 VAE 解码多帧图像时，图像列表全部调入显存。后者往往更致命。

解决：先分辨清是哪个阶段爆显存。在采样阶段报错，就把 frames 从 32 降到 16，分辨率保持 512，或者开启 ComfyUI 的低显存模式，让部分权重按需加载。如果报错发生在 VAE 解码阶段，可以临时换一个轻量 VAE 做逐帧解码，输出预览动画；最终版本再换回标准 VAE 单独渲染。另外，可以在视频合成节点里限制预览尺寸，避免界面端边预览边解码带来的多余显存开销。

5.3 线稿断断续续与角色变形

现象：输出动画里角色的结构有时候贴合线稿，有时候直接崩掉，尤其在线条密集的位置，比如手指、五官和衣褶。

原因：一是把彩色原图直接当作 ControlNet 条件图像输入，Lineart 模型需要的是黑白线稿，彩色输入会让模型错误理解结构；二是线稿预处理时阈值不对，太粗的线把细节糊掉，太细的线让控制信号不稳定。

解决：输入 ControlNet 的图一定是经过 Lineart 预处理器提取的黑白线稿，建议白底黑线统一成模型训练时的常见格式，如果模型默认输入黑底白线，就做一个反色节点。处理纸绘扫描件时，先用阈值清除纸张噪点，再适当加粗细线条，反复抽一两帧测试，确认结构稳定后再跑整段。调试的时候别整段动画一起看，浪费时间，先用单帧验证控制效果。

5.4 seed固定后仍然闪烁：上下文覆盖不住时长

现象：seed 已经固定，分辨率、strength 都没动，但动画后半段开始频繁闪烁，帧间内容出现明显跳变。

原因：总帧数大于 context_length 的覆盖范围，导致后半段的帧只能依赖时间窗口内的有限信息，远端结构关系丢失。常见于从 16 帧扩展到 32 帧或 64 帧时，context_length 没有同步提升。

解决：给这种长动画做分段生成。比如 64 帧拆成两段，每段 32 帧，段与段之间保留 4 到 6 帧的重叠区域，重叠区域的 seed 保持一致。再把两段视频在后期剪辑软件里做交叉重叠或帧融合，能明显减少接缝处的跳变。这个方法比强行提 context_length 更省显存，也更适合批量生产场景。

6. 把工作流固化成模板：批量出片与三帧质检习惯

6.1 推荐把工作流存成模板文件

调通一版能稳定出片的流程后，第一件事就是存模板。不要只在界面上保存，那会把画布的节点坐标也存进去，不利于批量替换。我一般会把 API 格式的工作流 JSON 单独存一份，字段里只用占位符标注需要变更的位置：线稿路径、提示词、seed、输出文件名。下次要用时，直接修这几个字段提交即可。这样固化的好处是，团队里另一个人拿到模板，不需要理解整套节点图也能跑动画。

6.2 批量任务：用脚本按清单排队出片

批量出片建议用一个简单的清单文件，每一行是一条任务：线稿路径、提示词、输出名。脚本读过清单后逐行生成工作流 JSON，调用前面的 queue_prompt 提交到 ComfyUI 队列。

import csv JOBS = "jobs.csv" def build_workflow(image_path, prompt, output_name): # 实际为读取模板 JSON，替换占位字段后返回 return workflow_with_replaced_fields(image_path, prompt, output_name) with open(JOBS) as f: for row in csv.DictReader(f): wf = build_workflow(row["image"], row["prompt"], row["output"]) pid = queue_prompt(wf)["prompt_id"] print(f"queued: {pid}")

这里要注意一个细节：连续提交大量任务时，给每次提交之间加一点间隔，避免请求打太快出现连接被拒。ComfyUI 有队列机制，任务堆积后会自动排队执行，所以脚本只要负责提交和记录 prompt_id 即可。

6.3 固定的三帧质检法与我的检查习惯

批量出片后不要直接看整段视频判断好坏，我的习惯是每一条任务生成后抽三帧做检查：第一帧、中间帧、最后一帧。把这三帧并排放在一起对比线稿结构，如果三帧的角色发型、五官位置和服饰边缘都能对齐，这条动画在结构一致性的基本盘上就及格了。如果中间帧对不上，优先回看是不是运动幅度过大导致 ControlNet 约束失效，再决定是调整 strength 还是重分段。

我自己吃过一次亏：有一批任务只看了首帧就批量导出，结果中间十几帧线条狂闪，返工成本很高。现在无论多急，都会先抽这三帧确认再合视频。养成这个习惯之后，这套 ComfyUI 加 AnimateDiff 加 Lineart 的管线才真正从“能跑”变成“能用”。希望帮到你。

本文还有配套的精品资源，点击获取