为 AI 智能体重做 PowerPoint API：小模型也能稳定出图

一家团队在 Hacker News 发布文章称，针对 AI 智能体创建与编辑 PowerPoint 场景，他们构建了一套新的编程接口（API）与配套工具，用以替代当前在 AI 圈广泛使用的 python-pptx 方案。在其内部 195 项任务的基准测试中，所有参与测试的模型在配备新工具后表现均有提升；其中最便宜的模型 Luna 击败了「写代码能力最强」的前沿模型 Opus，成本降低约 96%，且产出文件零损坏。

当前 AI 生成 PPT 的主流做法

目前 AI 智能体生成或修改 PPT 主要依赖两条路径：一是通过 VBA 宏、VSTO 插件或 Office.js 自动化运行中的 PowerPoint 客户端；二是直接读写 .pptx 文件内部的 OOXML（Office Open XML）文本。.pptx 本质是 XML 文件的 ZIP 打包，最常用的封装库是开源的 python-pptx。

由于在服务器端稳定运行 PowerPoint 客户端十分困难，AI agent 通常选择第二条路径，在沙箱中执行 Python 脚本来产出文件。但 python-pptx 存在多个能力空缺，包括无法复制幻灯片、增删表格行、创建双纵轴图表，以及在替换文本时会丢失原有的字符级格式。

绕过库能力的「开胸手术」与渲染兜底

为弥补这些空缺，agent 只能回退到解压 .pptx、手工替换 XML、再重新打包的原始操作。文章用「给文件做开胸手术」来形容这一过程，并指出 OOXML 规范本身在元素顺序、继承关系与隐式规则上极其容易出错，即便通过官方校验，PowerPoint 仍可能判定文件损坏；反过来，违反 schema 的文件却常常能被 PowerPoint 正常打开。

文章给出一个具体例子：为一张 100% 堆积柱形图添加数据标签时，即便按 ISO 规范第 4061 页正确地打开 showPercent 开关，PowerPoint 也不会渲染百分比标签，必须额外把数据本身设置为百分比格式并手动加数值标签。而一旦在 XML 中错把 dLblPos 放在 showLegendKey 之后，文件立刻损坏。

唯一的可靠兜底是渲染验证：在服务器端用 LibreOffice 无头模式渲染幻灯片截图，对照实际显示效果来排查 schema 无法体现的问题。

新工具思路与基准结果

团队表示，他们自 2025 年初开始研发这套工具（项目名 editide），核心思路是把这套「OOXML 陷阱」封装为更稳定、更易被 AI 调用的接口，让模型不必再深入操作裸 XML。在其 195 项任务的基准上：

• 配合新工具后，所有测试模型成绩均有所提升；
• 价格最低的模型 Luna 表现优于被标注为「写代码最强」的 Opus；
• Luna 的运行成本仅为后者的约 4%，即降低约 96%；
• 整个基准过程未产生损坏的 .pptx 文件。

行业层面的隐含信号

文章同时指出，包括 Anthropic 和 OpenAI 在内的厂商已不敢把低价位模型用于 PPT 场景：Claude 的 PowerPoint 加载项不允许用户从模型选择器中选 Haiku，ChatGPT 的 PPT 插件甚至不提供更低端的 Terra 模型。这从侧面说明，在文件生成这类「写出来就要能打开」的任务上，主流厂商对自家小模型尚缺乏信心。

（正文信息依据原文摘录整理；原文在「你…」处截断，更详细的工具实现与基准方法未能获取。）