HTML PPT 可以继续改了,设计交付也该从'定稿'变成'可接管'

最近，一个名为 qiaomu-bento-ppt 的开源项目把演示稿做成独立的 .bento.html 文件：浏览器可直接打开，内容可编辑，也能离线运行。它还保留 deck plan、JSON 和验证产物，并把浏览器中的视觉检查写进工作流。

先把边界说清楚：这只是一个具体项目展示出的能力，不代表所有 HTML PPT 都能稳定替代 PowerPoint、Keynote 或 PDF。可它揭示了一个更值得设计师关注的变化：当交付物本身可以继续运行、修改和检查，设计交付就不该只围绕“最终画面”，而要围绕“别人能否接管”。

传统演示交付常见三种状态：PDF 负责展示，PPT 或 Keynote 负责继续编辑，源素材散落在设计师自己的目录里。接收方拿到文件以后，能不能改，往往取决于字体是否安装、图片是否缺失、母版是否混乱，以及设计师有没有空解释。

HTML 演示看上去解决了这个问题。文本、布局和交互都留在文件里，浏览器又是普遍存在的运行环境。但“能改”与“敢改”之间还有很长一段距离。

接手者不知道一页为什么这样排，就不敢调整结构；不知道哪些样式是全局规则，就只能逐页修补；不知道图片来自本地还是外链，就无法判断离线是否可靠；没有验收标准，也无法确认一次修改有没有破坏其他页面。

所以，可编辑是文件属性，可接管才是交付质量。

— 图解：可编辑文件与可接管系统的区别

一份可接管的 HTML 演示，首先要让人看见内容结构。

至少说明三件事：整套演示的叙事顺序、每一页的角色、哪些元素由全局规则控制。像 deck plan 这样的中间产物之所以重要，不是因为它更“技术”，而是它把隐藏在画面背后的判断显性化了。

可以把结构层压缩成一张清单：

这张清单不需要解释每一个像素。它的作用，是让接手者知道哪些可以批量改，哪些不能随手动。

“单文件、离线可用”是很有吸引力的承诺，但它很容易被外部资源悄悄破坏。一张引用网络地址的图片、一个在线字体、一个远程脚本，都可能让文件在演示当天变样。

交付前应把资产分成三类：

如果必须保留外部依赖，就不要继续写“完全离线”。准确说明条件，比给出一个漂亮但经不起现场检验的承诺更专业。

版权信息也属于资产层。可编辑不等于可任意复用。来源、授权范围和替换建议，应该和素材一起进入交付包。

结构化生成的一个优势，是可以检查缺页、字段、画布尺寸、文本溢出风险或文件引用。但通过这些检查，并不等于画面正确。

自动验证擅长回答“有没有”：有没有规定页数、有没有缺少标题、有没有找不到的资源。视觉 QA 要回答“好不好”和“对不对”：层级是否清楚、换行是否难看、图表是否误导、动画是否抢信息、不同浏览器里是否仍然成立。

建议保留两张表：

尤其要用真实最长标题、最复杂数据和最差网络条件检查。占位内容通过，不代表最终内容也能通过。

— 图解：机械验证与视觉 QA 要走两条轨道

可接管交付不需要写厚厚的操作手册。一份短 README 通常就够了：如何打开，哪里改全局样式，如何新增或删除页面，如何重新验证，已知限制是什么。

再加一条变更规则：修改什么之后必须重新检查什么。比如改字体后检查换行，替换图片后检查裁切，新增页面后检查导航，调整动效后检查减弱动画设置。

这会把验收从“设计师最后看一眼”，变成任何接手者都能重复执行的过程。

— 图解：结构、资产、验证、说明构成四层可接管交付

如果交付只是一次性汇报，需要严格锁版，或者接收方没有维护 HTML 的能力，那么 PDF、PPT 和 Keynote 仍然可能是更低成本的选择。格式没有高低，只有是否匹配后续使用方式。

但只要一份演示要长期更新、多人协作、批量替换内容，或继续承载交互，可接管就比定稿更重要。此时设计师的责任也会扩大：不只控制最后一帧，还要组织结构、依赖和验证方法。

下一次交付可运行的设计，不妨先问四个问题：结构能看懂吗，资产能找到吗，结果能验证吗，别人能继续改吗？四个答案都明确，文件才真正离开了设计师，也真正进入了团队。

微笑面对设计｜关注 AI 如何改变设计流程，也关心一份设计离开作者之后能否继续工作。