先说一句可能让很多人意外的话：看到“Claude Opus 5.5”这个名字，你可能第一反应是它和“文生视频”工具一样，输入一句话就能直接“生成”一段成品视频。这个印象不能说全错，但和实际情况差得很远。我实际动手做了几次之后才彻底反应过来——Claude Opus 5.5真正做的是“写代码”，视频是这段代码跑出来的。它自己根本不直接生成视频文件，而是把“做视频”这件事拆成一个又一个确定性的程序步骤，交给Python生态里的图像库、音频库、剪辑库去执行。这篇文章，我想把这条“代码视频的五步流水线”从头到尾拆开，讲清楚每一步在做啥、为什么必须这么排、以及如果你也想做同样的事，可以怎么复现，少走哪些弯路。

这个内容适合两类人看：一类是刚开始接触AI生成内容、以为工具能一键出片的新手，可以先破除幻觉；另一类是已经在跑Notebook、想系统性掌握“AI生成视频”正确姿势的开发者。我下面会把五个步骤分别拆开，从素材规划、画面渲染、语音合成、视频拼接，到最终转码发布，每一步配代码、配参数、配踩坑记录。全部跑通的代码量并不大，但你在任何一个环节漏掉细节，视频就会出现乱码、没声音、画面卡顿或者音画不同步的问题。所以我建议你跟着这篇文章，把每一步亲手跑一遍，不要跳过中间任何一段。

1. 先打破幻觉：Claude不产视频，它产代码

很多人都在社交媒体上看过那种“AI生成的一段小短片”，配文写着“用Claude做了一条视频”。实际上这句话的完整版本是：我用Claude写了一段Python脚本，脚本调用Pillow画分镜图、用gTTS合成语音、用Pydub处理音频、用MoviePy拼接画面，最后再用FFmpeg渲染，最终才得到一个MP4文件。Claude Opus 5.5在这一整条链路里扮演的是一个“施工队长”的角色，而不是“一台视频生成机”。

1.1 为什么大家会产生这种误解

原因是多方面的。首先，不管是哪家的大语言模型，用户界面都长得很像“对话框”：你输入文字，它输出内容。这和视频生成工具的交互方式一模一样，区别只在于输出的是一个MP4还是一个代码块。当你看到一个代码块里写着ImageClip、AudioFileClip、write_videofile这些字样时，潜意识会把这些东西归并成“AI生成了视频”。其次，很多演示视频只展示结果，不展示过程——你看到的是成片，看不到中间那一大堆png文件和mp3文件。这就好比你看到外卖小哥把菜送到门口，会以为菜是他炒的。

但搞清楚了这一点之后，反而会有个好处：你可以完全掌控每一步的细节。大多数“直接生成视频”的工具是个黑盒，分镜不能调、字体不能换、语音情感不能改。而用代码流水线，你等于把整个视频制作过程拆成了五个可替换的零件。任何一个环节不满意，你只需要修改对应的代码段再跑一次就好。

1.2 五步流水线的全貌与各环节分工

我把这条流水线整理成一张清晰的分工表，先让你看到全貌：

后面几个大节，我就按这张表的顺序逐个讲。你需要注意，这五个环节不是等重的。第一步“规划”最容易被新手跳过，但恰恰是它决定了后面所有代码能否自动化跑通。如果第一步输出的是散乱的文字，第二步到第五步你就得手动去做大量调整，那还不如直接用剪辑软件。所以我建议你把重心放在理解第一步的数据结构上。

2. 第一步：素材预规划，所有内容先变成一份清单

拿到一个视频需求时，大多数人会让Claude“直接开始做”，这是我最不建议的做法。直接把目标甩给模型，它大概率会一边写代码一边临时决定标题文字、旁白内容、每段画面的停留时长，结果就是你得到一段能跑但完全无法控制的视频。我更倾向的先做素材预规划：把所有与视频内容相关的信息抽象成一份JSON清单，让后续每段Python代码都依赖这份清单去执行。这一步的本质，是把“创意”翻译成“数据”。

2.1 结构化脚本与分镜约定

你需要让Claude先输出一个明确的分享结构。我自己常用的约定是：一段视频按“开场 + 三个知识块 + 收尾”划分，五个场景以内，每个场景都包含“标题、副标题、正文、旁白、时长”。比如做一条科普类短视频，我会要求Claude给出类似这样的一份JSON：

