story-to-handdrawn-video开源：文案变手绘动画，插画也能做成翻书视频

手绘故事视频看起来很治愈，做起来却不一定轻松。

写完文案，还要拆分镜、统一人物、准备插画，再安排文字出现和画面转换。好不容易完成一版，换个故事，又得把流程重新走一遍。

能不能把这些重复操作整理成一套固定流程，让AI负责执行？

gnipbao推出的开源项目 story-to-handdrawn-video，就是围绕这个需求设计的。

它将Agent Skill与Remotion渲染器结合起来，支持把中文故事或已经画好的图片，制作成3:4竖屏手绘视频。

文字逐渐出现，黑白画稿展开，随后进入彩色画面；也可以保留完整插画，用右下角卷页的方式翻到下一页。

不过，它的定位需要先说清楚：这是手绘视频画面轨制作工具，不是自动完成配音、音乐和全部后期的一站式短视频平台。

01｜它不是另一个视频模型，而是一套手绘内容制作流程

story-to-handdrawn-video主要由两个部分组成。

Agent Skill负责理解故事、规划分镜、调用生图工具，并组织后续操作。

Remotion渲染器负责读取已经准备好的素材，按照时间安排播放图层和转场，导出视频。

可以简单理解为：

AI负责准备画面，程序负责让画面按照规则动起来。

因此，它不需要把整段动画交给一个文生视频模型重新生成。已经确认的图片，可以作为素材继续制作和调整。

对需要长期更新手绘故事、图文解说和绘本视频的创作者来说，这种方式值得关注：先把每一页做好，再控制页面如何出现，制作过程更容易拆开检查。

但“本地渲染”不等于“全流程离线”。

从文字生成新插画，仍然需要Agent能够调用的生图工具；该工具是否联网、是否收费，要看实际使用的服务。

02｜中文故事先拆分镜，保留原文，不急着改写

项目对中文故事的处理，强调保留原文措辞。

默认情况下，一个完整句子对应一个叙事节拍。遇到较长的复句，再根据叙事转折进行拆分。

这里的“节拍”不一定意味着每句话都必须换一张全新图片，而是让文字、画面和时间安排有明确对应关系。

例如，一段故事写着：

“奶奶把旧相册放在桌上。窗外的光，刚好照在那张毕业照上。”

创作时需要先判断：第二句话应该切换到照片特写，还是继续保留桌面场景，让光线成为重点？

这类问题最好在生图之前决定，而不是等所有素材生成后再补救。

项目使用storyboard JSON记录分镜信息，创作者可以在渲染前检查文字、素材引用和时间安排。

先确认讲什么、怎么讲，再投入生成和渲染，比反复修改成片更有条理。

另外，保留原文是流程要求，不代表生图模型一定能把每个汉字都画对。当前默认流程会将手写文字与插画一起生成，因此仍需要逐字检查，尤其是人名、数字和较长句子。

03｜不只原来的20种画风，当前主分支已扩展素材库

项目原有20种内置手绘风格，支持通过名称、编号或对应标识选择。

目前，主分支已经扩展为 297条画风配方和30套主题配色，共327项资产，并提供在线风格库和离线目录。

需要注意，这部分扩展在更新日志中仍列于Unreleased，也就是尚未归入正式发布记录的更新。使用旧版本时，不一定具备同样的风格数量。

画风库涵盖日记、线描、彩铅、水墨、水彩、绘本、拼贴等类别。用户可以先看示意图，再选择适合故事的表现方式。

这些配方也不是297个独立生图模型，而是围绕线条、画材、造型和颜色整理的视觉规则。

它的实际价值是减少反复描述风格的工作。

比如，一个系列确定使用彩铅日记风，后续制作就可以沿用相同配方，而不必每次重新解释线条和配色。

但画风配方能够约束风格，不等于保证人物永远不变、每张图都完全一致。角色参考、构图检查和必要的重生成，仍然不可省略。

