用 Claude Opus 5.5 写代码做视频：7类技术路线与提示词框架

平时做视频，最烦的不是创意不够，而是剪辑、合成、字幕这些重复劳动太耗时间。我最近把制作视频的流程大改了一遍，核心就一件事：让 Claude Opus 5.5 帮我写代码，再用这些代码去生成视频。没错，就是用代码做视频。这个方案我实际跑了一个多月，做了十几个成品，包括数据报告动画、产品宣传片、数学讲解短片、动态片头，都靠一套可复用的提示词框架快速出片。这篇文章把整个思路整理出来：7 类技术路线怎么选、5 个案例从提示词到成片的完整链路、以及可以直接照抄的提示词模板和避坑清单。

适合谁看？两类人。一类是内容创作者或运营，靠模板剪辑效率太低，想用 AI 批量出片；另一类是开发者，把 Claude Opus 5.5 当编程助手，但不知道如何系统催它生成视频代码。我会把“写什么提示词”“代码怎么跑”“出问题了去哪查”三件事讲明白，尽量用大白话，就算你没写过多少代码，跟着操作也能跑通。

1. 为什么用代码做视频：需求分析与 7 类技术路线全景

1.1 代码做视频的本质：把剪辑变成写程序

视频在技术底层就是一堆连续的帧图像，加上音频轨道，按时间顺序打包编码。所谓代码做视频，本质就是跳过剪辑软件的操作界面，直接用程序去生成帧、合成帧、最后调用编码器输出 MP4。听起来抽象，但好处非常实在：脚本可以在不同的输入数据上反复执行，改了参数就能出一个新版本，完全可复制、可批量、可追溯。

我举个例子。以前做季度数据报告视频，用剪辑软件要一帧一帧对图表动画，改一个数字就要重新拖时间轴。现在我只改代码里的一个数值，重新运行一遍，一个 60 秒的视频几十秒就渲染出来了。这就是代码做视频最吸引人的地方——它不是帮你把剪辑按钮换了个位置，而是把“做视频”这件事从操作流程变成了一种可编程的资源。

1.2 7 类技术路线逐一拆解与选型建议

用 Claude Opus 5.5 写代码做视频，第一关不是写提示词，而是搞清楚自己要做哪种视频。不同视频的技术路线完全不同，方案选错了，后面再调都别扭。我把常见需求归纳成 7 类，每类都有典型场景、工具组合和难度评分。

1. 前端动画路线：用 HTML/CSS/JavaScript 写动画，再用工具录制成视频。适合产品宣传片、动态文字海报、界面演示。优点是视觉风格时尚、文字排版自由，缺点是渲染需要真实浏览器，效率中等。工具链：Puppeteer + Playwright + ffmpeg。

2. 数据可视化路线：用 Python 的 matplotlib 或 Plotly 生成图表序列，合成动画视频。适合财经数据、运营报表、统计图表的动态展示。优点是和数据源结合最紧密，参数驱动，改数据就能重新生成。工具链：matplotlib + PIL + numpy + ffmpeg。

3. 3D 场景路线：用 Manim、Blender Python API 或 Three.js 生成 3D 场景动画。适合数学原理讲解、物理模拟、抽象概念可视化。优点是画面有空间感，解释性强，缺点是生成速度慢、学习成本高。工具链：Manim / Blender / three.js + ffmpeg。

4. 逐帧渲染路线：用 Python 的 Pillow、OpenCV、Cairo 逐帧绘制图像再合成视频。适合片头标题、手写文字动效、像素风动画。优点是控制力极强，任何画面细节都能精确控制，缺点是需要一帧一帧算，代码量偏大。工具链：Pillow + OpenCV + PIL.ImageDraw + ffmpeg。

5. 图形着色器路线：用 GLSL 着色器配合 WebGL 渲染特效画面。适合粒子系统、故障艺术、抽象视觉背景。优点是画面华丽、运行性能好，缺点是对图形学基础有要求。工具链：Three.js + WebGL + ccapture.js。

6. 模板拼接路线：用 MoviePy 把已有素材、图片、文字、音频拼接组合成视频。适合口播视频、图文快剪、批量制作。优点是上手最快、最稳定，缺点是可发挥空间有限，本质是“程序化剪辑”。工具链：MoviePy + Pillow + ffmpeg。

