“同人手书”这个类型很多刚接触的人会下意识把它归为“画画”的范畴画得好看视频就成了一大半。但真上手做过几个镜头之后你会发现一个截然不同的结论同人手书更像一个轻量级视频工程项目最大的敌人不是绘画水平而是流程失控。以《路易斯安那系列 | 同人手书·漂浮游戏》为例这类带世界观背景、有人物设定、需要连续叙事镜头的系列作品一旦镜头数量多起来就会出现一串非常具体的“工程事故”文件改了十几版之后不知道哪个才是最终版画完角色却找不到对应背景音频时长和画面长度对不上合成时才发现帧率、分辨率里混了好几个规格最后渲染出来颜色又和预告片差了一截。这篇博客不会替你写剧情也不会评价画风。我会把《漂浮游戏》当作一个“软件开发项目”来拆解重点讲一套可以复制到个人或小团队同人创作中的生产流程如何用 JSON 管理分镜、用 Python 自动化检查素材、用表达式批量生成漂浮运动、用 ffmpeg 完成合成与渲染。即使你现在完全不打算用代码处理创作也能从这套流程里拿走一些立竿见影的经验。1. 这篇文章真正要解决的问题同人手书不是“画不出来”而是“工程失控”先说结论同人手书里最贵的成本是返工而不是绘画本身。很多同人视频项目一开始都是这样推进的先脑补一个很有感觉的剧情然后打开画板开始画画到一半觉得节奏不对回头改分镜分镜一改前面画好的素材就作废一部分素材开始堆积之后又出现“这张图是给哪个镜头用的”这类问题等到剪辑阶段才发现音频和画面的时值根本没对齐。这在“路易斯安那系列”这样具有连续世界观和复杂故事线索的系列手书中会被放得更大。因为系列意味着人物关系、场景风格、道具设定都要保持跨镜头的一致如果中间任何一个环节丢失了“当前项目的标准信息”每个镜头就会各自为政风格自然失控。我见过最典型的场景是这样的角色素材文件夹里同时存在默认图层、表情改、发光版、最终版、最终版2、最终_真的不改了三个版本分镜本来在电子文档里是第 4 话剪辑工程里编号却是 PV02_04有人把所有背景图拖到一个文件夹文件名是背景1.png、背景2.png渲染预览时发现第一个镜头是 1920x108030fps第二个镜头是 2560x144025fps第三个直接是竖屏导出的。这些问题任何一个拿出来都不严重但叠加在一起就会把创作时间大量消耗在“找文件、对编号、重命名、重新渲染”上。这也是为什么我强烈建议做手书之前先画好一张“工程蓝图”把分镜、素材、时间、渲染都变成结构化数据而不是靠脑子和聊天记录。这篇文章要解决的就是怎么用最低成本把这套蓝图搭起来。你不用掌握很深的编程只要能看懂 JSON、会用 Python 运行脚本、能复制 ffmpeg 命令就可以把过去最耗时的整理工作交给脚本去做。2. 先把项目拆清楚路易斯安那系列、同人手书与“漂浮游戏”要让流程有效第一步是确认项目里的概念边界。这里有几个容易含糊的词必须先定义清楚。2.1 什么是“同人手书”“手书”在中文同人创作圈里通常指作者基于某部已有作品的角色、世界观或设定手工绘制动画画面再配合音乐和叙事做成视频的一种同人创作形式。它和逐帧动画不一样。逐帧动画通常追求连续、完整的运动规律而手书更接近“把关键性场面画出来用镜头语言和音乐节奏带动情绪”。所以手书往往画面张数不多但必须有强烈的画面设计感和叙事效率。这也是手书非常适合“工程化管理”的原因。张数不多意味着素材数量可控画面设计感强意味着镜头规划和分镜设计非常重要音乐驱动意味着音画对齐是一个硬性指标不能用“差不多”糊弄过去。2.2 “系列”意味着什么标题里“路易斯安那系列”中的“系列”并不只是一个普通的作品标签。它意味着这是一个多集、多视角、或者长期更新的创作计划。系列作品最需要的内容资产是“一致性”。角色在不同分镜里长得像同一个人场景在不同集数里风格统一道具、服装、氛围色符合同一个世界观镜头语言有系列惯性不能一集一个剪辑风格。这些要求决定了你的项目不能只靠单个画师“手感稳定”而必须有一套可供查询和参照的资料库。角色设定图、场景清单、配色规范、镜头风格参考都必须集中存放并且命名一致。2.3 “漂浮游戏”中的视觉关键词“漂浮游戏”这个标题其实就已经给出了大部分镜头的视觉方向漂浮、悬浮、失重、轻盈。不考虑剧情单看美术与动画“漂浮”这种运动状态和陆地行走、奔跑是有本质区别的角色移动速度更慢更强调惯性上浮和下沉不是匀速运动而是带有明显缓入缓出衣服、头发、配饰会滞后于主体动作形成拖拽感重力感减弱之后画面里往往需要补充粒子、水珠、光斑或尘埃来衬托空间。因此在拆分镜头时我们应该把所有和“漂浮”相关的动作定义成一种可以复用的动画参数而不是每个镜头都从零开始调。这样既能保证全片漂浮感统一又能节省大量调节时间。我们不需要在这里纠结“路易斯安那”具体对应哪个原作设定因为从流程设计角度来看任何系列世界观的通用逻辑都是相通的设定越完整越值得用结构化方式管理。3. 总体管线设计把一部同人手书当成一个软件项目来推进管线Pipeline这个词听起来很工业但实际上它就是为了解决一个问题让每个环节的产出能够被下一个环节稳定、高效地使用。以《漂浮游戏》为例我的建议是把它拆成七个阶段阶段核心任务产出物1. 策划与设定确定剧情、分镜、角色、场景、风格系列设定文档、分镜表2. 分镜清单把每个镜头变成结构化条目shot_list.json3. 素材制作画角色、场景、道具、特效素材规范命名的素材文件4. 动画处理给素材添加运动、表情、物理反馈动画关键帧、表达式5. 音频对位对齐 BGM、音效、对白音频时间码表6. 合成与渲染叠加图层、统一规格、输出视频预览视频、最终成片7. 发布与复盘分发平台、收集反馈、更新系列设定发布说明、经验记录从传统创作习惯看这个表并不神奇。真正重要的不是“分阶段”而是“阶段之间的接口”。比如绘画阶段结束之后合成阶段不会再去凭空找素材文件剪辑阶段开始之后不会因为分镜修改导致所有素材命名作废。为了做到这一点必须有一个贯穿始终的核心数据文件我建议就是shot_list.json。所有环节都围绕它生成和检查。这里有一个非常像软件开发的设计原则约定优于配置。与其让每个人按自己的习惯命名和组织文件不如先约定一套规范然后用脚本去校验和执行。这样做的代价是需要一点前期约束收益是后期省几百倍找文件、对编号的时间。4. 分镜表设计用一份 JSON 管住所有镜头分镜是整个视频的“产品需求文档”。它是一切的起点。过去我们可能用 Word 或 Excel 整理分镜这也没有问题。但如果你希望后续能用脚本自动检查素材、自动生成剪辑清单、自动对齐音频那更推荐把分镜表做成结构化数据比如 JSON。下面是一份简化的shot_list.json示例{ project: louisiana_float_game, episode: pv01, fps: 30, resolution: 1920x1080, shots: [ { id: S01_001, scene: 01, duration: 4.2, subject: 角色A从水面漂浮上升, camera: 固定机位轻微仰拍, fx: 水珠、光斑、浮空碎屑, audio: BGM_B_段环境水声, assets: { bg: BG_01_marsh, char: CHAR_A_default, fx: [FX_bubble, FX_light] }, note: 注意缓出漂浮感优先 }, { id: S01_002, scene: 01, duration: 3.8, subject: 角色A在悬浮物之间穿行, camera: 横移跟拍, fx: 悬浮石块、粒子拖尾, audio: BGM_C_段风噪, assets: { bg: BG_02_sky, char: CHAR_A_default, fx: [FX_stone, FX_dust] }, note: 前景与背景错峰运动 } ] }看到没有这里不只是记录“镜头拍什么”还把每个镜头需要用到的背景、角色、特效都列出来了。这么做有一个巨大的好处后续素材检查、渲染勾选、音频对齐都可以直接读取这份 JSON自动完成。分镜表字段的设计建议如下字段类型作用建议idstring镜头唯一编号统一格式如 S01_001scenestring所属场次按场景编号分块durationnumber镜头时长秒前期预估即可subjectstring画面内容描述写清楚主体动作camerastring镜头运动固定、横移、摇镜等fxarray特效需求便于后续素材盘点audiostring音频对应点标记 BGM 段或音效assetsobject素材引用对应素材库 IDnotestring备注给合成师/画师的说明这份 JSON 可以和团队成员共享。如果你不想用复杂工具直接在文档里维护它也行。它比 Excel 强的地方是脚本可以直接读取。比如当你的项目已经画了一部分素材时你可以写一个 Python 脚本读取这份 JSON对比素材目录自动列出“哪个镜头还缺背景”“哪个镜头缺角色图层”。这比人工逐个核对快得多而且不会漏。5. 素材资产管理命名规范加上 Python 自动化检查同人手书项目里素材文件管理是最容易被低估的一项工作。很多人觉得“文件名嘛我自己看得懂就行”但两周之后回来看自己也看不懂了。这里我建议用一套固定规则来管理素材目录。以《漂浮游戏》为例目录结构可以是float_game/ ├── 00_project_settings/ │ └── shot_list.json ├── 01_assets/ │ ├── characters/ │ │ └── character_a/ │ │ ├── base/ │ │ ├── expressions/ │ │ └── poses/ │ ├── backgrounds/ │ ├── props/ │ └── fx/ ├── 02_storyboard/ │ └── S01_001.png ├── 03_source_footage/ │ ├── S01_001/ │ │ ├── layer_char.png │ │ ├── layer_bg.png │ │ └── layer_fx.png │ └── S01_002/ ├── 04_audio/ │ ├── bgm/ │ ├── sfx/ │ └── voice/ ├── 05_comp/ │ └── comp_s01_001.aep └── 06_render/ ├── proxy/ └── final/命名规则建议固定为[镜头ID]_[素材类型]_[版本].png示例S01_001_char_v01.pngS01_001_bg_v03.pngS01_002_fx_bubble_v01.png这样做的好处是当合成师拿到一个文件光看文件名就知道它是哪个镜头、什么类型、哪个版本不需要额外询问。有了目录和命名规范接下来就可以写一个简单的 Python 检查脚本。它的作用是读取shot_list.json检查每个镜头对应的素材目录是否都存在于03_source_footage下并警告缺失项。import json from pathlib import Path PROJECT Path(./float_game) SHOT_LIST PROJECT / 00_project_settings / shot_list.json SOURCE PROJECT / 03_source_footage def check_shot_assets(): data json.loads(SHOT_LIST.read_text(encodingutf-8)) print(f项目{data[project]}镜头数{len(data[shots])}) missing [] for shot in data[shots]: shot_id shot[id] shot_dir SOURCE / shot_id if not shot_dir.exists() or not any(shot_dir.rglob(*)): missing.append(shot_id) else: # 检查 JSON 中记录的素材是否都有实际文件 for asset_key, asset_value in shot.get(assets, {}).items(): if isinstance(asset_value, list): for item in asset_value: if not list(shot_dir.rglob(f*{item}*)): print(f [缺素材] {shot_id} - {item}) else: if not list(shot_dir.rglob(f*{asset_value}*)): print(f [缺素材] {shot_id} - {asset_value}) if missing: print(以下镜头没有任何素材请优先补齐) for m in missing: print(f - {m}) else: print(所有镜头都有至少一个素材目录。) if __name__ __main__: check_shot_assets()运行脚本的方式很简单cd float_game python check_assets.py这段脚本本身并不复杂但它负责的是“人最容易烦躁”的检查工作。它会明确告诉你哪个镜头还缺背景、哪个镜头没画角色图层从而把精力留给真正的创作。这里真正容易踩坑的地方是很多人会把素材文件随意丢到桌面或者下载目录等批量制作时才发现文件散了。规避方法很简单——从一开始就规定“所有原始素材只能进入01_assets或03_source_footage素材一旦完成就立刻按命名规则归档”。6. “漂浮感”的实现波动动画、相位错开与脚本生成在《漂浮游戏》这样的作品里“漂浮感”是核心视觉体验。很多刚开始做动画的朋友会犯一个错误让角色直接匀速上下移动结果画面看起来像“电梯运行”完全没有轻盈感。要想做出好的漂浮效果可以记住三个关键点第一漂浮不是匀速运动。真实世界中浮力不等于重力物体会在某个平衡点附近反复震荡。所以动画曲线应该更像正弦波上升减速、下降减速而不是直线往返。第二多个漂浮物体必须错开相位。如果画面里同时有五块石头都在做完全同步的上下浮动一眼看过去就会特别“假”。只有让它们的相位相互错开画面才会出现层次感。第三增加轻微随机抖动。现实不会像数学公式一样干净。一点点噪点扰动可以让对象更生动。这里我给出两套工具。第一套是 After Effects 表达式适合在 AE 里直接控制图层位置让它产生漂浮运动// 在 AE 图层“位置”属性的 Y 轴表达式 const amplitude 50; // 上下幅度像素 const speed 1.0; // 每秒浮动周期数 const phase 0.0; // 相位偏移多物体错开时使用 const y transform.position[1] amplitude * Math.sin(time * 2 * Math.PI * speed phase); [transform.position[0], y]使用方法是选中图层按 P 打开位置属性按住 Alt 点击“位置”前的码表把上面的表达式粘贴进去。不同的物体只需要修改phase比如前景石块相位给0.5背景浮板相位给2.1画面立刻就有错落感。第二套是 Python 脚本用于批量生成漂浮关键帧数值。如果你不想在 AE 里写表达式想用更可控的数值关键帧方式可以用这段脚本输出 JSON 或 CSVimport json import math import random def gen_float_frames(seconds, fps30, amplitude40, frequency0.8, noise2.0, seed7): rng random.Random(seed) frames [] for i in range(int(seconds * fps)): t i / fps wave amplitude * math.sin(2 * math.pi * frequency * t) jitter rng.uniform(-noise, noise) frames.append({frame: i, y_offset: round(wave jitter, 2)}) return frames # 以 4 秒镜头为例 data { shot: S01_001, fps: 30, frames: gen_float_frames(4.0) } print(json.dumps(data, ensure_asciiFalse, indent2))这段脚本运行后你可以把输出的 JSON 导入到剪辑或合成软件里作为关键帧偏移数据。这样做的最大好处是所有镜头的浮动参数都可以集中在一份脚本里统一调整。如果后期你觉得浮动幅度太大只需要改一个amplitude参数然后重新生成所有镜头的关键帧数据而不用手工逐条改。在这个阶段建议在合成工程里把“浮动动画”和“角色原始图层”分开管理。角色图层负责有没有表情、动作浮动控制层负责整体位置变化。这样当你想替换角色表情时不会影响已经调好的漂浮运动。7. 合成与渲染ffmpeg 批处理与预览迭代工作流到了合成与渲染阶段很多人会一股脑直接出最终视频。但在工程化流程里我会强烈建议先做“代理预览”。代理Proxy的意思是把高分辨率素材临时压缩成低分辨率版本先用低画质完成剪辑节奏和镜头顺序的确认等确认无误后再用原始素材渲染最终版。这样能大幅减少预览等待时间尤其是当工程里堆了几十个大体积 PSD 或 ProRes 素材时。ffmpeg 在代理预览中非常有价值。下面这个命令可以把原始镜头统一转换为 1920x1080、30fps 的预览视频ffmpeg -i raw_shot_001.mov -vf scale1920:1080,fps30 -c:v libx264 -crf 23 -preset fast shot_001_preview.mp4如果你有角色绿幕素材需要把角色抠出来合成到背景上也可以用 ffmpeg 快速完成一版测试合成ffmpeg -loop 1 -i background.png -i character.mov \ -filter_complex [1:v]chromakey0x00FF00:0.12:0.18[fg];[0:v][fg]overlay0:0:shortest1[out] \ -map [out] -t 4.2 -c:v libx264 -crf 20 composed_test.mp4注意这个命令里的0x00FF00是绿色背景的色值0.12是相似度阈值0.18是平滑度。如果你的素材是蓝色背景需要把色值改成0x0000FF。当你把多个镜头大致剪好、顺序确认后可以用 ffmpeg 的 concat 功能把多个视频片段拼起来做连续性预览printf file shot_001.mp4\nfile shot_002.mp4\nfile shot_003.mp4\n concat.txt ffmpeg -f concat -safe 0 -i concat.txt -c copy all_shots_preview.mp4这里有一个重要的注意事项concat 命令要求所有视频使用相同的编码参数、分辨率、帧率和音频格式。如果各镜头规格不统一会出现拼接失败或者音画错位。所以最好在拼接前先用第一条命令统一规格。最后为成品合成背景音乐和音效可以这样把画面和音频合到一起ffmpeg -i all_shots.mp4 -i bgm_ost.m4a -shortest -c:v libx264 -crf 18 -c:a aac final_float_game.mp4在整个渲染阶段我的建议是用低画质代理确认剪辑顺序和节奏。用原始素材渲染最终画面。渲染前检查所有素材的分辨率、帧率、色彩空间是否一致。渲染输出时保留一份无损或高质量母版而不是直接输出微信或视频平台用的压缩版。这样做的原因是平台压缩是不可逆的如果成片希望后续再做二次剪辑或复盘高画质母版会很有价值。8. 同人手书常见问题与排查思路在实际制作过程中以下问题出现的概率非常高。我整理成了一张排查表方便你按图索骥问题现象可能原因排查方式解决方案素材文件找不到文件命名不规范或没有按目录归档检查00_project_settings里的资产清单查看03_source_footage是否遗漏镜头目录建立统一命名规则用 Python 脚本自动检查动画看起来像“电梯”没有漂浮感只有匀速上下运动没有相位错开和随机抖动检查位置关键帧的曲线确认多个图层是否相位不同改用正弦波表达式并给每个物体设置不同 phase音画不同步镜头时长和音频段落不对齐对照分镜表里每个镜头的 duration 字段和音频时间码在剪辑软件里以音频波形的节拍点为基准重新切分镜头渲染出来颜色和预期不一致色彩空间不同或用了不同编码检查各素材的ICC配置查看渲染日志统一色彩空间导出时锁定同一编码配置同一系列不同集画风不一致缺少统一的角色设定和配色规范建立视觉规范文档并让所有创作者持续参考维护角色设定图、配色表、场景参考图作为项目基准合成时图层顺序错乱素材没有按“镜头ID 类型”命名导入顺序混乱检查文件名确认是否为最新的带版本号素材严格按照S01_001_char_v01.png这类规范命名导入时按类型分组代理预览卡顿代理分辨率仍然太高检查预览文件规格是否过高把代理分辨率降到 1280x720 或 960x540保证流畅剪辑最终输出文件太大码率设置过高没有统一压缩参数用 ffprobe 查看输出码率使用-crf 18~23控制 H.264 码率不要直接设超大 bitrate排查问题时最忌讳的是“凭感觉改”。先看日志、先看文件、先查分镜表然后定位到具体环节效率会高很多。如果音频对不上我的建议是不要在剪辑软件里手动拖到“感觉差不多了”而是先看音频波形把节拍点标出来再让分镜表里的镜头起点对齐到节拍点。这个方法比肉眼硬拖可靠得多。9. 工程化之外同人创作的边界、资产管理习惯与最佳实践流程工程化解决的是“怎么做”但同人创作还有一些边界和习惯不能忽略。第一保持创作环境整洁。不管是一个人做还是一个小团队协作都要把“素材整理”当成一项日常工作而不是最后一天通宵来补。可以给自己设定一个简单规则每画完