企业官网建设流程全解析

前阵子有个做科普自媒体的朋友甩了条视频给我，开口就问：“这画面这么规整，肯定是 Claude Opus 5.5 直接生成的吧？”我点开一看，是个排序算法动画，旁边还有中文标注和坐标轴。我回他：这条视频不是“生成”的，是“写”出来的。他明显愣住——在他的认知里，AI 生成视频就等于输入一句话、点个按钮、等模型吐出一个 mp4。

这个误会我最近见了太多次。Claude Opus 5.5 确实很强，但它的能力边界很明确：它不直接生成视频文件，它生成的是文本、代码和结构化描述。真正让画面逐帧出现的，是代码执行后的渲染引擎，以及最后封装音频和画面的 ffmpeg。也就是说，一条“代码视频”从想法到成片，要走一条五步流水线。这篇文章我打算把这条流水线完整拆开，从需求拆解、分镜设计，到代码生成、帧渲染，再到音画合成和返工校验，每一段都配上我实际用过的命令、参数和踩坑记录。适合谁来读？想用 AI 做算法演示、数据动画、科普短片的创作者，尤其是那些已经被“文生视频”的可控性折磨过、想要一条能精确修改、能复现、能批量产出的路子的人。

1. 先破个误区：Claude 不是“生成”视频，它在“写”视频

1.1 文生视频和代码视频是两条完全不同的路

目前市面上的“AI 生成视频”其实分两大流派。一派是 Sora、Runway、可灵这类文生视频模型，输入一句话，模型内部的扩散网络直接预测出一段画面。这条路门槛最低，但代价是可控性差——你没法精确指定某个物体在第几帧出现在哪个坐标，也没法让画面严格符合某个数学过程，还经常出现多手指、乱拼文字这类“幻觉画面”。

另一派就是今天要讲的代码视频：让 Claude 这类代码模型生成可运行的渲染脚本，脚本被解释执行后逐帧画出画面，再用工具把帧序列合成视频文件。这条路的名字在行内叫“程序化动画”或“代码驱动渲染”，它和文生视频最大的区别是——画面里的每一个像素都来自确定性的计算，不是来自模型的概率预测。

1.2 Claude 的能力边界：它只能输出文本

说句不好听的，很多人是被宣传话术带偏了。Claude Opus 5.5 是个模型，模型的输出边界是 token 序列，也就是文本。它能给你一段 Python 脚本、一份分镜表、一张字幕清单，但它没有任何机制直接“吐”出 PNG 或 H.264 流。你拿到的render_sort.py本身不是视频，它只是一份“怎么做视频”的说明书。

打个生活化的比方：Claude 是写得一手好菜谱的厨师长，但厨房里真正开火、下锅、装盘的是别人。在这条流水线里，“别人”是两样东西：渲染引擎负责把代码变成一帧一帧的画面，ffmpeg 负责把画面拼成能播放的视频。理解了这个边界，你就不会再问“为什么 Claude 不能直接生成 MP4”，而是会开始琢磨“怎么让它写的菜谱更好执行”——后者才是真正能提升生产力的方向。

2. 五步流水线：一条代码视频是怎么从想法变成 mp4 的

2.1 五步流水线一览

我把做代码视频的整个过程固定成了五个环节，每一步都有明确的产出物和验收标准：

注意看，Claude 只出现在第一、二、五步，而且它的产出永远只是文本。真正“视频素材诞生”的时刻是第三步——当你敲下python render_sort.py --scene 2，几百个 PNG 文件被写进硬盘的那几分钟。

2.2 为什么中间不能省略任何一步

刚入坑的人最容易犯的毛病是：把所有需求一口气塞给 Claude，然后期待它直接给你一个完整成片。结果往往是一堆报错、半成品和无法理解的动画。问题不在于 Claude 笨，而在于你跳过了流水线的中间环节。

每一步存在的意义都是“可检查”。分镜表能检查内容逻辑，代码能检查语法和渲染逻辑，帧序列能检查画面细节，最终合成文件能检查音画同步。任何一步出问题，你都能精准定位到这一层的输入输出，而不是面对一团漆黑的“生成失败”。代码视频这条路的核心价值，就是每一层都可以被审计、被修改、被单独重跑。这也是它和文生视频最本质的分水岭。

