解密谷歌 NotebookLM 技术幕后【下】：如何用 AI 制作“带讲解的 PPT 演示视频”？-AI Express News

点击上方蓝字加入我们

接上篇（解密谷歌 NotebookLM 技术幕后【上】：知识如何被“转译”为 AI 对话式播客）：在上篇中，我们探索了 NotebookLM 如何将枯燥的文档转化为生动的"双人对谈"音频播客。今天，我们将挑战一个更复杂的任务：如何让 AI 将文本类的知识转化成"带讲解的 PPT 演示视频"？

从“听”到“看”：维度升级带来的复杂性

如果说生成音频播客是让 AI "开口说话"，那么生成解说视频就是让 AI "又画又说"，还要保持风格前后一致、“文字”-“画面”-“讲解”三者对齐。

很显然，这种应用模式下的视频无法像 Sora 那样天马行空的生成画面，它是生成一种"视觉辅助讲解"— 就像一位老师借助PPT演示为你讲课。每一页PPT都要与解说词匹配、画面的切换必须自然衔接、 PPT 的视觉风格要保持统一等。

图片[4]-解密谷歌 NotebookLM 技术幕后【下】：如何用 AI 制作“带讲解的 PPT 演示视频”？-AI Express News

这种"对齐"的要求，使得视频生成的工程复杂度直线上升。你无法简单地把文本扔给一个模型说"给我生成个讲解视频"，而是需要像电影制作一样，将整个流程拆解为多个"工序"，每个工序都需要精心的工程调优。稍微有一个环节跑偏，后面就会持续累积错误，最后呈现出的画面很可能和原文是两套世界。

核心架构：从知识源到视频的完整流程

我们要构建的，是一个“迷你版 NotebookLM 视频概览生成器”。输入是一个URL（比如技术博客，当然也可以是PDF文档、视频链接等），输出是一个带有讲解的“PPT演示视频”。

整个过程设计为六个关键步骤，每一步都承担特定职责，并将结果传给下一步：

这是一个典型的流程简单，但工程量较大的AI应用：由于多个步骤需要依赖LLM/VLM/文生图/TTS等模型，如果不加控制，模型之间的误差会不断传递、叠加，导致“虎头蛇尾”甚至“离题万里”。因此整个应用的可用性与稳定性，要靠大量的测试与反复试验来保证。

第一步：知识抽取 — 从多模态到单模态

要生成一个结构良好的视频，第一步是“把知识源变成人类和模型都能轻松处理的文本”，最好是 Markdown 格式。只有转成干净文本之后，后续的内容拆分、提炼、脚本生成、画面设计才有基础。

你需要根据知识源的类型从大量的开源或商业方案中作出选择：网页爬取、文档解析、OCR/VLM模型等结合。

这里我们输入的知识源是一个URL，那么可以选择：

第一种是网页爬取。如果输入的是普通网页，最简单的方式就是直接用开源工具或 API（例如 JINA 的 Reader API）来抽取内容。对于大多数技术博客、新闻报道、专栏文章，这种方式既快、成本又低，一次请求就能拿到结构清晰的 Markdown。

第二种是模拟浏览器访问+视觉模型。有的网站有严格的反爬机制、有的内容需要JS动态渲染、有的页面是纯图片。这时候需要借助Playwright做浏览器模拟访问，再配合OCR/VLM（视觉模型）等来理解源知识内容。

这里我们采用的方案是：

一个工程上的方法，是采用“双方案策略”：

优先尝试轻量级方案，如果提取失败或者内容质量不佳（需定义检查规则，比如文本太短、结构混乱、标题缺失等）；则自动切换到Playwright+VLM的组合方案。这样既保证大部分场景下的效率，也能确保复杂场景下的可靠性。

第二步：结构化编剧 — 让LLM当“导演”

当拿到一片5000字的长文后，下一件事就是思考：如何将他转化为一个可播放的PPT？这就像一位电影导演，面对大量的素材，你得决定哪些内容适合单独成页、哪些知识点需要配图、哪里该转场、章节如何分布，每一页画面又要呈现什么信息。

这些判断当然是交给 LLM 来做：

但为了让结果可控，需要先定义一个“PPT 页面”的数据模型，让 LLM 按固定格式输出。大致结构如下：

class Slide(BaseModel):
    index: int # 页码
    type: Literal["title", "content", "chapter", "summary"] # 页面类型
    key_points: List[str] # 3-5个核心关键词
    detailed_content: str # 本页详细的知识点说明（500字以内）
    image_prompt: str # 给AI绘图模型的提示词，下一节说明

LLM 根据这个结构生成整套视频的“剧本大纲”，最终会得到一组 JSON 的 slide 列表：

【关键要点】