7. AI 素材合成路线：先用生成式 AI 产出图片或视频素材，再用代码做剪辑、运镜、转场、字幕合成。适合创意混剪、分镜复杂的短视频。优点是素材生成几乎无限，缺点是需要另外管理生成素材的接口，环节多。

这 7 类路线不是互斥的，一个项目里经常混用。实际选型就一个原则：先确定成片里“最重要的画面效果”是什么，再选路线。比如你做产品宣传片，重点在版式和动效，那就走前端动画路线；重点是数据展示，就走数据可视化；既要有数据又要有高级包装，那就组合使用。

为了直观对比，我把 7 条路线的关键信息整理成了表格：

注意：不要一上来就追求最炫的路线。我见过不少人第一件事就学 3D，结果一个视频做了两周，热情全消耗在技术细节上。先做能跑通的简单方案，再做复杂包装，体验好得多。

2. 提示词框架：让 AI 真正帮你写出可运行的视频代码

2.1 一个通用的五段式提示词框架

把 Claude Opus 5.5 当“程序员”用，最关键的是提示词要结构化。你说“帮我做一个视频”，它只能给你一堆建议；你把需求、素材、规格、约束写清楚，它才能给你一份真的能运行出成片的代码。我测试了几十种写法后，沉淀出一个五段式框架，目前用下来稳定度最高。

角色与背景： 你是资深视频技术开发，熟悉 Python 图像处理、ffmpeg 合成、 前端动画等视频生成方案。 任务目标： 请完成一个[视频类型]的生成程序。视频内容大致是[描述内容]， 核心画面包括[画面要点]，总时长约[秒数]，要求[风格要求]。 输入素材与资源： 素材图片位于[路径]，音频文件位于[路径]， 数据来自[文件格式/数据源]。 输出规格与技术约束： 输出分辨率为 1920x1080，帧率 30fps，编码为 H.264。 代码必须完整可运行，不需要省略关键函数。 禁止使用未经确认的第三方库，优先选择[库名]。 渲染中间过程输出 PNG 帧序列，最后再调用 ffmpeg 合成。 验收标准与迭代要求： 生成后先打印关键参数，再开始渲染。 若某一步运行失败，请说明原因并给出修复后的完整代码。 最终交付：完整代码 + 运行命令 + 预期效果说明。

这个框架看起来简单，但每一段都有明确作用。角色设定帮它进入专业状态，任务目标是核心的“需求说明书”，素材路径减少来回确认，输出约束控制成片规格，验收标准保证交付质量。后面我会解释每段为什么要这么设计。

2.2 框架每段的设计逻辑：为什么这么写

先说输出规格。很多人忽略这一点，让 AI 自由发挥，结果生成 1280x720 的代码，你要发平台要 1920x1080，还得让它改。我在框架里直接锁死“分辨率、帧率、编码”，避免返工。特别强调“渲染中间过程输出 PNG 帧序列”，这和我实际踩坑有关——直接让程序输出 MP4，一旦某帧出错，整个文件作废；输出帧序列，容错能力很强，哪帧坏了重生成哪帧就行。

再说技术约束。“禁止使用未经确认的第三方库”这条非常有用。AI 倾向于堆库，可能用你没装、甚至不存在的库，导致运行即报错。指定优先使用的库，能让代码跑通的概率大幅提升。

最后说验收标准。我让 AI“先打印关键参数，再开始渲染”，这样运行时你能立刻发现尺寸、帧数、时长是否对得上，不用等渲染完才发现错了。“若某一步运行失败，说明原因并给出修复后的完整代码”这句话很关键，它引导 AI 在遇到异常时进入“解释—修复—交付新代码”模式，而不是丢一句“请检查安装”就结束。

2.3 三个高频场景的提示词模板（可直接复制）

框架是通用的，落到具体场景还需要微调。我给你三个我已经反复使用过的模板，直接复制改改就能用。

模板 A：数据可视化视频

用 Python 的 matplotlib 和 numpy 写一个视频生成程序。 输入数据是 CSV 文件，路径为 ./data.csv。 视频总时长 20 秒，分辨率 1920x1080，帧率 30fps。 画面要求：依次展示折线图、柱状图、饼图，每个图表持续 6 秒， 中间用 1 秒的渐变过渡。图表标题、坐标轴标签使用中文， 字体为 SimHei。先逐帧保存 PNG 到 ./frames， 再用 ffmpeg 合成 mp4，编码 H.264。 代码必须完整可运行，渲染前先打印总帧数。

