解决方案：logamee-auto-videoHERMES & AGENT ENGINEERING · 课时 04

思路大于具体实现。

4.1 先理清楚流程

logamee-auto-video 是我从日常工作中提炼的 Skill，主要功能是从一份基本想法，半自动地输出一份成品视频。当然，Skill 不是一次就能写好的，直到现在我还偶尔会迭代这个 Skill。下面给出Skill 的成品效果：

它的核心思路，不是让 Hermes 一口气把文章变成视频。我的一个观点是：

创造类的任务，没有能全自动化的。

这不是代码，代码是可以有确定性结果的。但是创造类的任务，没有硬性的标准。这涉及到一个审美的问题。这里要审查的不只是“美”，还有“逻辑”。样式外观是否符合你的要求？逻辑是否正确？这些都需要人工确认。

而且人工确认的越早越好。

如果一口气生成，问题很快就会出现：整个流程可能需要十步，消耗大量的 Token。而在这个过程中毫无人工审计。到最后 AI 给你丢了一个你自己都看不下去的 MP4，但你也没办法了，Token 已经消耗了。

所以这套流程把“生成视频”拆成几层。每一层只做一件事，并且留下一个明确的产物。下一层不依靠 Hermes 的记忆，而是读取上一层的产物（文件）。这一点很重要，很多 Skill 失败的原因都在于过分依靠 AI 的记忆，而不是依赖可靠的文件。这在短流程里没有问题，但是一旦链路变长，问题就会出现。

要完成整套视频制作，本机需要先准备一些第三方工具和相关 Skill。比如：

GSAP：组织 HTML 页面里的动画时间线
TTS：生成口播音频
ffmpeg：合成音频、字幕和视频
Playwright：控制浏览器播放和录制画面
Whisper 或字幕时间轴工具：生成或校准字幕时间
logamee-html-constraint：检查 HTML 画面和字幕约束（教材提供）
frontend-design：辅助检查画面设计质量

这些工具在后面的具体环节里还会再出现，到时候再说明它们各自负责什么。这里先交代一下：logamee-auto-video 这个 Skill 本身是纯文本的，它不会把 GSAP、ffmpeg、Playwright、TTS 引擎这些东西内置进去。

这不是缺点，反而是更合理的做法。不同用户的电脑环境不一样，有的人用 Homebrew，有的人用 nvm，有的人已经有自己的 TTS 或声音克隆工具。如果 Skill 把所有依赖都塞进去，最后会变成一个很重的软件项目，也很难维护。更好的方式是：Skill 负责讲清楚需要什么、怎么检测、缺了以后应该让 Agent 安装什么；具体安装动作交给使用者自己的 agent 去完成。

正式进入第一步之前，logamee-auto-video 会先做一次环境自检。自检不算正文创作流程的一步，它只负责确认本机有没有准备好后面要用到的工具和 Skill。缺少哪个工具，就先让使用者自己的 agent 安装哪个工具；安装完成后再重新检测。环境没有确认之前，不应该继续往后生成。

可以先把它理解成这样：

环境自检
  ↓
保存原稿
  ↓
理解原文
  ↓
提取主题
  ↓
设计分镜
  ↓
冻结分镜
  ↓
生成 HTML 画面
  ↓
本地字幕和画面预览
  ↓
生成音频
  ↓
校准字幕和时间
  ↓
完整预览
  ↓
录制并合成

下面我们就按这个顺序，逐一说明每个环节的任务、产物和需要确认的地方。每一步都会先给出一个结构化的小提纲，再进入具体解释。这样读者不用一开始就记住所有文件名，只要先理解每一层为什么存在。

4.2 正式流程前：自检环境，确认本机能不能完成视频制作

目标：确认本机具备后续生成、预览、配音、录制和合成视频的能力
输入：当前工作目录 + 用户选择的 TTS / 主题 Skill / 录制方式
输出：environment-check.md
使用技术：命令行探测、本地依赖检测、Skill 检测
人工确认：需要，尤其是缺依赖时是否允许 agent 安装

这一环节放在 Step 1 前面，是因为它不处理内容，只处理环境。真正开始制作视频之前，Hermes 要先检查本机是否具备必要条件。