3. 第一步·拆解分镜：把一句想法变成可执行的场景表

3.1 先有分镜表，再让 Claude 动手

我见过太多人拿着“帮我做个排序视频”这种需求直接去问 Claude，结果当然是一团糟。因为模型不是导演，它不知道你要讲什么、讲多久、什么风格。正确的做法是：先把一句话想法拆成一张分镜表。

分镜表是什么？就是一张描述“画面如何随时间推进”的表格。以我做过的一个插入排序科普视频为例，目标时长 30 秒，1920x1080，24 帧每秒：

这张表的价值是：它把模糊的意图变成了每个场景的时长、画面元素、关键动作、字幕文字。有了它，Claude 才知道自己该写什么。

3.2 一个可以直接抄的分镜提示词模板

我固定的分镜提示词结构是这样，你也可以直接复制去改：

我要做一个 30 秒的插入排序科普视频，分辨率 1920x1080，24fps。 画面风格：深色背景 #1e1e2e，柱状图主色 #89b4fa，交换高亮 #f38ba8。 请把它拆成不超过 4 个场景的分镜表，按 markdown 表格输出。 每个场景需要包含：时长区间、画面元素、关键动作、字幕文字、对应的渲染函数名。 不要写代码，只输出分镜表。

注意最后一句：“不要写代码，只输出分镜表。”这一步刻意分离任务。分镜设计和代码实现是两种不同的认知负荷，让模型同时做两件事，它往往会顾此失彼——分镜写得糙，代码也写得乱。先拿到分镜表，你确认内容没问题，再进第二步。

3.3 分镜评审：人机协作的第一个检查点

拿到分镜表后，花五分钟做一次评审：时长总数对不对、有没有从零到一讲清概念、每个场景的文字会不会太挤、颜色搭配是否符合频道整体视觉。这里我有一个血泪教训：第一次我让 Claude 列了 6 个场景，每个场景都塞满了知识点，成片节奏快到观众根本来不及看。后来我把规则改成“一个场景只讲一个知识点，最多 3 行字幕”，效果立刻好了。分镜表是整条流水线的地基，地基歪了，后面渲染得再精细也白搭。

4. 第二步·生成代码：Claude 出力，但约束得你来定

4.1 渲染技术选型：先想清楚你要哪种视频

“代码视频”是个大类，渲染技术远不止一种。我按自己的使用频率排了个序：

绝大多数科普数据动画，matplotlib 就够用；要做数学推导那种行云流水的动画，才需要 Manim。别一上来就 Manim，学习成本和成败感差距很大。我现在的组合是：图表类用 matplotlib，视觉向的手写 p5.js，最后统一 ffmpeg 合成。

4.2 让 Claude 生成“可测试”的代码

选好路线后，给 Claude 的 prompt 里要写清楚“可测试性要求”。我的固定模板是：

基于分镜表，写一个 Python 文件 render_insertion.py。 要求： 1. 每个场景对应一个独立函数 render_scene_01() ... render_scene_04()； 2. 每个函数只负责把自己的帧写入 frames 目录，互不依赖； 3. 分辨率、帧率、颜色等常量集中在文件头部； 4. 只允许使用 matplotlib、numpy、标准库，禁止引入未说明的第三方库； 5. 程序运行时不得访问网络； 6. 支持 --scene 参数和 --draft 参数，draft 模式只渲染 3 帧。

为什么强调“每个场景独立函数”？因为第五步返工时最常见的操作是“只重渲染第 2 个场景”，如果所有场景糊在一个脚本里，改动一个细节就得全部重跑。而--draft参数更是救命稻草，正式渲染前用低帧率、低分辨率试跑一遍，能把大部分低级错误扼杀在摇篮里。

一个我实际用过的 matplotlib 骨架，供参考：

# render_insertion.py import matplotlib matplotlib.use("Agg") import matplotlib.pyplot as plt from matplotlib.animation import FuncAnimation FPS = 24 W, H = 1920, 1080 BG = "#1e1e2e" BAR = "#89b4fa" HIGHLIGHT = "#f38ba8" OUT_DIR = "frames" def render_scene_02(): fig, ax = plt.subplots(figsize=(W / 100, H / 100), dpi=100) ax.set_facecolor(BG) data = [5, 2, 4, 6, 1, 3] # ... 这里写指针移动与柱状图更新逻辑 anim = FuncAnimation(fig, update, frames=240, interval=1000 / FPS) anim.save(f"{OUT_DIR}/scene2_%04d.png", writer="pillow")