模板 B：逐帧动画文字

用 Python 的 Pillow 写一个逐帧渲染程序。 内容是一行文字“年度总结”从屏幕左侧移动到右侧， 移动过程中文字逐渐放大并改变颜色。背景为深蓝色渐变， 文字字体使用思源黑体 Bold，初始字号 80， 最终字号 160。时长 8 秒，分辨率 1920x1080，30fps。 每一帧调用 draw.text 绘制，输出 PNG 到 ./frames， 最后用 ffmpeg 合成 MP4。代码运行前先打印帧尺寸和总时长。

模板 C：多素材混剪与字幕

用 Python 的 MoviePy 写一个混剪程序。 素材视频位于 ./source/ 目录，共 5 个片段。 每个片段截取中间 5 秒，顺序拼接，片段之间用 0.5 秒的交叉淡化转场。 全程添加文字字幕，字幕内容来自 ./subtitles.txt， 字幕显示在画面下方居中，白色字体，黑边。 背景音乐使用 ./bgm.mp3，音量降到 0.3，并自动适配成片时长。 输出为 1920x1080，30fps，H.264，最终文件输出为 ./output.mp4。

这三个模板覆盖了我日常 80% 的视频需求。你的场景可能不同，但照着框架改内容就行，核心是别删掉“输出规格”和“验收标准”两段。

3. 五个案例拆解：从提示词到成片的完整链路

3.1 案例一：产品功能宣传片（前端动画路线）

我有一个模拟项目，要给某个企业内部工具做 15 秒产品宣传片，传统剪辑需要设计动效、对齐节奏，至少半天。这次我走前端动画路线，提示词里明确了几个关键要求：页面用 CSS 动画实现功能模块的渐入渐出，配合滚动模拟效果，录屏工具用 Puppeteer 的页面录屏接口，最后接 ffmpeg 转码。

Claude Opus 5.5 生成的代码是一个自包含的 HTML 页面，所有动画都用 CSS 和少量 JavaScript 完成，视觉上做成了简洁卡片风格。我让 Puppeteer 打开页面，自动播放 15 秒动画，用页面录制 API 抓帧，最后 ffmpeg 把帧合成为 H.264 的 MP4。整个过程大概 20 分钟，远快于传统流程。

几个关键细节：提示词里一定要指定“动画总时长 15 秒，晚于 5 秒开始录屏”，否则录屏经常从动画中途开始；页面里的字体也要指定，不然 Linux 服务器上中文显示成方块。这个案例验证了前端动画路线的核心优势：视觉自由度最高，改文案只需要改 HTML 文本。

3.2 案例二：季度数据报告动画（数据可视化路线）

数据可视化路线是我最常用的一条，适合做运营数据报告。场景是这样的：一个 CSV 文件里有 12 个月的营收和用户数，要做一条 30 秒的数据动画，包含折线图、柱状图、占比饼图三种图表。提示词模板我用了前面给的模板 A，额外加了一条要求：“每个图表之间添加数字滚动动画，展示当月具体数值”。

生成的代码用 matplotlib 逐帧绘制，每帧根据时间索引选择当前月份的数据并更新图表，配合一个简单的数字文本。运行起来后我在关键节点做了验证：第 5 秒应该出现折线图、第 15 秒柱状图、第 25 秒饼图。检查生成的 PNG 帧序列，时间轴完全一致。渲染时间大约 40 秒，出片效果比我想象中顺滑，渐变过渡是靠相邻帧的数据差值实现的，画面没有跳变。

这个案例让我意识到，数据可视化路线和真实数据对接太方便了。只要 CSV 格式不变，每个季度改一次数据重新跑一遍，一份新的季度报告视频几十秒就出来了。适合做周期性内容的朋友重点研究。

3.3 案例三：数学概念讲解短片（3D 场景路线）

一个数学类内容的需求：制作 3 分钟视频解释“导数就是切线的斜率”。用剪辑软件很难表达几何概念，这次走 3D 场景路线，用 Manim 生成数学动画。提示词里我要求生成一个 Manim Scene，包含坐标平面、函数曲线、切线和动态逼近过程，并且每一步要配文字说明。