{ "resolution": [1920, 1080], "fps": 30, "scenes": [ { "scene_id": 1, "title": "什么是代码视频？", "subtitle": "打破一键生成幻觉", "body": "很多人以为AI直接生成视频，其实是AI写代码。", "voiceover": "你以为AI直接生成了视频，实际是靠一段段代码画图、发声、剪辑。", "duration_hint": 5 }, { "scene_id": 2, "title": "第一步：素材规划", "subtitle": "用JSON约束内容", "body": "把脚本拆成分镜，让每个画面和每句话一一对应。", "voiceover": "第一步，把所有素材规划成一份清单，让画面和语音一一对应。", "duration_hint": 6 } ] }

为什么必须用JSON而不是直接给文字？因为JSON有明确的键值结构，后面你写Pillow渲染代码时，可以用scene["title"]直接取数据，用scene["voiceover"]直接做语音合成。程序代码不需要做任何“语义理解”，只需要按字典的键去取值。这就把所有不确定性从执行环节挤出去了。你现在可以实验一下：让Claude按这个格式输出6个场景，大部分情况下它能做得很好；如果它漏了字段，你只需要在系统提示里强调“必须包含voiceover和duration_hint”。

2.2 用JSON约束画面与语音的对应关系

这一份JSON存在的意义，是建立起“画面 ↔ 语音 ↔ 时间”三者的映射关系。在第四步拼接视频时，MoviePy需要知道每张图片要显示多长时间；在第五步合成视频时，FFmpeg需要音量信息和字幕出现时间。这些数据全部来自这份JSON，不需要你在剪辑软件里重新对齐。

我自己习惯在JSON里额外加一个“visual_style”字段，用来统一全片视觉风格，比如“深蓝背景”“白色大字”“居中排版”。加上这个字段以后，第二步渲染代码会遍历所有场景统一应用，整条视频的观感会非常一致。不然你一段白底、一段黑底，衔接起来特别像PPT拼接，观感很差。你可以理解为，这份JSON是所有后续脚本的“数据库”，而视觉风格就是数据库里的一个全局配置字段。

一个很容易忽略的点：每段旁白的长度会决定画面对应的播放时长。我有一次把“voiceover”写得很长，但duration_hint只给了5秒，后期语音还没播完画面就已经切换了。所以我在这个阶段会多做一个动作，让Claude预估一下每段旁白读完大概需要几秒，并把对应的建议时长填进去。如果它经验不足，你可以在后续第三步用Pydub量出实际时长后再回填一次，这一步我们马上会讲到。

3. 第二步：用Pillow逐帧“画”出画面

当JSON里有了全部内容后，接下来真正把“文字变成图”的是图像处理库Pillow。它不像视频生成模型那样会根据语义去“想象”画面，它做的事情非常机械：创建一个指定尺寸的画布、填充背景色、读取字体文件、把文字画上去、保存成PNG。这个过程不涉及任何AI推理，所以你完全不需要GPU，任何一台普通PC都能跑。

3.1 Pillow的渲染原理与中文支持

如果你第一次接触Pillow，可以把它的工作方式理解成“用代码替你在画图软件里点了一遍工具栏”。你告诉它“新建一个1920x1080的白色图层”，它就新建；“在这个位置写上这段文字”，它就写；“把这个文件存成PNG”，它就存。那为什么还要让大模型来写这段代码？因为“在哪个位置写什么字、用什么颜色、字体多大”这些排版决策，恰恰是Claude Opus 5.5最擅长做的。它能在几秒钟内根据JSON里的字段生成一整套布局代码，比你自己对着坐标调快得多。

不过这里有一个高频天坑——中文乱码。Pillow的默认字体不支持中文，如果你不指定一个包含中文字符的字体文件，写入图片的全部中文字符都会变成方块。我处理的方案是预先准备一个开源中文字体文件，并把路径写入代码。以文泉驿正黑或者思源黑体为例，它们的通用性都很好。使用方法很简单：

from PIL import Image, ImageDraw, ImageFont img = Image.new("RGB", (1920, 1080), "#1C1C2E") draw = ImageDraw.Draw(img) font_title = ImageFont.truetype("SourceHanSansSC-Medium.otf", 84) font_body = ImageFont.truetype("SourceHanSansSC-Regular.otf", 40) scene = scenes[0] draw.text((140, 180), scene["title"], font=font_title, fill="#FFFFFF") draw.text((140, 320), scene["subtitle"], font=font_body, fill="#A0A0C0") draw.text((140, 420), scene["body"], font=font_body, fill="#E0E0E0") img.save(f"scene_{scene['scene_id']}.png")

