四步做出 AI 解说视频：Grok 写稿、Kokoro 配音、ffmpeg 合成

一句话结论

做解说视频不需要扩散模型：Grok 4.6 写约 60 秒解说词、Kokoro af_heart 语音合成、ffmpeg Ken Burns 处理静帧——四步流水线在普通 32 核 x86 机器上就能产出可发布到 YouTube 的 720P 成片，整套零 GPU 成本。

我们要什么形态

NotebookLM 的视频概览是：一份脚本、一个声音、一组配图幻灯片——不是八秒的扩散短片。我们给 WisdomForge 需要的正是这个形态，而且要能合法发布。

现在有了一条品味锁定的路径。本文记录完整流程，包括那次失败。

交付什么：四步流水线

四步，没有一步在 DGX Spark 上：

写稿——Grok 4.6 写约 60 秒的 Ember 解说词：一个观点、短句、一对父母和一个 11–14 岁的孩子坐在桌边。

配音——Kokoro af_heart 音色、语速 0.85，跑在 32 核 CPU 上。调用就是 pipeline(text, voice=…)，这就是 TTS 的全部契约。

画面——ffmpeg 对静帧做 Ken Burns 效果，1280×720，带 WisdomForge 铜色水印、片头片尾卡。

成片——MP4 加 WAV。上 YouTube 前先在手机上听一遍 WAV。

已锁定的样片：《The Line That Goes Both Ways》（约 60 秒）。本文的流程演示视频用同一套技术栈讲解这套技术栈本身。

我们不交付什么

MiniMax H3 在 Spark 56bc 上能生成 2/5/8 秒的说话视频，但有两个问题：社区许可证仅限评估（不能上 YouTube）；一段 8 秒片段要约 24 分钟，而且不是课程形态。我们让 H3 待命，改在 x86 机器上做静帧。

本地 Qwen 在 Spark d369 上写了第一版脚本，随后容器不断被停（Exited (137)，非 OOMKill）。写手换到 Grok 4.6。Spark 不在这条流水线里。

配音踩坑：Kokoro 的正确调用

第一批 Kokoro 产物听着像苏格兰口音且含混不清。模型没问题，调用错了。generate_from_tokens 要的是音素（phonemes），我们喂了英文文本——Bella 和 Sarah 两个音色都产出垃圾。Piper 的 en_US-lessac 音色验证了静帧路径可行，英文清晰，但略带机器味。正确的 Kokoro 调用——KPipeline(“a”)(text, voice=“af_heart”, speed=0.85)——才是我们保留的声音。

不要「改进」那个调用。

代码仓库

流水线开源在 GitHub（smfworks/smf-notebooklm-video-pipeline，本地运行器在 feat/local-explainer-grok-kokoro 分支），依赖版本锁定在 LOCAL.md。

这是一个验证过的成片加一个运行器，不是产品。从写稿到配音到合成再到 Drive 的一条命令，仍是后续工作。

制作操作参考

想复刻这条 AI 解说视频流水线的读者按四步操作：第一步把解说词任务交给 Grok 4.6，提示词里限定一个观点、短句、约 60 秒时长，生成第一版后人工检查节奏再定稿。

第二步用 Kokoro 做语音合成，调用 KPipeline 传 voice 为 af_heart、speed 0.85，在普通 32 核 CPU 上运行即可；注意别用 generate_from_tokens 接口直接喂英文文本，那个接口要的是音素，喂文本只会得到含混音频。

第三步用 ffmpeg 对静帧图做 Ken Burns 缩放效果，输出 1280×720，加水印和片头片尾卡；第四步导出 MP4 与 WAV 双文件，发布前用手机听一遍 WAV 检查音质，再上传 YouTube。

工具选型依据记两条：MiniMax H3 的社区许可证禁止商用发布（不能上 YouTube），评估可以、正式交付不行；本地小模型写长稿容易中途崩（容器 Exited 137），写手环节固定用云端大模型更稳。

原文信息

• 作者：Michael Gannotti（@MichaelGannotti），AI 内容工程作者
• 原文标题：How We Make an Explainer: Grok, Kokoro, and Stills — Not a Spark 原文地址：
• 发布日期：2026-09-08