2026 年 9 月底开始，抖音和 B 站上冒出一批画风高度统一的 AI 科普解说视频，话题叫 Vibe 知识大赏。> 大多数人的第一反应是”这是哪个模型做的”。
这篇文章不聊这个。这篇文章聊的是：为什么这类视频能被稳定地产出，以及你该怎么搭出属于你自己的那条流水线。

0. 先给结论

如果你只有三十秒，记住这五句话：

1. 这不是”AI 生视频”。它不用文生视频模型，画面是代码渲染出来的。
2. **LLM 在这条链路里的角色是”编剧 + 程序员”**，不是画师。
3. 这波的起点是 Claude Opus 5.5（2026-09-22 发布 → 次日引爆），但它连图片都生成不了，输出只有文本。
4. 决定成败的不是模型，是流程——同一套画风，不同模型都能做出来，这件事本身就是证据。
5. **难点不在”能不能画出来”，而在”画出来像不像 PPT”**，而这一条可以用工程手段解决。

下面逐条展开。

1. 现象：这波到底是什么

先把这个词说清楚，因为很多文章一上来就搞混了。

「Vibe 知识大赏」不是一个官方比赛，而是抖音上生长出来的一个内容范式/话题——用 AI 把知识重新表达成一支动画解说视频。你在抖音搜这个标签，能看到大量同类作品；在 B 站也能直接搜到成片，比如：

• 「你越接近光速，时间就越慢？相对论到底有多反直觉」
• 「原来北京时间不是北京的时间｜差了 14 分钟，还是从陕西发出来的」
• 「《耗散结构》混乱不代表终点」

这类视频的画面特征非常统一：

1.1 这波潮流的起点：Claude Opus 5.5

必须先把这件事说清楚，否则后面的讨论会失真。

这波”代码出片”潮的引爆点，确实是 Claude。 时间线对得很整齐：

数据也能佐证：在那个汇总仓库里，1352 个作品中 Opus 5.5 占 1261 个（Sonnet 5.5 84 个、Fable 5.5 40 个）——约 93% 是 Claude 家族。

注意：本文前面提到的”Fable 5.5 做三星堆”案例，Fable 5.5 同样属于 Claude 家族（该仓库标题即 “Opus 5.5 · Sonnet 5.5 · Fable 5.5”，注明 Fable 5.5 当时仍是 limited preview、未正式发布）。

来源：阿里云开发者社区《Opus 5.5 生成视频的真相》、HuggingFace 教程

1.2 但”同一套画风，不同模型都能做”依然成立

起点是 Claude，不等于只有 Claude 能做。做这些视频的人，用的模型其实五花八门：

• 有人用 Fable 5.5（微博案例：三星堆 AI 科普解说）— Claude 家族
• 有人用 Opus 5.5（LINUX DO 讨论帖）— Claude 家族
• 有人用 glm-5.3-flash 做视频分析、再用别的模型生成 HTML 动画（大佬说论坛的实操记录）— 不是 Claude
• 也有项目同时支持 Claude Code 和 Codex 两种宿主（见后文 §8）

所以准确的表述是：

Claude 是这波的引爆点，但决定成败的变量不是模型，而是流程。

这个区分很重要。Claude 能占 93%，很大程度上是因为它的编程能力强、且 Agent Skills 生态先成熟——而不是因为它有什么”生成视频”的独门绝技。换个编程能力相当的模型，把工具链配齐，同样能跑通。

这不是一句鸡汤，下面会用具体的工程细节证明它。

2. 关键认知：这不是”AI 生视频”

这是最多人踩的认知坑，也是这篇文章最重要的一节。

看到”AI 做的视频”，直觉是去找一个文生视频模型，输入一段话，等它吐出一支片。Vibe 知识大赏这类视频基本不走这条路。

原因很实在，我们逐条对比：

任何一条单独拿出来，都足以否决文生视频路线。**尤其是”文字要准确”**——科普视频里出现错别字或者错误数字，是致命的。

所以这类视频的真实技术路线是：

用 LLM 写"代码"和"文稿"
        ↓
用代码渲染引擎把代码渲成视频

画面里的每一个元素——进度条、柱状图、代码窗口、箭头、公式、标注——都是 React 组件。

想通这一点，整件事就从”抽卡”变成了”工程”。

2.1 一个最能说明问题的反转

这一节值得单独写，因为它几乎完美地印证了上面的判断。

那支引爆一切的 donald MV（2 分 21 秒、320 万播放），画面其实不是代码渲染出来的。

有人把 donald 公开的那串约 9500 字符提示词翻了一遍，发现里面明确写了调用：

• Seedance 2.5 生成画面
• ElevenLabs 生成声音
• fal 跑视频生成
• 再用 JavaScript 叠动态图形

也就是说，那支 MV 的画面来自外部视频生成模型，Opus 5.5 在里面干的是导演加剪辑的活——决定每个镜头用什么素材、怎么接、哪里重来。

而真正纯靠写代码渲出来的，是另一批作品：@noahwachnik 的浏览器版《我的世界》、@WinterArc2125 用代码渲染的奥斯特里茨战役短片等，画面全部由 HTML、Canvas、SVG、Three.js 在浏览器里实时画出来。

