本节课我们将继续围绕一个非常热门的智能体应用场景来展开：PPT生成智能体。 目前市面上，很多智能体产品都在提供类似的能力，例如输入一个主题，让 AI 自动生成一份完整的 PPT，包括页面结构、文字内容以及配图设计等。从表面上看，这似乎只是一个简单的“文本生成任务”，但在实际工程实现中，PPT生成其实涉及到 内容生成、排版设计、文件格式处理等许许多多的问题，而且实现方式也并不只有一种，整体的复杂度还是非常高的。 目前市面上的 AI PPT生成方案，大致可以分为几种不同的技术路线。不同方案在 生成质量、可编辑性、实现复杂度以及成本方面都有明显差异。本节课我们就来分析目前主流的几种实现方式，并理解它们背后的工程思路。
文生图 PPT
第一种方式就是 通过文生图大模型生成 PPT 页面。 这种方案的核心思路非常简单：既然 PPT 的每一页本质上就是一张设计好的页面，那么完全可以让 文生图模型直接生成 PPT 页面图片，然后再将这些图片组合成一个 PPT 文件。 整个流程通常是这样的：
用户输入一个主题，例如：生成一份关于人工智能发展趋势的PPT
↓
大模型生成 PPT大纲和每一页的设计描述
↓
将这些描述作为提示词，调用文生图模型生成高质量的页面图片
↓
将生成好的图片按照顺序插入到 PPT 文件中，输出最终的 PPT。
这种方式目前在一些 Agent Skills 中非常流行，可能大家经常刷抖音的话，很多的科技博主都在推荐这种方式，尤其是搭配了一些高质量的文生图模型，如：nanobanana-pro，可以生成质量非常高的 4K图片，整体效果确实是非常的惊艳，看起来就像专业的 UI 设计师制作的一样。 所以这种方案最大的优点是 视觉效果非常好。因为图像生成模型在设计、配色和视觉风格上通常比程序化排版更加灵活，因此生成出来的页面往往更有设计感。 但这种方式也存在非常明显的问题。 - 首先是 成本问题。如果一份 PPT 有 20 页，就意味着需要生成 20 张高分辨率图片。高质量文生图模型的推理成本通常比较高，一张4K图片基本要大几毛到1块多，因此整体生成成本会明显增加。 - 其次是 对模型能力依赖非常强。如果文生图模型的文字生成能力不够好，就很容易出现一些问题，例如中文文字乱码、字体变形，甚至出现“鬼画符”一样的文字。 但这还不是最关键的问题。 - 这种方案最大的缺点是 PPT无法编辑。因为最终生成的 PPT 本质上只是一个“图片合集”，每一页都是一张完整的图片。用户在打开 PPT 后，无法单独修改文字，也无法调整图片位置。如果想要修改内容，就只能重新让模型生成整页图片。 因此这种方式更适合 展示型PPT，例如营销展示、宣传海报类的场景，而不太适合日常办公场景。
代码生成 PPT
第二种方式是 通过生成代码来创建 PPT 文件。 这种方案的核心思路是：让大模型直接编写用于生成 PPT 的代码，然后执行这些代码生成 .pptx 文件。在 Anthropic 开源的 Anthropic Skills 项目中，就提供了一个专门的 PPT Skill： https://github.com/anthropics/skills/tree/main/skills/pptx 这个 Skill 的实现方式其实非常直接：模型负责写代码，代码负责生成 PPT。 整个流程通常是这样的：
用户输入一个主题，例如：生成一份关于人工智能发展趋势的PPT
↓
大模型生成 PPT 的大纲和每一页的内容
↓
大模型编写 Python 脚本，使用 PPT 库创建 slides
↓
系统执行生成的代码，自动生成 .pptx 文件
↓
输出最终的 PPT 文件这种方式最大的特点是 生成的 PPT 是完全可编辑的。
因为最终生成的是标准的 PPT 文件，而不是图片，因此用户可以随意修改文字、替换图片、调整布局，也可以继续在原有 PPT 上进行编辑。 当然，这种方式的 成本也更低。因为整个流程只需要调用一次大模型生成内容和代码，不需要额外调用文生图模型，因此整体推理成本会明显下降。 但这种方式同样也存在一些问题。 首先是 视觉设计能力有限。因为 PPT 的排版是通过代码实现的，而不是设计模型生成的，如果没有精心设计模板，生成出来的 PPT 往往会比较普通。 其次是 对模型代码能力依赖较强。因为 PPT 的布局、字体、图片位置等都需要通过代码控制，如果模型生成的代码不够稳定，就可能出现排版不整齐或布局异常的问题。
生成 HTML PPT
第三种方式是 通过生成 HTML 页面来生成 PPT。 之所以会有这种方案，是因为 HTML 本身就是一种非常强大的布局语言。通过 HTML 和 CSS，可以很容易地实现各种复杂的排版效果，例如： - 多列布局 - 图文混排 - 渐变背景 - 图标与装饰元素 而大模型在生成 HTML 代码方面通常表现得非常好，因为 HTML 的结构是非常规则的。你想想，现在AI写前端代码有多厉害，所以像PPT这种样式代码，大模型写的效果会非常好。 因此一些智能体系统会让大模型直接生成一段 HTML 页面代码，每一页 PPT 对应一个 HTML 页面。HTML 渲染完成后，再通过一些转换工具，将 HTML 页面转换为 PPT 文件，甚至有些产品，直接就是将 HTML 页面渲染给用户。 这种方式的优点在于 设计灵活度非常高。HTML 可以轻松实现很多复杂的视觉效果，例如卡片式布局、响应式排版等，因此生成的页面通常也比较美观。 但这种方式同样存在一个比较严重的问题：HTML 和 PPT 的格式体系并不一致。 HTML 页面使用的是 CSS 布局系统，而 PPT 的底层格式是 Office Open XML，它的布局方式与 HTML 完全不同。因此在 HTML 转换为 PPT 的过程中，很难做到完全一致的效果。 在实际转换时，经常会出现一些问题，例如： - 页面布局错位 - 字体样式变化 - 背景样式丢失 - 元素位置偏移 因此虽然这种方式在理论上非常灵活，但在实际工程中，转换稳定性往往很难保证。所以如果你能接受生成的PPT是个 HTML 页面，那就可以用这种方式。
直接操作 PPTX
第四种方式是 让大模型直接操作 PPT 文件结构。 PPT 文件实际上是一种结构化文档格式，底层是 Office Open XML（PPTX）。开发者可以通过一些库来操作这些结构，例如： - python-pptx - pptxgenjs 这些库允许程序创建 PPT 页面、插入文本框、插入图片、设置位置和大小等。 在这种方案中，系统会给智能体提供一个 PPT操作工具。模型在生成过程中，可以通过工具调用的方式去创建 PPT 页面，例如： 创建一页新的幻灯片、插入标题文本、添加一张图片等等。 这种方式的优点是生成的 PPT 是 原生结构，因此用户可以自由编辑、修改和调整布局。 但如果让大模型 从零开始生成一份完整的 PPT，效果一般是非常不理想。 原因主要在于 排版规划问题。 PPT 的布局往往需要非常精细的设计，例如： - 左右图文比例 - 元素间距 - 图片大小 - 标题层级 这些内容很难仅通过自然语言描述清楚。如果让模型自己决定每个元素的具体位置，就很容易出现页面布局混乱的问题。 因此这种方式在实践中通常更适合 对已有 PPT 进行修改，例如替换文字、插入图片、更新数据，而不是从零生成整份 PPT。
模板填充 PPT
最后一种方式，也是目前很多实际产品中使用最多的方案，就是 模板填充生成 PPT。 这种方案的核心思想是：让 AI 只负责生成内容，而不是负责设计页面。 在这种模式下，系统会事先准备大量设计好的 PPT 模板，例如不同风格的模板： - 商务风模板 - 科技风模板 - 学术汇报模板 - 简约风模板 这些模板通常由专业设计师制作好，并且在页面中预先设置好各种 占位符，例如标题区域、正文区域、图片区域等。 当用户输入一个主题时，大模型首先生成 PPT大纲和每一页的内容结构。这些内容通常会用一种结构化格式表示，例如 JSON，用来描述每一页需要填充哪些内容。 随后系统读取对应的 PPT 模板，将生成好的内容填充到模板中的占位符中，最终生成完整的 PPT 文件。 这种方式的优点非常明显。 首先，生成的 PPT 是 原生可编辑的。用户可以随意修改文字、替换图片或者调整布局。 其次，PPT 的视觉效果比较稳定，因为页面设计是由模板决定的，而不是由模型临时生成。 同时，这种方式的生成成本也比较低，因为只需要生成文本内容，以及一些简单的配图（不需要调用昂贵的图像生成模型），甚至可以直接使用echarts-mcp生成图表即可（完全免费）。 当然，这种方案的缺点是 系统实现会相对复杂。需要额外实现模板管理、占位符解析以及渲染逻辑等功能。 但从实际工程经验来看，这种方式是目前 最稳定、最可控、最适合产品化落地的方案。 因此在接下来的实战课程中，我们也将重点讲解 模板填充生成 PPT 的实现方式，并带大家一步一步实现一个完整的 PPT生成智能体。