04｜两种动画方式：逐层展开，或者像绘本一样翻页

story-to-handdrawn-video提供两种主要表现方式，适合不同素材。

逐层揭示：文字、黑白画稿、彩色插画依次出现

这种模式会把页面中的文字与插画分开处理，再从彩色插画派生出对齐的黑白版本。

播放时，画面按照文字、黑白、彩色的顺序展开，形成逐步绘制和上色的视觉效果。

这里有一个重要区别：

它是在揭示已有图层，不是还原画师每一笔真实的绘画轨迹。

黑白层由最终彩色图转换而来，有利于保持两者的位置和构图一致，避免分别生成两张图片以后出现明显错位。

这种形式可以用于强调步骤、情绪推进或重点内容。

翻书转场：保留完整页面，从右下角卷起

翻书模式不会把整张图重新拆成文字和黑白阶段，而是保留原有排版、文字和配色。

页面静态展示后，从右下角卷起，露出下一页；纸张背面带有淡化的原页内容。

对于已经排好版的绘本、漫画或手账图片，这种处理更加直接。

需要区分的是，保留纸页感不等于所有画风都必须叠加纸纹。最终效果仍然取决于原始图片与所选风格。

05｜已经有插画，也能直接做视频，不必重新生图

这个项目并不要求所有内容都从文字开始。

如果已经有一套手绘稿、漫画页或图文素材，可以按照指定顺序导入，再选择动画方式。

例如，将六张已经完成的故事插画排好顺序，用翻书效果串联，就能得到一条方便继续配音的视频画面轨。

对于长期做图文的创作者，这是一种值得尝试的内容复用方式。

不过，不同模式对素材的要求不一样。

翻书模式可以直接使用完整页面；逐层揭示模式则需要可靠地区分文字区与插画区。如果文字、人物和装饰大量交叠，自动拆分就可能不理想。

此时，更适合调整原图，或者改用保留整页的转场，而不是强行裁切。

不是每张图都必须拆成动画，选择适合素材的表现方式更重要。

06｜参考图也能变成风格模板，方便后续复用

当前主分支还支持根据参考图提取视觉特征，用于生成新的故事页面。

Agent会分析线条、形状、配色、材质、构图和文字表现，再将这些特征应用到新内容中。

这里需要分清两个需求：

“按照这些图片的顺序做视频”，使用的是已有页面。

“参考这张图的画风，重新画一个故事”，使用的是风格参考。

后者不应该直接把参考图中的人物、文字和情节搬进新故事。

用户提出保存要求后，项目还可以把参考图和风格描述存入本地私有目录，后续按名称调用，而不加入公共风格库。

这对于建立自己的系列内容风格比较方便。

但风格资料保存在本地，并不意味着后续生图时绝不会向外部服务发送参考素材。涉及未公开设计或客户图片时，仍应检查所用Agent和生图工具的数据处理方式。

07｜story-to-handdrawn-video怎么用？先预览，再正式渲染

这不是打开网页就能完成全部制作的消费级工具，需要先配置本地环境。

当前项目要求Node.js 20或以上版本、Python 3.10或以上版本、npm、包含ffprobe的FFmpeg，以及兼容的浏览器环境。

制作全新插画时，还需要可用的生图工具。

安装渲染器与Skill

克隆仓库并进入项目目录后，执行npm ci安装依赖，再运行npm run check检查项目。

随后，将skill-package/story-to-handdrawn-video目录复制到所用Agent支持的skills目录。

如果从其他项目中调用，需要按照说明设置STORY_VIDEO_PROJECT，指向渲染器所在位置。

这里要注意：安装通过，不代表图片已经生成，也不代表可以跳过素材准备直接出片。

默认命令行生成阶段可以先准备生图任务，但实际图片仍需由Agent调用生图工具完成。

准备故事与画风要求

可以把故事写入story.txt，也可以直接向Agent提供中文文案。