这两批作品被大量转发者混为一谈了。

来源：阿里云开发者社区《Opus 5.5 生成视频的真相》（作者：晚安code）

还有个更硬的技术事实，值得记住：

Claude 连图片都生成不了。 Anthropic 官方文档写得很清楚：Claude 不能创建图像，输入支持文本、图片和文件，输出只有文本。

一个连静态图都吐不出来的模型，不可能”生成视频”。它输出的是 token，不是像素。

判断一个模型是不是视频生成模型，最省事的标准就一条——看输出。

这个区分搞清楚了，你在选工具时才不会买错东西。

3. 技术底座：为什么是代码渲染

3.1 Remotion 是什么

四个开源项目无一例外都选了 Remotion 作为渲染引擎。它的核心思路很朴素：

用 React 写视频。每一帧就是一个 React 组件的渲染结果。

关键 API 只有几个：

import { useCurrentFrame, useVideoConfig, interpolate, spring } from "remotion";

const frame = useCurrentFrame();        // 当前帧号
const { fps, durationInFrames } = useVideoConfig();
const scale = spring({ frame, fps });   // 弹性动画
const opacity = interpolate(frame, [0, 30], [0, 1]);  // 线性插值

这个模型带来三个决定性优势：

① 动画是帧号的纯函数

// 同一帧永远渲出同一画面
const opacity = interpolate(frame, [0, 30], [0, 1]);

这意味着可复现。渲染两次结果一致，可以 diff，可以回归测试。

② 一切皆可编程

想要一个”数据驱动的柱状图随旁白逐根升起”？那就是一个接收 data 和 frame 的组件，没有任何限制。

③ 时间轴可计算

视频时长不是猜的，是由音频时长精确反推的。这是后面”音画同步”能成立的基础。

3.2 为什么不用别的方案

代码生成视频不是只有 Remotion 一条路。这里做个诚实的对比：

vibe-video 的工程文档里明确记录了这个选型过程，结论是：Remotion 唯一引擎，不与 HyperFrames 共用双引擎。而且留了再评估的触发器——“HyperFrames 发 1.0 并承诺 API 稳定”或”Remotion 5.0 许可条款收紧”。

来源说明：上表中 Remotion 与 HyperFrames 两行的结论来自 vibe-video 仓库的选型文档；
Manim、Motion Canvas、Lottie、After Effects 四行是我自己的分析，用于补全对比视野，
并非该仓库的结论。请按需自行验证。

这个”留触发器”的做法本身值得学：技术选型不是一锤定音，要写清楚”什么条件下我会重新考虑”。

顺带一提，这个项目的演进路径是：单文件 Canvas 制作包 → Remotion 工程模式 → 九阶段门禁化 → 十阶段双锚点独立技能。它也是一路迭代过来的，不是一次设计到位。

4. 十阶段流水线

这是全文的核心。把它拆开看，你会发现每个阶段都对应一类具体的失败模式。

4.1 为什么分两层

vibe-video 把流水线拆成内容层和生产层，这个分层的价值在于：

• 内容层产出的是写作产物（文稿、分镜），由人和 LLM 撰写，可以用”评审”来把关
• 生产层产出的是工具产物（音频、视频），由脚本生成，可以用”门禁”来把关

混在一起的后果是：你不知道一个失败该”改内容”还是”改工具”。

4.2 内容层（①–⑥）

这些阶段名和通过门，逐字来自 vibe-video 仓库的 references/stages.toml——它是”有哪些阶段”的唯一声明源。

阶段 ① 为什么最重要

科普视频翻车，基本都翻在信源上。

vibe-video 把信源分成三类，纪律完全不同：

B 型信源有个很聪明的发明：证据三级。

三级证据往往是信息量最大的部分，也最容易说错。规则是：三级断言前 3 句内必须出现归属语，而且可以机械检查。

还有一个”数字纪律”值得抄：

• 口径必须可复算——引用行数前自己量一遍，wc -l 和”非空非注释”是两个不同口径，必须说明用哪个
• 复算不出就不用——改说趋势（”从一百多行长到两百多行”），画面给实测值 + 口径 + 取数日期
• 活数据不进口播——star 数、榜单排名，说死必陈旧

阶段 ② 的”钩子候选矩阵”

前 3 秒决定完播率。vibe-video 的做法是在策划阶段就产出多个候选钩子，形成矩阵，而不是写稿时临时想。

阶段 ③ 的”单一事实源”

narration.md 是全片唯一的维护处，narration.json 是派生物（由脚本生成），永远不要手改派生物。

格式契约长这样：

## P0 开场

- [p0-01] 这是一支画面、配音、字幕全部由代码生成的视频。
- [p0-02] vibe-video 流水线把它自动做了出来。

## P1 收束

- [p1-01] 顶部进度条，就是章节在走的证明。

两个设计细节：

1. 句 id 必须以幕名小写为前缀（p0-01），全片唯一
2. > 引用块是画面备注，不进配音；英文方法名做角标也不口播

幕标题还会自动派生成顶部分段章节进度条的标签数据——一处维护，两处使用。

阶段 ④⑤ 的分工

这两个阶段容易混，它们的区别是：

