前段时间发布了几个技术演示视频，评论区里大家问得最多的，就是这个效果到底怎么做出来的。趁着假期，我把整个流程打包成了一个小工具，让更多人能够用较低的成本复现这种效果。

今天的内容信息量比较大，主要聊三件事：第一，视频的制作方法；第二，背后的工具设计思路；第三，从零开始手把手走一遍完整流程——从一篇文章，到生成一个精美的知识讲解视频。

一、视频到底是怎么做的

先澄清一下：之前的视频，既不是用视频生成模型做的，也没用 NotebookLM。说白了，就是网页。自己手动写出来的网页。

肯定会有人问：AI 视频生成模型都这么强大了，为什么还要折腾网页？答案很简单：可控性。字体、配色、每一步停留几秒、某一帧要不要出现一个精确数字——这些东西在网页里改几行代码就能搞定，比用模型反复抽卡稳定得多，成本也更低。NotebookLM 我也试过，它做不了动画演示，出来的都是静态图。像 Remotion 这类框架，反而限制了模型的发挥，不如直接手写来得干脆。

1.1 一个案例

拿上期视频来说，那期完全由 AI 生成，算是一次演示。输入很简单，就是 Anthropic 最新发布的一篇文章。输出是一个网页，把文章拆成了 13 个章节、100 多个细粒度的讲解步骤，每一步都有完整的视觉演示。画布固定在 16:9，适配任意尺寸的显示器。底部有一个隐藏的进度条，鼠标悬停才会出现，可以自由跳转到任意章节的任意步骤。画面干净，没有页眉、页码、品牌标识，录屏时观众看到的是一块纯净的画面，更像视频，而不是网页。

1.2 关键流程

要实现这种效果，有几个关键步骤：

• 把文章变成口播稿。 原始技术文章通常很书面化，像"该工具旨在提供高效的解决方案"这种话，没办法直接念。需要改成"这玩意儿是干嘛的呢？"这种短句、口语化、带点第二人称的表达，就像跟人聊天一样。
• 把口播稿拆成开发大纲。 每段话对应一个画面步骤，每几个步骤组成一个章节，每章聚焦一个话题。整个开发任务很复杂，大纲是保障后续开发稳定性的基础。
• 给每步做视觉演示。 不是把文字贴上去就完事了。TCP 三次握手要画时序图，DNS 查询要画节点链路，反垃圾审判要画评分仪表盘。得把抽象概念"演"出来。
• 让步骤和口播对齐。 网页的关键演示步骤必须跟着口播稿的节奏走，这样出来的视频效果才自然流畅。

1.3 为什么要做成工具

上面这些事，全部交给 Agent 一步步做，确实是可行的。模型不缺能力。问题在于：怎么保证每次都能稳定产出？怎么让不同的人、不同的文章、不同的主题都能得到同样靠谱的结果？怎么让开发效率不依赖运气？

直接跟 Agent 说"帮我做个视频网页"，它可能做得不错，也可能跑偏。比如，稿子和画面对不上、章节数和音频数不一致、后面章节的风格突然跟前面完全不搭……这些都是可能发生的问题。

模型有能力，但需要一套系统来驾驭这个过程——划定边界、管理状态、设立检查点、在关键节点拦住错误。这就是整个工具要负责的事情。所以，我才做了这个 Skill。

二、web-video-presentation Skill

Skill 是 Agent 通用的一种扩展能力标准，可以理解成一份"操作手册"——它告诉 AI 什么时候该做什么、做到什么标准、哪些红线不能碰。AI 加载 Skill 后按里面的规则干活，不用每次都重新讲述这些规矩。

这个做视频的 Skill 和其他开源 Skill 一起托管在 garden-skills 仓库里。一个成熟的工具系统，通常至少包含六个核心部分：

下面，就从这个角度来拆解一下这个 Skill 的核心设计。

2.1 执行与编排

执行与编排解决的是"模型下一步该做什么"的问题。整个 Skill 把"从文章到视频"切成了四个阶段，中间卡了两个人工检查点。

