GPT88 / API Docs
வலைப்பதிவுக்குத் திரும்பு

AI 会生成 PPT 之后，为什么 Runtime 才决定上限？

技术教程2026-08-179 நிமிட வாசிப்புAI PPTArtifact RuntimeAI AgentPptxGenJSpython-pptx文档运行时

AI 已经可以通过代码生成 PPT，但“能生成文件”并不等于“能持续做好一份专业演示文稿”。

当任务只是从零生成一份空白 PPT 时，PptxGenJS、python-pptx 或其他文档库通常已经足够。但真实工作很少从空白画布开始：团队手里有历史材料、旧模板、用户修改过的页面、不断变化的数据，以及需要保留的排版约束。此时，Agent 不仅要生成，还要在几天之后重新找到对象、修改局部、保持结构，并确认结果没有被破坏。

公众号文章《AI 会生成 PPT 之后，Runtime 决定了它能做多好》把问题归纳成两条线：

  1. Agent 如何重新进入并持续操作一份 PPT？
  2. 底层能力已经足够丰富，为什么生成结果仍然容易千篇一律？

文章给出的关键答案是：下一阶段的重点不只是增加更多 API，而是引入一层 Artifact Runtime（产物运行时）。

先看结论：PPT 要从“文件”变成“工作对象”

一次性生成器的工作方式大致是：

输入需求 → Agent 写代码 → 导出 PPTX

这种方式适合快速出第一版，但导出的 PPT 很容易变成任务终点。用户在 PowerPoint 里修改之后，Agent 不知道对象是否移动、文字是否变化，也无法稳定地继续接管。

Artifact Runtime 希望把流程变成：

观察产物 → 找到对象 → 局部操作 → 验证结果 → 再次进入

PPT 不再只是 Agent 的输出文件，而是一个可以被反复观察、定位、修改和检查的 Artifact。

为什么“API 足够多”，表达仍然容易模板化？

今天的大模型已经很会写 JavaScript，PPT 生成库也能够表达常见的文本框、图片、形状、表格、图表和连接线。问题不再是“画不出来”，而是 Agent 经常只使用能力空间中的一小部分。

常见结果会不断收敛到：

  • 三栏卡片；
  • 四宫格指标；
  • 左文右图；
  • 时间线；
  • 标题加一排内容卡片。

这些版式并不一定错误，但它们说明 Agent 经常在直接选择坐标和形状，而不是从“这页真正要表达什么”出发。

对于同一组数据，专业表达可能是：

  • 突出一个异常值；
  • 表示几个系统之间的边界；
  • 展示一条演进路径；
  • 解释一个因果关系；
  • 对比两个阶段的变化。

如果 Agent 只拿到 rectangle、text、line 和坐标，它很容易继续拼装熟悉的卡片模板。可编程性解决“能不能做出来”，表现力解决“这个意图应该怎样被表达”。

什么是 Artifact Runtime？

Artifact Runtime 位于 Agent 与专业产物之间。它不是简单增加一组绘图函数，而是为 Agent 提供一个可以反复进入的工作环境。

一个完整的产物运行时至少需要让 Agent 能够：

  1. 观察当前文档状态；
  2. 找到并引用具体对象；
  3. 只修改需要修改的部分；
  4. 检查修改是否生效；
  5. 在用户再次编辑后重新进入同一份产物。

可以把它抽象成：

Agent  ↔  Artifact Runtime  ↔  PPT

Runtime 负责处理对象身份、布局关系、格式转换和验证流程；Agent 继续负责专业判断、内容组织和叙事方向。

四步工作循环：Observe、Address、Operate、Verify

文章把实际工作过程拆成四个动作。

动作作用需要回答的问题
Observe观察产物当前页面、对象和布局是什么状态？
Address寻址对象我要修改的对象是谁，如何稳定引用？
Operate执行局部操作这次只需要改哪些文本、属性或关系？
Verify验证结果修改后是否正确，布局是否仍然可读？

Observe：先理解当前产物

Agent 不能假设 PPT 仍然保持自己上次生成时的状态。用户可能改过标题、删除过元素、移动过图片，也可能替换了模板。

因此，Agent 重新工作前应该先获取当前文档的可观察状态，而不是直接执行一段几天前写好的坐标脚本。

Address：给对象稳定身份

“第三页左边蓝色的框”不是稳定的对象引用。用户移动它之后，这个描述可能失效；页面增加一张卡片之后，“第三页左边”也可能指向另一个对象。

更可靠的流程是先搜索和检查，再拿到对象 ID：

inspect({ search: "Revenue" })

→ {
    kind: "textbox",
    id: "sh/c3d4e5f6",
    name: "headline",
    text: "Revenue outlook"
  }

之后，Agent 可以通过稳定 ID 重新定位对象：

resolve("sh/c3d4e5f6")

对象的身份不应该依赖它当前在页面上的像素位置。

Operate：优先修改局部

找到对象之后，Agent 应该尽量做局部操作，而不是重新生成整份 PPT。例如只替换标题中的一个词：

headline.text.replace("Revenue", "Revenue outlook")

