不爱恰糖
搜索 K

Appearance

PPT Agent 2.0：从五阶段内容流水线到可复用交付链路 ​

之前写过一篇 《如何构建一个 PPT Agent：从需求调研到 SVG 页面生成》，当时重点是把 PPT 生产拆成五个阶段，让模型不要一上来就套模板。

那篇文章解决了一个很重要的问题：先有内容结构，再有视觉设计。

但如果真的把这套流程跑到交付，你会发现还差一截。因为真实的 PPT 任务不只是“把 SVG 生出来”就结束了，它还包括：

  • 需求要不要继续追问
  • 页面标题什么时候冻结
  • 多个阶段文档怎么避免互相漂移
  • SVG 怎么稳定导成 PPTX
  • 导入后为什么会留白边
  • 最后怎么补出演讲稿，而不是只有一堆设计稿

所以我更愿意把这次升级后的版本叫做 PPT Agent 2.0。

它不再只是一个“五阶段生成流程”，而是一条更完整的内容生产和交付链路。

为什么需要 2.0 ​

很多 AI PPT 的问题，表面上看是页面不够好看，实际上是前面的信息链路就断了。

常见症状一般有这几种：

  • 用户只给一个标题，系统就开始出 15 页大纲
  • 大纲是段落，不是结构
  • 搜资料只搜一次总资料，没有按页面补内容
  • 页面策划和视觉生成混在一起
  • 最后虽然有 SVG，但没有办法稳定装进 .pptx

如果把这些问题放到一起看，你会发现缺的不是一个更强的“设计模型”，而是一条更稳的生产流程。

这也是 2.0 的核心变化：

  1. 不再只关注五个内容阶段，而是补齐前后的工程化环节。
  2. 不再只生成页面，而是把脚本、测试、导出和讲稿一起纳入交付。
  3. 不再只讲方法论，而是用一次真实案例把流程跑通。

这次我拿什么案例来验证 ​

这次我用的是一场内部技术分享，主题是 Harness Engineering。

它很适合做 PPT Agent 的验证案例，因为这个主题有几个特点：

  • 不是产品宣传，而是认知升级型分享
  • 听众是程序员，而且很多人已经在高频使用 Codex / Claude Code
  • 内容不能停留在工具介绍，必须讲清楚判断
  • 既要讲 OpenAI / Anthropic 的案例，也要回到团队自己的工程实践

换句话说，这不是一个“搜几篇文章拼一拼”就能做好的 PPT。

它要求整条链路同时具备：

  • 结构能力
  • 检索能力
  • 策划能力
  • 视觉生成能力
  • 工程交付能力

从 5 个阶段，升级成 7 个阶段 ​

在 2.0 里，我建议把整条链路理解成 7 个阶段，而不是只盯着原来的五步。

前五步负责内容和页面，后两步负责交付和复用。

如果只做到阶段五，你得到的是“设计产物”。

如果做到阶段七，你得到的才是一套可真正复用的 PPT 工作流。

阶段 0：先收拢上下文，而不是马上动手 ​

很多任务一开始就失败，不是模型不够强，而是上下文不完整。

所以 2.0 里我加了一个显式的 阶段 0：先看当前目录有什么。

这一步通常要确认：

  • 当前目录有没有已有资料
  • 是否允许联网检索
  • 输出是只要 SVG，还是最终还要 .pptx
  • 有没有现成的图片、评审文档、实践文档
  • 有没有仓库约束，比如命名、目录、构建要求

这次 Harness Engineering 的案例里，目录下其实已经有很多基础资料，包括：

  • 阶段 1 到阶段 4 的文档
  • 多篇本地技术资料
  • AIAPP 实践说明
  • 最终 SVG 产物

如果跳过这一步，后面就很容易重复搜索，或者把已有材料浪费掉。

阶段 1：PPT 的起点不是版式，而是信息目标 ​

阶段 1 的核心不是“出内容”，而是把任务边界讲清楚。

这一步建议至少要问清楚：

  • 主题是什么
  • 使用场景是什么
  • 目标受众是谁
  • 期望结果是什么
  • 页数或时长大概多少

以这次分享为例，最后澄清出来的结论不是“做一份 Harness Engineering 介绍”，而是：

这是一场面向客户端开发组的认知升级型分享，主结论应落在：模型重要，但真正拉开差距的是 Harness。

这一步听起来不“炫技”，但它决定了后面所有步骤的质量。

如果任务边界没定清楚，大纲一定会空。