• 阶段一：内容编写。 AI 同时产出两样东西——口播稿和开发大纲。口播决定信息的描述方式和整体节奏，大纲决定每章做几步、每步屏幕上放什么信息。
• 检查点 Plan。 Agent 走到这里会被强制停下。人需要对齐五件事：稿子要不要改、大纲要不要改、用哪套主题、真实素材谁准备、后续章节是逐章做还是并行做。这五件事不拍板，后面的工作全建立在假设上。
• 阶段二：开发。 第一章必须经过人工验收，确认视觉气质和节奏都对了，它才成为后续章节的基准。之后的章节可以顺序做，也可以开多个子进程并行写。每章写完都要逐项对照清单自检，不过关不准说"做完了"。
• 检查点 Audio。 再停一次。决定要不要合成音频。要的话走阶段三，不要的话跳到阶段四用人声录。
• 阶段三：音频合成。 从每章的口播文本里提取合成清单，调 TTS 逐段生成音频文件。
• 阶段四：录屏。 浏览器全屏打开演示页，开自动播放模式，音频和画面天然对齐，录完裁头尾。

工作流程很清晰，重点在于怎么让 Agent 在每个环节里不跑偏。

2.2 上下文管理

上下文管理要回答的核心问题是：模型到底看到了什么？

这个 Skill 的链路跨了四个 Phase，涉及多个复杂流程。如果在启动时把所有文档一股脑灌进去，模型的注意力会被严重稀释。所以，我把所有信息拆成了多份文档，每份文档只在指定的阶段读取。例如，SCRIPT-STYLE.md 只在 Phase 1.2 读取，负责文章到口播稿的转换规则；CHAPTER-CRAFT.md 只在 Phase 2.4 读取，是单章开发的完整指南；而像 AUDIO.md 和 RECORDING.md 这样的文档，则分别只在音频合成和录屏阶段才被调用。这样，模型在每个阶段都只看到它需要的信息，效率自然更高。

2.3 状态与记忆

状态与记忆要回答的问题是：系统如何跨步骤保持连续性？

在这个 Skill 里，最重要的"记忆"就是 outline.md（开发大纲）。一个项目十几章、几十个步骤，Agent 写到第 8 章时，前面章节定过什么结构、用户在 Checkpoint 里改过什么方向，很可能已经不在当前上下文里了。大纲的作用，就是把这些关键决定固定下来，成为开发阶段的持续记忆。Agent 开发任何一章时，大纲就是任务边界。

在真正开发阶段，Skill 还会让 Agent 每轮强制关注 script.md（口播稿）和 article.md（原文章）。口播稿负责节奏，原文章负责信息密度。这三份文件各司其职：大纲管结构边界，口播稿管叙事节奏，原文章管信息密度。Agent 同时参考它们，就不容易出现"结构对了但画面空"或"信息很多但节奏乱"的问题。本质上，这是一种文件化的工作记忆，把关键状态写进文件，需要时再读回来。

2.4 工具系统

工具系统要回答的问题是：模型到底能做什么？这个 Skill 中没有特殊的工具，所以目标就是让模型把 Agent 本身的文件读写工具用好。

在章节开发中，支持并行开发。但并行有一个致命问题：多个 Agent 同时改同一个项目，会不会冲突？Skill 为此设计了严格的隔离机制：每章独立文件夹，物理分离；每章独立 CSS 前缀，不会出现两个章节抢同一个 class name；主题 token 兜底视觉统一，颜色、字体、间距走全局 CSS 变量，即使每个 subagent 独立开发，最终画面在色彩和排版上也不会跑偏。但风格不强求一致，每章的动画、节奏、视觉演示方式允许不一样。

2.5 约束与恢复

约束与恢复要回答的问题是：出错了怎么办，怎么避免跑偏？

在这个 Skill 里，"出错"最常见的形式不是代码报错，而是用户觉得不对。比如"这一章节奏太快了"、"这个动画太 AI 味了"。面对这类反馈，Agent 的本能反应是重做整章。但重做整章会把已经对的部分也改掉。所以，Skill 里有一条原则叫"反馈修复的最小切片"：先定位问题在哪一层（节奏、视觉、内容、代码），再改最小切片，不要重做整章。例如，是节奏问题，就只调整对应步骤的口播文本长度；是视觉问题，就只改对应步骤的 CSS。

2.6 评估与观测

评估与观测要回答的问题是：系统怎么知道自己做得对不对？

这一层是设计这个 Skill 时花心思最多的地方。让写代码的 Agent 自己评价"这章写得怎么样"，结果几乎一定是"还不错"。它不会告诉你"这一步的动画其实是无脑淡入"或"这个列表一次性全展示了，违反了逐步揭示原则"。

