用Claude Opus 5.5打造代码视频五步流水线

先给你打个预防针：Claude Opus 5.5 并不会像 Sora 那样，给你一句话就吐出一段视频。很多人第一次听到“用 Claude 做视频”就往生成式视频那个方向想，但代码视频这条路完全是另一套逻辑——模型负责写代码，渲染引擎负责画画面，最后由 FFmpeg 之类的工具把帧串成片。这套流程我平时踩得比较多，把它总结成五个步骤，也就是标题里说的“五步流水线”。这篇文章就把每一步掰开揉碎讲清楚，包括需求怎么拆、技术栈怎么选、代码怎么写、渲染怎么调、最后怎么合成交付，适合刚接触代码视频、想亲手跑通一条完整链路的朋友，也适合已经被生成式视频的不可控搞到头大、想转投精确控制路线的人。

1. 先想清楚件事：Claude Opus 5.5 在流水线里到底干什么

1.1 “生成视频”和“写代码生成视频”是两条完全不同的路线

很多朋友有个思维惯性，觉得“AI 做视频”就等于输入一句描述，等程序自动生成一段画面。生成式视频模型确实是这么干的，它直接预测像素分布，输出 mp4 或者一组连续帧；而代码视频的路线完全相反——Claude Opus 5.5 这样的语言模型输出的是 Python、TypeScript、Shell 脚本，它生成的是“制作视频的程序”，不是视频本身。

我常用一个类比来解释这件事：生成式视频就像是请一位画师，你讲一段需求，他直接给你交一幅成品画，画得不对你也只能改描述从头再来；代码视频则更像是请一位程序员，他帮你写一套绘制脚本，你拿到的是配方和流程，哪里不对改哪里，改完重跑脚本就能看到新结果。

在演示动画、数学讲解、数据可视化、程序化艺术这些场景里，代码路线的优势非常明显。你会发现 Claude Opus 5.5 这类模型的角色更像“代码驱动器”，它把自然语言需求转换成可执行代码，再由本地渲染引擎一帧一帧把画面画出来。整个过程中模型没有直接产出一帧画面，但它决定了画面怎么被画出来。

1.2 代码路线三个不可忽视的好处

第一个好处是可控性。直接生成视频，你想让一个标题字从红色变成蓝色，大概率要重新生成整个片段；代码视频里这只是一个颜色变量的问题，改一行字符串，重新渲染，完事。这种“可修改性”在真实项目里太重要了，做视频不是一个一次成型的事情，返工才是常态。

第二个好处是可复用性。一套动画脚本就是一套模板，这周做一个算法讲解，下周换一组数据、换一个标题，逻辑完全不动。我经常一个项目里留下十来个场景脚本，后面做新视频直接用，根本不用每次从零开始。

第三个好处是可调试性。视频生成是黑盒子，代码视频不是。渲染出来的某一帧不对，你可以单帧查看，可以加 print 输出，可以让模型帮你检查哪里的坐标算错、哪里的字体没加载。问题定位到行，这体验是生成式模型给不了的。

当然代价也很直白：你得配环境、装依赖、处理字体、等渲染。这些成本在第一次搭建流水线时最高，跑通一次之后边际成本会越来越低。

1.3 五步流水线到底长什么样

我平时固定的流水线是这样，大家可以直接照着建立自己的工作流：

注意每一步的“主导者”都不一样。需求拆解必须由人来定，因为模型不知道你视频的受众是谁、重点讲什么；技术选型人可以参考模型建议；真正写代码的阶段才是模型的强项；渲染阶段是机器执行；最后的合成又是半自动操作。

说到底这五步不是丢一个提示词进去就自动完成的，而是“人 + 模型 + 工具链”的协作。搞清楚这一点，后面每一步的执行才会有正确的预期。

2. 需求拆解与技术栈选型：动手前的两个关键动作

2.1 先别急着写代码：把需求拆成镜头表

我见过不少朋友上来就让 Claude 直接生成一个“关于某某算法的 3 分钟动画”，结果就是模型给出一坨看起来很华丽、但根本跑不起来的代码。问题不在于模型能力，而在于需求颗粒度太粗。你给一个模糊的大需求，模型只能凭猜测写一个模糊的大脚本，出错概率高得吓人。