检查结果会写进 environment-check.md。这个文件要记录几类信息：logamee-html-constraint 和 frontend-design 这些 Skill 是否存在；Node.js、ffmpeg、Playwright、TTS 工具是否可用；gsap.min.js 这类本地浏览器资源是否已经准备好；录制和字幕合成能力是否通过检测。

如果某个工具不存在，流程不应该继续往下走。正确的做法，是让 Hermes 明确告诉用户：缺少哪个工具、它会影响哪一步、建议让 agent 怎么安装，以及安装后应该用什么命令重新检测。比如缺少 GSAP，就要先让 agent 把 GSAP 安装到本地依赖里，并确认 deck.html 后面可以加载本地的 gsap.min.js，而不是临时从 CDN 引用。

这一点很重要。我们要交付的是一个可复用的 Skill，不是一个只在我电脑上能跑通的临时脚本。所以依赖不应该藏在作者的本机环境里，也不应该靠会话记忆说明。它们必须先被检测出来，再写进文件里。

4.3 Step 1：保存原稿，确定唯一内容来源

目标：把用户提供的材料保存成后续流程唯一认可的原文
输入：文章链接 / 粘贴文本 / 文件路径
输出：article.md
使用技术：文件读取、网页抓取或文本保存
人工确认：通常不需要，除非原稿不完整

第一步不是创作，而是先确定“原文到底是哪一份”。用户给的材料可能是一篇文章，也可能是一段粘贴进来的文字，或者是一个文件路径。Hermes 要先把它保存成 article.md。

这个文件后面不要再改动。因为它是所有内容的源头。后面如果发现视频表达出来的意思和预期不一致，就可以回到这里核对：问题到底来自原文，还是来自中间某一步的理解和改写。

4.4 Step 2：理解原文，先写出创作判断

目标：把 Hermes 对原文的判断写出来，作为后续创作依据
输入：article.md
输出：content-understanding.md
使用技术：大模型内容分析
人工确认：需要

有了原稿之后，Hermes 不能马上做 PPT。它要先读文章，然后把自己对文章的判断写成 content-understanding.md。

这份文件不是摘要，也不是把文章压缩成几条要点。它要回答的是更基础的问题：这篇内容讲给谁，核心论点是什么，读者原来可能误解什么，最后应该理解什么。只有先把这些判断写清楚，后面才知道每一页应该讲什么、哪些内容适合放到画面里、哪些内容应该留在口播里。

content-understanding.md 的作用，是把 Hermes 对原稿的理解先固定下来。后面写分镜、设计画面、安排口播，都要从这份理解出发。也就是说，它不是给用户看的摘要，而是后面所有创作判断的依据。

所以这一步必须人工确认。对于这份文档，文采不重要，而应该关注一些基础问题：

Hermes 有没有判断错读者？有没有抓错核心论点？有没有把原稿里的重点讲成另一个方向？这些问题如果留到 deck.html 才发现，返工成本就会高很多。

这段的人工确认非常重要。这里提供一个我和 Hermes 讨论的例子，你可以感受一下应该怎么去纠正：

> **我：** 我一直很看重原文里杨立昆的那一段引入，这样会有一个更真实的案例。但是我看到你没有提到。我不知道这个观点是不是应该包含在 understanding 里。
>
> **AI：** 应该放进 content-understanding.md，但它不应该被当成主线。杨立昆那一段的作用不是介绍"世界模型"，而是证明"回到基础"这件事真的有用。它在 understanding 里的处理方式是：主线仍然是"焦虑来自失序，解决方式是回到基础，建立主干"，杨立昆那段是真实证据——当你有了底层知识结构，就能听懂真正有深度的人在讲什么，也能判断自己是否赞同。建议补到两个位置：一是 Deep Structure 里作为"回到基础"的关键证据；二是 Visual Opportunities 或 Risks 里，提醒后续分镜可以做成真实场景，但不要把画面重点变成名人或 AGI 争论。比如补一句：「杨立昆访谈这一段，是'回到基础'的真实证据。它说明作者不是抽象地劝读者打基础，而是用自己的经验说明：当底层知识结构建立起来以后，面对真正有深度的观点，读者才有能力听懂、判断，并保持在线。」

AI 的观点非常准确，我同意。

4.5 Step 3：提取主题，只借视觉气质