所以，我设计了一套硬性自检规则。每个关键产出完成后，必须走自检、修复、再汇报的流程。比如，口播稿的自检清单包括口语化、无AI味、信息保留率等；单章实现的自检清单包括有动图、不套模板、逐个揭示等。更关键的是执行方式：最优是用 Agent Teams 开一个独立的 Reviewer Agent，次优是用 SubAgent，兜底是当前 Agent 自己逐项核查。但即使是自检，也必须"严格逐项"，不允许目测一遍就放行。

2.7 回过头看

把这个 Skill 的设计摊开来，你会发现它和 OpenAI、Anthropic 做的事本质上没有区别——都是在搭建一个可控的系统。只不过他们搭的是工业级的运行系统，我们搭的是一个 Skill 级别的协作协议。

这里也要明确一个误区：做系统并不一定要从零搭建一个 Agent。能用一个小工具把一个垂直的开发工作做好，本身就是在构建系统。下面，我们进入实战环节，从零走通整个流程，并用这个 Skill 完成一个文章到视频的制作项目。

三、环境搭建

这条链路里主要会用四个工具。

3.1 Claude Code

首先，选择 Claude Code 作为核心执行 Agent。如果你本地用 Cursor、Codex 或其他支持 Skill 的 Agent 也是可以的。安装命令见下方，装好后通过 claude -v 命令可测试是否安装成功。

3.2 MiniMax

在国内正常使用 Claude Code 非常困难。目前推荐的做法是搭配一个国产模型。经过大量试用，我这边选择的是 MiniMax。它的 Token Plan 和 Claude Code 的适配非常好，订阅 Plus 极速版后，速度快、量大、性价比高，日常开发完全够用。订阅完成后会生成一个 API Key，需要提前存好。

3.3 CC Switch

CC Switch 是一个桌面配置工具，可以让你的 Agent 切换为任意自定义模型。在这里，主要用它来配置 MiniMax 的 Token Plan。到其 Github Release 页面下载对应系统的安装包，点击右上角"+"，选择预设的 MiniMax 供应商，填写 API Key，将模型名称全部改为 MiniMax-M2.7，保存启用即可。之后在终端输入 claude 就可以直接使用了。

3.4 MMX CLI

MiniMax 的 Token Plan 还有一个优势：附带多模态套餐（图片、语音、视频）。今天的教程中，一个关键环节是将口播稿合成音频，Token Plan 自带的每天 9000 字语音合成额度完全够用。MiniMax 官方还提供了一个 CLI，安装非常简单，只需将一条指令发给 Claude Code（注意替换密钥），安装完成后在本地执行 mmx 即可验证。

3.5 安装 Skill

下一步安装我们的 Skill。访问 garden-skills 仓库，找到 web-video-presentation 的下载地址，下载后解压。在你的工作目录下新建 .claude/skills 目录，将解压后的文件夹粘贴进去。然后在当前目录启动 Claude Code，如果输入 /web-video 能智能提示出这个 Skill，说明配置成功。

3.6 Agent Teams 和 tmux（可选）

这一步配置是可选的。如果只是做一个小 Demo，一个 Claude Code 会话就够了。但如果是 10 章、100 多步的视频项目，单 Agent 会非常慢。由于 Skill 在设计上对多个章节做了严格的物理隔离，天然支持了多 Agent 并行编写。

Claude Code 中支持两种多 Agent 工作的能力：SubAgent 和 Agent Teams。SubAgent 像子进程，各写各的，互不干扰，适合并行开发；Agent Teams 像小项目组，成员间可以互相讨论，适合需要来回反馈的任务，比如代码审查。Agent Teams 目前是实验性功能，需要在配置中开启。为了更好可视化整个过程，可以安装 tmux，配合使用后，每个组员会出现在不同的终端面板中，能同时看到各自的工作进展。

四、实战：完整流程演示

这里，我们以《一封邮件发出后的 600 毫秒》这篇文章为例，演示如何将其变成知识讲解视频。

4.1 启动 Claude Code

进入项目目录后，在终端先输入 tmux 进入会话，然后启动 Claude Code：claude --dangerously-skip-permissions。这个参数会跳过每次工具调用时的权限确认，避免并行开发时频繁打断流程。但它名字里带 dangerously 不是开玩笑的，只在你确定当前目录安全、项目内容可信的时候用。

4.2 先生成脚本和大纲

