HTML PPT工具测评：免费编辑导出，告别古法PPT

先分享一个自己的教训，后来把它做成了个小东西，顺带把过程梳理出来——希望能帮到正好遇到同样问题的人。

说回来，过去这一年里，让AI直接用HTML写幻灯片，其实已经悄悄成了不少人的日常工作方式。大模型处理Flex、Grid布局、嵌入KaTeX公式、Mermaid图表、加载自定义字体，样样在行。但你要让它去写原生PowerPoint那套XML，效果真的不敢恭维。于是越来越多的人索性让AI生成一个漂亮的deck.html，不再跟Keynote死磕。

但只要真的这么干过几次，就会发现每次撞上同一堵墙：AI写起来容易，改起来费劲。 每次改一个字都得回到对话框重新发一轮prompt，等它响应，再看diff变化——Token烧得飞快，效率却直线下降。

当然也有人让AI直接把内容做成图片，但改起来仍然很头疼。改几个字就要反复在对话框里沟通调整，无尽循环。实在太麻烦，于是抽空做了个叫 NextPPT 的小工具。

• 官网：next-ppt.com
• 代码开源在：github.com/Trade-Offf/…

太长不读

• AI很会生成漂亮的HTML演示稿，但想改动一个字都很费劲——得回对话框重新发prompt、等、看diff，Token哗哗烧。NextPPT让你把HTML拖进浏览器，点哪改哪。
• 最终投影、提交、分享还是要PPT/PDF，而HTML上投影仪容易掉字体、卡网络。NextPPT一键导出高保真、图片型的PPTX/PDF。
• 答辩稿、客户方案、内部资料，没人想传到在线编辑器。所以NextPPT编辑全程在你本机，文件不上传。
• 可以马上试试：用Chrome/Edge打开 next-ppt.com，拖一个 .html 进去，点一下标题改两个字。三十秒就懂了。

下面从“为什么”一路讲到“怎么实现”和“怎么用”。这些观察未必都对，但多少算是一些真实思考。

一、先看为什么：问题的本质不是“做PPT”，是“改PPT”

做工具有个习惯：先别急着想用什么技术栈，先问这个问题的本质是什么，用户真正的痛点在哪。

把AI写HTML幻灯片这件事拆开，你会发现痛点根本不在“生成”——生成这一步AI已经做得很好了。痛点全在生成之后：

• 临场改一句话太难受。 答辩前一晚导师说“第16页那句话改一下”，你又得回到AI工具：发prompt、等、看diff、保存。一次还好，第十次真的想骂人。更要命的是，AI经常顺手把你没让它动的地方也“优化”了。
• 投影还是要PPT/PDF。 学校要求交 .pptx，客户要 .pdf，而HTML直接上投影仪，掉字体、卡CDN、动画乱飞，是常态。
• 隐私是真的焦虑。 答辩稿、客户方案、内部资料，谁都不太敢传到一个不知道会不会拿去训练的云端编辑器里。

光是第一个痛点，循环起来就足够磨人——你想改的只是一句话，付出的却是一整圈：

这三个痛点背后其实是同一件事情在变：AI把“从零到一”做便宜了，于是“从一到对”那段路，反而成了新的瓶颈。 大家都在卷怎么生成得更快更好看，却很少有人去管生成完之后那一地鸡毛。

想清楚这点，产品形态其实就定了：它不该是又一个AI生成器，而该是一把专门修剪AI演示稿的剪刀。

二、我砍掉了什么

挺认同马斯克那套“五步工作法”的，尤其前两步——质疑每一项要求，然后大胆删掉。所以在动手之前，先想清楚NextPPT 不做什么：

• 不做AI生成PPT。 生成交给任意AI就好，只接管最后一公里。多做一个生成器，既卷不过大模型，又把产品做散了。
• 不做reveal.js / Slidev那种DSL。 那些工具很好，但要重学一套语法。而AI吐出来的就是普通HTML，凭什么逼用户再学一门DSL？任意
  结构都该能直接用。
• 不做云端编辑器。 一上云，隐私这条最硬的卖点就没了。

砍到最后，剩下的核心就一句话：拿你已经有的HTML，在浏览器里点哪改哪，再导出一份高保真的PPT/PDF——而且文件全程不离开你本机。

在AI让做加法变得几乎零成本的时代，功能是堆出来的，产品却是删出来的。一个工具真正的样子，往往不是由它能做什么定义的，而是由它坚决不做什么定义的。需求一旦砍干净，架构也就清爽了。

三、架构：一个编辑器 + 一个“即用即焚”的导出服务

整个系统就两块：一个浏览器SPA负责全部编辑；一个无状态服务只在你点“导出”那一下出现，干完活立刻把一切忘掉。

