开篇：一个数字引发的讨论
2026年7月22日，Hacker News上出现了一个帖子：“Show HN: Bento —— 整个PowerPoint装在一个HTML文件里”。8小时内，它收获了591个赞和141条评论。这个数据本身就是一个信号——在聚集了全球最苛刻技术读者的社区里，一个项目能获得这样的关注，说明它触碰到了某种真实的需求。
笔者打开链接，看到一个浏览器标签页，里面是一套完整的幻灯片编辑器。有工具栏、有缩略图侧栏、可以打字、画形状、插入图表、添加注释。你按Esc进入编辑模式，按箭头播放演示，按S打开演讲者视图。看起来没什么特别的——除了一个事实：这个编辑器不是一个网站，也不是一个App，它就是一个HTML文件。
图：Bento Slides的编辑界面。顶部工具栏、左侧缩略图、主编辑区和底部导航，和主流幻灯片软件无异，但这一切运行在一个560KB的HTML文件中。
“文件就是软件”
这句话是Bento项目的核心信条。笔者在GitHub上找到了它的完整代码——项目名为bento，作者是starfallg，MIT开源协议。
我们来做个比较。一个标准的PowerPoint .pptx文件是一个压缩包，里面包含XML、图片、音频等资源，但它本身不能运行——你需要安装PowerPoint软件（或者用网页版Office 365），才能打开和编辑它。Microsoft 365个人版一年的订阅费用是数百元人民币，安装包动辄几个GB。
而Bento的做法恰好颠倒过来：它把软件装进了文件里。
打开bento.page/slides，浏览器里直接出现了一个完整的幻灯片编辑器。你可以在这个”页面”上创建内容、调整布局、添加动画。最令人惊讶的是，按Ctrl+S保存的时候，这个HTML文件会把自己重写一遍——你编辑的内容被写回了它自身。下一次你双击这个文件，它打开的还是那个完整的编辑器，带着你上一次保存的所有内容。
笔者用文件体积做了个对比：
| 项目 | 体积 | 是否需要安装额外软件 |
|---|---|---|
| Bento默认演示文稿 | ~560 KB | 不需要，浏览器即可 |
| PowerPoint安装包 | 3-5 GB | 需要安装 |
| Keynote安装包 | 约1.5 GB | 需要安装 |
| Google Slides网页版 | 依赖网络加载 | 需要登录和联网 |
差距是几千倍的。这个对比本身就构成了一个需要回答的问题：为什么一个演示文稿需要几GB的软件来支持？
拆开那个文件看看
为了理解Bento为什么能做到这么小，笔者查看了它的文件结构。一个.bento.html文件从外到内分为几个层次。
最外层是一个合法的HTML文档。它有DOCTYPE声明、有<head>和<body>。这意味任何浏览器都能打开它。但它的内部结构不同寻常。
文件的头部附近有一个<script>标签，id是”bento-doc”，类型是”application/bento+json”。这里面以纯文本JSON格式存储着幻灯片的所有数据——每一页的内容、每个元素的位置和大小、颜色、字体、动画设置。你可以直接在浏览器里用”查看源代码”看到它，格式可读。
这个设计有一个深远的好处：数据和代码分离，但共存于一个文件中。AI工具可以直接读取和修改这个JSON块；开发者可以直接用文本编辑器搜索和替换内容；版本控制工具可以逐行比较差异。
文件的其余部分，也就是真正的”软件”，存储在一个压缩过的JavaScript代码块里。这套代码包含了几个关键部分：基于Reveal.js的演示引擎、一套自研的动画系统、一套自研的图表绘制引擎，以及Vue驱动的编辑器界面。在v0.7.0版本之前，Bento使用GSAP做动画、ECharts做图表。作者后来将它们全部替换成了自研方案，理由很直接：为了把文件体积从1.3MB压缩到560KB。
图：Bento在GitHub上的项目主页，260次提交、389颗星，显示着这个项目活跃的开发节奏。MIT许可证意味着任何人都可以自由使用和修改。
一张白纸与一套瑞士军刀
如果要用一个比喻来描述Bento的设计思路，笔者能想到的最贴切的画面是：一张白纸里面，藏着一套完整的瑞士军刀。
传统的办公软件模式是”先买工具，再做东西”。你要做幻灯片，得先安装PowerPoint（或买一台Mac用Keynote），然后才能在软件里新建文件。文件本身是脆弱的——如果你把.pptx发给一个没有安装Office的人，他打不开。
Bento的模式是”做好的东西本身就是工具”。你从bento.page/slides下载一个HTML文件，你得到的是一个”演示文稿壳”。你在里面创作，保存后，这个文件就变成了一个自包含的演示文稿——它既是内容，也是打开内容所需的全部工具。
你把这个文件通过微信、邮件或AirDrop发给同事，他双击打开，看到的就是你的幻灯片——可以直接演示、可以直接编辑。不需要任何额外的安装步骤，不需要注册任何账号。
这种体验的差异，用一个简单的场景就能说明：
假设你是一个项目经理，做好了一份季度汇报PPT。你把文件发给老板，老板在手机上打开——在传统模式下，他大概率看到的是”无法打开此文件”或格式错乱。而在Bento的模式下，他只需要有一个浏览器，就能看到和你设计时完全一致的排版、动画和图表。
协同编辑：加密盲转发的设计巧思
更让人感兴趣的是Bento的协同编辑功能。笔者一开始的疑惑是：一个HTML文件怎么能支持多人同时编辑？数据存在哪里？
答案是：数据存在文件里，编辑通过一个经过加密的”盲转发”通道同步。
当你在Bento中开启协同会话时，文件会在本地生成一套加密密钥。你邀请的协作者拿到的是同一个文件副本（以及嵌入其中的密钥）。每个人的编辑操作会被加密，然后发送到一个运行在Cloudflare Durable Objects上的中转服务器——这个服务器只做一件事：把收到的加密数据转发给房间里的其他人。
这个中转服务器被设计成”盲”的——它传递的是密文，服务器本身无法读取你的任何内容。它看不到你的文字、图表、图片，甚至看不到你的名字。它只是一个加密数据的搬运工。
同步引擎采用了CRDT（无冲突复制数据类型）技术。这是分布式系统里一种被广泛研究的方法，允许多人同时编辑同一份数据，而不需要一个中心服务器来裁定”谁的修改是最终的”。Bento的CRDT是自研的，作者在HN的讨论中特别提到：“我最满意的就是CRDT的流畅度。”
还有一个贴心的设计：离线编辑。你可以在没有网络的情况下修改幻灯片，等连接恢复后，你的修改会自动与团队同步。CRDT保证了合并的正确性——不会出现”你改的覆盖了我改的”这种情况。
一个父亲在业余时间做的项目
在HN的评论区，笔者看到了一些有趣的背景。有人问作者花了多长时间、用了多少AI辅助。作者starfallg的回答是：“上周开始的，利用业余时间，全部通过Claude Code完成。我其实很想像以前那样手写代码，但我在一家可再生能源公司带技术团队，下班还要带学龄前的孩子，实在没时间。”
这段话透露了几个信息：Bento的主要代码是由AI辅助生成的（作者使用了Claude Code），整个项目从构思到发布大约只用了一周多的业余时间，作者本人是技术管理者，日常工作与办公软件无关。
这或许可以解释为什么Bento的设计思路与传统办公软件如此不同——它没有背负”兼容旧格式”的历史包袱，也没有”我们必须设计得和Office一样”的路径依赖。它是从”一个开发者真正需要什么”的角度出发的产物。
560KB的边界与局限
当然，作为一个诞生仅一周多的项目，Bento有它的局限。笔者在试用中注意到几个方面：
首先，它目前只适合制作中等复杂度的演示文稿。如果需要非常精细的排版控制、复杂的母版设计、或者大量高分辨率图片的处理，传统工具仍然更成熟。
其次，它的协同编辑目前依赖作者的Cloudflare账户提供的中转服务。虽然作者表示”成本很便宜，完全在预算范围内”，但这也意味着如果大量用户同时使用，服务稳定性可能存在变数。不过，由于代码完全开源，任何团队都可以部署自己的中转服务器。
第三，它的文件格式目前是专有的JSON结构。虽然源码开放、格式可读，但与.pptx格式之间没有直接的互转通道。作者提供了一个思路：把.pptx交给AI，让AI根据Bento的格式规范重新生成。
这个项目的真正意义
如果仅仅把Bento看作一个”替代PowerPoint的工具”，笔者觉得有些浪费了它背后的思考。Bento更有价值的追问是：在一个AI可以写代码的时代，软件的分发方式是否需要被重新思考？
传统软件的分发模式——下载安装包、安装运行时依赖、注册账号、登录云服务——这套流程对于越来越多的轻量级工具来说，可能已经是过度的。Bento给出了另一种答案：把软件和内容融合成一个文件，用浏览器作为运行环境，让文件本身具备不需要任何基础设施的”自运行能力”。
这种思路其实并不新鲜。二十多年前的TiddlyWiki就尝试过类似的方式——一个自包含的HTML文件，既是Wiki引擎又是Wiki内容。TiddlyWiki至今仍有一批忠实用户，但它始终没有进入主流视野。
但时代可能不同了。浏览器的能力今非昔比（File System Access API让网页应用可以直接读写本地文件，WebCrypto API提供了浏览器级的加密能力），现代前端工具链让构建复杂单页应用变得更加高效，而AI辅助编码大幅降低了实现这类想法的技术门槛。Bento恰好站在了这些趋势的交汇点上。
笔者在HN的评论区看到一条评论，大意是：“这项目是对Google Workspace团队在AI时代无所作为的绝佳控诉。“无论这种评价是否公允，Bento确实提出了一个值得思考的问题：当560KB的HTML文件已经能完成一个演示文稿的编辑、展示、协同全流程时，我们真的需要几百GB的Office套件和按月付费的云服务吗？
答案也许不是简单的”是”或”否”。现实世界中的大多数用户可能既需要Bento的轻便简洁，也需要传统办公软件的稳定性和生态兼容。但Bento的存在，至少让人看到了另一条路的可能性——一条更轻、更自由、更”属于自己”的路。
参考链接：格式
- Show HN：Bento —— Hacker News原帖及讨论（591赞，141评论）
- Bento项目GitHub仓库 —— nyblnet/bento，MIT协议，260次提交
- Bento/Slides在线演示 —— 打开即用的编辑器，内置功能展示幻灯片
- Bento官方网站 —— Templates Gallery和项目介绍
- TiddlyWiki —— 自包含HTML文件的Wiki系统，Bento设计思路的前辈
- Reveal.js —— 开源HTML演示框架，Bento的底层渲染基础
- Cloudflare Durable Objects —— Bento协同中转服务的基础设施
- File System Access API —— 使Bento能够”自我保存”的浏览器API