正确的做法是先拆镜头表。我自己用的是这样一个模板：

为什么镜头表这么重要？因为 Claude 这类模型的上下文学习和指令遵循能力是有上限的，给它一张结构化的镜头表，它更容易理解每个镜头的边界和顺序，生成的代码也更符合预期。镜头表本质上是把“一个视频”这个大任务分解成“多个小场景”的小任务，每个小任务独立生成独立渲染，最后再拼接，整个管线会稳定非常多。

拆表的时候注意四个信息维度：叙事时间轴、视觉风格、信息层、转场特效。镜头时长最好精确到秒，画面内容要能用一句话说清楚，字幕和解说词要单独列，转场方式也要写明确。这些信息越细，后续模型写代码时越省力。

2.2 技术栈选型：Manim、Remotion、Three.js、p5 怎么选

这是每次搭建流水线时最让人纠结的地方。选型没有绝对正确答案，但要匹配你的视频类型。

如果做数学讲解、算法演示、公式推导这类“逻辑型动画”，Manim 几乎是默认选项。它是 3Blue1Brown 开源的那个动画引擎，基于 Python，对公式、坐标系、几何变换的支持非常好，Claude 训练数据里包含大量 Manim 代码，生成质量和修复速度都明显靠谱。

如果做的是产品介绍、网页风格动效、带大量 UI 元素和文本排版内容的视频，Remotion 更顺手。它是基于 React 的视频生成框架，本质上是把网页渲染成视频，对样式和排版的控制力极强，适合程序员做技术宣传片。

如果做三维场景、数据可视化大屏类的视频，Three.js 是最常用的路线，配合 PPipe 或者直接用它自带渲染器导出序列帧。p5.js 则适合生成艺术风格的内容，粒子系统、噪波、分形这类视觉天然友好。

除了渲染引擎，还有一个必不可少的东西：FFmpeg。它不负责画画面，负责把画面串成视频、压编码、挂字幕、合音轨。所有路线到最后几乎都要经过它。

2.3 我现在常用的默认组合

说一下我目前最顺手的组合：Claude Opus 5.5 生成 Manim 脚本，Manim 输出 PNG 序列帧，FFmpeg 负责序列帧转视频和最终合成。

选这套组合的原因有三点。第一，Manim 脚本是纯 Python，对 Claude 来说生成难度低、错误率低，哪怕跑不通，把报错贴回去它也能快速修复。第二，Manim 自带高质量预览模式，可以先低清晰度跑一遍看看动画效果，确认没问题再正式渲染，这个迭代节奏太舒服了。第三，FFmpeg 作为最后一道工序，能统一处理每一镜头输出的编码格式，避免多段素材拼接时出现不兼容问题。

如果是数据可视化视频，我会让 Claude 先用 matplotlib 生成静态图表，再写一个 Manim 场景把图表图片放进动画里做平移、缩放、高亮。这种“静态图 + 动态效果”的组合比全部用代码绘图省事很多，渲染速度也快。

3. 代码生成与渲染校准：让模型写的每一段都能跑

3.1 给模型写代码的正确姿势：约束、分镜、迭代

和 Claude 协作写代码，尤其写视频脚本，核心原则是“一次只解决一个镜头”。我会先给它一个镜头表，让它针对单个镜头生成代码。一次性让它写完整条视频的脚本，大概率会写出一大段互相冲突的代码，而且一旦出问题，排查难度直接拉满。

我常用的写码 prompt 格式大概是这样的：

请用 manim 版本 0.18 生成一个 8 秒场景。背景色 #0d1117。画面内容：一个有序数组，包含 10 个整数，用圆角方块展示数字；目标值设为 7；动画过程是从数组中间位置开始逐段缩小搜索范围，最终目标方块变绿。字幕文案：“每次从中间开始找”。字体固定为 Noto Sans CJK SC，字体路径通过 config 注入。先输出 pip 安装命令，再输出完整可运行脚本，最后说明运行参数。

关键点在于：版本号、画面内容、字幕文案、字体路径、运行方式，每一项都给它明确边界。版本号尤其重要，manim 不同版本 API 有差异，不指定版本很容易拿到一个旧代码然后跑出一堆报错。