• **④ 判”对不对、懂不懂”**（真实性 + 易懂性）
• ⑤ 只改表达，不改事实（结构 → 衔接 → 句子 → 词句 四层 pass）

⑤ 有一个硬约束：事实与句 id 集合冻结。改完的句子要回 ④ 复核。

阶段 ⑥ 最反直觉的一条

分镜表只写”这一镜覆盖哪几句旁白”，绝不写帧号。

| 镜号 | 句区间 | 画面 | 动效 |
| --- | --- | --- | --- |
| 0-A | p0-01..p0-02 | accent 视觉锚冲击入场 + 错峰词卡 | FadeUp |
| 1-A | p1-01 | 章节进度条放大解剖图（与顶部条逐帧同步） | FadeUp |

帧号、镜头关键帧、音效钉帧，全部由脚本从 TTS 词级时间戳推导。

这个设计的收益极大：改台词不用重新对帧。notebook-video 把它作为”授权契约”的第 2 条：

分镜表只写语义：cues 里绝不写帧号，帧号由 resolve-shots.py 推。

4.3 生产层（⑦–⑩）

⑦ 的”双档配音”设计

这是我认为很值得抄的一个设计：

关键纪律：克隆实跑必须本人显式点名（--final-voice），agent 不得主动提议。

为什么？因为声音是生物特征，成本也高。让 agent 自己决定”要不要克隆你的声音”，这个授权边界设得很对。

音画同步的机制（零手工对轨）

这是整条流水线最精妙的部分：

每句一段 MP3
     ↓ tts.py
manifest.json（含每句实测时长）
     ↓ Remotion calculateMetadata
全片时间轴

改稿后只需重跑：build → tts → render。

还有一个”单一事实源”的细节：时序常数（句间/幕间/片头/片尾）统一放在 video/src/timing.json，TypeScript 侧通过 resolveJsonModule 同步 import，Python 侧直读同一文件。改节奏只动 JSON，双语言镜像漂移结构性不存在。

4.4 四条核心设计原则

把上面所有细节收敛一下，我认为这四条是这套流水线的灵魂：

5. 四个真难点，以及各自的解法

“能跑起来”不难。难的是跑出来不像 PPT。下面四个问题，所有人都会撞上。

5.1 难点一：做出来像 PPT

症状：每一页都是”标题 + 几个要点”，四个场景长得一模一样。

解法：把”不像 PPT”变成可执行的结构约束，而不是靠审美。

notebook-video 的做法是最彻底的，直接抄：

① 四种场景骨架

硬性规则：相邻场景不得同款，全片 ≥3 种。

② 介质路由

允许的介质只有 6 个值：

chart | console | code | graphic | text | metric

每支片 ≥3 种介质，每个讲解场景至少有一个会随旁白变状态的组件。

③ 受限镜头语言

每镜必须有 camera.intent（6 种意图 + still = 7 个合法取值）和 anchor。而且：

声明了运镜就必须真的动：max(s) − min(s) ≥ 0.02 或 |Δx| + |Δy| ≥ 20。
把 still 改名成 push-in 不算运镜。

这几条一上，”四页 PPT”在结构上就不可能出现了。

④ 活性组件不能造假

分镜里声明的 live 组件，必须是场景文件里真实 import 并渲染过的组件名——写假名字等于没写，门禁会查。

5.2 难点二：字幕对不齐、音画脱节

症状：字幕比语音快半拍，或者句子中间断在奇怪的地方。

根因：凭感觉给每句设固定时长。

解法：词级时间戳驱动全片时间轴。

旁白文本
   ↓ TTS 合成
mp3 + 词级时间戳 JSON（每个字的起止毫秒）
   ↓ 语义断句
字幕 cue（拼接后必须等于旁白原文）
   ↓ 反推
帧号、动画触发点、镜头切换点

配套三个细节：

1. 句末标点严格消除——否则字幕 cue 的终点会拖出静默期，外挂字幕留残字
2. 多音字规避——中文 TTS 的老问题，写稿时就要处理（vibe-video 甚至有专门的发音标注语法 <原文|读音>）
3. 保护短语不被切断——比如”人工智能”不能被断成”人工”+”智能”

第三条在 notebook-video 里由 validate-semantic-breaks 执法，而且它用了一个中文断行的专门库 BudouX——缺 BudouX 是硬失败，不是静默跳过。

5.3 难点三：文字互相压、元素被裁

症状：卡片文字溢出、两个标签叠在一起、圆被 SVG 视口切掉半边。

这类问题肉眼逐帧看根本抓不完。 而且它会以最隐蔽的方式漏过去——notebook-video 的文档里记录了一个真实案例：

接触表第 ⑥ 页「按 Flash 结算」被画布右缘裁成「按 Flash 结」。
就这么漏过去了。

解法：做成渲染期门禁，自动拒绝。

关键设计：P0 不为 0 就拒绝渲染。不是等你逐帧看图才发现，而是构建期门禁 + 渲染期硬拦门禁直接拦下。