这段代码你直接复制到自己环境中跑也没问题，前提是你下载了对应字体文件。标题字号我设置得比正文字号大一倍，副标题用更柔和的浅灰色，这样画面层次感会更好。第一次跑的时候，你可能需要微调坐标值，别怕，这本来就是正常的调试过程。

3.2 画布、字体与版式的实操细节

版式设计上，我建议你先想清楚“这条视频在哪看”。如果在手机端竖屏短视频平台看，那么画布应该设置成1080x1920；如果是横屏的课堂讲解或B站知识区视频，1920x1080更合适。分辨率一旦定下来，后面所有分镜图、字幕都会围绕这个尺寸，不要中途更换，否则后处理阶段会非常痛苦。

另一个经验是别让画面信息太满。很多人第一次让AI写渲染脚本时，会倾向于把所有文字堆到一屏上，结果视频播放时观众根本没时间看完全部内容。我的做法是：一屏只承载一个核心信息。比如讲“代码视频”这个概念，画面上只有一行大标题和最多三行正文摘要，详细解释完全交给配音。这样观众眼睛不累，成片节奏也更接近专业短视频的观感。

还有一个配色小技巧：背景统一用深色，字体用高对比度的白色或浅灰色，这样即使视频被压缩后也能保持可读性。如果背景是深蓝，标题是白色，整体会显得干净；如果画面里出现了多张分镜，用同一套背景色方案，切换时不那么突兀。你可以在JSON的visual_style字段里把这些设定记录好，方便二次生成时保持一致。

4. 第三步：用Pydub与TTS产出语音和字幕时间轴

画面生成之后，视频还缺“声音”。这一部分，Claude同样不能直接“发声”，它需要调用文本转语音工具，再通过音频库Pydub来读取音频时长、切片、统一格式。文字转语音我目前用得比较多的是gTTS，因为它对中文支持简单，调用接口就能直接返回MP3文件。如果你有更高的音质需求，也可以换成商用TTS，但链路是一样的：先合成整段音频，再用Pydub整理时长。

4.1 TTS的边界与旁白生成方法

你必须在思维上明确一点：Claude Opus 5.5不负责出声，它只负责生成“调用TTS接口的代码”。具体到实操中，我把每个场景的voiceover字段取出来，循环调用gTTS，生成这个场景对应的语音文件。下面这段代码是可以直接用的：

from gtts import gTTS from pydub import AudioSegment voice_files = [] for scene in scenes: tts = gTTS(scene["voiceover"], lang="zh-CN") tts.save(f"voice_{scene['scene_id']}.mp3") audio = AudioSegment.from_mp3(f"voice_{scene['scene_id']}.mp3") duration_ms = len(audio) print(f"Scene {scene['scene_id']} duration: {duration_ms} ms") voice_files.append(f"voice_{scene['scene_id']}.mp3")

这里有个非常关键的实操细节：你本来计划的是画面时长由JSON里的duration_hint决定，但实际上“配音要多长时间”是TTS决定的。所以我在第二步得到画面图片后，并不急着设定图片播放时长，等第三步拿到duration_ms后，再用这个真实时长去覆盖JSON里的duration_hint。也就是说，视频的总节奏实际上是以“语音读完为准”。画面是静帧，它会一直停留到旁白结束，这种做法最适合这种讲解式短视频。

4.2 如何对齐字幕时间轴

假如你的视频需要字幕，就得把每个场景的语音起始时间记录下来。做法就是从第一个场景开始，逐步累加每个场景音频的毫秒数。比如第一个场景语音是4000毫秒，第二个是5000毫秒，那么第二个场景的字幕起始时间就是4000毫秒。把这份时间轴导出成外部字幕文件，在第五步用FFmpeg烧录即可。

这里有一个容易出问题的点：网络波动会导致TTS生成的语音文件损坏，偶尔返回一个空文件，长度是0毫秒。你在生产环境里需要加一个判断，如果duration_ms小于某一阈值，比如500毫秒，就重新生成一次，或者直接报错让你检查。否则一个长度为0的音频片段会让后续拼接视频时出现黑帧或者声画不同步。判断代码如下：

if duration_ms < 500: raise ValueError(f"Scene {scene['scene_id']} audio too short, regenerate")

还有一个建议：把每段音频统一格式。gTTS输出的是MP3，Pydub处理MP3需要有对应解码器，我一般会把它转为WAV再参与后续拼接，减少格式编解码带来的麻烦。尤其在MoviePy拼接时，WAV格式的兼容性远比MP3更稳。