• 编辑全部在浏览器里，通过File System Access API直接读写本地文件，不上传。
• 导出才把内容送到一个短命的Puppeteer worker：高DPI逐页截图、拼成PPTX/PDF、回吐文件，然后把临时目录删干净。没有数据库，没有对象存储。

这个边界划分很关键：模型/服务端只负责一次性的、可丢弃的计算，状态全在用户本机。 说到底，最硬的隐私承诺，从来不是“我保证不看”，而是让系统压根没有看的能力——能力上的不能，永远比道德上的不愿更让人安心。

四、技术实现：几个我觉得有意思的点

1. 用File System Access API把“本地”做实

要做到“文件不离开本机”又“能自动保存”，靠的是浏览器的File System Access API。它给了两种入口，对应两种真实场景：

• 文件夹模式：你选一个包含 deck.html 和图片资源的目录，NextPPT能读写同级图片、自动回写、保留备份。适合图文混排、资源较多的稿子。
• 单文件模式：直接拖进来一个自包含的 .html，编辑后另存为一份副本，图片以base64内联。适合“就一个文件”的轻量场景。

代价是这套API目前只有Chromium系（Chrome/Edge/Bra ve/Arc）支持，Safari/Firefox还得等。这是个清醒的取舍：与其做一个处处妥协的全兼容方案，不如先把Chromium上的体验做到极致，ZIP兜底以后再说。

2. 沙箱iframe + 强类型postMessage协议

幻灯片本身是别人（AI）写的HTML，里面可能有任意脚本。直接挂到主文档里既不安全、样式又会互相污染。所以每一页都渲染在一个沙箱iframe（srcdoc，origin是 null）里，主应用和iframe之间只通过 postMessage 通信。

通信协议做成了强类型的，编辑这一侧的核心是一组 PatchOp：

export type PatchOp =
  | { kind: 'text'; value: string }
  | { kind: 'attr'; name: string; value: string | null }
  | { kind: 'style'; name: string; value: string | null }
  | { kind: 'class'; add?: string[]; remove?: string[] };

你在属性面板改字号、改颜色、改对齐，本质上都是往iframe发一条 patch 消息，里面带一个由runtime生成的稳定CSS选择器和一串 PatchOp。iframe改完DOM，再把整页最新的outerHTML回吐给主应用。整条链路没有任何“魔法”，就是感知 → 决策 → 行动 → 反馈这个朴素循环，只不过两端隔着一道安全边界：

这里其实最重要的不是协议写得多花，而是把选择器做稳：忽略布局占位符、优先用稳定id，否则patch会打到错的元素上——这种bug比“功能没做”还难查。

3. 实时iframe：自己改的不重载，别人改的才重载

最早天真地以为，每收到一条 patched 就把iframe重新render一遍。结果就是：你刚选中一个元素，handle一闪没了；刚插入一张图，还没来得及拖就被刷掉了。体验稀碎。

后来想明白了：iframe应该是“活的”编辑现场，而不是一块被反复重绘的画布。

于是改成：iframe自己产生的改动（移动、缩放、改字、patch）绝不触发重载；只有“外部原因”才重新挂载——撤销/重做、恢复历史快照、切换页面。判断逻辑就是拿当前HTML和“上一次自己patch出来的HTML”比一下，是自己改的就跳过remount：

if (html !== prevHtmlRef.current) {
  prevHtmlRef.current = html;
  if (html !== lastPatchedHtmlRef.current) setCanvasKey((k) => k + 1);
}

这套“是不是自己改的”判断，画出来就一个分叉：

一个 canvasKey 控制remount，配合“重载后用选择器把选区重新选回来”，体验一下就顺了。这种问题，模型再强也帮不上忙，得靠你对状态边界的工程判断。

4. 编辑/拖动双模式：要PPT的自由，也要不误触的安全

想让每个元素都能像原生PPT那样自由拖动、缩放、删除。但马上就有矛盾：自由变换和“点文字改字”会互相打架——你想改个字，结果手一抖把整块挪走了。

解法是两个严格互斥的模式，顶部中间一个pill切换：

• 编辑模式：只能点选、双击文字行内编辑、用右侧属性面板。没有拖拽handle，绝不会误移。
• 拖动模式：能移动、四角缩放、删除（带handle）。但不能行内改字。

切到拖动模式去拽一个原本在文档流里的元素时，它会自动转成绝对定位（detach-on-grab）。这个边界是产品决策，不是技术限制——宁可让用户多点一下切个模式，也不要让他在“改字”时提心吊胆。

5. 资源解析：blob URL和相对路径的双向翻译

文件夹模式下，图片在磁盘上是相对路径（assets/cover.png），但iframe里要显示得用blob URL。于是维护了一张blob URL ↔ 相对路径的映射表：显示时把相对路径解析成blob，导出/存盘时再翻译回相对路径。

这块踩过一个挺典型的坑，后面“踩坑”那节细说。

6. 历史快照：让用户“永远不怕改坏”