局部操作更容易保留用户已有的模板、字体、间距和其他页面结构，也更容易在出现问题时定位原因。

Verify：修改之后重新检查

操作完成不代表任务完成。Runtime 需要重新检查目标对象和页面状态，确认：

  • 文本确实被替换；
  • 对象没有跑出页面；
  • 换行没有破坏层级；
  • 新增内容没有遮挡其他对象；
  • 用户已有的布局关系仍然成立。

这一步把“代码执行成功”和“文档结果正确”区分开来。

从坐标到布局语义

如果 Runtime 只保存最终坐标，它仍然需要让 Agent 反复计算宽度、间距、换行、对齐和高度。

例如，四张指标卡在一次生成中可能只是四组坐标：

card-1: left=72,  top=160, width=260
card-2: left=356, top=160, width=260
card-3: left=640, top=160, width=260
card-4: left=924, top=160, width=260

但坐标没有表达它们之间的关系。卡片数量变化、标题变长或画布尺寸变化后，Agent 仍然要重新排版。

布局语义保存的则是：

  • 等宽；
  • 等距；
  • 同一行对齐；
  • 可填充剩余空间；
  • 内容变长时自动扩展；
  • 空间不足时如何换行。

文章提到的 row、column、grid、fill 和 hug，可以被理解为这类关系的描述方式：

row   → 横向结构
column → 纵向结构
grid  → 网格关系
fill  → 填充可用空间
hug   → 根据内容包裹尺寸

这样，Agent 决定“这里需要四个指标”，Runtime 负责把四个指标稳定地排成一行，并在内容变化后重新求解布局。

从布局语义到领域对象

布局语义解决的是空间关系，但还不能完整表达专业意图。

grid 知道对象如何排列，却不知道它们是一组“指标卡”；connector 知道节点需要连线，却不知道这条线表达的是服务依赖、流程演进还是系统边界。

因此，Runtime 还可以继续向领域语义演进：

坐标与形状
      ↓
布局关系
      ↓
领域对象
      ↓
专业意图

在更高一层，Agent 不必先写 Shape，而可以先描述：

  • 这是一组关键指标；
  • 这是一条产品演进路径；
  • 这是一个服务依赖图；
  • 这是一个架构边界；
  • 这是一个需要突出异常的对比页。

Runtime 再把这些领域对象展开成可编辑的 PPT 对象，继承样式、调整布局、重排连接，并验证最终页面是否仍然可读。

Runtime 的边界：接管工程复杂度，不替代专业判断

Runtime 并不是抽象得越高越好。它适合接管那些可以被工程化、重复出现、需要稳定执行的工作：

  • 对象寻址；
  • 关系维护；
  • 布局求解；
  • 文档格式转换；
  • 局部修改；
  • 结果验证；
  • 版本或状态重新进入。

但下面这些判断仍然属于 Agent 或使用者：

  • 这一页最重要的观点是什么；
  • 应该突出异常还是平均值；
  • 叙事顺序应该怎样安排；
  • 哪些数据应该合并，哪些应该拆开；
  • 用对比、流程、架构还是故事来表达。

可以用一句话区分两者：

Agent 负责专业判断
Runtime 负责稳定展开、修改和验证

如果现在要做一个 PPT Agent，应该先做什么？

不要一开始就堆更多模板或更多 Shape API。更稳妥的实现顺序是：

第一步：建立稳定对象身份

先让文档中的页面、文本框、图片、表格和连接线有可查询、可引用的 ID。确保用户移动对象后，Agent 仍然能够重新定位它。

第二步：实现 Observe-Address-Operate-Verify

把“先看状态、再找对象、做局部修改、修改后复核”做成固定工作流，而不是让每个 Agent 自己临时发明。

第三步：把布局关系从坐标中抽出来

将等宽、等距、对齐、填充和包裹等规则交给 Runtime，减少 Agent 在坐标计算上的重复劳动。

第四步：沉淀领域对象

根据真实使用场景，把指标卡、架构边界、流程节点、演进阶段等高频结构封装成领域对象。

第五步：把专业意图留给 Agent

Runtime 提供稳定的表达材料，但不要替 Agent 决定页面要强调什么。真正的差异化来自专业判断，而不是 Shape 数量。

总结

AI 生成 PPT 的下一阶段，重点可能不是再写一个更大的绘图库，而是让 PPT 从一次性文件变成可持续操作的产物。

Artifact Runtime 的价值在于：

  • 让 Agent 能重新观察一份 PPT；
  • 用稳定对象 ID 代替脆弱的视觉描述；
  • 支持局部修改，而不是每次从头生成；
  • 让布局关系由系统维护；
  • 让领域对象承载专业结构；
  • 在每次操作后验证文档结果。

最终，Agent 与 Runtime 的分工应该越来越清晰：Agent 决定专业意图，Runtime 把意图稳定地变成可编辑、可维护、可验证的 PPT。

本文根据 Phodal 的公众号文章整理，涉及具体实现时，建议继续阅读原文以及相关项目的最新代码和文档。

தொடர்புடைய வழிகாட்டி

工具集成指南