5. 第四步：把静帧变成动态视频（MoviePy拼接）

到这里，你已经有了若干张1920x1080的PNG图片，以及若干个和它们对应的语音文件。接下来要做的是把它们合在一起，产生“视频感”。这一步的核心工具是MoviePy，它做的事情是把每一张图片当成一个静帧片段，设置好时长，把音频放进去，然后全部首尾拼接，再输出成一个连续播放的视频文件。如果你完全不做任何特效，那么成品看上去会像一个“有声图片播放器”；所以通常我还会加一点简单的缩放或平移效果，让画面不显得死板。

5.1 为什么用MoviePy而不是FFmpeg直接拼

你可能会问，FFmpeg也能把图片和音频拼成视频，为什么中间还要插一个MoviePy？原因是MoviePy用Python语法描述剪辑逻辑更直观，可以按JSON循环处理所有分镜，并且能非常自然地写“渐进缩放”这类动态特效。等逻辑跑通后，再用FFmpeg做最终编码和字幕压制。这样分工的好处是：剪辑逻辑在MoviePy里调整，编码参数在FFmpeg里调整，互不干扰。

下面这段代码，我会给每个图片片段加上一个轻度的“缓慢放大”效果，模拟摄像机推近的感觉，这种手法在剪辑里叫Ken Burns效果——它会让静态画面显得更有生命力：

from moviepy.editor import ImageClip, AudioFileClip, concatenate_videoclips clips = [] for scene in scenes: duration = scene["duration_ms"] / 1000.0 clip = ImageClip(f"scene_{scene['scene_id']}.png").set_duration(duration) # 慢速推近效果：从比例1.0放大到1.05 clip = clip.resize(lambda t: 1 + 0.05 * t / duration) audio = AudioFileClip(f"voice_{scene['scene_id']}.wav") clip = clip.set_audio(audio) clips.append(clip) final_video = concatenate_videoclips(clips, method="compose") final_video.write_videofile( "temp_no_audio.mp4", fps=30, codec="libx264", audio_codec="aac" )

这段代码跑完后，你已经得到了一个“有声无声暂且不论、画面至少能动”的临时视频。为什么要先输出temp_no_audio？因为我通常会在这一阶段只检查画面效果，确认没有问题后，再到最后一步做正式渲染并加字幕。如果直接一步到位输出成品，画面出问题时你得重新渲染老半天，非常浪费时间。

5.2 片段时长与淡入淡出的控制

在MoviePy里，每个片段的时长是“画面停留时长”，它的核心参考因素不是文字多少，而是配音长短。这也正是我前面强调先用语音时长回填JSON的原因。如果字幕和画面还没结束，语音却已经停了，整条视频会产生明显的“空洞感”；反之，语音还没说完就切换了画面，观众会感觉信息被拦腰截断。

在切换处，可以给ImageClip加一个很短的fadein和fadeout效果。注意，不要给每个片段都加很长的淡入淡出，那样整条视频会显得拖沓。我的参数是每个片段开头0.15秒淡入、结尾0.15秒淡出，只在画面切换时生效。这样既不突兀，也不会影响讲解节奏。

还有一个细节：如果你的JSON里有“片头标题”和“片尾结束语”这种特殊场景，我建议把它们单独拆出来，不要和其他知识块放在同一个循环里处理。它们的停留时长往往更长，背景可能也不一样，特殊处理会让成品更精致。

6. 第五步：用FFmpeg渲染、合成与发布

前四步跑完，你已经拿到一个临时MP4文件，它包含了画面和音频，但没有字幕，码率可能也比较“随意”。如果你只是自用，其实到这一步就可以收工了；但如果你打算传到短视频平台，或者给别人看，我建议再用FFmpeg做一次最终转码，烧录字幕并严格控制输出参数。FFmpeg在这里扮演的角色，相当于一个全能封装工匠。

6.1 准备字幕文件并烧录

字幕文件有很多种格式，最轻量易写的是SRT。每一条字幕需要记录序号、起始时间、结束时间、文本内容。如果你已经有了第四步的时间轴，生成SRT只是格式化字符串的工作。下面这个例子是一个SRT片段，时间格式是“时:分:秒,毫秒”：

1 00:00:00,000 --> 00:00:04,000 很多人以为AI直接生成视频 其实AI是写代码

生成好SRT后，用FFmpeg把它烧录到视频里。烧录的意思是，字幕文本被直接画进画面像素，成为视频的一部分，任何播放器打开都能看到；它区别于“外挂字幕”，后者某些播放器可能不会自动加载。烧录命令我通常会写成这样：