还有个小习惯：让模型先输出一个“工具函数”而不是全流程脚本。比如一个通用的数组可视化和高亮函数，先单独跑，确认没问题，再让它生成完整的场景代码。这样每一步都可验证，能迅速定位问题。

3.2 一个可直接跑的 Manim 示例

给一个我用得最多的简单场景，看完你就能理解代码视频的基本形态。下面这段代码会生成一个标题场景，黑底，文字淡入：

from manim import * class TitleScene(Scene): def construct(self): # 设置中文字体，避免渲染出来全是方框 Text.set_default(font="Noto Sans CJK SC") title = Text("代码视频五步流水线") self.play(Write(title)) self.wait(0.5)

运行命令很直接：

manim -pql demo.py TitleScene

参数含义简单解释一下：-p表示渲染完自动打开播放器，-q l是低质量预览，l代表 low；调试阶段永远先跑低质量，因为速度快。确认动画没问题后再用-q h或者直接指定分辨率输出正式版本。

你可能注意到我加了Text.set_default(font="Noto Sans CJK SC")这一行，这是代码视频踩坑的重灾区：Manim 默认字体不支持中文，不指定中文字体，渲染出来的中文全是豆腐块。这个细节我第三节专门展开讲。

3.3 渲染校准：分辨率、帧率、超时与字体这些坑

渲染校准阶段最容易忽略几个参数，我把它们列出来：

第一个是分辨率。短视频平台习惯 1080x1920 竖屏，B 站和 YouTube 惯例是 1920x1080 横屏，Manim 可以通过-r参数指定，比如-r 1920,1080。不要相信默认输出，默认配置可能不是你要的宽高比，最后发现素材对不上再做二次裁剪会很痛苦。

第二个是帧率。我默认用 30fps，短视频足够；遇到运动速度特别快的镜头，比如粒子飞散、高速切换，建议升级到 60fps，否则动起来会有闪烁感。但帧率翻倍意味着渲染时间接近翻倍，别在不需要的镜头上硬上 60fps。

第三个是超时问题。每个镜头渲染超过一定时间就失败，处理办法是拆镜头——一个大场景切成几个小场景，分别渲染再拼接。这比无脑加大超时参数更有效，因为超时往往不是机器慢，而是脚本里做了过于复杂的计算。

第四个就是中文字体。前面说了，Manim 默认字体不覆盖中文，需要手动指定支持中文的字库。Linux 上我安装fonts-noto-cjk包，Mac 上直接用系统自带的“PingFang SC”或“Heiti SC”，Windows 上一般用“SimHei”或“Microsoft YaHei”。指定字体时注意用系统能识别的字体名，路径或字体 ID 不对照样失效。

3.4 把“审美参数”暴露出来，而不是每次重写代码

我发现一个很实用的习惯：让 Claude 写代码时，把颜色、字体、缓动效果这种“审美参数”全部抽到一个配置文件里，而不是散落在代码各处。

STYLE = { "bg_color": "#0d1117", "highlight_color": "#58a6ff", "success_color": "#3fb950", "danger_color": "#f85149", "font": "Noto Sans CJK SC", "fps": 30, }

这样做的直接好处是，后续想让 Claude 调整风格只需要说“把底色改成浅色系”，它只改配置文件里的值，不会动核心动画逻辑。我自己的做法是先让模型生成这个 STYLE 字典，再在场景里引用，第一次多花半分钟，后面每次修改都能省五分钟。做视频哪有不返工的，返工时的修改成本才是真正的大头。

4. 合成与交付：FFmpeg 是流水线的最后一道工序

4.1 为什么不能跳过合成这一环

很多人以为单个镜头渲染出 mp4 就完事了，实际上不是。一个视频项目往往有 5 到 10 个镜头，每个镜头单独渲染，它们的分辨率和编码可能完全一致也可能不一致，但最终都要拼接成一条完整的成片，还要挂字幕和音轨。这些工作全部交给 FFmpeg 完成。

合成环节承担三件事：拼接多段素材、挂载字幕和音频、统一编码格式。我习惯让 Manim 输出带透明通道的 PNG 序列帧，然后统一交给 FFmpeg 做编码。这样每个镜头都能输出高质量单帧，最后合成时再统一压成 H.264 或者 H.265，避免中间反复压缩损失画质。

4.2 一套我常用的 FFmpeg 合成命令