注意matplotlib.use("Agg")，这行必须有——服务器或后台渲染环境下没有显示器，不切 Agg 后端，脚本会直接报错。这类细节 Claude 未必每次都记得，你最好在 prompt 里主动补充。

4.3 静态校验与单帧试渲染

拿到 Claude 生成的代码，别急着全量渲染。第一步跑语法检查：

python -m py_compile render_insertion.py

第二步跑 draft 模式：

python render_insertion.py --scene 2 --draft

draft 只出 3 帧，打开看一眼构图、颜色、字体是否正常。如果这一步就发现文字是方块、柱子出了画布，直接让 Claude 改，成本几乎为零。别问我为什么强调这个——我第一次就直接跑了全量 720 帧，早上醒来发现所有中文字幕全是乱码，白渲了几个小时。

5. 第三步·逐帧渲染：真正的“视频素材”是在这一步产生的

5.1 执行渲染：从代码到一堆 PNG

到了这一步，才算真正“生产”视频素材。30 秒视频、24fps，就是 720 帧画面。每帧是一张 PNG，渲染脚本会把它们依次写进frames/目录：

python render_insertion.py --scene all

然后你会看到这样的输出：

frames/scene1_0001.png frames/scene1_0002.png ... frames/scene4_0180.png

性能预期说个大概：matplotlib 渲染 720 帧，视动画复杂度而定，通常几分钟到二十分钟；Manim 的 3D 场景单帧可能就要几秒，整片以小时计。所以分级渲染策略非常重要：草稿用低分辨率低帧率，定稿再跑全量。

5.2 帧命名规范与中文字体这两个大坑

帧文件的命名必须规范，我的建议是场景前缀_四位数字.png，比如scene2_0048.png。千万别用连续的裸数字命名，否则后面拼接场景时你会完全分不清哪帧属于哪个场景。

中文字体是第二个大坑，也是我见过翻车率最高的一项。matplotlib 默认字体不含中文，直接plt.title("插入排序")渲染出来全是方块。解决方法是下载一款中文字体，比如思源黑体或 Noto Sans CJK SC，然后在代码里强制指定：

import matplotlib.font_manager as fm plt.rcParams["font.family"] = "Noto Sans CJK SC"

我建议把字体安装和配置写进项目 README，因为每次换机器都得重新配。顺便说一句，Manim 和 p5.js 也各有各的中文字体坑，处理思路一致：先去系统里装字体，再在代码里显式指定。

5.3 性能问题与内存泄漏

长渲染最怕两件事：内存耗尽和进程被杀。matplotlib 里最常见的内存泄漏写法是在动画循环里不断创建新的 artist 对象（ax.add_artist(...)）却不清理旧对象，帧数一多，内存就像漏水的桶。更好的模式是复用画布上的对象，只更新其set_*属性。如果 Claude 生成的代码是“每帧新建元素”的写法，趁早让它改成更新式。

另外，渲染是 CPU/GPU 密集任务，笔记本风扇会狂转。如果场景多，我习惯用nohup挂后台跑，或者干脆写个简单的渲染队列脚本：

nohup python render_insertion.py --scene all > render.log 2>&1 &

之后用tail -f render.log盯进度，而不是傻坐着等。

6. 第四步·音画合成：ffmpeg 把帧变成能播的片子

6.1 帧序列封装为 mp4 的基础命令

帧序列齐了，先用 ffmpeg 把每个场景的 PNG 序列变成 mp4：

ffmpeg -framerate 24 -i frames/scene2_%04d.png \ -c:v libx264 -pix_fmt yuv420p -crf 18 -preset slow \ scene2.mp4

解释几个关键参数：-framerate 24告诉 ffmpeg 每秒播放多少帧；-pix_fmt yuv420p是兼容性关键，不加的话很多播放器和剪辑软件不认；-crf 18控制画质，数字越小画质越高；-preset slow是同画质下体积更小的编码策略，代价是编码慢，定稿时才用。

6.2 场景拼接、音轨混流与字幕烧录

四个场景的 mp4 都生成后，用 concat 方式拼接。先写个列表文件：