Claude Opus 5.5 生成的代码结构很清晰，核心是用 Manim 的 Scene 类，调用坐标系绘制坐标轴，用参数曲线渲染函数图像，用切线和移动的点表现切点逼近过程。渲染时我关掉了不需要的镜头运动，大幅减少渲染时间。成片效果在数学表达上非常精准，切线角度的动态变化一目了然。

3D 路线的坑也很明显：Manim 渲染慢，这段 3 分钟视频渲染用了将近 40 分钟，还要先装系统级依赖。如果你不是数学、物理这类强空间表达需求，我不建议一开始就上这条路。

3.4 案例四：动态片头标题（逐帧渲染路线）

片头标题这类需求，用逐帧渲染路线最可控。我的需求是做一个“年度回顾”的动态标题：文字从左侧滑入、放大、变成金色渐变，然后背景出现光晕粒子效果。提示词用的模板 B，额外要求了粒子用随机位置和帧号做种，保证每次运行效果一致。

生成的代码基于 Pillow，核心逻辑是每一帧按时间比例计算文字坐标、字号、颜色值，再用 draw.text 绘制，文字和粒子分开绘制后合并。渲染 200 多帧，几十秒就能跑完。逐帧渲染的优势在于：你能精确控制每一帧的视觉元素，哪里不满意直接改那一帧对应的参数函数。缺点是代码量偏大，粒子效果这类东西用 OpenCV 做要写不少逻辑。

3.5 案例五：多素材混剪与智能字幕（模板拼接路线）

最后一个案例是模板拼接路线，也是最稳定的路线。需求：把 5 段实拍素材剪成 25 秒的口播短视频，每段 5 秒，片头加标题，片尾加联系方式，全程配中文字幕，背景音乐自动降低音量。

我用模板 C 的提示词，让 Claude Opus 5.5 生成 MoviePy 脚本。脚本先读取素材目录下所有文件，用 subclip 截取每段中间 5 秒，用 CompositeVideoClip 做交叉淡化转场；字幕用 TextClip 生成，逐条显示在画面下方；音频用 AudioFileClip 加载后降音量，再和视频合在一起。整个过程运行一次约 2 分钟，成片直接可用。

这个案例看起来平淡，但它恰恰是很多人最需要的。模板拼接路线适合“大量、快速、稳定”的内容生产，尤其是口播号和混剪号。提示词只要把素材目录、字幕文件、背景音乐路径写清楚，AI 生成脚本后基本不用改。

4. 实操链路：环境准备、参数调优与效率优化

4.1 最小环境搭建：ffmpeg + Python 图像/视频库

所有路线的共同底座是 ffmpeg 和 Python 生态。ffmpeg 负责最后的编码合成，Python 负责生成帧或调用封装好的视频库。先说最基础的安装（以常见 Linux 环境为例）：

# 安装 ffmpeg sudo apt update && sudo apt install ffmpeg -y # 安装 Python 基础库 pip install pillow numpy opencv-python moviepy matplotlib

如果你走前端动画路线，还要装浏览器和录制工具；走 3D 路线要装 Manim 或 Blender 的 Python 绑定。建议每装一个库就跑一个最小示例，别一次性装一堆，否则出了问题很难排查。我用的是一个独立的虚拟环境，避免和日常项目互相干扰。

4.2 从提示词到成片的完整操作流程

我梳理了一个固定流程，每次做视频都按这个走。第一步，按五段式框架写好提示词；第二步，让 Claude Opus 5.5 生成完整代码，运行前打印关键参数；第三步，先渲染一个低分辨率测试版本，比如 640x360、15fps，确认画面运动、转场、字幕都正确；第四步，测试版本确认无误，再改成正式分辨率渲染；第五步，检查输出视频，确认帧数、音频、编码符合预期。

这里有个重要参数计算要解释。视频总帧数 = 时长 × 帧率。比如 20 秒视频，30fps，就是 600 帧。matplotlib 逐帧渲染时每一帧都要重新绘制图表，渲染时间 = 单帧绘制时间 × 总帧数。如果单帧绘制 0.1 秒，600 帧就是 60 秒。所以测试版本先用低帧率和小分辨率，能判断你的渲染时间是否可接受。提示词里让 AI“先打印总帧数”，就是方便你做这个估算。