先做最简单的拼接，把多个已经渲染好的 mp4 片段连起来：

echo "file 'scene1.mp4'" > list.txt echo "file 'scene2.mp4'" >> list.txt echo "file 'scene3.mp4'" >> list.txt ffmpeg -f concat -safe 0 -i list.txt -c:v libx264 -pix_fmt yuv420p -crf 18 out.mp4

-crf 18是质量参数，数值越小质量越高，18 到 23 之间是常用的高质量区间；-pix_fmt yuv420p则保证视频在各类播放器里都能正常解码，不指定这个参数很多播放器会出现色块或无法播放的问题。

如果是序列帧转视频，用这条：

ffmpeg -r 30 -i frame_%04d.png -c:v libx264 -pix_fmt yuv420p -crf 18 scene.mp4

-r 30是帧率，frame_%04d.png是文件名通配符，对应 frame_0001.png 到 frame_9999.png 这种命名格式。

再复杂一点，加上字幕和音轨：

ffmpeg -i out.mp4 -i audio.m4a -i subtitles.ass \ -c:v copy -c:a aac -c:s ass \ -map 0:v -map 1:a -map 2:s \ -shortest final.mp4

这里字幕文件用的是 ASS 格式，因为它对中文字体和样式控制更友好。建议制作视频时都用 ASS 而不是 SRT，ASS 能指定字体、字号、位置、描边，看起来专业很多。

4.3 交付检查清单

我在每次交付前会过一遍这份清单，避免翻车：

这个清单看起来是小事，但很多项目都是栽在这些小细节上。

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

5.1 中文字体显示成方块字符

这是我被问次数最多的问题。排查步骤简单直接：先确认系统里有没有中文字体，再确认 Manim 是否能按名字找到它。Linux 命令行输入fc-list :lang=zh能看到已安装的中文字体列表；Manim 脚本里用Text.set_default(font="字体名")指定；如果还不行就写绝对路径，用font="font.ttf 的路径"这种形式。字体问题 90% 出在字体名不匹配上，不是系统没字体。

5.2 渲染超时或长动画中断

单个镜头动画超过两分钟，基本都会遇到问题。我的习惯是超过 60 秒的镜头就拆分成多段，先渲染出三段小片，再用 FFmpeg 的 concat 拼接。另一个技巧是先用低分辨率跑完整条动画确认没有问题，再开正式分辨率渲染。低分辨率跑 2 分钟的视频也只要几十秒，而高分辨率一旦中途崩掉，损失的时间是不可逆的。

5.3 视频体积过大或画面有颗粒感

1080p 视频体积异常增大，多半是 CRF 值设置太低，或者画面里有大量高频噪点，比如粒子特效。降体积优先调 CRF，从 18 调到 23 能明显变小；噪点是渲染引擎的锯齿和美工特效导致，可以通过增加渲染采样次数解决；Manim 相关动画可以开抗锯齿提升平滑度。

5.4 Claude 生成的代码跑不通怎么办

这是代码视频日常里的日常。我的标准处理流程是三步。第一步，把完整报错信息原样发给 Claude，让它定位问题；第二步，注意反馈信息里要带上版本号，经常是 API 版本不匹配导致，比如旧版写法在新版本被弃用；第三步，用一个独立的虚拟环境跑项目，比如 venv，把所有依赖锁在固定版本，避免系统级依赖串了。

遇到那种反复修反复报错的情况，就换一个更小的复现用例，单独测一小段功能，而不是让模型继续在大脚本里找问题。代码视频的调试本身就是缩小范围的游戏，把问题的最小边界找出来，修复就快了。

我个人在实际操作中的体会很直接：代码视频这条路线最大的特点不是“一步到位”，而是每一步都能兜底。模型可能写错，渲染可能崩，合成可能出问题，但每个环节都有明确的手段去修复。如果你愿意花一个下午把这条流水线第一次完整跑通，后面再做什么视频都会顺畅很多，因为你手里有了一套能改、能调、能量产的“视频生产方式”。每次开工前我还会把分镜表里每个镜头的时间码打印出来，和成片时长做自动比对，早点发现问题能省下大把等待渲染的时间。这套东西用熟了，做视频就不再是碰运气，而是像工程流水线一样一步步产出成果。