ffmpeg -i temp_no_audio.mp4 -vf "ass=subtitle.srt" -c:v libx264 -c:a aac -b:a 128k -pix_fmt yuv420p final_output.mp4

不过上面的命令里写的ass，实际需要先把我的SRT转成ASS文件，因为FFmpeg的subtitles滤镜对ASS兼容更好。先用下面的命令做一次转换：

ffmpeg -i subtitle.srt subtitle.ass

6.2 码率、分辨率与发布参数选择

处理发布时，不同平台对视频规格有不同偏好。我的经验是：竖屏内容优先推1080x1920，30fps，码率不超过6000kbps；横屏内容推1920x1080，30fps，码率控制在6000kbps以内。码率太高会导致上传变慢或者平台二次压缩过度，太低则画面会有马赛克。FFmpeg里可以直接用“-b:v 6000k”指定视频码率。

编码器方面我建议固定用libx264，兼容性最好，几乎所有平台都能直接读取。像素格式要指定为yuv420p，否则某些平台会无法解码。音频码率128k或192k对旁白都够用，声道用立体声或单声道都可以，纯人声旁白用单声道能省不少体积。

压完码率后，别忘了做最后一遍“人工抽检”，我一般会随机拖到视频的30%、70%位置，各看5秒，检查有没有乱码、黑屏、音画不同步。这一步不可省，因为你无法保证TTS没在某个拐点断句出问题。

7. 常见问题与排查技巧实录

这条视频流水线我跑了几十次，踩过的坑比预想中多。在这里挑几个高频问题整理成速查，希望能让你少走弯路。

7.1 中文字体乱码或方块字

这个问题出现的频率最高，几乎每个没准备字体文件的新手都会遇到。解决方案只有一条：在代码中显式加载一个包含中文字形的字体文件，不要依赖Pillow默认字体。下载一个开源字体，比如思源黑体、文泉驿正黑，放在项目目录里，并把ImageFont.truetype的路径指向它。注意检查你的字体文件格式，TTC和OTF都可能需要按不同方式加载，遇到问题先确认文件能否用字体软件正常打开。

7.2 TTS生成了空文件或超时长文件

网络不稳定或者语速变化，会导致gTTS输出与预期不符。我的做法是在第三步加一个“时长合理性检查”，如果音频长度小于500毫秒，或者大于预期的两倍，就重新生成一次。此外，如果旁白文本里有特殊符号，比如百分号“%”或英文引号，gTTS有时候会读得不对，建议把voiceover里的内容限制为口语化短句，不要放复杂公式或代码片段。

7.3 音画不同步与画面闪烁

音画不同步多数是因为用错了时长。如果你在第五步才意识到第2段画面时长和第2段语音对不上，那就回第四步检查是不是没有用duration_ms回填JSON。画面闪烁一般和淡入淡出参数设置过短有关，也可能是因为帧率不一致。统一把fps设为30，淡入淡出设为0.15秒，基本能消除。

7.4 内存不足或渲染卡死

MoviePy在处理很长的视频时会把多个片段读入内存，场景太多时容易卡死。我的对策是分段渲染，比如5个场景分成两次，第一次拼接前3个，第二次拼接后2个，最后再合并两个视频流。这个方法虽然多一步操作，但稳定性提升明显。

这里放一张常见问题速查表，方便你随时对照：

8. 一点个人心得

这套五步流水线跑到现在，我个人最看重的其实是第一步“素材预规划”。我见过的绝大多数失败案例，都不是败在画图或配音技术，而是败在没把“内容”抽象成一份严格的数据结构。当你把视频当成“数据驱动的渲染过程”而不是“灵感驱动的艺术创作”时，Claude Opus 5.5的威力才会真正发挥出来。它会帮你把重复劳动简化到最低：换一套JSON，换个文案，它就能在几分钟内重新生成一版风格统一的成片。

如果你想要把“AI生成视频”这件事持续做下去，我建议你把这套流水线保存成一个独立项目文件，把字体、素材、脚本都放在固定目录里。后续你做新视频时，只需要改JSON和重新跑一次全部脚本，整体效率比直接操作剪辑软件高很多。有人说这样做出的视频“没有灵魂”，但在我看来，能用程序稳定复现的流程，才是普通个人创作者稳定产出的起点。希望这篇拆解能给你提供一个清晰可靠的起步框架，让你少走我踩过的那些坑。