企业官网建设流程全解析

开头直接说结论：如果你还停留在"让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 类路线，覆盖了从数学科普、数据新闻、产品演示到创意片头的常见视频需求。先放一张总览表，再逐个展开。

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 行，核心是 CSS@keyframes动画加少量 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(width=6, height=3) 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_time=5)

这段代码的巧妙之处在于用了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 容易版本问题，FFmpeg 容易时序问题，ECharts 容易状态管理问题，p5.js 容易性能问题。提示词里提前问一句"这一类问题要注意什么"，让 Claude 自己标注风险点，往往比事后排查更省事。

5. 真实工作流里的效率账：一次完整视频生产的成本与收益

说完了路线和框架，回到一个现实问题：这套方案到底值不值得投入？我用实际数据给你算笔账。

5.1 一条片子的时间分配

拿我最典型的一期科普视频来算。最终成片约 8 分钟，包含：30 秒粒子片头、3 分钟的 Manim 数学动画、2 分钟 ECharts 数据图表、1.5 分钟 Web 动画产品示例、1 分钟字幕和片尾。

传统方式总耗时约 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 费用"。相比之下，传统视频生产方式每期都要从零开始，或者至少付出大量重复性剪辑劳动。如果我的判断没错的话，这个差距会在代码化视频成为主流工作流之后，变得更加显著。