阶段 2：大纲必须结构化，不能只是一段漂亮话 ​

PPT Agent 进入第二步之后，不应该马上写自然语言正文，而应该先产出结构化大纲。

我比较推荐强制输出 JSON，至少要包含：

  • cover
  • table_of_contents
  • parts
  • end_page

每一页都明确：

  • 标题是什么
  • 这一页承载什么内容

这样做的好处很直接：

  • 后续更容易做逐页检索
  • 页面可以程序化编号
  • 目录、章节、内容页之间的关系会非常清楚

这次案例最后稳定下来的是 17 页 结构：

  • 第一部分：Harness 到底是什么
  • 第二部分：OpenAI 的实践案例
  • 第三部分：Anthropic 的实践案例
  • 第四部分：从 AIAPP 试点到团队级 Harness

这里的重点不是页数本身，而是它已经从“主题”变成了“页面列表”。

阶段 3：不是搜一遍总资料，而是逐页补内容 ​

这是整个流程里最容易被偷懒，也最容易出问题的一步。

很多系统在做 PPT 时，会先搜一份总资料，然后让模型自己去“理解并分配”。这个做法看起来省事，实际上问题很大：

  • 有些页会被喂太多信息
  • 有些页根本没有足够证据
  • 不同页面会争抢同一份资料

更稳的做法是：按页面粒度检索。

也就是说，大纲里每一页都应该拥有自己的资料块。

比如这次案例里：

  • P3 要解决的是“为什么现在行业集中开始讲 Harness”
  • P8 要解决的是“为什么 OpenAI 放弃一个超长 AGENTS.md”
  • P12 要解决的是“Anthropic 怎么做长时任务接力”
  • P14 则完全依赖本地 AIAPP 实践文档

你会发现，只有当资料按页组织后，后面的策划稿才会真正稳。

阶段 4：先做页面策划，再做视觉设计 ​

如果说前面三步在解决“讲什么”，那阶段 4 解决的是“这一页怎么讲”。

这一步本质上是把高端 PPT 里的“策划师”角色显式化。

每页策划稿建议固定输出这些字段：

  • 页面类型
  • 核心观点
  • 页面目标
  • 内容模块划分
  • 模块优先级
  • 推荐版式
  • 可用图片 / 图表 / 数字
  • 演讲备注

这样做的价值是：

  • 先把信息组织定住
  • 再决定版式和视觉
  • 避免模型一拿到内容就开始堆装饰

这次实战里，阶段 4 其实帮我提前挡掉了不少问题。

比如：

  • P9 必须明确说 OpenAI 是重投入版本，借鉴的是原则，不是照搬做法
  • P13 必须明确来源是 Anthropic Labs 的另一篇文章
  • P14 不适合在页上放 commit hash，应该放结果面和代表性文件
  • P17 不能写成结束语，必须给讨论留空间

这些问题如果拖到 SVG 阶段才改，代价会高很多。

阶段 5：SVG 不是模板输出，而是布局语言的执行结果 ​

进入视觉生成后，真正要做的不是“随机生成一页好看的图”，而是让模型按照明确布局语言去渲染页面。

这次我用的是 SVG + Bento Grid 方案，约束包括：

  • viewBox="0 0 1280 720"
  • 页面之间用卡片形成层级
  • 卡片之间至少 20px 间距
  • 内容优先驱动布局，而不是反过来

这一步我最后落成了两类产物：

  • 一套逐页的 SVG 页面
  • 一个可重复执行的生成脚本

更关键的是，我没有只生成文件，还补了测试：

bash
python -m unittest tests/test_generate_svg_pages.py
python generate_svg_pages.py

这意味着以后页面再改，不用靠肉眼数页数、看文件名、查标题是否对齐，直接跑测试就知道有没有退化。

这就是 2.0 和“做完就算了”的最大差别。

阶段 6：从 SVG 到 PPTX，才是 2.0 真正补上的那一截 ​

这是我这次最直观踩到的坑。

最开始我以为只要有了 SVG，装进 .pptx 应该是很顺手的一步，结果事实完全不是这样。

首先，python-pptx 不能直接把 SVG 当图片塞进去。

其次，就算先截图成图片，再装进 PPTX，也不一定靠谱。因为如果你直接拿浏览器去截图 file:///xxx.svg，浏览器通常会把它当成一个居中的图像文档，而不是整页画布，于是导入 PPT 后四周就会出现白边。

