别再把所有 AI 演示工具都叫 PPT Skill
一套 AI 生成的幻灯片可以在浏览器里播放，可以导出 .pptx，也可以只是把十张图片装进 PowerPoint。它们看起来都像“PPT”，交付给同事之后却完全不是一回事。
选工具前最该确认的不是主题数量、截图效果或 GitHub Star，而是交付合同：谁来播放，在哪个环境播放，接收方还要改什么。答案会决定你需要的是 PowerPoint 对象、HTML 运行时，还是固定画面的图片。
先看对象模型，不要只看扩展名 #
.pptx 是基于 Office Open XML 的容器。文件能被 PowerPoint 打开，不代表其中的内容都能按预期编辑。判断可编辑性至少要继续问：标题是不是文本框，图表有没有数据表，表格是不是表格对象，图形是独立形状还是一张整页图片，备注、母版和动画是否保留。
按实际交付，当前工具大致落在四条路线：
- 直接生成 PowerPoint 原生或 DrawingML 对象，接收方能在 Office 中继续修改。
- 先用 HTML 设计，再把受支持的 DOM 元素翻译为文本框、形状和图片。
- 交付 HTML/CSS/JavaScript，源代码可改，但 PowerPoint 用户不能直接接手。
- 生成整页图片，再封装为
.pptx或 PDF；文件能翻页，页面元素并不可编辑。
这四类没有统一的优劣。问题在于，很多项目只写“支持 PPTX”或“可编辑”，没有说明可编辑到哪一层。
ppt-master 走的是 PowerPoint 交付路线
#
截至 2026-07-29，hugohe3/ppt-master 仍是这批候选中对 PowerPoint 对象合同说明最完整的项目。它将 SVG 设计转换为可编辑的 DrawingML deck，支持文本、形状、图片、演讲者备注、模板填充、转场和动画。普通导出中，图表与表格可以作为独立形状继续修改；使用 --native-charts-and-tables 时，符合条件的内容会改成带 Edit Data 能力的 PowerPoint Chart/Table 对象。
这个区别很实际。独立形状更容易保持跨 PowerPoint、Keynote 和 LibreOffice 的视觉一致，原生 Chart/Table 更方便换数据，却可能在不同软件里出现渲染差异。项目把两种结果分开输出，比笼统承诺“原生可编辑”更可信。
它也不是一键成片服务。官方 README 明确要求本地 Python 环境和 Agent 工作流，并承认模型决定生成上限，最终仍需要人工润色。适合它的场景是客户或同事必须拿到可继续编辑的 PowerPoint，且团队愿意为对象质量、模板和本地工具链付出配置成本。
huashu-design 已经不能再归为纯 HTML 工具
#
旧版比较常把 alchaincyf/huashu-design 放进纯 HTML 队伍，这个结论现在已经过期。项目目前仍以 HTML 作为设计和演示主画布，也支持 MP4、GIF、PDF 与 SVG，但新增了 html2pptx.js 路线，可把符合约束的 DOM 元素翻译成 PowerPoint 文本框和形状。
代价写在官方文档里：可编辑 PPTX 必须从一开始就按固定画布和 DOM 规则设计，不支持随意使用 CSS 渐变、background-image 或复杂 Web Component；视觉自由度优先时，应走 HTML/PDF 路径，而不是指望导出后同时保留全部网页效果和 PowerPoint 编辑能力。
因此，它更像双轨工具：一条轨道保留 HTML 的视觉与动画能力，另一条轨道用设计约束换取可编辑 PPTX。是否适用，要看团队愿不愿意在创作阶段接受这些约束。不能再说它“只会输出 HTML”，也不能把它的任意 HTML 产物都当成可以无损转成 PPTX。
HTML 工具解决的是演示运行时 #
frontend-slides、guizang-ppt-skill 和 html-ppt-skill 的主交付仍是 HTML。
frontend-slides 生成内联 CSS/JS 的单文件演示，也能把已有 PowerPoint 转成网页并保留内容、图片和备注。这里的转换方向是 PPTX 到 Web，不是生成一个可继续在 PowerPoint 里编辑的 deck。
guizang-ppt-skill 明确把单文件 HTML、浏览器直接播放和视觉模板作为核心能力，README 也写明 PPTX 不是当前主流程。它适合现场展示、网页发送、截图或录屏，不适合多人在 Office 里接力改稿。
html-ppt-skill 提供主题、布局、动画和 Presenter Mode。演讲者窗口包含下一页预览、逐字稿和计时器，这些是浏览器运行时能力，不应因为没有 .pptx 就被低估。反过来，依赖 Web 字体、浏览器版本或脚本的 deck，离线交付前必须在目标电脑上实测。
reveal.js 的官方文档提供了一个稳定对照：HTML 演示可以有 speaker view、notes、Auto-Animate 和 PDF 导出；PDF 导出还明确依赖 Chrome/Chromium 的打印路径。HTML 的价值在交互和可编程运行时，限制也来自这个运行时。
“导出 PPTX”可能只是把图片装进去 #
JimLiu/baoyu-skills 现在确实包含 baoyu-slide-deck，会先生成每一页的图片，再合并为 .pptx 和 PDF。它已经不应被简单排除在演示工具之外，但产物仍属于图片路线：适合固定视觉、快速分享和社交传播，不适合在 PowerPoint 里逐项修改文字、图表和布局。
这正是只看扩展名最容易犯的错误。整页 PNG 放进 .pptx 后，文件可以播放，接收方却只能替换整张图。若需求写的是“交付可编辑 PPT”，这种结果仍然不合格。
审美截图不能替代同题测试 #
AI 幻灯片研究也在逐渐摆脱只看单页截图的评估方式。PresentBench 将内容约束、视觉设计和来源忠实度放在一起；PreGenie 则把代码检查与渲染后的页面检查分开，用视觉回看发现溢出、错位和缺图。共同点很朴素：源文件正确不代表渲染结果正确，画面漂亮也不代表内容忠实或方便修改。
比较候选工具时，准备同一份真实材料，让每个工具完成 8 到 10 页。不要只看第一版截图，实际执行几项编辑：改一段标题，替换一个数据，调整一张图，增加一页，换到另一台电脑离线播放。记录修改花费的时间、导出是否错位、字体是否替换、备注是否可用，以及重新生成一页会不会破坏其他页面。
如果交付物是 PowerPoint，还要打开选择窗格检查对象：一页里究竟有文本框、形状和图表，还是只有一张图片。若项目声称支持原生图表，亲自点一次 Edit Data。这些动作比“支持 PPTX”四个字更能说明问题。
按交付方式选，不按排行榜选 #
需要客户继续修改 Office 文件，优先实测 ppt-master；若团队偏好 HTML 设计，同时愿意从起稿阶段遵守转换约束，可以比较 huashu-design 的 PPTX 路线。需要网页级动画、演讲者模式或在线分发，frontend-slides、guizang-ppt-skill、html-ppt-skill 更合适。只要固定画面和快速传播，可以选 baoyu-slide-deck 这类图片路线。
许可证也要在试用时一起检查。当前仓库元数据中，ppt-master、frontend-slides、huashu-design、html-ppt-skill 和 baoyu-skills 使用 MIT，guizang-ppt-skill 使用 AGPL-3.0。具体分发、修改和服务化义务仍应回到目标版本的许可证核对。
AI 演示工具没有脱离交付场景的冠军。真正需要先分清的是：最终交付的是 Office 对象、HTML 运行时，还是固定画面。把对象模型问清楚，很多看似复杂的选型会立刻简单下来。
来源 #
- ECMA International：ECMA-376 Office Open XML 与 Microsoft Learn：MS-PPTX: PowerPoint extensions（
.pptx的标准与对象基础）。 - PptxGenJS 官方文档（OOXML 输出及文本、形状、表格和图表对象）。
- reveal.js 官方文档及PDF Export（HTML 演示、speaker view、notes 与浏览器导出边界）。
hugohe3/ppt-masterREADME 与输出说明（DrawingML、原生 Chart/Table 可选导出，复核于2026-07-29）。alchaincyf/huashu-designREADME 与editable-pptx.md（HTML 双轨输出及 DOM 到 PPTX 的转换约束，复核于2026-07-29）。zarazhangrui/frontend-slides、op7418/guizang-ppt-skill、lewislulu/html-ppt-skill（HTML 主交付与演示运行时能力，复核于2026-07-29）。JimLiu/baoyu-skills的baoyu-slide-deck（逐页图片生成并合并为 PPTX/PDF，复核于2026-07-29）。- PresentBench 与 PreGenie（内容、视觉、来源忠实度和渲染后检查的评估思路）。