一个诚实的补充：渲染期门禁并非全部硬拦。CaptionFitGate、CardFitGate、OverlapGate、ClippingGate 在正式片子里是 block（拒绝渲染），但 FillGate、SlotGuard 是 warn（观感线，只出声不拦），CanvasBoundsGate 在片子里也是 warn、只在接触表上 block。
这个”分档”是刻意的——“画错了”那几类硬拦，”不够好看”那几类先提醒。

而且门禁会告诉你**”哪一帧、哪两处、压了多少 px”**，这比报个错有用得多。

还有一条容易被忽略的纪律：

“没报警”和”没运行”必须能区分开。

所以 CardFitGate、OverlapGate、ClippingGate、FillGate 会每 5 秒打一行覆盖率（已测 N 个字…）。如果一行覆盖率都没看到，说明门禁根本没执行——这要当成失败处理，而不是通过。

有意的重叠（镜头交接、标题滑变、数值替换）必须显式标注 data-gate-allow 放行，不允许用白名单掩盖两个不同信息互相压字。

渲染期门禁的采样策略也值得学，而且它是分档的：

前者靠”事件帧”保证覆盖的同时控制开销（画面变化恰恰发生在这些时刻），后者因为要抓”文字被画布切掉”这种任意帧都可能发生的缺陷，所以不抽样。

这个分档本身说明了设计者的判断：不是一刀切地”抽样省性能”，而是想清楚每类缺陷会在什么时刻暴露。

5.4 难点四：成片有”AI 味”

症状：句子像说明书，画面像模板。

解法：这一层只能靠写作流程。vibe-video 的”四层改稿”是个好框架：

结构 → 衔接 → 句子 → 词句

只改表达不改事实，而且改动句要回 ④ 复核。

再加一个”钩子候选矩阵”专门优化前 3 秒。

6. 质量门禁：把主观标准变成可执行约束

这一节单独拎出来，因为这是整套方法论里最可复用的部分，而且它的思想可以迁移到任何工程领域。

6.1 构建期 vs 渲染期

notebook-video 把 14 道门禁按执行时机分成三类（构建期 6 / 渲染期 7 / 成片后验 1），这个划分有明确的原则：

能用算术在构建期证明的，就不留到渲染期。
只有需要真实字体/布局测量的，才放在浏览器内。

6.2 一个绝妙的例子：帧参数名门禁

这是我觉得最能说明”门禁思维”价值的例子。

notebook-video 里有两套组件，传帧号的 prop 名字不一样：

// fxkit 层
<Component frame={f} />

// media / kit / stagekit / skeletons / insert / shotkit 层
<Component f={f} />

传错不报错，只会整体错位——组件会静默回落到全局帧，入场动画直接失效。

这是”最高频的静默事故”。所以有了 validate-frame-props.py：

构建期检查 fxkit 传 frame、其他模块传 f，写错即 P0。

注意这个思路：它不是”写个规范文档提醒大家”，而是写个脚本让错误无法通过。

6.3 “门禁的存在本身也要被验证”

这是最狠的一层。

A gate that exists in name only is the most dangerous defect.
（只在名义上存在的门禁，是最危险的缺陷。）

所以 notebook-video 有一个 negative-gate-check.py：给六道构建期门禁喂”该拦的夹具”，验证它们真的会拦。

规模是 65 个夹具 / 112 条断言，而且每个阻塞型夹具都钉住了预期的错误信息子串——这样一来，某个夹具因为别的原因失败，就不能冒充成被正确拦截。

夹具清单里能看到很多真实的坑：

• 镜头 anchor 出界的分镜表
• 平移超出缩放预算
• 相邻场景共用骨架
• 没有活性组件的镜头
• 时间轴有缺口
• 伪造的 live / 介质名
• 声明了运镜但从未移动
• fxkit 层和 components 层的帧参数名 typo
• beat 提前剧透它那一句
• beat 指向了另一镜的 cue
• beat 合法但紧贴容差边界
• 字幕读得太快
• 字号低于地板
• 正文颜色和纸色一样
• 文字颜色对比度不到 4.5:1
• beat 索引越界（三种拼写都测）
• import 了已不存在的名字
• 文档点名了不存在的组件

最后一条特别值得说：**”文档点名了不存在的组件”也要被门禁抓**。因为文档漂移会误导下一个 agent。

6.4 对比度与字号是硬约束

notebook-video 的配色有个很聪明的约定：每个强调色都成对出现。

原始色：blue, orange, green, gold, red
墨色变体：blueInk, orangeInk, greenInk, goldInk, redInk

规则是：

填充和描边用原始色；文字（color:）永远用墨色变体。
因为原始色在纸色上只有 2–3:1，远低于正文所需的 4.5:1。

而且 validate-presentation.py 会双向执法：墨色变体必须达标，且任何被用作 color: 的调色板键都会被测量。

字幕的阅读预算是：≤9 加权字/秒，单行 ≤16 字，≤2 行。

来源要说清：字号地板（不低于 13px）和正文色对比度（≥4.5:1）来自 WCAG 2.2 SC 1.4.3；
而字幕的阅读预算（加权字/秒、单行字数、行数）来自 Netflix 的中文字幕规范，不是 WCAG。
两套标准服务于不同目的，别混为一谈。

这些都是有出处的行业标准，不是拍脑袋的数字。

7. 五个开源项目横评

