做“整本书自动转长视频”这条流水线我踩了快一个月的坑最后用一套全开源工具串起来了。这套方案解决的核心问题是PDF/EPUB电子书拿到手不用人工一句句写文案、不用手动配音、不用手动剪画面丢给流程自动跑几个小时就能产出一条带配音、带字幕、有画面的完整长视频。适合做读书讲解、知识类短视频、课件视频化的朋友参考也适合想搭建个人自动化内容管线的开发者。先说清楚我理解的“视频skill”它不是一个具体软件而是一个能力组合——把“输入一本书输出一条视频”这个复杂任务拆解成文本提取、内容分段、配音生成、画面渲染、字幕合成几个环节每个环节都用开源工具实现再串成一条可复用的流水线。这套组合不依赖任何商业平台数据全程本地处理可定制性非常高。1. 项目思路把整本书转成长视频核心不是“做视频”而是“拆流程”1.1 这个需求背后的真实场景我在做知识类短视频时发现一本书几百页内容如果靠人工提炼、写脚本、配音、剪辑一本书至少得投入一周时间。但书里很多内容本身是完整的线性叙述章节结构清晰非常适合自动切成视频单元。尤其是一些通识类、工具类、历史故事类书籍每章读出来就像一期播客配上背景画面就能当视频发。一开始我也试过直接拿整本书的文字去生成视频结果画面全是字幕朗读枯燥不说音频时长和画面帧数经常对不齐。后来我把流程拆成“文本处理”和“媒体生成”两条线前面的环节只做文字整备后面的环节只做音画合成问题才真正解决。这个拆分思路是整套方案的精髓你后面看每个环节都会发现所有细节都是在为“数据对齐”服务。1.2 全自动化的核心流程设计整条流水线分五个环节书稿解析、文本清洗与分段、自动配音、画面素材生成、音视频合成。箭头方向是单向的每个环节的输出都是下一个环节的输入中间不需要人工介入。书稿解析把 PDF、EPUB、TXT 等格式的书提取成纯文本这一步决定整条流水线的原料质量。文本清洗与分段去噪、去水印、修正OCR错字再按语义或章节把长文本切成短段落作为配音单元。自动配音每个短段落调用开源 TTS 引擎生成语音文件同时记录每句的起止时间。画面素材生成为每个段落生成背景画面可以是纯色渐变、关键词图片或者简单动态效果。音视频合成把语音和画面按时间轴拼接叠加字幕导出为 MP4。这个流程里我刻意让“文本分段”和“TTS 时间戳记录”作为中间枢纽。因为只要这两步做扎实了后面的画面和字幕都对得上最终视频就不可能出大问题。1.3 技术选型为什么这些开源工具最合适我最终的选型组合是Calibre PyMuPDF 负责书稿转换Python 正则 本地大模型做文本分段edge-tts 做中文配音FFmpeg PIL 生成画面MoviePy 做最终合成。整套工具全部开源没有授权限制。选择这套组合的考量很简单第一Calibre 处理 EPUB 几乎是行业标准遇到各种花式排版都能兜底第二edge-tts 的中文音色接近真人而且能直接拿到每个字的时间戳这对自动字幕来说太关键了第三FFmpeg 和 MoviePy 组合可以灵活控制视频码率、分辨率和封装格式完全能满足主流视频平台的发布要求。我也对比过商业 TTS 平台音质确实更好但批量调用要付费自动化的前提就直接破功了。2. 书预处理把各种格式的书变成干净文本这一步决定成败2.1 不同格式的提取方案拿到书之后先看格式。EPUB 是最好处理的本质上就是个 zip 压缩包用 Calibre 的ebook-convert命令一行就能转成 txtebook-convert input.epub output.txt需要注意的是这条命令转出来的 txt 里经常残留章节页码、出版信息、注释引用序号必须在后续清洗环节处理掉。PDF 分两种情况。如果是文字版 PDF直接用 PyMuPDFfitz按页提取文字import fitz doc fitz.open(input.pdf) with open(book.txt, w, encodingutf-8) as f: for page in doc: text page.get_text(text) f.write(text \n)如果是扫描版 PDF就需要先做 OCR。我推荐 PaddleOCR它对中文版面识别效果不错支持按行输出文字和坐标。如果你已经有在跑本地 Python 项目加一个 OCR 环节不会增加运维复杂度如果不想折腾也可以先用免费工具把扫描 PDF 转成文字 PDF再走上面的 PyMuPDF 流程。这里要特别提醒无论哪种提取方式输出的原始文本里都会混入大量干扰信息比如页眉页脚、图片说明、表格碎片。这些内容不清理干净后面 TTS 读起来会非常出戏——想象视频里突然冒出“第 37 页”或者“表 3-1”的机械朗读观众立马划走。2.2 文本清洗的关键细节我的清洗流程分三层。第一层是规则清理用正则删掉页码、页眉、URL、纯数字行import re def clean_text(raw_text): lines raw_text.splitlines() cleaned [] for line in lines: line line.strip() if re.fullmatch(r\d{1,4}, line): continue if re.search(rhttp[s]?://, line): continue if 目录 in line and len(line) 10: continue cleaned.append(line) return \n.join(cleaned)第二层是用 OCR 上下文修复明显错字。比如“凡例”被识别成“凡列”这种情况靠规则很难全覆盖我的做法是整理一份高频错字映射表用替换的方式批量修正。第三层是段落重排很多 PDF 提取出来是每行一段需要把在正文行尾没有句号的行合并起来。这些细节听起来繁琐但实际做一遍也就几十行代码。真正让我节省时间的是把清洗逻辑写成独立脚本放进整个流水线的开头。以后不管输入什么书直接跑同一套清洗遇到特殊问题再往映射表里加规则就行。2.3 章节切分与内容分段策略清洗完的全文需要切成适合配音的片段。切片长度直接决定观众体验太短了视频显得支离破碎太长了单集没有节奏感也容易因为 TTS 单次朗读时间太长而出错。我的经验值是每段控制在 200~300 个汉字之间大约朗读 40 到 60 秒。具体做法是先按目录或标题关键词把书切成章节再把每个章节内部按段落聚类遇到明显的语义转折点就断开。这一步需要一点自然语言处理技巧。如果只是纯规则切容易把完整的因果叙述切断如果完全按段落切有些三四百字的长段落又超时。我的方案是优先保留原文段落段落超过 300 字时按句号、分号、省略号等完整句边界二次切分段落太短少于 80 字时与下一段合并。这样既保持了语义连贯又控制住了时长。3. 配音环节让每段文字自动开口说话音色和节奏是关键3.1 TTS 引擎选型与音色参数对比TTS 是整个流水线里观众感知最强的一环一个生硬的机器音能把内容再好也毁了。我用的 edge-tts 是基于微软神经网络语音的开源封装支持中文普通话、粤语、台湾腔等多种音色最常用的三个音色名称风格适合内容语速建议zh-CN-XiaoxiaoNeural温柔女声通用讲解、情感类内容0% 到 5%zh-CN-YunxiNeural阳光男声技术教程、故事类内容5% 到 10%zh-CN-YunjianNeural沉稳男声历史、财经、深度分析-5% 到 0%我平时讲技术内容固定用 Yunxi因为他的句尾上扬感和停顿比较自然长时间听不疲劳。如果你做的是情感类、励志类视频Xiaoxiao 更合适。调用方式非常简单edge-tts --voice zh-CN-YunxiNeural --rate5% --text 要朗读的文字 --write-media output.mp3还可以同时生成字幕时间轴稍后细说。3.2 配音脚本的生成与处理一本书几十万字逐条手动调用显然不现实。我会把分段后的文本写入一个 CSV 文件每行一条再用 Python 循环调用 edge-tts 生成音频文件。这里唯一要注意的是edge-tts 对单次请求文本长度有限制建议每段音频单独生成不要试图一次生成整章节。我踩过最大的坑是并发问题。刚开始我写了个多线程脚本同时跑 10 个 TTS 请求结果大量音频文件只有前半段。排查后确认是 TTS 服务端对并发连接有限制。解决方案是把并发数降到 3并且每段音频生成后校验文件大小小于 10KB 的视为失败重新生成。这里还有个实用技巧在调用 TTS 时把每段的章节号和段落号写进文件名例如chapter3_004.mp3。后面做字幕和合成时通过文件名排序就能保证顺序不错乱。3.3 配音时长与节奏控制生成音频后用 ffprobe 获取每段音频的时长并保存到时长表中。这个时长表是后面视频合成的核心依据画面停留时长、字幕显示时长全部由它驱动。我推荐的节奏控制方式是在每段开头加入极短的静音避免段落之间衔接过于突兀。edge-tts 本身没有直接的静音参数我的做法是用 pydub 在每段音频前后各插入 200ms 静音from pydub import AudioSegment audio AudioSegment.from_file(chapter3_004.mp3) silence AudioSegment.silent(duration200) combined silence audio silence combined.export(chapter3_004_final.mp3, formatmp3)实际跑下来这种微调能显著提升听感尤其是连续章节切换时不会出现“上一句刚读完下一句立刻蹦出来”的紧张感。4. 视频合成把文本、语音、画面拼接成完整长视频4.1 画面素材从哪里来画面素材是这条流水线里最容易被忽视的部分。最朴素的方案是用一张纯色背景图垫底在图上叠加段落文字类似“文字提词器视频”。如果想做得更有观赏性我推荐两种开源路线。一种是按段落关键词匹配本地图片库比如做历史类书匹配到“故宫”“长城”等关键词时就抽取对应图片用 FFmpeg 的 zoompan 滤镜做缓慢缩放形成类似纪录片的动态感。另一种是用 PIL 动态生成渐变背景配合标题和段落文字这种做法完全不依赖外部素材而且视觉风格统一适合批量生产。我实际常用的是第三种组合首尾用书籍封面信息做片头片尾正文段落用“关键词模糊匹配图片渐变蒙层文字浮现”成本低且观感在线。4.2 字幕生成方案字幕生成有两个思路。思路一是用 edge-tts 生成每个字的时间戳逐句对齐后生成 SRT 字幕文件思路二是用 whisper 对音频做转写自动生成带时间戳的字幕。我强烈建议用思路一因为 TTS 是机器合成的文本本身就是正确答案没必要再用语音识别走弯路。edge-tts 可以生成 word boundary 数据edge-tts --voice zh-CN-YunxiNeural --text 测试文字 --write-media out.mp3 --write-subtitles out.vtt它输出的 WebVTT 字幕文件里带每一句话的时间点用 Python 把 VTT 转成 SRT 格式即可。这样做的好处是字幕与音频天生同步不会出现口型对不上的问题。对于视频平台SRT 格式直接可用如果你要烧录到画面里可以用 ffmpeg 的 subtitles 滤镜将字幕写进视频。4.3 用 MoviePy 完成最终合成所有素材准备完毕后合成环节我用 MoviePy 按时间轴拼接。核心逻辑是遍历所有音频文件对每个音频创建一个时长相同的画面片段画面片段上叠加对应文字字幕再把所有片段按顺序接起来。一个简化版的核心代码from moviepy.editor import * clips [] current_time 0 for audio_path, subtitle_text in zip(audio_files, subtitle_texts): audio AudioFileClip(audio_path) duration audio.duration # 用 PIL 生成背景图层再加载为 MoviePy ImageClip bg_path generate_background(chapter_title, index) clip ImageClip(bg_path).set_duration(duration) # 叠加字幕文本 txt_clip TextClip( subtitle_text, fontsize52, colorwhite, fontMicrosoft-YaHei, size(1280, 720), methodcaption, aligncenter ).set_duration(duration).set_start(0) composite CompositeVideoClip([clip, txt_clip]).set_audio(audio) clips.append(composite) final_video concatenate_videoclips(clips, methodcompose) final_video.write_videofile(output.mp4, fps24, codeclibx264, audio_codecaac)这里generate_background是我自己写的背景生成函数根据当前段落的关键词去匹配预先准备好的图片。如果你的书有几十个章节最好做一层缓存避免每段都重新读图、缩放、加蒙层能省不少时间。输出参数方面推荐 1920x1080 或 1280x720 分辨率24 帧或 30 帧视频码率 4000kbps 左右H.264 AAC 是目前各大平台的通吃组合。整本书如果特别长比如六七个小时不建议一次跑完最好按章节单独输出再用 ffmpeg concat 协议合并。5. 常见问题与排查技巧实录5.1 高频问题速查我把这条流水线跑了几十轮整理了出现频率最高的问题和排查路径现象可能原因解决方案音频只有开头一句TTS 请求超时或并发限制降低并发数校验文件大小并重试字幕与音画不同步VTT 时间戳解析错误检查是否按每段单独生成字幕不要跨段拼接视频画面卡顿图片分辨率过大背景图统一缩放为 1920x1080避免超大原始图合成时内存爆掉一次性加载所有音视频片按章节分组导出再合并中文文字显示为方框MoviePy 缺少中文字体指定系统已安装中文字体如Microsoft-YaHei段落顺序错乱文件名排序不统一文件名用章节号序号补零如ch03_0045.2 我踩过的坑和独家心法这里分享几个不太容易在文档里看到的经验。第一严禁在一开始就想做一个“完全通用的工具”。书的领域、排版、语言风格差异太大通用性越强代码复杂度越不可控。我的做法是先针对一类书比如中文人文社科类把流程跑通再反向抽象出通用接口。第二文本清洗比技术选型更重要。我试过用大模型直接整书生成脚本效果不稳定且成本高反而是先做轻量规则的清洗和分段只把“语义聚类”和“标题补充”这类任务交给大模型整体效果最稳。第三批量生产时务必记录中间产物。我每本书都会生成一个work/目录里面按01_clean_text/、02_segments/、03_audio/、04_images/、05_video/分目录存放中间结果。这样任何环节出问题都能从断点继续不用从头跑。遇到需要微调配音音色或字幕样式的情况也能单独重跑对应环节。最后还有一个心法不要把整本书一次性塞进一条命令跑到底。我的流程支持断点续跑比如书稿解析完先人工扫一眼清洗后的文本确认关键部分没问题再继续往下跑。这个习惯帮我避免了两次“整本书跑完才发现前面章节被清洗规则误删”的惨痛经历。这套流水线跑顺之后不只是书任何长文档都能自动转成视频。把方法沉淀成自己的 skill以后换一本书换一套素材换个音色都是改配置的事。