第一次尝试，建议先用三到五句话，明确人物、场景和画风，再检查分镜与插画是否匹配。

例如，可以这样提出需求：

“使用story-to-handdrawn-video，将这段故事制作成3:4手绘视频。保留原文，采用彩铅日记风，先检查分镜和中文字，再输出预览，不添加配音与音乐。”

检查预览后，再输出正式视频

项目提供720×960预览和1080×1440正式输出，两者都是3:4比例。默认导出为30fps、H.264编码的静音MP4。

文本生成路径的正式文件为out/picture_silent.mp4，上传图片路径则使用对应的uploaded输出文件。

预览时，建议重点检查文字有没有错、人物是否连续、每页停留是否足够，以及转场是否打断阅读。

3:4不等于9:16。 如果目标平台或项目要求9:16，应重新检查版式与画布，不能只是拉伸原有画面。

另外，翻页模式存在页面重叠时间，不能简单用“每页时长乘页数”计算成片长度。需要匹配配音时，应根据实际输出调整节奏。

08｜适合做什么内容？重点是图文叙事，而不是复杂角色表演

从项目的表现方式看，可以优先考虑几类内容。

故事绘本与生活随笔。 用少量句子组织情节，以固定角色和场景推进，让画面承担叙事，而不是让每页都塞满文字。

知识讲解。 通过逐层出现的文字和图示，逐步解释一个概念或过程。此时，准确性和阅读节奏应比装饰效果更优先。

品牌故事与产品理念。 用连续插画讲述一个使用场景、创作过程或用户故事，再在后期加入旁白。

已有图文的视频化。 把完成的手账、漫画或系列插画整理成可播放内容，减少重新制作素材的工作。

以上是根据功能设计的应用建议，不代表项目已经提供现成的行业模板。

它更适合“页面逐步展开”的内容。如果任务需要连续人物动作、复杂表演或大幅度运镜，就超出了当前图层揭示与翻页渲染的重点。

手绘图文动画与完整角色动画，解决的是不同需求。

09｜开源不等于零成本，MIT也不覆盖所有依赖

story-to-handdrawn-video项目代码采用MIT许可证，可以在遵守条件的前提下使用、修改和分发，并需保留相应版权与许可声明。

但实际制作仍可能涉及生图服务、Agent使用、本地计算资源和后期处理成本。

如果直接导入自己已有的图片，可以减少为这些页面重新生图的需要，但不代表所有环节都没有成本。

还需要注意，项目的MIT许可证不等于所有依赖都采用MIT。

Remotion有自己的许可规则。个人、小型团队和较大组织的使用条件不同，商业项目或对外提供的生成工具应单独核对适用条款。

故事文本、插画、参考素材和后期音乐，也需要分别确认使用权限。

另外，项目默认输出没有声音。配音、背景音乐和音画对齐属于后期工作，演示视频中出现音乐，也不意味着渲染器会自动为每段故事生成音轨。

总结｜它真正解决的，是手绘视频里那些重复又零散的工作

story-to-handdrawn-video没有试图包办所有视频创作。

它选择了一条比较明确的路线：整理故事、准备画面，再用可调整的程序化动画把页面连接起来。

对内容创作者来说，值得关注的不是“又多了一个生图工具”，而是手绘视频能否形成一套可以检查、修改和重复使用的流程。

分镜可以先看，画风可以复用，素材可以导入，预览确认后再输出正式画面轨。

不过，文字准确性、人物连续性、配音节奏和最终观感，仍然需要创作者把关。

真正有价值的自动化，不是让人完全不看过程，而是把重复操作交给工具，让人有更多时间判断故事好不好看。

对于已经有文案或插画，又想尝试手绘故事视频的人来说，这个开源项目提供了一条值得动手验证的路线。

story-to-handdrawn-video项目仓库
https://github.com/gnipbao/story-to-handdrawn-video