这是全文最实用的部分。这些项目做的是同一件事，但侧重完全不同。

7.1 ThreeFish-AI/vibe-video — 流程最完整

定位：十阶段门禁流水线，重内容质量。

技术栈：Remotion + Python + edge-tts / IndexTTS-2.5

亮点：

• 十阶段双层流水线，每个阶段都有明确的通过门
• 双档配音：edge-tts 草声 → IndexTTS-2.5 本人声音克隆
• 抽帧 QA：按幕/句/末 N 句及过渡窗口抽帧，自动体检黑帧与安全区
• 双语版本：中英逐字稿句 id 1:1 对齐，--lang 一参切换
• archify 动效图例：架构图逐章录制为视频动效，按句级锚定率执法”图与口播互证”

双语实现值得单独说：不是翻译两遍，而是英文逐字稿与主稿句 id 一一对应，分镜和场景全复用，时间轴随英文配音自动重排。这是把”多语言”当成工程问题而不是内容问题来解决。

一个细节：它要求 macOS 渲染主机，因为场景字体走系统 CJK 字体栈（PingFang SC / Songti SC / SF Mono），未内嵌字体文件。

适合：想做系列、对文案质量要求高、愿意投入搭流程的人。

7.2 znyupup/knowledge-explainer-skill — 上手最快

定位：最轻量，markdown → mp4，一行命令。

技术栈：Remotion（自动装好）

git clone https://github.com/znyupup/knowledge-explainer-skill
cd knowledge-explainer-skill
npm install
node cli.js examples/script.md out/example.mp4

内置 6 种版式：

真正的能力在 custom/——让 agent 写任意 React/SVG/物理仿真组件，文件名跟文稿段名一致即可识别。

它的 showcase 很能说明这套方法的上限：

文稿长这样（节选，为节省篇幅省去了 ContentCard 段与部分字段）：

---
title: 三角形面积怎么算
fps: 30
width: 1280
height: 720
---

## Title
title: 三角形面积怎么算?
subtitle: 5 分钟讲明白
duration: 4

## Triangle
title: 套公式算一下
base: 10
height: 6
unit: cm
formula: 底 × 高 ÷ 2
result: 30
resultUnit: cm²
duration: 9

注意：这里 duration 是手填的——它是轻量方案的代价。要精确同步，就得用前面说的词级时间戳方案。

适合：想快速跑通第一支片、建立手感。

7.3 chenwr727/TextToTalk — 最产品化

定位：有完整 Web UI + Electron 桌面版，不写代码也能用。

技术栈：React 19 + Remotion 4 + Fastify 5 + Electron

四步流程：

粘贴文案/链接 → AI 出大纲（可编辑）→ 逐页分镜预览 → 渲染成片

几个聪明的设计：

• 大纲先行，不是黑盒直出——在花时间渲染之前就把方向定对
• 逐页重做，不是整片重抽——第 5 页不满意就单独重做
• 零素材依赖——背景音乐是纯 Node 数学生成的 WAV，地图是结构化 SVG，不调用任何在线地图服务
• 预览即成片——分镜缩略图直接复用服务端真实的 Remotion 场景组件渲染

画面能力：16 个场景组件 + 26 条分发规则，自动匹配版式。

部署方式：Docker 一键起，或下载桌面版解压即用（内置 ffmpeg，无需 Node、无需 Docker）。

已知限制（作者自己列了，很诚实）：仅支持 1920×1080 横屏；任务状态存内存、重启丢失；渲染是逐帧 CPU 密集任务。

适合：不想碰代码，当软件用。

7.4 hyt315/notebook-video — 质量兜底最完整

定位：2K 手账风，14 道质量门禁，专治”像 PPT”。

技术栈：Remotion + TypeScript + Python

核心特色：

• 四种场景骨架 + 内容→介质路由表
• 十四道门禁，区分构建期/渲染期/成片后验
• 帧精确中文 TTS 同步（毫秒级词时间戳 → 语义断句 → 动画节拍）
• 四套锁定皮肤：paper（暖白手账，默认）/ cel（动漫赛璐璐）/ sticker（贴纸）/ flat（扁平几何）
• 三种锁定画布：2560×1440（16:9）、1920×1440（4:3）、1440×1920（3:4），原生 30fps

两条我特别欣赏的设计：

① 拒绝”信箱化缩放冒充适配”

4:3 / 3:4 需要各自的版面重排，不再用信箱化缩放冒充适配。

② 背景可读性契约

锁定背景位图保持原样不改；压在装饰上的内容坐在半透明羽化底托上（面板 88%、底托中心 76%）。
不靠”纯白挡板”换可读性，画面才不会变成白底 PPT。

零 Token 本地运行：渲染与门禁全部在本机完成，不需要任何在线 API 额度。配音走你自己的 TTS 端点。

关于可复现性的诚实说明（这段值得学）：

still / PNG 逐字节可复现（同一帧渲两次哈希一致）；
长片段 mp4 不保证逐字节——x264 在长片段上的多线程/前瞻决策会让连渲两次的 md5 不同，
实测像素差只落在边缘少数点（最大 76、平均 0.12、95.2% 字节相同），属编码层噪声而非内容差异。

把边界说清楚，比声称”完全可复现”更可信。