目标：从用户指定的主题 Skill 或模板里提取配色和气质，但不继承版式
输入：用户指定的主题 Skill / 模板风格
输出：theme-extraction.md
使用技术：主题 Skill 读取、视觉 token 提取
人工确认：建议确认

内容理解确认之后，才轮到视觉风格。这一步做的不是“套模板”，而是先把用户喜欢的风格拆出来，变成后面可以安全使用的视觉约束。

绝大多数自动化视频工具，风格都是内置的。用户最多在几个预设里选一个，比如商务、科技、简约、国潮。logamee-auto-video 不是这样设计的。它允许用户指定一个自己喜欢的 Skill，或者指定一套已经存在的模板风格（第三方模板），然后让 Hermes 从里面抽取视觉气质。

比如用户可以说：“我喜欢归藏那个 Skill 里的某个模板，想要类似的配色和气质。”这时 Hermes 不应该直接照搬那个模板，而是要先把可参考的视觉部分提取出来。

这里要注意，第三方主题不能接管整个 PPT 的舞台。主题 Skill 只应该提供配色和气质，比如背景色、文字色、强调色，整体是偏冷静还是偏纸感。它不能决定每一页怎么排，也不能把自己的模板塞进来。

所以 Hermes 会生成一份 theme-extraction.md。

这份文件的作用，就是把主题 Skill 里可以参考的视觉部分单独提出来。

为什么不直接用现成的第三方 Skill 生成一套成熟的 PPT 底稿（类似第 3 章中制作的 HTML-PPT）？

第三方主题确实能生成不错的 PPT 底稿，但这些第三方主题的排版是固定的，很呆板。固定版式意味着布局是静态的，每一页都是预先设计好的位置、大小、比例。我们要的不是这个。我们要让 AI 根据内容创造场景动画，需要的是一个自由的舞台，而不是固定的格子。用固定版式，等于扼杀了大模型的创造性。所以只取配色和气质，版式由 AI 根据内容自由发挥。

4.6 Step 4：设计分镜，把文章改造成一页一页的视频方案

目标：把文章转成页面级视频方案，写清每一页讲什么、怎么讲、怎么呈现
输入：article.md + content-understanding.md + theme-extraction.md
输出：storyboard.md
使用技术：大模型分镜生成、口播断句和朗读节奏检查
人工确认：必须确认

理解和主题都有了之后，才进入真正的分镜。这里的“分镜”，不是简单分页，也不是把文章切成几段。它是在决定一支视频的表达方案：先讲哪一页，后讲哪一页；每一页要让观众明白什么；这页适合用什么画面关系来表达；口播、字幕和动画分别承担什么作用。

这一层的产物是 storyboard.md。

storyboard.md 之所以要单独存在，是因为它要把整支视频的创作方案放到一个文件里审查。用户不需要在一堆零散文件里跳来跳去，只要从第一页读到最后一页，就能判断这支视频的叙事顺序、画面方向和口播节奏是否合理。

每一页至少要写清楚如下要点：

• 这一页要让观众明白什么
• 画面怎么组织
• 屏幕上出现哪些字
• 口播说什么
• 字幕显示什么
• 动画大概怎么展开

所以这一层是创作母版。后面如果要改“这一页到底想讲什么”，或者要调整整支视频的顺序，最应该改的就是这里（实际上我改得最多的就是这个文档）。

这里还要多做一件事：检查 Narration 是否适合被 TTS 稳定地念出来。

很多时候，文字读起来没有问题，但一交给 TTS，就会出现另一类问题。比如一句话里塞了太多逗号，TTS 可能会一口气冲过去；英文术语连续出现，语速会忽快忽慢；一页里既有判断、例子、转折，又有一串技术名词，声音就容易失去节奏。

所以 storyboard.md 里的 Narration 不能只按“文字通顺”来审查，还要按“念出来是否自然”来审查。Hermes 在这一步要做一次口播适配：不改观点，不增加信息，只调整断句、标点、长句拆分和术语分组。比如把一个很长的复合句拆成两三句，把 Function Calling、MCP、Skill 这类术语从过长句子里拆出来，让它们有正常的停顿位置。