另外，如果你要修改视频某个环节，最好的方式是改提示词重新生成，而不是手动改代码。Claude Opus 5.5 每次都能生成完整新版本，改提示词比逐行改代码更不容易留下隐藏问题。

4.3 渲染效率优化的三个关键取舍

做视频生成，效率是绕不开的话题。我实测下来有三个取舍最常见。

第一是分辨率取舍。大多数平台播放 1280x720 完全够用，但接收方要求 1080p 的情况很多。我习惯先 720p 测试，最后 1080p 出片。渲染时间提升不是线性的——从 720p 到 1080p，像素数翻了 2.25 倍，渲染时间大约也是 2.2 倍，不是你想的简单 1.5 倍。

第二是编码器取舍。H.264 是兼容性最好的选择，文件小、播放端基本全支持。但如果你要后期二次剪辑，建议输出无压缩或轻压缩的帧序列加无损音频，最后剪辑时再转 H.264。H.264 是“牺牲兼容性代价”换体积，无损是“保住画质和可编辑性”的代价。

第三是并行渲染取舍。Python 单进程渲染很慢，我把帧绘制任务用 multiprocessing.Pool 分配到多个 CPU 核心。比如 20 秒 720p 视频，单核心渲染 120 秒，4 核心同时跑可以压缩到 40 秒左右。提示词里可以加一句“支持 multiprocessing 并行渲染，渲染函数可安全传递帧号”，AI 会帮你把代码改成可并行版本。

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

5.1 高频问题速查表

代码做视频的过程里，我遇到过好几类典型问题。这些问题在纯剪辑工作流里根本不会出现，但程序化生成时特别容易踩。我把高频问题整理成了速查表。

这个表是我根据自己跑过的项目总结的。大多数问题不是 AI 代码写得差，而是环境差异和素材差异导致，所以排查顺序永远是：先跑小尺寸、打印参数、单帧检查。

5.2 实战中总结的独家避坑心得

先说最重要的一条：永远先让小模型尺寸测试通过，再上正式渲染。我一开始贪快，直接 1920x1080 跑全量，渲染几十秒后发现画面布局有问题，改动一次就浪费大量时间。后来规定所有视频先跑 640x360 的测试版本，画面确认无误再上 1080p，效率反而高了好几倍。

第二条心得是“用帧序列工作流，不要直接输出 MP4”。直接输出 MP4 虽然方便，但一帧出错就要重跑全部。帧序列的话，每帧是独立文件，哪个环节有问题只重定向那一帧。尤其是做复杂动画时，这个习惯救了我很多次。

第三条心得是关于提示词的。Claude Opus 5.5 这类模型生成代码时，倾向于一次写完所有功能，导致一个文件几百行，出问题很难定位。我在提示词里加了一句“将程序拆分为三个函数：帧内容绘制、帧保存、参数设置”，AI 生成的代码结构就清晰多了，排查问题时直接看帧内容绘制函数就能定位视觉错误。

还有一条环境心得：ffmpeg 的 H.264 编码在部分服务器上默认不支持，需要指定 libx264，同时在命令行里加上 -pix_fmt yuv420p，否则某些播放器会显示绿色画面或无法播放。这个坑我印象很深，因为成片在本地播放一切正常，上传平台后才发现问题。

最后分享一点个人体会。代码做视频的门槛，其实不在“写代码”本身，而在于你能不能把自己的需求拆成可执行的画面和时间线。Claude Opus 5.5 这个帮手能写代码、能解释报错、能按提示词迭代，但前提是你得说清楚“第几秒出现什么画面、用几个像素、什么字体、什么颜色”。我前后花了不少时间调提示词，现在一套框架用下来，十几个不同类型的视频都能两个小时以内出片。

如果你也想试试，我的建议是别一次追求所有技术路线，选一个离你需求最近的，比如口播号就选模板拼接，报表号就选数据可视化，先用几段素材跑通一遍完整的“提示词→代码→成片”流程。跑通一次之后，你会对“视频是程序生成的结果”这件事有完全不同的感知。后续还可以给这套工作流加上批量处理、自动发布这些能力，空间很大。