适合：已经能出片，但片子”像 PPT”，要系统解决质量问题。

7.5 怎么选：一张决策表

这五个不是五选一，而是你不同阶段该看的东西。

即使你最后不用它们，它们的设计文档本身就是最好的教材——尤其是门禁设计和授权契约那两部分。

7.6 Claude 教程与技能生态（重要）

既然这波潮流的起点是 Claude，那”有没有 Claude 教程”就是个真问题。答案是：有，而且比”教程”更值得关注的是它的技能生态。

① ~/.claude/skills/ 已经成了事实标准

这是最值得注意的一点。回头看前面四个项目的安装方式：

# vibe-video
ln -s ~/projects/vibe-video ~/.claude/skills/vibe-video

# notebook-video
git clone https://github.com/hyt315/notebook-video.git ~/.claude/skills/notebook-video

# anything2explainer
ln -s "$PWD/anything2explainer" ~/.claude/skills/anything2explainer

清一色的 ~/.claude/skills/。

这背后是 Agent Skills 规范——SKILL.md 那一套东西。它把”给 agent 的操作手册”标准化成了：

skill-name/
├── SKILL.md          # 路由壳：任务分流、工作流、关键不变量
├── references/       # 按需加载的规格文档
├── scripts/          # 工具脚本
└── assets/           # 模板与素材

**这个规范的价值在于”按需加载”**：SKILL.md 只放路由和速查，详细规格放在 references/ 里，agent 用到哪份读哪份。否则一个技能几万字的规格全塞进上下文，既贵又容易失焦。

notebook-video 的 SKILL.md 就把这点做得很彻底——它的参考文件读取时机写得很明确：

先读 locked-style-contract.json — 绑定令牌、坐标与禁用项（不可改）
照抄 scene-authoring.md — 场景代码的标准形状与八个坑；不要重新发明
何时读（切字幕 / 合成配音时）：subtitle-timing.md 与 tts-audio.md

**”先读 / 必读 / 照抄 / 何时读 / 仅当”**——这套标记法本身就是可复用的经验。

② 一个完整的 Claude 教程项目

如果你要一份”从零到出片”的 Claude 教程，anything2explainer（中文说明）是目前最完整的：

它的 9 个阶段：

建项目 → 调研(1 agent，带出处) → 解说词与时间轴 → 分镜 → 覆盖层与图元
→ 打样(先渲 30 秒) → 并行构建(每 agent 5-7 镜) → 渲染 → QC 与修复

几个设计得很好的地方：

1. 四个确认点——在”写文案之前””配音之前””跑 TTS 之前””整片渲染之前”停下来问。尤其是”前 30 秒样片”：在这里改一次是 1 个组的成本，整片渲完再改是全部组的成本。
2. 解说词定稿后不可改词——因为镜头代码里硬编码了帧号，改一个字全片重对位。它把这条明确写成了限制，而不是假装没有。
3. 事实有出处——画面上出现的每个数字、年份、机构、英文术语，都必须能在调研文档里找到来源 URL，没核实的不上画面也不进配音。
4. **明确说了”不适用”**——不复刻现有视频、不做真人口播、不做实拍为主的片子。

它的许可要注意：工具包是 PolyForm Noncommercial——非商业免费，商用需作者授权（用它做出来的视频归你自己）。这和前面四个（MIT / Apache-2.0）不一样。

③ 一个反过来的提醒

Claude 生态成熟，不代表你必须用 Claude。注意 anything2explainer 的徽章是并排的两个：

[Claude Code skill]  [Codex skill]

它同时支持 Claude Code 和 Codex，skill 本身就是 Markdown 加一个 Remotion 工程——任何能读 SKILL.md 式技能目录、能执行 shell 命令的 agent，理论上都能照着做。

这正好回到 §1.2 的结论：生态先成熟 ≠ 技术上不可替代。

8. 最小可跑通闭环

如果你不想一上来就装四个项目，可以先手搓一个最小闭环，理解原理。

8.1 环境准备

node -v            # 需要 18+，建议 22+
npm -v
ffmpeg -version    # 必需，Remotion 依赖

⚠️ ffmpeg 是最常见的卡点。
我在写这篇文章的环境里实测：node v24.21.0、npm 11.19.0、pnpm 11.7.0 都有，
但 ffmpeg 和 python3 都不存在。很多”跑不起来”就是这个原因，先装它。

8.2 建 Remotion 工程

# 官方现行写法
npx create-video@latest --yes --blank --no-tailwind my-video
cd my-video
npm install
npm run dev     # 打开 Remotion Studio，实时预览

注：npm create video@latest 是旧别名，通常仍可用，但官方文档现在用的是上面这条。

Remotion Studio 是一个可视化的预览器，你改代码它能实时刷新——这是它相比 Manim 这类方案体验最好的地方。

8.3 写一个”会动”的场景

关键 API 只有几个。下面这个组件包含了三个关键要素：纯函数、帧驱动、错峰入场。

import {
  AbsoluteFill,
  useCurrentFrame,
  useVideoConfig,
  interpolate,
  spring,
} from "remotion";

type Props = {
  title: string;
  points: string[];
};