这一步看起来很细，但它会直接影响后面的音频质量。因为 TTS 不是一个真正的讲师，它会非常依赖标点和句子结构来判断停顿。如果前面的口播稿本身太挤，后面再怎么调字幕时间，也只能修表面问题。真正稳定的做法，是在 storyboard.md 阶段就把口播稿调整成适合朗读的形式。

4.7 Step 5：冻结分镜，拆成单页执行文件

目标：把确认后的 storyboard 拆成后续程序可以逐页读取的制作文件
输入：storyboard.md
输出：slide-specs/01.md、02.md、03.md...
使用技术：结构化拆分、字段校验
人工确认：不需要

等 storyboard.md 确认之后，Hermes 会把它拆成 slide-specs/。这一步不再重新创作内容，只是把已经确认的分镜切成单页任务。

这一步叫 freeze，也就是冻结。意思是：母版已经确认，接下来要进入制作阶段。

slide-specs/ 中的 md 文档不是给用户来回阅读的，而是给后面程序执行用的。每一个 md 文档对应未来生成的一个 HTML 页面，也就是视频里的其中一页。

这里有一个规则很重要：不要手工修改 slide-specs/01.md、slide-specs/02.md。如果要修改内容，回到 storyboard.md 改，然后重新 freeze（其实就是让 Agent 重新生成 slide-specs/）。

否则很容易出现两个版本：母版是一套，执行文件又是一套。到最后视频里到底用的是哪一版，就说不清楚了。

为什么不一开始就拆成很多小文件？因为人工审查会很困难。一个八页的视频，如果拆成八个文件，你的阅读阻力就很大，因为你要不停地跳文件。storyboard.md 放在一个文件里，用户可以从第一页读到最后一页，判断整支视频的叙事是否连贯。

4.8 Step 6：生成 HTML，把单页方案变成可看的画面

目标：根据 slide-specs 生成可以预览的 HTML 幻灯片
输入：slide-specs/ + theme-extraction.md
输出：visual-logic.md + deck.html
使用技术：HTML / CSS / JavaScript、GSAP、logamee-html-constraint、frontend-design
人工确认：需要

有了 slide-specs/，Hermes 还不能马上写 HTML。它要先写一份 visual-logic.md，把每一页的内容关系翻译成视觉关系。比如这一页到底是在讲因果、对比、层级、路径，还是误区纠正。只有先把这个关系讲清楚，后面的 HTML 才不会退回到“标题加几条文字”的老套路。

visual-logic.md 确认之后，Hermes 才开始生成 deck.html。这一步做的事情，是把每一页的文字方案变成真正能在浏览器里看到的画面。

这里的 HTML 不是普通网页，而是一组可以播放的幻灯片。每一页都有自己的画面结构，也有自己的动画。读者可以把它理解为“用 HTML 做出来的一份动态 PPT”。

这一层要解决三个问题。

第一个问题是画面要服务内容。讲因果，就做因果关系；讲对比，就做对比结构；讲层级，就做层级关系。不能把每一页都做成标题加三条项目符号文字（这种事最常见的 PPT 设计）。

第二个问题是设计质量不能太弱。前面的 theme-extraction.md 只提供颜色和气质，不能替 Hermes 完成具体画面设计。所以生成 HTML 时，可以参考 frontend-design 这类 Skill，帮助它处理字体层级、空间关系、视觉焦点和信息密度。这里要注意，frontend-design 只是设计质量层，不是新的主题来源，也不能接管内容和动画逻辑。

第三个问题是技术底线不能逾越。字号不能太小，字幕不能挡住主要画面，动画不能乱飞，颜色要来自前面提取出来的主题。这里会配合 logamee-html-constraint 做检查。

做完 deck.html 之后，需要人工确认视觉效果。因为画面这个东西，光读文字是不够的。这是人工审核的重点，我绝大多数时间都是花费在这一步上。

4.9 Step 7：先预览字幕和画面，用估算语速检查节奏

目标：在调用 TTS 前，用估算语速检查字幕、画面和翻页是否协调
输入：slide-specs/ 口播稿 + deck.html
输出：本地字幕和画面预览，通常是 deck.html?subtitlePreview=1
使用技术：浏览器、本地 HTTP 服务、字幕分段、语速估算
人工确认：必须确认

视觉确认之后，也不要马上调用 TTS。TTS 尤其是声音克隆 TTS，通常会消耗时间、算力或者 Token。如果字幕文案还没有确认，就反复生成音频，是很浪费的。