启动后，把原始文章丢给 Claude，告诉它使用 web-video-presentation Skill，并读取 @article.md 文件，要求其完成第一步，编写口播稿和开发大纲，并使用 Agent Teams 创建独立 Agent 进行质检。

它会创建一个独立的 Content Writer Agent 来编写这两个文件。文件编写完成后，再创建两个 Reviewer Agent 分别对两篇内容进行质检。质检完成后，主 Agent 会进行最终校对，输出定稿。口播稿会把原始文章改成更适合 B 站视频的表达，句子短、节奏快。而开发大纲则把脚本拆成章节和步骤，把控后续的开发节奏和信息密度。

4.3 第一次人工确认

上面的流程完成后，它会向你询问几个关键问题：

• 稿子和大纲还要不要改？ 如果觉得稿子AI味比较重，可以调整成你的讲话风格。另外要确认大纲有没有明显的节奏问题。
• 视觉主题选哪个？ Skill 内部定义了几套不同风格的主题，例如 paper-press（温暖印刷）、warm-keynote（现代演讲）、blueprint（技术蓝图）、chalk-garden（黑板风格）等，可以根据内容选择。
• 素材怎么准备？ 有三种模式：从现有素材路径挑选、用户自己提供、全部用占位图。
• 后续章节的开发模式？ 支持逐章确认、第一章后顺序开发、第一章后并行开发三种模式。

4.4 先把第一章做好

当所有信息确认完成后，进入开发阶段。Skill 会先只做第一章，让用户确认无问题后，再开发后续章节。因为从第一章的效果中，你已经可以看到页面的密度、字体大小、动效节奏等是否合理。第一章定下来之后，后面的章节才知道往哪个方向靠。确认无误后，可以回复指令让它继续。

第一阶段开发完成后，它会再次开启独立的 Review Agent 对章节内容进行质检。完成后，会提示你进行验收。第一章的验收非常重要，最好亲自在浏览器里从头点到尾，看看画面是不是舒服，节奏是不是顺畅。

4.5 并行开发后续章节

第一章定下来后，就可以让 Agent Teams 上场了。剩下的章节可以并行开发，建议最多同时跑 3 个。每个 Agent 会拿到自己负责的章节大纲、Skill 规范、主题变量，以及第一章的代码作为参考。它们各写各的，互不干扰。每章完成后，都会进入质检环节。

4.6 确认网页效果

所有章节开发完后，启动本地开发服务器，在浏览器里完整预览一遍。一定要手动把所有步骤都点完，检查有没有空白页、动画卡顿、步骤跳段、内容错位等问题。

4.7 合成音频

网页确认无误后，进入音频阶段。使用 MiniMax 的 CLI，将口播文本批量合成为音频文件。流程分两步：第一步，先抽取一份口播文本清单，人眼扫一遍确认无误；第二步，再逐条合成音频。合成完成后，每章会有子目录，每一步对应一个音频文件。

4.8 三种播放模式

到这里，视频项目已经可以播放了。这套 Skill 里有三种模式：

• 手动模式： 不加参数，用鼠标一步步点击推进，适合检查画面细节或自己录制音频。
• 音频模式： 网页加 ?audio=1 参数，在每步自动播放音频，手动推进。
• 自动模式： 网页加 ?auto=1 参数，按下空格后，页面会按音频节奏一路播放到底。配合屏幕录制软件，可直接出片。

4.9 最后归档

这套流程还有一个好处：所有资产都能跟着项目走。原始文章、口播稿、大纲、网页代码、音频文件，都可以放进版本控制里。以后换一个题材，只需换一篇原始文章，再沿着同一条流水线跑一遍即可。

最后

回到开头的问题：这些视频到底是怎么做出来的？

表面上看，这是一套"文章生成知识讲解视频"的流程。但本质上，它是一次对系统构建的实践。模型本身已经很强，真正的问题不是"模型会不会做"，而是"怎么把这些能力编排起来，让它稳定地做完"。

所以这个 Skill 做的事情，就是把一次复杂的内容生产任务，拆成有流程、有状态、有检查点、有自检、有恢复机制的工程系统。它不是让 Agent 自由发挥，而是给 Agent 搭了一条可重复执行的轨道。这也是整个系统最核心的价值：把模型能力、工具能力和人的判断，组织成一条稳定可控的生产流程。

这个 Skill 已经放到了 garden-skills 仓库里，感兴趣的同学可以拿一篇自己的文章试试看。