export const Scene: React.FC<Props> = ({ title, points }) => {
  const frame = useCurrentFrame();
  const { fps } = useVideoConfig();

  // 标题弹性入场
  const titleScale = spring({
    frame,
    fps,
    config: { damping: 12 },
  });

  return (
    <AbsoluteFill
      style={{
        background: "#0E1116",
        justifyContent: "center",
        alignItems: "center",
        fontFamily: "PingFang SC, Noto Sans SC, sans-serif",
      }}
    >
      <h1
        style={{
          color: "#FFFFFF",
          fontSize: 96,
          fontWeight: 900,
          transform: `scale(${titleScale})`,
        }}
      >
        {title}
      </h1>

      {points.map((p, i) => {
        // 错峰入场：每个要点延迟 12 帧
        const delay = 20 + i * 12;
        const opacity = interpolate(frame, [delay, delay + 18], [0, 1], {
          extrapolateLeft: "clamp",
          extrapolateRight: "clamp",
        });
        const y = interpolate(frame, [delay, delay + 18], [40, 0], {
          extrapolateLeft: "clamp",
          extrapolateRight: "clamp",
        });

        return (
          <p
            key={i}
            style={{
              color: "#9FC4FF",
              fontSize: 44,
              opacity,
              transform: `translateY(${y}px)`,
            }}
          >
            {p}
          </p>
        );
      })}
    </AbsoluteFill>
  );
};

三个要点解释：

关于错峰还有个具体经验值：notebook-video 规定同句内错峰 ≤8 帧。
因为 18–30 帧的间隔会读成”一个个淡出来”，而不是”成串落下”。

8.4 把逐字稿变成时间轴

这是整个流程的枢纽。

第一步：生成配音和词级时间戳

pip install edge-tts mutagen

edge-tts \
  --voice zh-CN-XiaoxiaoNeural \
  --text "这是一句旁白" \
  --write-media out/p0-01.mp3

第二步：拿到真实时长，反推帧数

// 伪代码
const durationSec = await getAudioDuration("out/p0-01.mp3");
const durationInFrames = Math.round(durationSec * fps);

第三步：按累积帧号串联

<Sequence from={0}   durationInFrames={90}>
  <Scene title="开场" points={["画面、配音、字幕全部由代码生成"]} />
</Sequence>
<Sequence from={90}  durationInFrames={150}>
  <Scene title="展开" points={["流水线把它自动做了出来"]} />
</Sequence>

⚠️ 注意：这里的 90 和 150 应该是脚本从音频时长算出来的，不是你手填的。
手填就是后面所有对不齐问题的源头。

更完整的做法是让 Remotion 的 calculateMetadata 直接读 manifest：

export const calculateMetadata = async ({ props }) => {
  const manifest = await fetch("/audio/manifest.json").then((r) => r.json());
  return {
    durationInFrames: manifest.totalFrames,
  };
};

8.5 渲染

# 草渲：半分辨率，快很多
npx remotion render MyComp out/draft.mp4 --scale=0.5

# 终渲
npx remotion render MyComp out/final.mp4

⚠️ 重要提醒：npx remotion render 只出画面，不做响度归一和色彩元数据回写。
要交付到平台，得自己补 ffmpeg 那一步。

notebook-video 的文档把这条说得很清楚：npm run render 产出的文件过不了 validate-video 的色彩断言，
必须走它的交付链路（会做色彩元数据回写与响度归一，目标 −16 LUFS / −1.5 dBTP）。

渲染加速：渲染是逐帧 CPU 密集任务。用 --concurrency 控制并发，或参考各项目的性能文档。

9. 成本

这是很多人关心但很少有人讲清的部分。

结论

这类视频的边际成本几乎只有 LLM token。

渲染不花钱，素材不花钱（纯代码绘制），配音可以免费。这是它相比”文生视频”最大的优势——文生视频是按秒计费的。

代价是时间：渲染是逐帧 CPU 密集任务，成片越长等待越久。所以：

• 草渲用半分辨率（--scale=0.5）
• 门禁在构建期做完，别浪费渲染时间
• 用 review-frames 只重渲问题片段，而不是整片重渲

这个”用时间换钱”的取舍，正是它适合个人创作者和小团队的原因。

10. 许可与合规（别跳过）

这块很容易被忽略，但踩了很麻烦。我专门查证了各项许可。

10.1 组件许可

注意 Remotion 的”3 人”门槛。 很多团队会忽略这条，等到商业化后才发现要补许可。

10.2 声音样本是生物特征

vibe-video 的做法值得学：

声音样本是生物特征：样本目录整目录 gitignored，仓库只存指纹（refs.toml）。

而且克隆实跑必须本人显式点名（--final-voice），agent 不得主动提议。

10.3 素材版权

两家项目都给了明确的图片纪律，但归属不同，别搞混：

vibe-video 的图片纪律（references/01-source-extraction.md §五）：

严禁下载或嵌入站点/仓库的图片素材（版权 + 与代码动画美学不一致）。
站点图表与交互式演示只转文字规格（节点/流向/分区/帧文案）供 Remotion 重建。