所以在真正配音之前，logamee-auto-video 会先做一次本地字幕和画面预览。这个预览不调用 TTS，也不需要真实音频。Hermes 会从每一页的 Narration 里切出字幕，再按照一个接近人类正常口播的语速估算每条字幕应该停留多久。然后它用这个估算时间去驱动字幕、翻页和页面动画。

这一遍预览要确认的不是音色，而是字幕和画面关系。比如某一句字幕出现时，画面是不是已经进入对应状态；某一页是不是停得太短；字幕分段是不是太碎；页面和页面之间是不是切得太紧。

这里的时间还不精确，因为它只是按语速估算出来的。但它已经足够用来发现大多数文字问题。只要用户在这一步改了口播或者字幕，就回到 storyboard.md 修改，再重新冻结和预览。等这一关通过，再进入 TTS。

如果在这一步发现字幕节奏不舒服，也不要只改字幕文件。默认情况下，字幕和口播都来自同一份 Narration。所以问题通常不是字幕层的问题，而是口播稿本身还不够适合朗读。正确的处理方式，是回到 storyboard.md 里调整 Narration，再重新生成后面的产物。这样后面的 TTS、字幕和预览才会继续使用同一份文本。

这里还有一个小细节：翻页之间要留一个很短的停顿。它不需要很长，通常零点几秒就够了。这个停顿的作用，是让上一页有一个收束，不要让整支视频像一段连续滚动的字幕。

4.10 Step 8：生成音频，记录每一页真实时长

目标：生成口播音频，并记录每一页真实时长
输入：通过预览确认的 slide-specs/ 口播稿
输出：audio/01.mp3 或 01.wav、audio/all.mp3 或 all.wav、audio/durations.json、audio/tts-metadata.md
使用技术：TTS、ffmpeg
人工确认：需要试听

字幕和画面预览确认之后，Hermes 才生成语音。每一页都有自己的口播，所以会先生成一组音频，再合并成完整音频。人工确认主要集中在音色、语速和停顿上，不需要像审查分镜那样逐句改内容。

如果用户有自己的声音克隆工具，就应该优先问清楚怎么调用。没有的话，再使用默认的免费 TTS 路径。无论使用哪一种，Hermes 都要把实际使用的 TTS 配置写进 audio/tts-metadata.md，包括声音、速度、采样参数、输出文件和重生成记录。

这一步之后，整支视频的时间才真正确定（理解这一点很重要）。前面做 HTML 和字幕预览时用的只是估算时间。TTS 生成之后，才知道第一页到底是 18 秒，还是 24 秒。

所以后面要反过来调整 deck.html。字幕什么时候出现，动画什么时候展开，什么时候翻到下一页，都要围着音频来排。

这一点非常重要。视频里的动画速度、字幕节奏和 PPT 切页速度，都应该以音频为准。音频说得快，动画就要跟着快一点；音频说得慢，翻页也要相应变慢。否则画面和声音就会分开，观众会明显感觉不舒服。

4.11 Step 9：精确校准字幕，检查声音和画面是否同步

目标：在浏览器里完整确认声音、字幕、画面、动画和翻页是否同步
输入：deck.html + audio/all.mp3 或 all.wav + slide-specs/ 口播稿
输出：subtitles.srt + 校准后的 deck.html?preview=1
使用技术：浏览器、本地 HTTP 服务、预览模式、Whisper 或字幕时间轴工具
人工确认：必须确认

声音、字幕、画面都准备好之后，不要急着录制。先要在浏览器里完整预览一次，确认这支多模态的混合体作为一个整体能正常播放。

Hermes 会打开一个预览模式，也就是 deck.html?preview=1。在这个模式里，浏览器会加载完整的 HTML、音频和字幕。字幕、动画和翻页都会随着音频播放的节奏推进，这也是这一环节最需要确认的地方。

这一遍预览和前面的本地字幕预览不一样。前面那一遍靠的是估算语速，是为了避免在文案没确认时反复调用 TTS。到了这里，音频已经生成，时间轴就要反过来以真实音频为准。Hermes 会读取每页音频时长，重新分配字幕停留时间；如果需要更精确，还可以用 Whisper 或其他字幕时间轴工具进一步校准。