这次最后稳定下来的做法是：

  1. 先把每个 SVG 包进一个 0 margin 的临时 HTML
  2. 强制 SVG 以 1280 x 720 撑满视口
  3. 再用无头浏览器截图成 PNG
  4. 最后用 python-pptx 全屏铺到 slide

对应的工程产物是：

  • build_output_pptx.py
  • tests/test_build_output_pptx.py

这一步很重要，因为它说明了一件事：

如果没有打包和验证阶段，所谓的“PPT Agent”很多时候只是一套页面生成器，还不是一套真正的交付系统。

阶段 7：最后别忘了演讲稿 ​

到了这一步，很多系统会停下，因为“页面都出了”。

但真实的分享并不是只有页面，最后还要有人去讲。

所以 2.0 里我把“演讲稿”单独列成一个阶段。它至少要解决三件事：

  • 每页到底怎么讲
  • 哪几页可以压缩
  • 哪几页适合展开讨论

这次最后形成的是一份逐页自然口语稿，而不是照本宣科式稿子。

它的价值不只是“方便演讲”，更重要的是你会倒逼自己再检查一遍：

  • 页面之间的转场顺不顺
  • 逻辑有没有跳
  • 讨论页的问题是不是够真实
  • 有没有哪一页只是页面好看，但其实讲不出来

很多 PPT 的问题，只有在写讲稿时才会暴露。

做完这一轮，我觉得 2.0 最值得保留的不是页面，而是这些中间资产 ​

这次真正留下来的高价值资产，其实不是那 17 页 SVG，而是下面这些：

  • 阶段 1 到阶段 4 的文档
  • SVG 生成脚本
  • PPTX 打包脚本
  • 两组测试
  • 演讲稿
  • 最后抽象出来的 SOP

如果没有这些东西，下一次做新主题 PPT 时，你还是会从零开始。

如果这些都留下来，下次你只需要替换：

  • 主题
  • 资料
  • 页面清单
  • 页面内容数据

整条链路就可以复用。

这也是为什么我会把这套东西叫做 PPT Agent 2.0，而不是“PPT 生成器升级版”。

它已经不只是一个模型提示词，而是一条完整的内容生产和交付工作流。

这套流程还可以继续优化什么 ​

虽然 2.0 已经能跑通，但它还不是终点。

我觉得下一步最值得优化的有三件事：

1. 增加一个“内容冻结”关口 ​

在阶段 4 到阶段 5 之间，强制冻结：

  • 页面标题
  • 核心观点
  • 页码
  • 讨论问题
  • 文件名映射

不冻结，就不要进 SVG。

2. 建一个唯一的页面清单 ​

现在信息还散在：

  • 大纲
  • 逐页资料
  • 策划稿
  • SVG 页面

更稳的做法是维护一个 page-manifest.json，作为后面所有阶段的唯一页面索引。

3. 提前决定最终交付是“图片型 PPT”还是“可编辑 PPT” ​

这次的 .pptx 是图片型 PPT，优点是稳定，缺点是后续不好在 PowerPoint 里细改。

这个决策应该前置，而不是到最后才发现。

一套最小可复用实现 ​

如果你现在就想做一个最小可用版本，我建议先不要上太重的系统，保留下面这些就够了：

text
docs/
├── 阶段1：需求调研与任务澄清
├── 阶段2：结构化大纲
├── 阶段3：逐页资料检索
├── 阶段4：页面策划稿

scripts/
├── generate_svg_pages.py
└── build_output_pptx.py

tests/
├── test_generate_svg_pages.py
└── test_build_output_pptx.py

最小命令链路也很简单：

bash
python -m unittest tests/test_generate_svg_pages.py
python generate_svg_pages.py

python -m unittest tests/test_build_output_pptx.py
python build_output_pptx.py

把这条链路先跑通，比一开始追求“全自动、高智能、多模板”更重要。

结语 ​

我现在越来越觉得，做 PPT Agent 和做别的 Agent 系统其实是同一件事：

真正决定效果的，不是最后那一下生成，而是前面的信息组织、约束设计、反馈回路和交付验证。

如果只看最后生成了一堆页面，那它还是一次性劳动。

如果把中间文档、脚本、测试、导出和讲稿都沉淀下来，这件事才真正从“会用模型”升级成了一套工程化工作流。

这也是 PPT Agent 2.0 想表达的核心：

不是让模型替你做 PPT，而是把 PPT 生产过程拆成一条可以被 Agent 稳定接管的流水线。