notebook-video 的做法：需要”这确实是官方界面”这类论据时，用实拍素材框把真实截图装进锁定皮肤的墨线框，并按 visual-assets.json + asset-manifest.json 双清单登记（来源/授权/是否含文字/校验和）。

10.4 AIGC 标识

国内对 AI 生成内容有明确的标识要求，发布前确认平台规则。这不是可选项。

10.5 事实核查

科普视频翻车的成本极高。信源取证阶段（流水线 ①）不能省。

11. 避坑清单

把全文的坑收敛成一份清单，动手前对一遍：

环境类

1. 忘了装 ffmpeg——Remotion 依赖它，这是最常见的卡点
2. Node 版本太低——需要 18+，建议 22+
3. **pnpm 用了 --ignore-workspace**——会把工程自身的 pnpm-workspace.yaml 一起忽略，导致安装半残（此坑出自 vibe-video 的 PIPELINE.md §六.3）

流程类

4. 一上来就追求画面炫——先跑通”文稿 → 配音 → 出片”的闭环，再优化视觉
5. 用固定时长硬编码——这是音画脱节 100% 的原因。时间轴必须从音频反推
6. 分镜表写帧号——改一次台词你就得重排一次
7. 手改派生物（narration.json）——它是脚本生成的，改了会被覆盖

质量类

8. 靠肉眼看帧找问题——你抓不完的。把能自动化的都做成门禁
9. 门禁没输出就以为通过了——“没报警”和”没运行”是两回事，要求覆盖率日志
10. 用白名单掩盖真实问题——有意的重叠才允许放行
11. 忘了检查对比度和字号——WCAG 4.5:1 是硬线，别靠感觉

合规类

12. 忽略 Remotion 许可证——团队超过 3 人就要买
13. 声音克隆没拿授权——这是生物特征，法律风险高
14. 没做 AIGC 标识——平台有明确要求
15. 跳过信源取证——科普翻车成本最高的一环

12. 结语：这波热度真正教会我们的事

回到开头那个观察。现在我们可以说得更准确了：

这波的起点确实是 Claude，但决定成败的变量不是模型，而是流程。

这两句话不矛盾，反而互相印证：

所以「Vibe 知识大赏」这类视频的本质，不是模型能力的展示，而是一条工程流水线的产物。

谁把流水线搭好——信源取证、逐字稿、词级时间戳、代码动画、门禁兜底——谁就能稳定产出。谁还在”抽卡”，谁就还在碰运气。

而 Claude 真正值得学的地方，也不是模型，是它的技能生态：SKILL.md 那套”路由 + 按需加载”的规范，让一个几万字的复杂流程能被 agent 稳定执行。这个设计思路的价值，比”用哪个模型”大得多。

而且这套方法论的价值不限于做视频。它示范了三件可以迁移到任何工程领域的事：

建议的路径

1. 先跑通：用 knowledge-explainer-skill 做第一支片，建立手感
2. 嫌麻烦：换 TextToTalk 桌面版
3. 像 PPT：读 notebook-video 的门禁设计
4. 做系列：按 vibe-video 的十阶段重构流程
5. 用 Claude：看 anything2explainer 的 9 阶段教程，注意它是非商业许可

这五个项目不是五选一，它们是你不同阶段该看的东西。

最后一句：这类工具的价值不只是”帮你做视频”。它真正的启示是——

当一件事能被拆成带通过门的阶段，它就从”手艺”变成了”产能”。

参考

开源项目

• ThreeFish-AI/vibe-video — 十阶段门禁流水线（MIT）
• znyupup/knowledge-explainer-skill — markdown 一键出片（MIT）
• chenwr727/TextToTalk — Web UI + 桌面版（MIT）
• hyt315/notebook-video — 十四道质量门禁（Apache-2.0）
• Vincentwei1021/anything2explainer — Claude Code / Codex skill，9 阶段教程（PolyForm Noncommercial，商用需授权）
• xuanyuanzhifeng/ai-video-agent — 图片轮播 + HTML 动画
• DLeungDL/LearnTok

技术底座

• Remotion — React 渲染视频引擎
• Remotion 许可说明
• BudouX — 中文断行

现象与背景

• B 站成片：相对论到底有多反直觉
• B 站成片：原来北京时间不是北京的时间
• B 站成片：《耗散结构》
• 微博案例：用 Fable 5.5 制作三星堆 AI 科普解说视频
• 大佬说论坛：小白 AI 视频创作实操帖
• 抖音知识类视频破圈，AI 佳作持续产出（2026 创作者大会）

Claude 与这波潮流

• 阿里云开发者社区：Opus 5.5 生成视频的真相——它不生成视频，是写代码让浏览器逐帧画出来（本文 §2.1 的主要依据）
• HuggingFace：How to Make Videos with Claude Opus 5.5 — A Deterministic Render Pipeline
• awesome-opus-5.5-video — 1352 个作品汇总（含提示词）
• anything2explainer — Claude Code / Codex skill，9 阶段完整教程（中文说明）
• Agent Skills 规范 — SKILL.md 目录结构的标准
• Anthropic 帮助中心：Claude 能生成图像吗 — 官方说明：输出只有文本

本文基于对各开源项目仓库文档（README / SKILL.md / references）的逐份查阅写成，技术细节均可在对应仓库中核对。