用大模型写代码做视频：七类技术路线与可复用提示词框架

1. 从写代码到做视频这条路线到底在解决什么问题很多人第一次听到用大模型写代码来做视频脑子里浮现的画面大概是对着一个对话框敲几句提示词然后一段成片就自动吐出来了。实际干过的人都知道这个想象和现实之间隔着一条不小的鸿沟。视频这个东西本质上是时间轴上的一连串帧 音轨 字幕 转场 特效的复合体它不像生成一张图那样一次性出结果而是涉及素材准备、时间轴编排、渲染合成、编码导出等一长串工序。大模型真正能帮上大忙的地方不是一键出片这种玄学而是把这条工序链里那些重复、繁琐、需要写脚本才能批量处理的环节用自然语言驱动代码的方式接管掉。我自己做视频的路径经历过三个阶段。最早是纯手工剪辑软件里一帧一帧拖做个几分钟的片子能耗掉一整天后来开始写脚本用命令行工具批量处理素材、拼接、加字幕效率上来了但写脚本本身也费劲尤其是遇到不熟悉的库查文档的时间比写代码还长再往后我开始把写这些脚本这件事本身交给大模型来做——我描述需求它给我可运行的代码我负责跑、看结果、提修改意见。这个转变带来的效率提升是实打实的原本要查半天文档的合成逻辑现在几句话就能拿到一个能跑的初版。所以这篇内容要聊的不是AI 能不能做视频这种已经被讨论烂了的话题而是一个更具体、更落地的问题当你手里有一个能写代码的大模型时做视频这件事可以被拆成哪几条技术路线每条路线适合什么场景具体怎么落地以及那些提示词该怎么写才能稳定拿到能用的代码。我会把路线分成七类每一类都配上真实的案例拆解和可复用的提示词框架。适合的读者是有一定动手能力、愿意跑命令行、想用代码把视频生产流程自动化的创作者和开发者。你不需要是视频专业出身但最好对视频是由什么组成的有个基本概念这样后面看代码逻辑会顺很多。需要先说明一点下面提到的所有工具、库、案例都是基于当前常见的开源生态和通用实践来展开的具体版本和 API 可能随时间变化你在实操时以官方文档为准。我分享的是思路、结构和踩过的坑不是一份永远不过期的 API 手册。2. 七类技术路线的全景拆解与选型逻辑在动手之前先把地图铺开。用大模型写代码做视频可以按介入的环节和产出的形态分成七条路线。这七条不是互斥的实际项目里往往是几条组合着用。理解每条路线的边界能帮你在遇到具体需求时快速判断该走哪条。2.1 路线一脚本化剪辑与批量处理这是最基础也最实用的一条。核心思路是把剪辑软件里那些重复操作裁剪、拼接、调速、加转场、批量导出用命令行工具或 Python 库写成脚本让大模型帮你生成这些脚本。典型工具是 FFmpeg 配合 Python 的 subprocess 调用或者用 moviepy 这类封装库。这条路线适合的场景是你有一批素材需要统一处理比如把几十个片段统一裁成 9:16 竖版、统一加片头片尾、统一压制到某个码率。手工做这些事是灾难脚本做就是几行代码的事。大模型在这里的价值是你不需要记住 FFmpeg 那一大堆参数直接说把 input 目录下所有 mp4 裁成竖版并加 3 秒淡入它就能给你一条能跑的命令。2.2 路线二程序化动画与数据可视化视频如果你的视频内容是把数据讲清楚或者展示一个抽象概念那程序化生成动画会比手工剪辑高效得多。典型工具是 Manim做数学动画的那个、matplotlib 的动画模块、或者直接用 HTML/CSS/Canvas 配合录屏。大模型在这条路线上的优势特别明显因为 Manim 这类库的 API 学习曲线陡峭而大模型对它的语法掌握得相当不错。适合场景教学视频、数据报告视频、产品演示里那些数字动起来的片段。我做过一个把季度销售数据做成动态柱状图 racing 的视频全程没打开剪辑软件纯靠 Python 脚本生成帧再合成。2.3 路线三模板驱动的批量成片这条路线解决的是同一套版式换不同的文案和素材批量产出几十上百条视频的需求。典型做法是用一个模板引擎比如基于 HTML 的渲染或者 After Effects 的脚本接口或者纯 Python 的 PIL/Pillow 逐帧绘制把可变部分参数化然后循环生成。适合场景电商产品视频、社交媒体批量内容、个性化祝福视频。大模型在这里帮你写的是模板渲染逻辑和参数替换逻辑一次写好后面改数据就行。2.4 路线四AI 生成素材 代码编排这条路线是把生成素材和编排素材分开。素材生成可能用到图像生成、语音合成、音乐生成等能力编排则回到路线一的脚本化处理。大模型在这里扮演两个角色一是帮你写调用素材生成接口的代码二是帮你写把生成结果编排成时间轴的代码。适合场景需要大量原创素材但又不想实拍的视频比如概念短片、抽象视觉、旁白驱动的解说视频。2.5 路线五字幕、配音与多语言处理字幕和配音是视频生产里最耗时也最适合自动化的环节。典型工具链是语音识别Whisper 这类出时间轴翻译模型做多语言语音合成出配音最后用 FFmpeg 把字幕烧进画面或做成软字幕。大模型在这里的价值是帮你把这一整条链路的胶水代码写出来以及处理那些识别结果需要清洗的脏活。适合场景访谈视频、课程视频、需要出多语言版本的内容。2.6 路线六视频分析与内容理解前面几条都是生产视频这条是理解视频。用代码把视频拆成帧、抽音频、做场景检测、提取关键信息再让大模型基于这些信息做摘要、打标签、生成章节。适合场景视频内容管理、自动生成视频简介、长视频切片段。2.7 路线七全流程编排与自动化管线最后这条是把前面六条串起来做成一条从输入素材和需求到输出成片的自动化管线。典型形态是一个 Python 项目里面分模块处理素材、生成中间产物、调用渲染、导出成片用配置文件或命令行参数控制流程。大模型在这里帮你写的是整个项目的骨架和各个模块的接口。选型逻辑其实很简单我总结成一张表路线核心工具最适合的场景上手难度大模型介入价值脚本化剪辑FFmpeg / moviepy批量处理已有素材低高省去查参数程序化动画Manim / matplotlib数据与概念可视化中极高API 复杂模板批量成片Pillow / HTML 渲染同版式批量产出中高生成素材编排各类生成接口 FFmpeg原创素材短片中高高字幕配音Whisper TTS FFmpeg访谈课程多语言中高视频分析OpenCV 模型内容理解与切片中高中高全流程管线Python 项目整合长期自动化生产高极高选路线的时候先问自己三个问题我的素材是现成的还是要生成的我的产出是单条还是批量我的瓶颈在处理还是在创作答案基本就能定位到该走哪条或哪几条。3. 五个案例的完整拆解从需求到能跑的代码光讲路线太虚下面用五个案例把怎么跟大模型对话、怎么拿到代码、怎么调试这条链路走一遍。每个案例我都会给出需求描述、提示词结构、关键代码逻辑和踩坑点。3.1 案例一把一批横版素材批量转成竖版并加统一片头需求很明确手上有 20 个横版 mp4要全部转成 9:16 竖版中间画面居中上下补模糊背景再统一加一个 3 秒的片头。我给的提示词大致是这样的结构先说清楚输入输出的目录结构再说清楚每个片段的处理规则分辨率、补边方式、片头拼接最后要求用 FFmpeg 命令实现并给出一个可以循环处理整个目录的 Python 脚本。大模型返回的核心逻辑是先用 FFmpeg 的scale和pad滤镜把横版转竖版补边用boxblur做模糊背景然后用concat把片头和正片拼起来。关键命令片段长这样ffmpeg -i input.mp4 -filter_complex \ [0:v]scale1080:1920:force_original_aspect_ratioincrease,crop1080:1920,boxblur20:5[bg]; \ [0:v]scale1080:-1[fg]; \ [bg][fg]overlay(W-w)/2:(H-h)/2 \ -c:a copy output.mp4这里有个坑我踩过force_original_aspect_ratioincrease配合crop会把画面裁掉一部分如果你不想裁得改成先scale到合适尺寸再pad。另一个坑是片头拼接时如果片头和正片的编码参数不一致concat会失败得先统一转码。这些细节大模型第一次不一定全考虑到需要你在提示词里明确片头和正片编码参数要一致。批量循环的部分大模型给的是一个os.listdir遍历加subprocess.run调用的脚本我加了异常捕获和进度打印跑起来很稳。20 个片段处理完大概几分钟比手工快了一个数量级。3.2 案例二用 Manim 做一个数据变化的动态柱状图这个案例是给一份月度数据做动态展示。需求是柱子按月份依次长出来数值实时变化最后定格。Manim 的 API 对不熟的人来说很劝退但大模型对它相当熟。我的提示词里明确了用 Manim 的BarChart类数据用一个字典传入动画用Create和Transform组合最后wait两秒。大模型给的代码基本一次就能跑核心结构是构造BarChart对象然后用self.play依次播放动画。这里的心得是Manim 的版本差异比较大不同版本的类名和参数有变化。我在提示词里加了一句请基于较新的稳定版本 API能减少不少返工。另外渲染分辨率默认是 480p要出成片得在命令行加-qh或-qk参数这个大模型不一定会主动提得自己知道。3.3 案例三模板化批量生成带不同文案的产品短视频需求是有一个固定的版式背景图 产品图 标题文字 价格文字要换 50 组文案和产品图批量出 50 条 15 秒的视频。这条走的是路线三。我的做法是用 Pillow 逐帧绘制每一帧再用 FFmpeg 把帧序列合成视频。提示词里我描述了版式的坐标布局、字体、颜色以及每条视频的文案从 CSV 读取这个数据来源。大模型给的方案是写一个函数接收文案参数返回一张绘制好的图主循环读 CSV对每条数据生成一组帧再调 FFmpeg 合成。关键点是帧率要固定我用 30fps15 秒就是 450 帧每帧都重新绘制。这里性能是个问题50 条视频如果每条都逐帧绘制会很慢我的优化是静态部分背景、产品图只绘制一次缓存起来动态部分文字淡入才逐帧算。这个优化思路是我自己加的大模型第一版给的是全量重绘。3.4 案例四自动生成字幕并烧录进视频需求是给一段口播视频自动生成中文字幕做成硬字幕。工具链是 Whisper 做识别输出 SRT再用 FFmpeg 把 SRT 烧进画面。提示词里我明确了用 Whisper 的 Python 接口输出 SRT 格式然后用 FFmpeg 的 subtitles 滤镜烧录。坑点集中在两处一是 Whisper 的模型大小选择base快但准度一般medium准但慢得根据视频长度权衡二是 FFmpeg 烧字幕时字体路径和编码问题中文容易出乱码得指定字体文件并确保 SRT 是 UTF-8。这些我在提示词里都提前说明了所以大模型给的代码基本可用。3.5 案例五把长视频按场景自动切成片段需求是一段 40 分钟的讲座视频要按场景变化自动切成若干片段每段单独导出。这条走路线六。做法是用 OpenCV 或 FFmpeg 做场景检测拿到切分时间点再批量导出。提示词里我要求用 FFmpeg 的 scene 检测滤镜输出时间戳然后按时间戳切分。场景检测的阈值是个经验值默认 0.3 左右太高会漏切太低会切太碎。我一般先用默认值跑一遍看结果再调。大模型给的代码里阈值是写死的我改成了命令行参数方便调整。切分导出时注意关键帧对齐否则开头几帧可能花屏加-ss和-t配合-c copy能快切但可能不准要精确切就得重新编码。4. 可复用提示词框架让大模型稳定产出能跑的代码五个案例跑下来我总结出一套提示词框架核心是把大模型当成一个需要明确需求文档的工程师而不是一个会读心术的魔法师。框架分五块缺一块返工率就上去。4.1 环境与依赖声明块第一块必须交代清楚运行环境。包括操作系统、Python 版本、已安装的关键库及版本、可用的命令行工具。比如我在 macOS 上Python 3.11已装 FFmpeg 6.0 和 moviepy 1.0.3。这一块能避免大模型给你一个依赖不存在或版本不兼容的方案。我吃过亏有次没说明 FFmpeg 版本大模型用了一个新版本才有的滤镜我本地跑直接报错。后来养成习惯环境信息永远放提示词最前面。4.2 输入输出契约块第二块定义清楚吃什么、吐什么。输入是什么格式、放在哪个目录、命名规则如何输出是什么格式、分辨率、码率、放哪里。这一块越具体代码越不需要改。比如不要写处理一批视频而要写处理./input下所有.mp4文件输出到./output文件名保持一致分辨率 1080x1920H.264 编码码率 8Mbps。契约清晰了大模型写的循环和参数就是对的。4.3 处理逻辑分步块第三块把处理流程拆成有序步骤。不要一句话概括要一步一步列。比如第一步读取视频时长第二步如果时长超过 60 秒则截取前 60 秒第三步统一转成竖版第四步加片头。分步描述能让大模型生成的代码结构清晰也方便你定位问题出在哪一步。4.4 约束与边界条件块第四块声明那些必须满足和必须避免的条件。比如必须处理文件名含空格的情况必须捕获异常并跳过失败文件继续处理不要用已废弃的 API。这些约束是代码健壮性的来源不写的话大模型默认给的是理想情况能跑的版本。4.5 输出格式要求块第五块要求大模型怎么给结果。我一般要求先给完整可运行的代码再给依赖安装命令再给运行示例最后列出可能的坑和调试建议。这个顺序让我拿到结果后能直接跑不用来回问。把这五块拼起来就是一个完整的提示词模板。实际用的时候根据具体任务填充内容即可。这套框架我用了几十次返工率从最初的基本要改降到了小改即用。5. 实操中的性能、兼容与调试经验代码能跑只是第一步跑得快、跑得稳、出问题能查才是真正落地。这一章聊几个我在实操中反复遇到的问题和应对方法。5.1 渲染性能什么时候该并行什么时候该省着来视频处理是计算密集型任务尤其是逐帧绘制和重新编码。我的经验是IO 密集的环节比如读文件、调接口适合并行CPU 密集的环节比如逐帧渲染、编码并行要谨慎因为并行太多反而会因为资源争抢变慢。具体做法批量处理多个视频时用 Python 的concurrent.futures开一个进程池池大小设成 CPU 核心数的一半左右比较稳。单个视频内部的帧渲染如果非要加速可以考虑用 GPU 或者把静态部分缓存。我那个模板批量成片的案例缓存静态部分之后50 条视频的总耗时从预估的两小时降到了二十多分钟。5.2 编码兼容为什么你的视频在别人电脑上打不开编码参数不统一是视频交付里最常见的坑。我遇到过自己电脑上能播的 mp4发给别人打不开原因是用了某些播放器不支持的编码 profile。解决办法是统一用 H.264 的main或highprofile音频用 AAC容器用 mp4这套组合兼容性最好。还有一个坑是色彩空间。不同来源的素材色彩空间可能不一样拼接时如果不统一会出现颜色跳变。稳妥做法是在处理前统一转成yuv420p这是兼容性最好的像素格式。5.3 调试链路当大模型给的代码跑不通时怎么查大模型给的代码跑不通是常态关键是有一套排查链路。我的顺序是先看报错信息定位到具体行再看那一行的输入数据是否符合预期然后单独把那一行拿出来在命令行或 REPL 里跑最后才是改代码。有个技巧让大模型帮你写调试代码。比如这段 FFmpeg 命令报错了请帮我加一个打印实际执行命令的日志并解释每个参数的作用。这样你能看到它到底拼出了什么命令往往一眼就能看出问题。5.4 版本漂移为什么上个月能跑的代码这个月不行了开源库更新频繁API 变化是常事。我的应对是在项目里固定依赖版本用requirements.txt锁死。另外把大模型生成的代码里的关键 API 调用单独抽成函数一旦库升级只改这几个函数就行不用全项目翻。还有一点大模型的训练数据有时间截止点它可能不知道最新的 API 变化。遇到这种情况我会把最新的官方文档片段贴进提示词让它基于最新文档写代码。这个做法很有效相当于给大模型补课。6. 把七条路线串成一条管线我的实际项目结构最后聊聊怎么把前面这些东西整合成一个能长期用的项目。我的视频自动化项目大致长这样video_pipeline/ ├── config/ │ └── settings.yaml # 分辨率、码率、路径等配置 ├── modules/ │ ├── ingest.py # 素材导入与预处理 │ ├── transform.py # 转码、裁剪、拼接 │ ├── generate.py # 程序化生成帧或动画 │ ├── subtitle.py # 字幕识别与烧录 │ ├── analyze.py # 场景检测与内容理解 │ └── render.py # 最终合成与导出 ├── prompts/ │ └── templates.md # 可复用的提示词模板 ├── main.py # 命令行入口 └── requirements.txt这个结构的好处是每个模块职责单一大模型帮你写某个模块时上下文清晰不容易串味。config集中管理参数改分辨率不用翻代码。prompts目录把提示词也当成项目资产管理起来下次做类似任务直接复用。main.py用argparse做命令行入口支持--stage参数选择跑哪一步方便调试。比如python main.py --stage subtitle --input xxx.mp4就只跑字幕环节。这套结构不是一次设计出来的是踩了所有逻辑堆在一个文件里改到崩溃的坑之后重构的。我的建议是哪怕你只做一个小任务也把配置、逻辑、入口分开后面扩展会轻松很多。关于提示词模板的维护我有个习惯每次大模型给的代码特别好用我就把那次用的提示词存进templates.md标注适用场景。攒了半年现在遇到新任务先翻模板库能复用的直接改不能复用的也有参考。这比每次从零写提示词高效得多。整个管线跑通之后我做一条几分钟的视频从素材到成片纯操作时间能压到十几分钟剩下的时间都花在创意和调优上。这才是用代码做视频真正的价值所在——把机械劳动交给脚本把人的精力留给真正需要判断力的部分。