detaild_content是“知识点的深入解读”，但不是最终讲解的逐字稿。为什么不在这里直接生成完整的口播词？因为目前还没有“画面”。所以会在有了画面以后，再结合画面重新生成一次“口播词”。
image_prompt是给下一步AI 绘图模型的提示词。通常包含内容指令（画什么）和布局指令（怎么画）等；此外，我们会在生成图片时再统一注入“风格指令"（比如“简笔画”风格）。

为什么在这里生成image_prompt呢？我们接着看下一步。

第三步：图片生成 — 最容易翻车的环节

根据上一节生成的 detailed_content 和 image_prompt，要为每一页生成对应的 PPT 演示图片。看上去简单，实际却是整个流程里最容易翻车的一步。

【出图方案】

这里有一个技术选择：是让模型直接"理解知识后画图"，还是"按照描述画图"？

第一种方式称之为"端到端生成"。这种方式下，直接把知识点扔给模型，比如"请画一张图解释这段文字中提出的自注意力机制"。模型需要真正理解文字后，然后自主决定用什么样的图形、箭头、标注来表达这个概念。

Google 的Nano Banana是这类模型的代表。其对概念理解和画面表达非常强，但对中文的支持仍不算理想：

第二种方式，是"基于提示词的绘制"。你给他一份详细的草图说明，他严格按照你的要求作画。这种方式下，在第二步中LLM 就已经为每一页设计好了具体的画面描述（如：“左右布局，左边列表文字....；右边用图标表示...”)。

这种方式的优势在于可控性和稳定性。我们实测 seedream、qwen-image 在这类任务里表现尚可，尤其对中文环境又好。

【中文渲染问题】

另一个棘手的问题是：中文文字渲染。AI 绘图模型在处理文字时都不够稳定，而处理中文时这个问题会被放大。测试发现，在生成纯文字的区域会比较稳定，而在带有文字的图案元素上则最容易“翻车”：

为了减轻这个问题，我们采取一个很实用的策略——减少文字。PPT 里本来也不需要太多文本，完全可以用图标、符号、配色来表达。

在实际中，我们还测试了一种“复合方案”：先让 Gemini 直接根据知识点生成英文配图（理解后自行设计）；再把这张英文图丢给 seedream 做图生图，将英文替换成中文。试图融合 Gemini 的抽象设计能力和 seedream 的中文渲染能力。但成本更高，一张图需要两次模型调用。这是一张生成的图片：

最终选择的方案是：Seedream+提示词绘制，提示词在第二步生成。

第四步：解说脚本生成 - 看图说话的艺术

在这一步我们借助多模态视觉模型（VLM），将图片与详细知识说明输入，让它”看着图片"写演讲词。注意，仅输入偏概念性的演示图片是不够的。

那么为什么不直接用 detailed_content 当解说词？为什么还要再生成一遍脚本？

原因在于它不考虑“画面在讲什么”。真正的讲解是“看着图说话”，而不是只根据知识点写论文式说明。

在第二步生成 detailed_content 时，LLM 还没有看到图片。它只是根据知识点写了一段说明，就像写论文摘要一样。但真正的解说视频，讲解者会根据屏幕上展示的内容来调整措辞。

假设我们要解释"神经网络的激活函数"，第二步的 detailed_content 可能写的是：

"激活函数是神经网络的关键组件，常见的有 Sigmoid、ReLU、Tanh 等。它们的作用是引入非线性..."

这是正确的知识说明，但作为解说词就显得生硬。而在第四步，LLM 在看到图片后，这时，生成的讲稿可能是：

"大家可以看到，这三条曲线分别代表三种常用的激活函数。蓝色的这条是 Sigmoid 函数，它的特点是...

这样的表达让观众的注意力能够跟随解说移动。这就是"看图说话"的效果。

除此之外，在实际演示的讲解中，主题页、章节页、总结页的解说方式也存在区别，都需要做针对性的提示词设计。你甚至可以让模型加入一些更口语化的表达，比如自问自答、轻度反问等，让讲解更像一段真实课堂。

第五步：语音合成 - 让AI“说”起来

将解说词转为语音，技术上并不复杂—调用TTS API 即可。当前主流的 TTS 服务（如阿里的 CosyVoice、Qwen-tts等）都已经达到了很高的自然度。

这里有两个技巧：

音色：由于这些TTS模型大多支持多种”音色”，可以把音色做成一个配置项，在不同场景下选择不同的音色生成更真实自然的语音。
SSML：一个可以让语音听起来更像“真实人类”的技巧：SSML（语音合成标记语言）。它是一种更精细的控制方式：允许在文本中插入标记，指导 TTS 引擎如何发音。

比如，在第四步生成脚本时，可以要求 LLM 在适当位置插入 SSML 标签：

* 输出的旁白文本用<speak>与</speak>包裹，方便语音合成处理。

* 适当增加停顿。停顿使用类似<break time="500ms"/>标签嵌入。

