开头直接说结论如果你还停留在让AI直接生成视频画面这个思路上那大概率会卡在同一个地方——生成式视频模型产出的内容不可控、不连续、没法微调、改了这帧毁了那帧。我最近用 Claude Opus 5.5 做了一批视频项目验证了一条完全不同的路线用 Claude 写代码让代码把视频算出来。这个思路的核心是Claude Opus 5.5 不是帮你拍视频而是帮你写视频——用程序化的方式定义动画、转场、数据可视化、粒子特效和剪辑逻辑最后渲染成片。这篇博文就是围绕这个主题把我实测过的 7 类技术路线、5 个真实案例以及沉淀下来的可复用提示词框架一次性整理出来。适合技术型内容创作者、做数据可视化的同学以及所有想用 AI 把视频生产流程真正代码化的人。先说明我的使用背景过去半年我在做一档偏技术科普的视频栏目覆盖数学讲解、数据报告解读、产品功能演示和不定期更新的创意片头。最开始玩法很朴素——用某生成式视频工具输入提示词出画面再用剪辑工具手动拼装。但很快我就发现这种流程在中长视频上根本撑不住画面风格不稳定、文字渲染经常出错、逻辑连续性靠运气、后续修改等于重做。后来我把重心转向了让 Claude 写代码来做视频这个转变解决了我 80% 的痛点。下面按这次验证的顺序展开。1. 从生成画面到生成代码我为什么把视频创作的链路整个换了1.1 先破除一个误区不是让 AI 直接生视频提到AI 做视频大多数人想的是给一句提示词AI 直接吐出一段画面。这是生成式视频模型的路子产品很惊艳但在实际内容生产中有几个硬伤。第一个硬伤是不可控。生成式模型对文字的理解停留在语义层它生成的画面是它理解的而非你指定的。你说一个红色小球从左上角运动到右下角它可能给你一个红色小球也可能给你一个坐在角落的小孩。第二个硬伤是不可微调。生成式视频的输出是一段固定像素序列你要改小球的运动轨迹没法在生成结果上直接改参数只能重新生成然后祈祷它别把其他部分改掉。第三个是不可嵌入工程链路。内容生产到后期往往要接剪辑、加字幕、调速度、做版本对比这些操作在生成的视频文件上做等于每一步都在重新处理一段死数据。相比之下用代码定义视频完全是另一套逻辑。画面里的每个元素都是一个对象运动轨迹是一组参数转场是一段函数字幕是一段文本叠加逻辑。这意味着一次生成、永久可改改一个参数只有对应部分变化整个项目可以进 Git 做版本管理。这正是我切换路线的根本原因——我需要的是可编程的视频不是碰运气的视频。1.2 Claude Opus 5.5 在写视频代码这件事上的真实优势那为什么选 Claude Opus 5.5而不是别的模型我实测下来核心是三点。第一超长上下文的连续工程能力。一个视频项目的代码动辄几百上千行数据预处理、动画逻辑、渲染配置、后期导出全部在一个上下文里。Opus 5.5 能稳定承接这种长代码工程而且中途切换话题也不会忘掉前面的结构约束。这一点在做迭代修改时价值极大——它能理解只改第三段动画的运动曲线其他保持不动这种精细指令而不会把无关部分一并重写。第二跨语言跨工具链的代码生成质量。做视频涉及的代码栈很杂Manim/Python 做数学动画HTML/CSS/JS 做 Web 动画ECharts/D3 做数据可视化FFmpeg 做自动化剪辑Three.js 做三维镜头。Opus 5.5 在这些栈上都有不错的输出质量尤其是对 API 参数和版本兼容性的敏感度很高这一点稍后会在案例里详细展开。第三它的调试协同能力。我现在的流程是让 Claude 生成初始代码本机运行把报错信息直接贴回对话它会基于报错给出修复方案。Opus 5.5 在错误诊断上不是只给改成 XXX而是会解释出错的原因和关联影响。这种跑-错-改的循环效率直接决定了整个视频生产链路能不能落地。1.3 这套方案适合谁不适合谁说实话这不是一条零门槛的路。你得有基本的代码常识知道什么是依赖安装、什么是执行环境、什么是文件路径最好能看懂报错。但门槛到此为止——你不需要成为图形学专家或前端高手因为写代码的主体是 Claude你要做的是给它清晰的需求、正确的约束以及在出错时和它对话调整。这套方案最适合三类人内容创作者做科普、知识类视频内容需要精确的图形表达而不是随机生成的氛围感画面。数据类从业者需要把数据报告、分析结果变成可视化的视频内容追求准确性和可复现性。产品和技术团队需要快速产出功能介绍、流程演示、复盘报告类的视频素材且需要批量生产和频繁迭代。如果你要的是输入一句话出来一个电影感短片那种效果那本文这套方案确实不适合你——那本质上是另一条技术路线不在今天的讨论范围内。2. 七类技术路线全景拆解别问哪条最好先问你要做什么视频我这次系统验证的 7 类路线覆盖了从数学科普、数据新闻、产品演示到创意片头的常见视频需求。先放一张总览表再逐个展开。路线核心技术栈最适合做的视频类型学习/使用成本可控性路线一Manim 程序化动画Python/Manim数学、算法、物理科普中极高路线二Web 动画三件套HTML/CSS/JS Canvas产品演示、动态海报、轻量解说低高路线三数据可视化叙事ECharts / D3.js数据报告、新闻图表、复盘视频中高路线四FFmpeg 脚本化剪辑FFmpeg 命令行 Python批量剪辑、课程切条、自动化出片低极高路线五Python 逐帧生成Python Pillow/OpenCV特殊转场、逐帧动画、像素级控制中高极高路线六生成艺术与粒子系统p5.js / Processing创意片头、背景氛围、艺术化表达中中路线七Three.js/WebGL 三维镜头Three.js三维场景漫游、产品三维展示高高2.1 路线一Manim 程序化动画——数学和算法内容的标准答案Manim 是 3Blue1Brown 开源的数学动画引擎核心逻辑是用 Python 代码描述场景定义对象、设计变换、控制镜头最后渲染成高质量数学动画。Claude 对 Manim 的掌握程度相当深包括Transform、FadeIn、Create这类基础动画以及AlwaysRedraw、ValueTracker这类高级控制。我的典型用法是给 Claude 描述一个数学过程比如用动画展示贝叶斯定理中先验概率如何随着新证据逐轮更新它会自动拆解成一个完整的 Manim 场景先画概率空间矩形再用ValueTracker控制分隔线的位置动态变化。关键提示词片段后面章节会给完整框架这里先感受一下# 目标贝叶斯更新可视化 # 画面一个代表概率空间的矩形中间有一条竖线 # 左侧面积代表 P(A)右侧代表 P(¬A) # 随着证据 E 的出现竖线左右移动面积比例变化 # 要求竖线移动时用 ValueTracker 驱动标签同步更新数字Manim 适合的场景非常明确凡是涉及精确几何关系、数学推导、算法流程的讲解基本是无可替代的选项。但它也有代价——渲染时间长、调试反馈慢一次渲染几十秒到几分钟不等所以不适合做需要大量试错的快速原型。我的经验用 Manim 时别让 Claude 一口气写整个长场景而是拆成场景一、场景二粒度去生成每个场景控制在 15 秒以内最后用后期剪辑拼接。这样调试成本低改起来也精准。2.2 路线二Web 动画三件套——轻量、快、迭代效率最高HTML CSS JavaScript 做视频是我在整个验证周期里使用频率最高的路线。逻辑不复杂把动画代码写在网页里用固定分辨率窗口按帧率录制屏幕或者直接用 Puppeteer/Playwright 做无头浏览器录屏。这条路线的好处极其明显语法简单Claude 生成 HTML/CSS/JS 的成功率极高基本不需要反复调试。调试即时浏览器里直接预览改代码即时生效不用等渲染。视觉上限够高CSS 动画、Canvas 绘图、SVG 路径动画已经能覆盖大多数看起来专业的动态图形需求。我做过一个典型项目给某产品的功能介绍视频做开场动画要求五个功能图标依次从底部滑入每个图标伴随一个环形进度条从 0 到 100% 填充。Claude 生成的代码大概不到 200 行核心是 CSSkeyframes动画加少量 JavaScript 控制触发顺序全程不到一小时就出了成片。关键提示词片段# 目标产品开场动画时长15秒 # 画面尺寸1920x1080 # 5个图标依次入场间隔0.8秒 # 每个图标下方有环形进度条从0填充到100%填充时数字同步滚动 # 入场动画使用 cubic-bezier(0.2, 0.8, 0.2, 1) 缓动 # 所有动画结束后停留2秒再整体淡出如果你要做的是产品介绍、课程片头、动态海报这类信息传达为主、视觉质感为辅的视频Web 三件套是性价比最高的选择。2.3 路线三数据可视化叙事——把一份报告变成一个有情节的视频做数据分析的同学都知道静态图表的表达力有限折线图的趋势变化、柱状图的对比演进、地图上的数据流动做成动态视频后信息密度和感染力是质的提升。路线三的核心逻辑是用 ECharts 或 D3.js 生成图表动画配合旁白文案的节奏逐段导出视频。我的实践案例是处理一份季度业务复盘数据集。需求是把 12 个月的核心指标变化做成一个 3 分钟短视频包含折线图的动态绘制、季度柱状图的对比、以及关键节点的数字高亮。ECharts 本身对动画的支持非常完善比如折线图可以用animationDuration控制绘制过程连续渐变的数据可以用setOption动态推送。Claude 在这个场景下的价值在于它知道 ECharts 的配置项细节能直接生成整套动态逻辑的初始化代码并且能处理一些 Easy to get wrong 的配置——比如notMerge参数要不要开、animationDurationUpdate和animationEasingUpdate怎么配合。关键提示词片段# 目标季度数据动态展示视频 # 数据12个月指标按月推进 # 视觉折线图按月绘制柱状图按季度出现 # 要求每月数据点出现时右侧文字标签同步更新当月数值和环比增幅 # 画面分辨率 1920x1080动画总时长 30 秒我的经验做这种数据叙事视频最大的坑不是写不出动画而是没有在开始前定义清楚数据叙事文案。Claude 可以帮你写代码但你得先告诉它每一段画面要传达什么信息。我建议先把旁白文案写好然后按文案段落切分画面脚本再让 Claude 按脚本生成动画。顺序反了就会陷入反复改图的泥潭。2.4 路线四FFmpeg 脚本化剪辑——不写画面但能把剪辑效率提升一个数量级路线四的思路和前三类完全不同不做动画画面而是用 FFmpeg 的脚本能力做自动化剪辑。它解决的不是怎么做出一段画面而是怎么把大量素材高效地拼成成片。我在实际工作中遇到的最典型场景是课程视频切条。我手上有一批长视频课程素材每段 40 分钟左右需要按话题切成若干 3-8 分钟的短视频并且统一加上片头片尾、字幕条、音量标准化。纯手动剪切的话每段课程要耗费几个小时而且极易出错。FFmpeg 在这件事上是无可替代的工具。配合 Python 脚本做批处理可以实现按时间戳自动切割、统一转码、自动拼接片头片尾、批量添加水印和字幕。Claude 在这个路线中的作用是帮你写那套胶水脚本——把 FFmpeg 命令行、JSON 配置、Python 批量逻辑串起来。关键提示词片段# 目标批量切条脚本 # 输入一个视频文件 一个 JSON 时间戳列表 # 每个条目包含start, end, 输出文件名, 标题 # 要求 # 1. 用 ffmpeg 精确切割重新编码不用 -c copy避免关键帧错位 # 2. 切割后统一加 2 秒黑场开头和结尾 # 3. 输出格式 H.264 AAC分辨率 1080p码率 4Mbps # 4. 生成一份 Excel 索引表文件名、标题、时长这条路线看起来最不酷但实用性极强。我后来把短视频栏目的大部分后期流程都脚本化了每周可以稳定处理上百条素材这个是纯手工时代无法想象的产能。2.5 路线五Python 逐帧生成——最笨但最灵活的视频造法第五类路线是逐帧生成用 Python 代码生成每一帧图像再把帧序列编码成视频。传统上这被用在程序化艺术和实验影像领域但其实它的应用面比想象中宽。最典型的案例来自我在一个模拟项目中做的特殊转场效果。需求是视频中段要从真实画面转到一个由几何图形构成的抽象世界。前四类路线都很难干净地处理这个转场因为需要插值时计算中间状态。最终我让 Claude 写了一个 Python 脚本用 OpenCV 读取前一段视频的关键帧提取边缘和色块信息生成一组介于写实和抽象之间的过渡帧序列再合成到视频中段。逐帧生成的优点是无与伦比的灵活性——你可以绘制任何你想要的图像只要能用代码描述。缺点是性能和开发成本高一帧图像的计算时间如果超过 0.1 秒渲染一分钟视频就要好几分钟甚至更久。关键提示词片段# 目标生成3秒转场帧序列90帧30fps # 输入前一段视频的关键帧图像 # 输出一系列几何抽象帧 # 思路 # 1. 第一帧完整真实图像 # 2. 中间帧逐渐将图像分割为三角形色块每个色块保留原图像平均色 # 3. 最后一帧纯几何抽象画面 # 要求用 OpenCV 实现 Delaunay 三角剖分帧间过渡平滑我的经验用这条路线时一定要先把单帧效果做对再批量渲染。Claude 生成的代码容易有个问题——逻辑正确但视觉效果不符合预期比如色块数量太多、过渡不够平滑。与其反复改代码再重渲染不如让 Claude 生成一个输出单帧预览的调试模式先看 3-5 帧的效果确认后再跑全量。2.6 路线六生成艺术与粒子系统——用随机规则制造高级感第六类路线面向的是创意片头、背景氛围和艺术化表达。核心工具是 p5.js 或 Processing——它们天生擅长用简单规则产生复杂视觉。比如成百上千个小粒子在画布上按某种力场规则运动构成流动的图案或者用随机生成算法产生无限不重复的几何纹理。我用这条路线做了一个栏目片头背景是流动的粒子海洋主标题文字在粒子汇聚中浮现。整个动画的核心逻辑也就 100 多行 p5.js 代码粒子系统的运动规则、汇聚力场、以及文字作为吸引源的逻辑。关键提示词片段# 目标粒子片头动画时长10秒 # 技术栈p5.js # 画面2000个粒子在黑色背景上流动 # 动画逻辑 # 1. 开场2秒粒子做随机漂移运动 # 2. 从第2秒开始粒子逐渐被吸引向画面中央形成Claude文字形状 # 3. 文字汇聚完成后整体淡出 # 关键参数粒子大小2px颜色蓝色系渐变吸引力随距离变化用 inverse-square 法则生成艺术的可控性比前几类低——因为视觉效果来自随机性和涌现行为很难完全预测。但不可完全预测恰恰也是这种路线的魅力所在。我的处理方式是让 Claude 关键参数粒子数量、吸引强度、衰减系数独立定义成常量跑一遍后根据效果的感觉去调参数而不是试图精确控制每一帧。2.7 路线七Three.js/WebGL 三维镜头——让画面真正站起来第七类路线用 Three.js 在浏览器里渲染三维场景。相比前几类方案的平面感Three.js 能做真正的三维镜头运动相机推拉摇移、物体旋转、场景光影变化。我用来做一个模拟三维数据空间展示的项目——数据点分布在三维空间中镜头沿一条预设路径穿过数据云。Three.js 代码比前几类复杂涉及场景、相机、渲染器、几何体、材质和动画循环的完整闭环。但 Claude 对这种经典框架非常熟悉只要描述清楚场景构成和镜头运动代码生成的质量通常不错。关键是要把物理世界的约束描述清楚单位大小、坐标方向、相机位置和视野角度。关键提示词片段# 目标三维数据空间漫游动画时长20秒 # 技术栈Three.js 已加载的点云数据 # 场景5000个数据点分布在 [x: -50, 50, y: -50, 50, z: -50, 50] 空间内 # 相机路径 # - 0-5秒从 (0, 0, 120) 缓慢推进至 (0, 0, 60) # - 5-15秒围绕Y轴旋转120度半径60 # - 15-20秒拉远至 (0, 0, 130) # 画面要求透视投影fov 45粒子材质大小2带轻微辉光效果三维动画的学习成本在七条路线里最高但它带来的质感上限也最高。如果你的内容需要展示空间关系产品结构、数据空间、地理信息这条路线值得投入。2.8 七条路线怎么组合一条片子往往不止一条路线把这 7 条路线分开讲是为了把逻辑说清楚。但真实生产中一条完整片子往往是多路线的组合。我目前的常规做法是片头用粒子系统路线六或 Web 动画路线二做品牌开场。主体内容数学推导用 Manim路线一、数据报告用 ECharts路线三、产品功能用 Web 动画路线二。剪辑串联用 FFmpeg 脚本路线四拼接所有段落加转场、字幕、音频。特殊镜头三维展示用 Three.js路线七、抽象转场用逐帧生成路线五。组合的关键在于统一风格规范所有路线的画面尺寸、字体、配色、转场节奏要在开始前定义好否则成片会像拼接怪。我一般会把这个视觉规范作为一个固定段落写进提示词框架里后面会详细展示。3. 五个案例拆解从提示词到成片一条完整的生产链路这一节挑五个代表性案例完整展示从需求到成片的过程。每个案例我会给出原始需求 - 我的提示词 - Claude 的产出流程 - 关键实现细节 - 踩过的坑。3.1 案例一用 Manim 做贝叶斯定理的可视化讲解需求来源是我的一期科普视频需要一段 60 秒的动画直观展示贝叶斯定理中先验 - 似然 - 后验的更新过程。我的做法是先用文字向 Claude 描述画面逻辑画一个代表全概率空间的矩形中间用一条竖线分成两个区域面积比例代表先验概率 P(A) 和 P(¬A)。随着新证据出现竖线缓慢向左或向右移动两个区域的面积随之变化标签数字同步更新。Claude 给出了一份完整的 Manim 场景代码核心结构是class BayesUpdate(Scene): def construct(self): # 定义概率空间矩形 rect Rectangle(width6, height3) divider Line(...).set_color(WHITE) # 用 ValueTracker 控制竖线位置 tracker ValueTracker(0.0) def update_divider(mob): x rect.get_left()[0] (0.5 tracker.get_value()) * rect.width mob.put_start_and_end_on(...) divider.add_updater(update_divider) self.add(divider) # 然后让 tracker 随时间变化模拟证据更新 self.play(tracker.animate.set_value(...), run_time5)这段代码的巧妙之处在于用了ValueTracker驱动竖线位置而不是硬编码每一帧。这样后续调整证据更新速度只需要改一行参数。这是 Claude 对 Manim 掌握深度的典型体现。踩过的坑第一次生成的代码渲染失败原因是 Manim 版本升级后put_start_and_end_on的接口签名变了。我把完整报错信息贴回去Claude 很快就定位到是版本兼容性问题并且给出了安装对应版本的具体方案。这个经历也让我养成了一个习惯在提示词里明确声明 Manim 版本号。3.2 案例二用 ECharts 把季度报表变成动态数据故事这个案例来自一个模拟数据报告项目。需求很朴素把某业务 12 个月的指标变化做成一段 3 分钟的数据视频包含月度趋势、季度对比、关键事件标注。我的提示词给了 ECharts 和数据结构两个关键说明用动态推送setOption的方式让折线图逐月绘制配合一个当前月份的标签实时更新季度对比用柱状图在折线图之后整体入场关键事件点用markPoint标注对应的月份数据点会闪烁高亮。Claude 给出的方案分为三层第一层是数据预处理把原始 CSV 解析成按月、按季聚合的数据结构第二层是 ECharts 配置包含折线图、柱状图和 markPoint 的完整 option第三层是播放控制逻辑用setTimeout控制每月数据点出现的节奏。这里最值得说的是时间轴和动画的同步Claude 的输出里定义了一个统一的playhead变量所有视觉元素的更新都由它驱动。这样我在后期调整视频节奏时只需改这一个变量。踩过的坑ECharts 动态更新时如果option.series的数组长度不一致会出现图表闪动。Claude 一开始生成的代码没处理这个问题导致折线图在每推送一个月份数据时都会重置整个坐标轴。后来它在代码里加了notMerge: true并对series做固定长度处理问题才解决。这类坑主要靠跑一遍发现再回去让 Claude 修效率也还行。3.3 案例三纯 Web 动画做产品功能介绍短视频这个案例是给某模拟产品做一段 40 秒的功能介绍视频。需求是五个核心功能点每个功能点用一屏动画展示包含图标、标题、一行说明文字半自动播放。我的提示词核心是按场景拆分 场景切换动画五个功能点对应五个全屏场景场景间用平滑过渡渐变 轻微的缩放每个场景内部元素按顺序入场。Claude 产出的代码结构非常干净一个Scene类管理五个场景的进入和离开每个场景的内容由 JSON 配置驱动意味着我改文案和图标不用动代码逻辑。动画效果用 CSSanimation配合animation-delay控制入场顺序JavaScript 只负责场景切换。这个案例的成本极低从生成到可以录制成片不到一小时因为 Web 动画调试太方便了直接在浏览器里刷新看效果。如果效果不对我都不用贴报错信息直接告诉 Claude第三个场景的元素入场顺序不对它就能针对性地改。踩过的坑录制视频时如果用 macOS 自带的屏幕录制默认帧率不稳定波动在 20-40fps视频会出现卡顿。后来我换成 Playwright 无头浏览器录帧把渲染帧率锁定在 60fps问题解决。这个话题和 Manim、FFmpeg 都不同但同样是跑通了才发现的典型问题。3.4 案例四用 FFmpeg 批量剪辑自动化课程切条这个案例是一个比较大的工程。需求是把 6 段每段 40 分钟的课程视频按章节切成共 47 条 5-10 分钟的短视频每条统一加标题片头片尾、水印和标准化音量。我给 Claude 的描述是提供一个视频目录和一份章节时间表写一个 Python 脚本自动批量切割并配合 FFmpeg 的-f lavfi生成标题卡作为片头再拼接切割的视频段。片头标题从章节表里读取输出为统一编码的 1080p 视频。Claude 确实按照我的描述生成了脚本而且加了一个我自己最初没想到的处理统一处理了音频响度。它用 FFmpeg 的loudnorm滤镜把每条短视频的音量标准化到同一响度这让后期不需要逐条调音量体验大幅改善。踩过的坑最初脚本用-c copy方式切割虽然速度快但在没有关键帧的位置切断会导致音频视频不同步。Claude 最终改成重新编码-c:v libx264 -c:a aac虽然耗时增加了但稳定性大幅提高。这个点是 FFmpeg 使用中的经典陷阱建议直接记住结论凡是要精准到秒的切割一律重新编码。3.5 案例五p5.js 粒子系统做栏目创意片头这个案例的效果前面路线六部分提过2000 个粒子在黑色背景上流动最后汇聚成Claude文字形状。这里是整个生产链路的详细过程。我的需求很简单就给了 Claude 一句话级别的画面描述黑色背景、粒子流动、最后汇聚成文字。它给出的实现思路是先用createGraphics()离屏绘制Claude文字的灰度图用文字图形的亮度值作为粒子汇聚的目标位置亮度高则粒子聚集亮度低则漂移。这个思路让我眼前一亮因为它不依赖文字渲染库用像素采样解决了粒子聚成文字的问题。# 核心逻辑伪代码 # 1. 离屏绘制文字graphics.text(Claude) # 2. 初始化 2000 个粒子初始位置随机分布在画布上 # 3. 每帧读取粒子位置附近 目标文字图 的 brightness 值 # 4. 若 brightness 高粒子向该位置加速移动否则做随机漂移 # 5. 粒子数量较多时用 grid 空间索引避免频繁读取像素踩过的坑粒子数量调到 5000 时get()读取像素的逻辑会让帧率掉到个位数。Claude 给出一个优化方案——把文字图的像素数据提前读取到一个数组里而不是每帧实时调用get()。这个改动让画面从PPT 播放变成了流畅动画差异非常明显。3.6 五个案例放在一起看共性是什么五个案例覆盖了七条路线中的六条漏了逐帧生成那个在路线五部分已经详细说过。把它们放在一起看有几条共性规律提示词质量的差距直接影响成片下限。给 Claude 描述得越具体——包括画面逻辑、参数边界、输出约束——它产出的代码越接近可运行状态调试成本越低。版本兼容性声明非常重要。Manim、ECharts、Three.js 都在持续迭代Claude 的知识库有一定滞后性。在提示词里声明版本号能大幅减少代码没问题但环境不兼容的报错。先跑通最小闭环再追求效果。无论哪条路线第一次生成往往不是最优解。让 Claude 先生成最小可运行版本确认逻辑正确再迭代优化视觉效果和参数效率最高。4. 可复用提示词框架让 Claude 按你的思路产出能跑的视频代码经过几十次迭代我沉淀了一套可复用的提示词框架。与其每次从头描述需求不如用一个固定的结构去组织信息。这套框架不只是写一段提示词而是定义了一套和 Claude 协作的规范。4.1 框架母版可以直接复制的提示词模板下面是我目前最常用的提示词模板适用于所有七条技术路线【任务定义】 用 {技术栈} 实现一段 {时长} 的视频内容是 {内容概要描述}。 【输出容器】 - 语言/框架版本{Python 3.10 Manim 0.17} 或 {HTML5 Three.js r160} 或 ... - 运行环境{本地 Python 环境 / 浏览器 / Node.js 环境} - 输出格式{MP4 1080p / 网页动画 / 帧序列} - 关键依赖{列出需要用到的库和版本} 【视觉规范】 - 画面分辨率1920x1080 - 主色系{主色 #RRGGBB 辅助色如果有品牌色约束必须写清} - 字体{中文字体名称如果涉及标题或字幕} - 转场风格{硬切 / 渐变 / 滑动 / 缩放} - 节奏{每个场景的目标时长整体节奏感描述} 【场景分镜】 场景1 - 内容描述... - 关键元素... - 进场动画... - 出场动画... 场景2 - ... 【验收清单】 - [ ] 所有场景动画能完整播放 - [ ] 无文字重叠、越界或渲染不全 - [ ] 帧率稳定在 {目标帧率} 以上 - [ ] 输出编码兼容 {目标平台如 B 站 / 微信 / YouTube} - [ ] 配色符合品牌约束 {如有} 【迭代规则】 - 如需修改我会指出具体场景和时间点你只修改对应部分 - 不要重写无关代码 - 保持原有架构不引入新的依赖这套框架的价值在于把模糊需求变成了结构化规格。Claude 收到的不是一句话需求而是一份接近技术设计文档级别的输入它能基于此产出更稳定、更可控的代码。4.2 框架设计逻辑为什么每个模块都必不可少逐个说下每个模块存在的理由。任务定义是整个提示词的锚点。我发现如果任务定义模糊Claude 会在代码架构层面做出错误假设比如做了多余的模块、加了很多不必要的抽象浪费大量 token 和调试时间。清晰的任务定义能约束它的创作欲。输出容器是减少环境报错的关键。之前提过 Manim 版本接口、Three.js 版本差异这些问题这类问题本质上是因为 Claude 无法知道你本地的环境状态。在输出容器里声明清楚等于提前划定了边界它能避开用了你环境里没有的 API这类的坑。视觉规范和场景分镜是保证视频质量的两道保险。前者保证全片风格统一后者保证 Claude 理解内容结构。场景分镜这一项尤其重要——它不仅仅是场景列表更是在定义时间轴和镜头语言。Claude 有了明确的分镜才能生成符合结构的代码。验收清单的价值在于把我觉得不行变成可以自动检查。Claude 生成代码后会自己对照验收清单做一轮自查很多低级错误会在它提交代码前就被发现。迭代规则解决的是改一处毁全局的经典问题。代码工程一大模型很容易在修改局部时顺带优化无关部分导致不知道哪里会出问题。明确了迭代规则之后Claude 会克制很多。4.3 提示词写法中的三个常见错误框架有了但落到实际使用时会发现有三个错误极其常见几乎每个人都会踩。错误一把视觉细节和逻辑细节混在一起。很多人写提示词时会把粒子数量 2000文字颜色 #FFFFFF动画时长 10 秒这些信息混在场景描述里。这会让 Claude 难以区分哪些是视觉约束全局生效哪些是场景细节仅该场景生效。正确做法是用我上面的分层结构视觉规范说全局场景分镜说局部。错误二不给失败反馈的语境。调试时直接把报错信息贴回去往往不够。更有效的做法是先描述预期行为是什么、实际行为是什么、具体在哪个时间点或哪个元素上出现异常再把报错信息贴上去。这样 Claude 在定位问题时就有了上下文而不是一头扎进错误堆栈里。错误三一次让 Claude 生成完整的高期望成品。即使是 Claude Opus 5.5一次生成也大概率达不到最终理想效果。反而是分步生成 逐步验证的模式成功率更高先做骨架跑通再填内容看效果最后调参数打磨质感。每一步的上下文都保留着越到后面前几轮的调整反而越少返工。4.4 不同路线的提示词关键点差异框架是通用的但不同路线的侧重点有明显差异。我把差异整理成一张对照表路线提示词中必须强调的关键点常见无效提示词示例Manim场景划分、动画时长、渲染帧率、版本号做一个好看的数学动画Web 动画帧率锁定、浏览器兼容、导出方式做一个吸引人的开场ECharts/D3数据结构、动画更新模式、坐标轴动态范围展示这些数据FFmpeg编码参数、切割模式重编码 vs copy、音频处理把视频切成几段逐帧生成单帧预览模式、批量渲染、文件命名规范生成一个转场效果p5.js 粒子系统粒子数量、力场规则、性能优化策略做一个粒子动画Three.js场景单位、相机路径、材质参数做一个三维动画这张表的核心含义是每种路线都有它最容易翻车的地方。Manim 容易版本问题FFmpeg 容易时序问题ECharts 容易状态管理问题p5.js 容易性能问题。提示词里提前问一句这一类问题要注意什么让 Claude 自己标注风险点往往比事后排查更省事。5. 真实工作流里的效率账一次完整视频生产的成本与收益说完了路线和框架回到一个现实问题这套方案到底值不值得投入我用实际数据给你算笔账。5.1 一条片子的时间分配拿我最典型的一期科普视频来算。最终成片约 8 分钟包含30 秒粒子片头、3 分钟的 Manim 数学动画、2 分钟 ECharts 数据图表、1.5 分钟 Web 动画产品示例、1 分钟字幕和片尾。环节传统手工生产方式耗时Claude 代码生产方式耗时前期策划 文案3 天3 天无法压缩数学动画制作4 天6 小时生成 2 小时 调试 4 小时数据图表动画2 天3 小时产品演示动画3 天4 小时片头片尾设计2 天2 小时剪辑合成3 天1.5 小时FFmpeg 脚本批处理修改迭代视需求 1-3 天1-3 小时改参数重新渲染传统方式总耗时约 18-20 个工作日代码化生产方式约 4-5 个工作日。效率提升的核心不是写代码快而是改起来快程序化视频改一个数字就重渲染一次手工视频改一个画面可能要从头剪辑。5.2 最容易翻车的五个环节逐个给解法尽管整体流程顺畅但有几个环节翻车率极高我必须单独列出来。第一渲染环境和本地依赖不一致。Claude 生成的代码默认假设你有一个干净的、支持最新版本的运行环境。我建议在项目开始时准备一个专用的虚拟环境文件requirements.txt 或 package.json让 Claude 在项目最初就生成这个文件避免后面环境问题耗尽耐心。第二提示词里的视觉规范出现了模糊措辞。比如让动画更流畅这种描述。Claude 会自行理解流畅的含义——可能是动画更平滑插值也可能是帧率更高性能优化。这两者的实现方案截然不同。我的做法是永远用可量化的描述帧率保持在 60fps、过渡时长 0.5 秒。第三时间轴设计没有留白。这是内容层面的问题不是代码层面的Claude 生成的动画往往信息密度过高——因为它在代码层面忠实地实现了你的所有描述没有考虑观众需要时间消化的体验。我开始做分镜时会有意识地加入停留 1 秒让观众阅读文字的约束条件。第四文本渲染的中文字体缺失。Manim、p5.js、Three.js 默认字体对中文支持都不好很容易出现方块字或乱码。我是在被这个问题折磨过一次之后学乖了在视觉规范里直接写清楚所有文本使用 {某个中文字体名}并提前准备好字体文件路径。第五长视频的内存溢出。逐帧生成路线五和 Three.js 渲染长镜头时如果代码写得不注意内存管理视频生成到一半内存就爆了。解法是在提示词里强制要求每 100 帧自动释放不再使用的对象以及渲染完的帧立即写入磁盘不保留在内存中。5.3 我现在的判断标准什么场景该用代码做视频说实话遇到各种需求不是所有视频都适合用代码来做。经过这轮实践我形成了几个简单的判断标准。优先用代码做视频的情况内容包含精确的数据、图表、公式或几何关系画面元素可以被清晰地拆解成对象 参数需要频繁迭代修改改数据、改文案、改配色需要批量生产版本或做版本对比需要和其他自动化流程数据抓取、定时发布打通不建议用代码做视频的情况需要真实世界影像拍摄镜头、实景素材需要高度拟真的物理模拟或角色动作内容以氛围感情绪表达为主画面不确定性反而是优点需求是一锤子买卖不需要迭代6. 实战体会几个从跑通到跑稳的关键认知如果要用一句话总结我从这套流程里学到的东西那就是AI 写代码做视频真正的杠杆不在生成而在约束和迭代。Claude Opus 5.5 的代码能力就是一把好用的枪但扣动扳机的精度取决于你给它输入的约束条件。几个从跑通到跑稳的经验最后分享给大家。第一花时间雕刻视觉规范段落是收益率最高的投入。我一开始做视频时视觉规范写得很随意——科技感高级感这类词随口就来。后来发现Claude 对这类词的理解和我的预期经常南辕北辙。把视觉规范改成具体参数色值、字体、留白、动画节奏之后成片的风格一致性显著提升。我把这套视觉规范沉淀成了一个独立文件每次做新项目时直接粘贴进来再针对当次项目做小改动。第二调试时要给 Claude 画面描述而不是只给运行结果。这可能是最重要的一个习惯。我观察到很多人调试时只会说报错了或者贴报错信息。但视频代码有个特殊性很多问题不报错只是画面和你预期的完全不同。这时把预期画面和实际画面用文字描述清楚哪个元素、哪个位置、哪个时刻Claude 定位问题会快得多。我甚至会截一两帧画面用文字转述画面里的关键差异给它——它确实能听懂。第三一轮生成不满意太正常了但你要会引导它逼近目标。我现在的习惯是每一轮迭代专注于只改一个问题——比如粒子数量从 2000 改为 5000看看效果。如果同时提多个诉求Claude 容易在修改中出现优先级冲突。一次一个改改完看效果再提下一个这个节奏下来最终的画面在一轮轮微调中慢慢长成了我想要的样子。第四关于成本代码生成方案的边际成本递减非常明显。初期搭建一套流程需要花时间设计提示词框架、跑通渲染链路、沉淀视觉规范这个投入是不可忽略的。但一旦跑通后面每做一期视频的边际成本几乎只有渲染时间 微调 token 费用。相比之下传统视频生产方式每期都要从零开始或者至少付出大量重复性剪辑劳动。如果我的判断没错的话这个差距会在代码化视频成为主流工作流之后变得更加显著。