file 'scene1.mp4' file 'scene2.mp4' file 'scene3.mp4' file 'scene4.mp4'

再执行：

ffmpeg -f concat -safe 0 -i list.txt -c copy full.mp4

注意：concat 要求所有场景的分辨率、帧率、编码参数完全一致，否则拼接处会卡顿甚至失败。这也是我在第二步强调“所有场景共用同一组常量”的原因。

音轨方面，我的做法是先生成一段解说语音（TTS 工具可自行选用），再备一首低音量背景音乐，最后混流：

ffmpeg -i full.mp4 -i narration.wav -i bgm.mp3 \ -filter_complex "[1:a]volume=1.0[a1];[2:a]volume=0.15[a2];[a1][a2]amix=inputs=2:duration=first[aout]" \ -map 0:v -map "[aout]" -c:v copy -c:a aac -shortest \ final.mp4

字幕同理，先写一个.srt字幕文件，最后烧录进画面：

ffmpeg -i final.mp4 -vf "subtitles=subs.srt:force_style='FontName=Noto Sans CJK SC'" \ -c:v libx264 out_sub.mp4

6.3 三轨独立原则：返工成本最小的剪辑习惯

我踩过一个大坑：早期做视频时，解说、背景乐和字幕全都一次性烧进画面，结果解说词改了一个字，整片重新渲染。后来我定下规矩：画面、音频、字幕三条轨道在交付前始终保持独立，最后一步才合并输出。改解说词就只重导音频，改字幕就只重烧一遍字幕，完全不用动渲染环节。这个习惯帮我省下的时间，足够再做三条视频。

7. 第五步·回放校验和返工：AI 视频项目的真实工作量

7.1 回放验收清单

别以为渲染完、合成完就结束了。最后一步是老老实实把视频从头到尾看一遍，我每次都按这份清单过：

• 按帧检查：有没有文字闪烁、元素跳动、柱状图比例失调、颜色超出预期。
• 按节奏检查：用 0.5 倍速看一遍，动画是太快还是太慢，观众能不能看清比较过程。
• 按音画同步检查：字幕和解说词对得上吗？背景音乐有没有盖过人声？场景切换点和解说停顿点是否吻合。

任何一项不达标，都进入返工流程。

7.2 返工的正确姿势：单场景定位，不全局重来

返工最容易犯的错是“让 Claude 重写整个视频”。正确姿势是三步走：

1. 定位到具体场景。比如发现 14–24 秒的交换动画高亮颜色不对，问题就锁在scene3；
2. 把问题描述和该场景的现有代码一起贴给 Claude，只让它修这一个函数；
3. 单独重渲染该场景，再走一遍 concat 拼接。

这样每次返工的成本只有几分钟，而不是几小时。我现在的迭代周期基本是这个节奏：发现问题，改scene_swap()里的高亮颜色，单场景渲染 240 帧，重新拼片，确认通过。全程十分钟以内。

7.3 把流水线沉淀成个人工具链

做熟了以后，你会发现这套流水线完全可以模板化。我把自己的项目结构固定成这样：

project/ ├─ scenes/ # 每个场景一个 py 文件 ├─ frames/ # 渲染产物，不入 git ├─ audio/ # 解说、bgm、字幕源文件 ├─ tools/ # ffmpeg 相关脚本 ├─ storyboard.md # 分镜表 └─ render.py # 统一入口

每次开新视频，我只改storyboard.md和各场景代码，工具脚本全套复用。甚至这个脚手架本身也可以交给 Claude 生成——给它一份项目结构描述，让它补出模板代码。但你要记住，脚手架只是流程的骨架，分镜质量、审美判断、节奏感，这些才是决定成片好坏的关键，也是模型替代不了你的部分。

最后再分享一个个人习惯：每次项目收尾，我会在storyboard.md末尾追加一段“本片踩坑记录”，比如“第二次渲染时发现 scene3 的动画快了 0.3 秒，原因是 frame count 算错”。下一部片子开工前，先翻一遍这份记录。做代码视频这半年，最深的体会就是：AI 能帮我们把“写代码”这件事变得很快，但“想清楚要什么、怎么验收、如何返工”这套流程功夫，才是真正决定你能走多远的门槛。流水线摆在这儿了，剩下的，就是动手跑通第一版。