* 强调关键数据或结论时，用 <emphasis> 标签加重语气。

...

这样生成的解说词文本可能类似于这样：

<speak>大家请看屏幕。<break time="500ms"/> 这三条曲线分别代表三种常用的激活函数......<speak>

这样在TTS合成时，这些标签会指导引擎进行语音合成，会让最终的语音听起来更像一位讲师在授课，显著的提升“听感“，而不是冷冰冰的机器朗读。具体的SSML所支持的合成指令可以参考TTS模型官方的文档说明。

第六步：视频合成 — 让一切无缝衔接

现在我们有了两类资产：一堆 PPT 图片（每页一张），和一堆音频文件（每页一段）。最后一步，是把它们"缝"在一起。这可以借助强大的ffmpeg来完成：

实现的关键要点：

每个视频片段（也就是一页图片的持续展示）的时长，必须严格等于对应的音频时长，否则会出现"画面已切换，但上一页解说还没说完"的错位。
简单地拼接视频片段，会导致 PPT 切换时的"跳变"，画面很生硬。为了让切换更流畅，我们可以加入转场效果，给人一种很自然的切换PPT的效果。
还可以根据需要做一些其他设置。比如编码格式、是否支持流式播放、分辨率、音频采样率和比特率等，其中部分参数可以放在程序的配置中。

最终效果：从理论到现实

将以上步骤全部用 LangGraph 编排起来，并配合 checkpoint 机制保证流程可以“断点续跑”后，我们就可以来测试这个应用。为了方便调试，这里把每一步的关键结构保存下来：比如生成的 slide 结构、脚本内容、每页的图片等，这样问题出现时可以快速定位。

我们以Google Gemini 3发布的这篇官方介绍作为输入：

https://blog.google/products/gemini/gemini-3/#note-from-ceo

我们回顾下整个过程：

步骤1：知识抽取

系统调用Jina Reader API，提取原文的Markdown文本。当然，如果需要更精确的图文混合信息，也可以切换到视觉模式。

步骤2：结构化编剧

LLM 分析全文，设计出若干页 PPT 的结构，每页包含要点、详解和图片提示词。比如第二页的提示词：

左侧区域列出要点：'• 最智能模型：融合前代所有优势'、'• 顶尖推理：1501 Elo基准测试分数'、'• 多模态革新：支持文本/图像/视频/音频'。右侧区域配图：抽象的AI推理示意图，包含重叠的知识图谱节点和代表多模态的图标（文本、图像、视频符号）。

步骤3：图片生成

系统使用 Doubao Seedream，根据提示词绘制对应的 PPT 页面图片。比如第二页：

步骤4：解说脚本生成

多模态模型根据“图片 + 详细知识点”产出最终讲稿。像第二页的脚本会从“Gemini 3 有多强？”这样的开场切入，再依次介绍智能性、推理能力、多模态处理优势等，并结合图上的元素进行“指着图讲”的表达。

步骤5：语音合成

使用阿里CosyVoice模型，根据脚本（含SSML标签）生成音频。

步骤6：视频合成

用 ffmpeg 将图片与音频合成视频片段，并加入轻量的转场，最终导出 MP4。

最终呈现的效果就是文章开头所示的讲解视频。图片[4]-解密谷歌 NotebookLM 技术幕后【下】：如何用 AI 制作“带讲解的 PPT 演示视频”？-AI Express News

当然，需要注意到这个版本仍然存在较多优化空间：语音仍然略显生硬、个别画面存在文字错误等等，这些都需要依赖模型的升级与工程细节的进一步打磨。

总结与展望

本文拆解了一条将“知识源 → 带讲解的 PPT 视频”的完整链路。它看起来似乎只是调用一堆模型，但真正做下来会发现，这是一项对工程细节和流程控制要求极高的工作。无论是提示词设计、模型选择、错误兜底，还是多模态内容的对齐，都会直接影响最终成品的质量。

这条链路在实际应用中“可扩展”，它有许多形态上的变体。例如，只保留“结构化编剧 + 图片生成”两步，就能自动生成图片式 PPT 文档，用于企业内训、产品介绍、方案演示；如果只保留“脚本生成 + TTS”，去掉图片部分，就能自动生成新闻快讯播报、技术文章的音频摘要；甚至可以持续订阅行业资讯做自动汇总；再加上一些模板化的图表生成，还能做成“自动生成行业周报”的模式。

或许有一天随着模型能力的增强，也许我们只需要告诉模型”把这篇文档做成带讲解的PPT演示视频“，它就能端到端的完成工作。但在那天到来之前，这种“分步控制、精细打磨”的工程能力，是目前构建高质量AI应用的核心竞争力。

本文源代码将在完善后提供，请分享点赞给作者一点动力。

END

文章版权归作者所有，未经允许请勿转载。

THE END