这一步相当于录制前的完整检查。它检查的不是某一个文件，而是声音、字幕、画面、动画和翻页放在一起之后是否协调。

你可以把它理解成一个还没有录制下来的成片预览。只要这一步的播放效果是对的，后面的录制本质上就是把这个播放过程保存成 MP4。

如果字幕慢了、某一页停得太久、画面还没动完就翻页了，都会在这里暴露出来。这里确认通过之后，再录制就不容易返工。

4.12 Step 10：后台渲染并合成，导出最终视频

目标：把已经确认的浏览器播放过程在后台渲染出来，并合成为最终视频
输入：确认后的 deck.html + audio/ 分页音频 + durations.json + subtitles.srt
输出：output.mp4
使用技术：Playwright / Headless Chrome、ffmpeg
人工确认：建议快速核对成片

最后一步才是导出。前面所有步骤都确认过之后，Hermes 才把浏览器里已经能正常播放的内容保存成 output.mp4。

这里不应该像人工那样打开一个可见窗口，再占着桌面录屏。更好的方式，是让 Playwright 或 Headless Chrome 在后台打开 deck.html，按时间轴逐帧渲染画面，然后再用 ffmpeg 把画面、音频和字幕合成成一个 MP4。这样不会打断用户当前的工作，也更容易复现。

这一步对本机环境有要求。至少要有浏览器自动化能力和 ffmpeg。如果缺少这些工具，流程应该停下来，把缺什么搞清楚，让使用者的 agent 去安装或者寻找替代方案。

字幕可以有两种处理方式：一种是后期用 ffmpeg 烧进视频里，另一种是直接把 HTML 字幕渲染进画面。具体用哪一种，要看本机 ffmpeg 是否支持字幕烧录。如果环境不支持，也可以退回到 HTML 字幕的方案。到了这一步，真正的创作判断基本已经完成，剩下主要是选择合适的渲染和合成方式。

到这里，一篇文章才算真正走完了从原稿到视频的流程。

4.13 最终目录结构

执行完整套流程后，工作目录大概会变成这样：

workdir/
├── environment-check.md
├── article.md
├── content-understanding.md
├── theme-extraction.md
├── storyboard.md
├── slide-specs/
│   ├── cover.md
│   ├── 01.md
│   ├── 02.md
│   └── ...
├── visual-logic.md
├── deck.html
├── gsap.min.js
├── audio/
│   ├── 01.mp3 或 01.wav
│   ├── 02.mp3 或 02.wav
│   ├── ...
│   ├── all.mp3 或 all.wav
│   ├── final-mix.mp3 或 final-mix.wav
│   ├── durations.json
│   ├── tts-metadata.md
│   └── subtitle-alignment.md
├── subtitles.json
├── subtitles.srt
└── output.mp4

这个目录的作用，是把从原稿到成片的关键状态保存下来。后面哪一步出了问题，就回到对应的文件修改，而不是让 Hermes 凭记忆重来（必须要有证据来回溯）。

但不是所有过程文件都要留下来。比如后台渲染时产生的 render/、浏览器 profile、逐帧图片、临时静音文件、TTS 原始响应日志、Whisper 原始识别 JSON、concat 临时清单、试听样本，这些都属于执行缓存或调试材料。视频确认导出之后，它们就应该清掉。示例目录应该保留的是用户能看懂、能复查、能从中恢复流程的文件，而不是把一次执行留下的临时痕迹全塞进去。

4.14 这套流程的重点

看完整个流程后，会发现 logamee-auto-video 真正解决的不是“能不能生成视频”。

能生成视频这件事，Hermes 本来就能做。真正的问题是：生成出来的视频质量是不是足够高，出了问题能不能回头改，改完之后音频、字幕、画面是不是还能对上。

内容创作最大的问题就是它不可能一次成型，反复修改是常态。logamee-auto-video 的实质是一个项目驱动的 Skill。

所以这套流程才会保留这么多中间文件。它们不是形式主义，而是在帮我们把每一步的状态固定下来。

下一节，我们就拿一个真实案例完整走一遍。到那时，这些文件名就不会只是流程图上的名字，而会变成一个个实际出现的文件。

4.15 完整示例

我们用 logamee-auto-video 实际跑了一个完整示例。

4.16 ■ 学点英语