先给你打个预防针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 五步流水线到底长什么样我平时固定的流水线是这样大家可以直接照着建立自己的工作流步骤做什么主要产物谁主导第一步需求拆解分镜表、镜头清单人第二步技术选型技术栈与依赖清单人 模型第三步代码生成各镜头的渲染脚本模型第四步渲染校准预览帧、正式渲染序列渲染引擎第五步合成交付拼接后的成片、字幕FFmpeg 等工具注意每一步的“主导者”都不一样。需求拆解必须由人来定因为模型不知道你视频的受众是谁、重点讲什么技术选型人可以参考模型建议真正写代码的阶段才是模型的强项渲染阶段是机器执行最后的合成又是半自动操作。说到底这五步不是丢一个提示词进去就自动完成的而是“人 模型 工具链”的协作。搞清楚这一点后面每一步的执行才会有正确的预期。2. 需求拆解与技术栈选型动手前的两个关键动作2.1 先别急着写代码把需求拆成镜头表我见过不少朋友上来就让 Claude 直接生成一个“关于某某算法的 3 分钟动画”结果就是模型给出一坨看起来很华丽、但根本跑不起来的代码。问题不在于模型能力而在于需求颗粒度太粗。你给一个模糊的大需求模型只能凭猜测写一个模糊的大脚本出错概率高得吓人。正确的做法是先拆镜头表。我自己用的是这样一个模板镜头时长画面内容字幕/解说词动效要求13s黑底显示标题“二分查找”“今天聊一个经典算法”文字淡入28s一个有序数组高亮中间元素“每次从中间开始找”高亮闪烁、指针移动35s目标值被找到颜色变为绿色“找到目标”绿色缩放特效44s收尾画面二维码/联系方式字幕淡出整体淡出为什么镜头表这么重要因为 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(fontNoto 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(fontNoto 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 而不是 SRTASS 能指定字体、字号、位置、描边看起来专业很多。4.3 交付检查清单我在每次交付前会过一遍这份清单避免翻车检查项判定标准说明时长与分镜表误差小于 1 秒前后时长差异影响解说词同步首尾帧首帧无黑场或闪烁黑场经常是拼接时误加的空帧字幕无错别字、无超框ASS 样式过宽会显示不完整音频音量统一、无爆音多段音频要统一用 loudnorm 处理编码H.264 或 H.265yuv420p保证各平台能播文件大小1080p 约 3MB/分钟超过太多检查 CRF 值是否偏低这个清单看起来是小事但很多项目都是栽在这些小细节上。5. 常见问题与排查技巧实录5.1 中文字体显示成方块字符这是我被问次数最多的问题。排查步骤简单直接先确认系统里有没有中文字体再确认 Manim 是否能按名字找到它。Linux 命令行输入fc-list :langzh能看到已安装的中文字体列表Manim 脚本里用Text.set_default(font字体名)指定如果还不行就写绝对路径用fontfont.ttf 的路径这种形式。字体问题 90% 出在字体名不匹配上不是系统没字体。5.2 渲染超时或长动画中断单个镜头动画超过两分钟基本都会遇到问题。我的习惯是超过 60 秒的镜头就拆分成多段先渲染出三段小片再用 FFmpeg 的 concat 拼接。另一个技巧是先用低分辨率跑完整条动画确认没有问题再开正式分辨率渲染。低分辨率跑 2 分钟的视频也只要几十秒而高分辨率一旦中途崩掉损失的时间是不可逆的。5.3 视频体积过大或画面有颗粒感1080p 视频体积异常增大多半是 CRF 值设置太低或者画面里有大量高频噪点比如粒子特效。降体积优先调 CRF从 18 调到 23 能明显变小噪点是渲染引擎的锯齿和美工特效导致可以通过增加渲染采样次数解决Manim 相关动画可以开抗锯齿提升平滑度。5.4 Claude 生成的代码跑不通怎么办这是代码视频日常里的日常。我的标准处理流程是三步。第一步把完整报错信息原样发给 Claude让它定位问题第二步注意反馈信息里要带上版本号经常是 API 版本不匹配导致比如旧版写法在新版本被弃用第三步用一个独立的虚拟环境跑项目比如 venv把所有依赖锁在固定版本避免系统级依赖串了。遇到那种反复修反复报错的情况就换一个更小的复现用例单独测一小段功能而不是让模型继续在大脚本里找问题。代码视频的调试本身就是缩小范围的游戏把问题的最小边界找出来修复就快了。我个人在实际操作中的体会很直接代码视频这条路线最大的特点不是“一步到位”而是每一步都能兜底。模型可能写错渲染可能崩合成可能出问题但每个环节都有明确的手段去修复。如果你愿意花一个下午把这条流水线第一次完整跑通后面再做什么视频都会顺畅很多因为你手里有了一套能改、能调、能量产的“视频生产方式”。每次开工前我还会把分镜表里每个镜头的时间码打印出来和成片时长做自动比对早点发现问题能省下大把等待渲染的时间。这套东西用熟了做视频就不再是碰运气而是像工程流水线一样一步步产出成果。
