pptx 撑不过 agent 时代，PPT 的终点可能是 HTML
周一晚上刷 X，看到向阳乔木发了条推，基于 bento PPT 改了一个 skill，输入内容或主题，自动生成可编辑、可在线演示、还能发给别人协作的 HTML PPT，一行命令安装。
推文下面照例是一排「马住」「感谢分享」。我的第一反应不太一样，AI 生成 PPT 这个赛道我看过太多 demo 了，十个里九个的终点是一堆好看但改不动的静态页面。真正稀缺的从来不是「生成」，是生成之后你能不能接着改、接着用、接着交付。
所以我没马住，直接把仓库拉下来跑了。
跑完的结论先放这，这个 qiaomu-bento-ppt 的价值不在「一句话出 PPT」，那是营销层。真正有点子牛逼的是它底下那套工程设计，我实测的时候被它的校验器连续打回三轮，被拒得越狠，我越觉得这东西做对了。
先交代下背景。skill 这个词圈外朋友可能陌生，你可以理解成给 AI 助手装的「专项技能包」，一个文件夹，里面装着操作手册和配套脚本，装上之后你的 Claude Code 或者 Codex 就多了一门手艺。这两年 agent 生态里 skill 已经卷成了一个小市场，做 PPT 的 skill 尤其多，因为这是打工人最真实的痛。
向阳乔木这个包是基于 nyblnet/bento 这个开源项目改的。bento 本身挺妙，它把一个 PPT 的全部家当，文档数据、渲染器、编辑器，全部塞进一个 HTML 文件。你双击这个文件，浏览器里打开的不是一张静态预览图，是一个完整的编辑器，能改字、能拖元素、能放映、能写演讲者备注。发给同事，同事改完存盘发回来，全程不需要装任何软件，不需要登录任何云服务。
仓库 7 月 25 号才建，我跑的时候已经 48 个 star 了，README 里那句话写得很直白，AI 做 PPT 最常见的失败，是交付一堆静态文字页。
冲这句话，值得花一个晚上。
安装是真的一行命令，npx skills add joeseesun/qiaomu-bento-ppt。装完跑它自带的 locate 检查，返回 standalone true，这里藏着第一个好评点。它把上游 bento 的运行时 shell、官方格式规范、构建脚本全部打进了包里，锁死版本，生成 PPT 的全程不联网、不要 API key、不依赖你另外去 clone 什么东西。做过工程的都懂这有多难得，多少开源项目的第一步是「先配好这八个依赖」，然后你就卡在第三个上过不去了。
然后我干了一件蠢事，我决定不让 AI 代劳，自己手写一份 deck 的 JSON 喂给它，看看这套流水线的底层长什么样。
它的数据格式是这样的，一个 deck.json，里面每一页幻灯片是一组绝对定位的元素，文本、形状、表格，坐标铺在 1280 乘 720 的画布上。我照着官方示例攒了一个四页的小 deck，封面、一张四个 CLI 编码工具的对比表、一页金句、一页收尾，前后写了十几分钟，然后信心满满地跑构建脚本。
啪，打回来了。二十多个 error。
校验器告诉我，每个元素的 rotation、opacity、fontFamily、valign、lineHeight 全是必填，形状少了 radius 不行，页面少了 transition 不行。我写惯了前端那种「能省则省、缺了给默认值」的宽松风格，在这全部撞墙。
行，我写了个小脚本把默认值全补上，第二轮。
又打回来了。这次的理由让我愣了几秒，speaker notes string is required，而且空字符串不算数。它强制要求每一页幻灯片都写一段非空的演讲者备注。也就是你不光要做出这页 PPT，你还必须写清楚，这一页你打算讲什么。
第三轮，表格缺一个 style 对象，继续拒绝。我从官方示例里把表格样式抄过来，再跑。
ok true，0 error，0 warning。产物是一个 604KB 的单文件 HTML，构建耗时 0.27 秒，纯本地脚本，一个 token 都没花。
Chrome 里打开的瞬间我是有点被打动的。左边是页面缩略图，顶上是工具栏，文本形状图片表格图表一应俱全，右边属性面板，底下放映按钮，我写在 JSON 里的那句演讲者备注就安安静静躺在右下角。这不是一个「导出结果」，这是一个活的文档。
说真的，被打回三轮的时候我是有点烦躁的。但摊开想一下就明白了，这套严格是故意的，而且严格的对象根本不是我。
这个 skill 预设的使用者是 AI，不是人。人写 JSON 会烦，AI 不会。而 AI 生成内容最大的毛病恰恰是「差不多先生」，字段少一个也能跑，渲染出来歪一点也不报错，最后所有的模糊都堆积到你打开文件的那一刻爆发。这套全量字段加强制校验的设计，等于把「差不多」三个字从流水线里物理删除了。校验器就是给 agent 立的规矩，宽进严出，错误当场打回，agent 拿着错误信息自己改，改到零错误为止。
强制演讲者备注那一条我后来品出味道了，那其实是在逼生成方交代「这页的叙事意图」。一页 PPT 有没有灵魂，差别就在做它的人（或者 AI）有没有想清楚这页要讲什么。这个字段空着，多半是没想。
它的完整工作流也是这个思路，先产一份 deck-plan.md 讲清楚受众、结论、叙事弧，再生成 JSON，再构建，再出一份机器验证报告，最后还要求在真实浏览器里过一遍视觉验收。README 里有句话我想给它鼓掌，脚本通过不等于视觉正确，没打开浏览器看过，就必须标记 missing evidence。
做工程的朋友应该已经反应过来了，这不就是 CI/CD 那一套吗。计划评审、构建、自动化测试、人工验收，一个环节不许跳。只不过这次流水线的产物不是服务，是 PPT。
还有一个细节我专门测了一下。每个 deck 有一个 docId，相当于文档的身份证。我把生成的文件 extract 回 JSON，手动篡改 docId 再构建，直接被拒，提示身份不匹配，让我先恢复原始身份。这是在防什么呢，防的是 AI 编辑文件时最阴险的那类事故，你让它改两个字，它顺手给你重新生成了一份看起来一样但身份全新的文档，历史、批注、协作关系全断。编辑必须继承身份，新建才发新证，UUID 只发一次。
好家伙，一个做 PPT 的工具，把配置管理的活都干了。
聊到这里可以回答那个更大的问题了，为什么我觉得这个方向，HTML 加纯文本数据，可能才是 agent 时代 PPT 的正确形态。
你想想 pptx 是什么，一个 zip 包，里面塞着一堆 XML 和媒体文件，格式规范几千页，人类不可读，diff 不可看，改一个字得靠 Office 或者 python-pptx 这种库小心翼翼地操作。它是为「人拿鼠标拖」这个交互设计的上一代容器，AI 在里面干活，就像戴着拳击手套绣花。
而 bento 这个路线里，PPT 的「源代码」是一份结构化 JSON，明文、可 diff、可进 git、可以让 AI 直接读直接改，改完有校验器把关，渲染器负责把它变成好看的样子。数据和表现分离，程序员看到这个结构只会觉得眼熟，这不就是我们写了十几年的前后端分离吗。
其实这个思路也不算凭空冒出来。写代码的朋友可能用过 Marp 或者 Slidev，用 Markdown 写幻灯片，也是纯文本路线。但那条路线的产物是「开发者风格」的演示文稿，样式天花板比较低，也没法发给不写代码的同事协作。bento 补上的正是这两块，视觉上限拉到了设计感封面的水平，协作上限拉到了「对方双击就能改」。
unix 哲学里最长寿的一条是一切皆文本，五十年过去，活得最久的格式全是纯文本家族的，代码、Markdown、JSON、配置文件。二进制黑盒们则一代代地死于不可读。PPT 可能是办公三件套里最后一个被「文本化」的，现在轮到它了。
当然，实测下来坑和边界也得说清楚。
手写 JSON 是真的苦，我那四页从动笔到过校验折腾了三轮，这个格式就不是给人徒手写的，老老实实让 agent 代劳，人负责提需求和验收。向阳乔木自己也提示了，生成质量吃模型的前端审美，他推荐 Kimi K3 或者 Opus 4.8 往上，审美差的模型出来的排版据说挺惨烈，这个我没逐个试，不下结论。
离线承诺有边界，你要是在 deck 里引了外链图片或视频，断网就露馅，想要真离线得把媒体转成内嵌数据。上游 shell 是锁死版本的，不自动升级，好处是稳定，代价是新特性得等维护者验证后手动同步。还有，这玩意再好，你司要是规定汇报必须交 pptx 原件，那它暂时只能当你的「草稿加速器」，导出这条路还没通。
最后还有个朴素的问题，多人协作靠互传文件加改完存盘，这是网盘时代的协作粒度，比不了在线文档的实时光标。单文件的自由和云端的实时，目前还是二选一。
但瑕不掩瑜。我今晚花掉的这一个多钟头，大部分时间不是在跑工具，是在围观一个想得很清楚的设计，什么该严（数据契约、文档身份、验收证据），什么该松（零依赖、离线、双击就能用）。严的全在机器侧，松的全在人侧。
很多 AI 工具的取向是反过来的，对人严，要你学它的提示词姿势、伺候它的环境依赖，对机器松，生成的东西对不对全靠缘分。哪种取向能走远，我觉得不难判断。
回到开头那条推。下次再刷到「一句话生成 PPT」，你可以多问一句，生成完之后呢，能改吗，能验吗，能交付吗。这三个问题，比 demo 视频里那三秒钟的惊艳诚实多了。
仓库在 GitHub，MIT 协议，向阳乔木的更多实践在他的个人站。这周要做汇报的兄弟，今晚可以试试，反正被校验器打回的时候，烦的又不是你，是你的 agent。