改动会防抖（1.5s）自动回写磁盘，同时在 .hds-backup/ 里留带时间戳的快照。任何时候都能从历史版本里把之前的样子捞回来。

这条看着不起眼，但它解决的是一个心理问题：人只有在“知道自己随时能反悔”的时候，才敢放心大胆地改。⌘Z撤销、⇧⌘Z重做、历史版本，三层兜底，原文件永远不会被你改坏。

7. 导出管线：Puppeteer高DPI截图 → 图片型PPTX/PDF

导出是唯一碰服务端的环节。思路很直白：把每一页当成一张高清照片拍下来，再拼进PPTX/PDF。

为什么是“图片型”而不是去还原可编辑的PPT元素？因为高保真和“PPT里还能改字”是冲突的，而用户的核心诉求是“长得和我的HTML一模一样”。所以选了高保真，明确告诉用户：导出的是图片，想改字回来改完再导一次。

服务端这边几个细节值得一提：

• 超采样控分辨率。幻灯片固定在1280×720画布上，输出清晰度纯靠 deviceScaleFactor 拉：@2x 就是2560×1440，往上能到4K甚至更高。视口不变，缩放因子变。
• 等渲染完成再截图。AI产出的稿子里常有没渲染的Mermaid源码，所以截图前先把页面里未渲染的Mermaid节点跑一遍，再 await document.fonts.ready 等KaTeX/Google Fonts落定，最后冻结所有动画。否则截出来缺图、缺字、动画糊成一团。
• SSE推进度。页数多、页面复杂时导出会慢，用Server-Sent Events把 unpack → screenshot → assemble 的进度实时推给前端，用户不至于对着转圈干等。
• 即用即焚。整个导出在一个 mkdtemp 出来的临时目录里完成，finally 里 fs.rm 删干净；产物丢进一个有10分钟TTL的下载缓存，过期自动清。服务端不持久化任何东西。

一整条导出流水线长这样，文件的“一生”也就这么几十秒：

// 固定1280×720画布，清晰度只由deviceScaleFactor决定
const SCALE_BY_RESOLUTION = {
  '1280x720@2x': 2,  // 2560×1440
  '1920x1080@2x': 3, // ~4K
  '3840x2160@2x': 4, // 5120×2880
};

8. 顺手把工具站做出SEO：SSG + i18n

工具站不能只有一个 index.html 空壳——又想要React的交互，又想要爬虫和分享卡片能拿到真实内容。所以落地页和指南页用 vite-react-ssg 做了静态预渲染，按路径前缀分中英双语（/ 和 /en），每个语言版本都预渲染出带 title、description、canonical、hreflang 的真实HTML。

这部分不算核心功能，但它是长期主义：一个工具想被人用，得先能被搜到、被分享出去时长得体面。

五、怎么用：生成 → 编辑 → 导出，就三步

讲完实现，说说普通用户视角的完整流程。其实一点都不复杂，三步：

第1步 · 让AI帮你做一份。 不会做也没关系，把一段提示词复制给任意AI（ChatGPT、Claude、Gemini、豆包、Kimi都行），把主题换成你的，它会回你一份现成的演示稿文件，存下来就行。官网指南页里直接备好了这段提示词，一键复制。

第2步 · 点一下就能改。 回到 next-ppt.com，用Chrome/Edge打开那个文件（或直接拖进来）。然后就像改PPT一样：点中文字在右边面板改内容/字号/颜色，双击直接在原位敲字，选中图片拖一张新图进去就替换，切到“拖动”还能自由挪位置、拉角缩放。改错了⌘Z，全程自动保存。

第3步 · 一键变PPT / PDF。 点右上角导出，选格式和清晰度，可以只导某几页（1,3-5,8），下载。搞定。整个过程除了导出那几秒，都在你自己电脑上。

六、踩过的几个真实的坑

写工具最有价值的部分，往往是那些README里不会写、但你确实流过血的地方。挑三个印象最深的：

1. 拖动之后，整个版面塌了。 第一版把元素从文档流里“拎出来”变成绝对定位时，它原来占的位置瞬间塌缩，后面的元素全往上挤，于是你一拖第二个，测出来的坐标全是错的——结果就是所有浮动元素叠在了一起。解法是：抽离前先在原位插一个透明占位符（data-hds-placeholder）把空间占住，元素删除或还原自动布局时再回收掉这些占位符。一个很小的trick，但不想到就是天天debug。

2. 存盘存进去一堆“死”的blob URL。 文件夹模式下图片在iframe里是blob URL，一开始直接把这份HTML写回磁盘了——结果下次打开，blob早失效，图全裂了。后来才意识到：存盘必须走和导出一样的“还原相对路径”逻辑，把blob URL翻译回 assets/xxx.png 再落盘。两条路径用同一套还原函数，才算闭环。

3. SSG之后页面出现两个