我放弃了PPT,用写代码的方式搞定了一份惊艳的“单文件”演示文稿
- 2026-06-28 10:59:32
🍃作者介绍：AI 应用负责人/AI产品架构师，阿里云专家博主。专注 LLM 应用开发、Agent 系统设计、具身智能与工业 AI 落地。日常在大模型训练、Coding Agent 工具链、AI 产品商业化等方向持续输出实战内容。
🐼GitHub主页：https://github.com/XZL-CODE
文章目录
1、前言
2、快速上手：最终怎么使用
3、整体思路：先定风格，再做内容，最后打包
4、目录结构：为什么每页单独一个 HTML
5、运行架构：它为什么能像 PPT 一样翻页
6、自适应缩放：为什么 4K 屏不会小成一块
7、视觉层：为什么 HTML 反而更好看
8、制作过程：AI 适合做什么，人必须守什么
9、最终打包：为什么不要直接 cat 合并
10、这个方案适合什么，不适合什么
11、我对这套工作流的总结
1、前言
最近我需要针对“企业级 AI 混合云参考架构”和“AI 原生研发”这类偏复杂的技术主题，准备一份演示材料。内容本身比较重：既有混合云、数据不出域、大模型网关，也有 Vibe Coding、SDD、机密推理这些概念。
按照以往经验，这类材料大概率会直接做成 PPT。但真正做起来，会遇到几个很典型的问题：
1. 复杂架构图在 PPT 里很难长期维护，改一个框、挪一条线，经常牵一发动全身。 2. 代码、流程、表格、架构图混在一起时，PPT 的排版自由度反而变成负担。 3. 如果希望有统一主题、响应式缩放、键盘翻页、全屏演示、最终一份文件分享，传统 PPT 工作流不一定舒服。
所以这次我换了一个思路：用 HTML 来做类似 PPT 的演示文稿。
不是把网页写成文章，也不是把 PPT 截图贴进网页，而是做一个“HTML Slide Deck”：每一页是一份独立 HTML，外面有一个播放器 index.html 统一加载、翻页和控制；等内容全部沉淀好之后，再用 JS 脚本把几十份 HTML、CSS、JS、SVG 全部打包成一个最终单文件 HTML。
这篇文章就复盘这个过程，重点讲清楚三个问题：
1. 为什么 HTML 可以更适合复杂技术演示？ 2. 这套结构怎么设计，才能既好看又好维护？ 3. 为什么开发阶段要多文件，交付阶段要单文件？
2、快速上手：最终怎么使用
先说结果，不先讲原理。
这套方案最终会得到一个可以直接双击打开的 HTML 文件：
终稿html/
└── AI架构演示_单文件版.html打开以后就是一个横向演示文稿：
重新打包也很简单：
node scripts/build-single-html.mjs执行后脚本会读取当前所有页面，重新生成最终单文件版。
这就是我认为它比传统 PPT 更方便的地方：开发阶段像前端工程，交付阶段像一个普通文件。
3、整体思路：先定风格，再做内容，最后打包
我的整体流程可以归纳成一条生产线。
3.1、第一步：先用 AI 出配色和视觉参考
不要一上来就写 40 页内容。
如果主题、配色、排版基调都没定，越往后改成本越高。我更推荐先让 Codex / Claude Code 这类 Coding Agent 帮你输出几套视觉方向，比如：
• 深色科技风 • 暖色咨询风 • 浅色纸面网格风 • 极简白底风 • 数据报告风
这一步 AI 很擅长，因为它可以快速生成多套 CSS token、组件样式和页面原型。
但最终不要完全交给 AI 拍板。视觉风格一定要人工确认，因为演示文稿不是“代码能跑就行”，它还要符合听众、场景和内容气质。
我这次最终选择的是偏浅色、暖陶、灰绿纸面、低饱和网格背景的风格。原因很简单：这份演示材料本身已经很重，如果再用大面积深色、高对比、强科技风，听众会更累。
3.2、第二步：基于原型固定播放体验
定完风格之后，再做一个最小播放原型：
index.html
assets/
deck.css
slide.js
slides/
01-cover.html
02-agenda.html
slides-manifest.js这个原型只需要解决几个核心问题：
1. 能不能全屏展示一页？ 2. 能不能键盘翻页？ 3. 页面在 1080P、2K、4K 下会不会过小或溢出？ 4. 每一页是否可以独立打开调试？ 5. 后面能不能被脚本打成单文件？
只要这个原型稳定，后面 10 页、30 页、50 页，本质都是往这个结构里加内容。
3.3、第三步：规划每一页呈现什么
做演示文稿最怕的是“内容堆叠”。
HTML 的自由度很高，但也更容易写成一篇网页文章。所以我给自己的规则是：
一页只讲一个核心判断。
比如：
• 这一页只讲“为什么混合云不是反云” • 这一页只讲“大模型网关为什么是战略咽喉” • 这一页只讲“SDD 的全称和核心反转” • 这一页只讲“机密推理为什么不是简单的传输加密”
先把每页的观点规划好，再写 HTML。否则再漂亮的页面，也只是信息噪音。
4、目录结构：为什么每页单独一个 HTML
我的目录结构大概是这样：
deck/
├── index.html
├── slides-manifest.js
├── assets/
│ ├── deck.css
│ └── slide.js
├── slides/
│ ├── 01-cover.html
│ ├── 02-agenda.html
│ ├── 10-m1-divider.html
│ ├── 11-the-shift.html
│ └── svg/
│ ├── 21-arch-overview.svg
│ └── 54-spec-funnel.svg
├── scripts/
│ └── build-single-html.mjs
└── 终稿html/
└── AI架构演示_单文件版.html这里最关键的选择是：每一页都是一份独立 HTML。
4.1、独立页面更适合迭代
如果把所有页面都写在一个巨大 HTML 里，刚开始会觉得省事，但后面会很痛：
• 找某一页很麻烦 • 修改某一页容易影响全局 • 单页截图、单页调试不方便 • AI 修改时上下文更混乱 • 版本 diff 会非常大
独立页面的好处是，每次只改一页：
<!DOCTYPE html>
<htmllang="zh-CN">
<head>
<metacharset="UTF-8">
<metaname="viewport"content="width=device-width, initial-scale=1">
<title>封面</title>
<linkrel="stylesheet"href="../assets/deck.css">
</head>
<bodyclass="slide-page">
<sectionclass="slide center cover">
<!-- 当前页内容 -->
</section>
<scriptsrc="../assets/slide.js"></script>
</body>
</html>这一页自己可以打开，放进播放器里也能展示。
4.2、统一 CSS 保证整体一致
每页独立，不代表每页各写一套风格。
所有页面都统一引用：
<linkrel="stylesheet"href="../assets/deck.css">deck.css 里放的是设计系统：
• 背景色 • 字体 • 标题层级 • 卡片 • 表格 • callout • SVG 容器 • 响应式缩放基础
这样每页只负责内容结构，不需要重复定义视觉规范。
4.3、manifest 决定页序
页面顺序不要靠文件名猜，也不要靠目录排序。
我用 slides-manifest.js 显式管理：
window.DECK_SLIDES = [
{ f: "01-cover.html", t: "封面" },
{ f: "02-agenda.html", t: "议程" },
{ f: "10-m1-divider.html", t: "模块 01 · 为什么必须是混合云" },
// ...
{ f: "99-closing.html", t: "小结 & 讨论" },
];这样做有两个好处：
1. 中间插页不用改一堆文件名。 2. 打包脚本可以严格按 manifest 顺序生成最终文件。
5、运行架构：它为什么能像 PPT 一样翻页
这套方案的运行方式可以理解成：
外层
index.html是播放器，内层slides/xx.html是当前幻灯片。
5.1、外层播放器负责翻页
index.html 里有一个全屏 iframe：
<iframeid="stage"title="slide"></iframe>翻页时并不是滚动页面，而是切换 iframe 里加载的 HTML：
functiongo(k) {
i = Math.max(0, Math.min(n - 1, k));
stage.src = "slides/" + slides[i].f;
pgnow.textContent = pad(i + 1);
prog.style.width = ((i + 1) / n * 100) + "%";
}所以它的体验更接近 PPT：当前屏幕永远只有一页。
5.2、键盘翻页靠 keydown 事件
外层播放器监听键盘：
document.addEventListener("keydown", function(e) {
var k = e.key;
if (k === "ArrowRight" || k === "PageDown" || k === "ArrowDown" || k === " ") {
e.preventDefault();
next();
} elseif (k === "ArrowLeft" || k === "PageUp" || k === "ArrowUp") {
e.preventDefault();
prev();
} elseif (k === "Home") {
go(0);
} elseif (k === "End") {
go(n - 1);
} elseif (k === "f" || k === "F") {
fs();
}
});这就是 空格、方向键、F 全屏这些能力的来源。
5.3、iframe 里的页面也能通知外层翻页
有一个细节：如果用户点了一下幻灯片内容，焦点可能进入 iframe。此时键盘事件会先被内层页面捕获。
所以每一页也引入 slide.js，它会把翻页动作转发给父级播放器：
functionsend(dir) {
if (window.parent && window.parent !== window) {
window.parent.postMessage({ deck: "nav", dir: dir }, "*");
}
}外层收到消息后再执行真正的翻页：
window.addEventListener("message", function(e) {
var d = e.data;
if (d && d.deck === "nav") {
handle(d.dir);
}
});这就是为什么你点进页面之后，键盘仍然能继续翻页。
6、自适应缩放：为什么 4K 屏不会小成一块
做 HTML 演示最容易翻车的点是：在不同屏幕上比例不对。
如果只写固定宽度，比如 width: 1200px，在 4K 屏上会显得很小；如果完全流式布局，复杂架构图又可能被挤乱。
所以我采用的是“固定页面结构 + 根据视口缩放”的思路。
核心逻辑在 slide.js 里：
var availableW = window.innerWidth - padX;
var availableH = window.innerHeight - padY;
var neededW = Math.max(slide.scrollWidth, rect.width);
var neededH = Math.max(slide.scrollHeight, rect.height);
var scale = Math.min(
availableW / neededW,
availableH / neededH,
maxScale
);
slide.style.transform = "scale(" + scale.toFixed(4) + ")";它的含义是：
1. 先看浏览器现在有多大。 2. 再看当前 slide 自然状态下需要多大。 3. 计算一个不溢出的缩放比例。 4. 用 transform: scale(...)把整页放大或缩小。
这和普通响应式网页不太一样。
普通网页追求内容随屏幕重排；演示文稿更追求“版面关系稳定”。所以对复杂图表页来说，缩放比重排更可靠。
7、视觉层：为什么 HTML 反而更好看
PPT 当然能做得很好看，但 HTML 有几个天然优势。
7.1、CSS 变量能形成真正的主题系统
比如：
:root {
--bg: #D9E0D7;
--surface: #FFFFFF;
--ink: #241F1A;
--muted: #8B8073;
--accent: #C15F3C;
--gold: #B5832F;
--sage: #5F8463;
}有了这些 token，页面里的卡片、表格、按钮、标签、图示都能共享同一套语义颜色。
这比每个 PPT 元素单独吸色更稳定。
7.2、SVG 很适合做复杂架构图
我这次大量图都用 SVG，而不是截图。
原因是：
• SVG 清晰，不怕放大 • 文本可控 • 线条、箭头、分层结构更适合架构图 • 可以直接被 HTML 引用 • 最后也能被脚本内联到单文件里
尤其是混合云、网关、机密推理、SDD 工作流这类图，SVG 的可维护性明显更好。
7.3、组件化样式让页面更统一
比如所有卡片都使用 .card：
.card {
background: var(--surface);
border: 1px solid var(--line);
border-radius: var(--radius);
padding: 16px17px15px;
box-shadow: var(--shadow);
}所有表格都使用同一套 .tablewrap。
所有重点提示都使用 .callout。
这样后面新增页面时，只要复用这些组件，视觉就不会散。
8、制作过程：AI 适合做什么，人必须守什么
这个过程中，AI 很有用，但不能把所有判断都交给 AI。
8.1、AI 适合做发散和机械实现
我会让 Codex / Claude Code 做这些事：
• 输出几套配色参考 • 生成页面原型 • 根据讲稿拆分页面结构 • 写 SVG 架构图 • 调整 CSS 细节 • 写打包脚本 • 做关键词扫描和格式检查
这些工作要么偏发散，要么偏机械，要么偏重复，AI 的效率很高。
8.2、人必须守住内容判断和最终审美
但这几件事必须人来拍板：
1. 这页到底讲什么？ 2. 这个观点是否准确？ 3. 哪些概念必须展开解释？ 4. 图是否真的帮助理解？ 5. 视觉风格是否适合听众？ 6. 这页是否信息过载？
比如这次做 SDD 部分时，我就刻意把 SDD 写成 Spec-Driven Development，规范驱动开发，把 Spec 解释成 specification，规格说明 / 规范说明。因为对技术听众来说，不是不能出现英文缩写，而是不能只丢缩写不解释。
这就是我对 AI 参与内容生产的基本判断：
AI 可以加速表达，但人要负责判断。
9、最终打包：为什么不要直接 cat 合并
很多人第一反应可能是：
cat slides/*.html > all.html这个思路不行。
因为每个 slide 文件都是完整 HTML，它们都有：
• <!DOCTYPE html>• <html>• <head>• <body>• CSS 引用 • JS 引用
强行拼接会变成一个不合法的 HTML 文件，样式和脚本也会混乱。
正确方式是：把每一页当成数据，交给一个播放器运行。
9.1、开发阶段使用多文件
开发时保持：
index.html
slides/*.html
assets/deck.css
assets/slide.js
slides/svg/*.svg这样最好改、最好调、最好让 AI 分页处理。
9.2、交付阶段使用单文件
等全部内容确认后，再打包成：
终稿html/xxx_单文件版.html打包脚本做几件事：
1. 读取 slides-manifest.js2. 按页序读取 slides/*.html3. 把 ../assets/deck.css替换成内联<style>4. 把 ../assets/slide.js替换成内联<script>5. 把 svg/*.svg转成data:image/svg+xml;base64,...6. 把所有页面作为 JSON 数据写入最终 HTML 7. 播放器通过 iframe.srcdoc加载当前页
核心差异是：
// 多文件开发版
stage.src = "slides/" + slides[i].f;
// 单文件交付版
stage.srcdoc = slides[i].html;这一个变化，让最终文件不再依赖 slides/、assets/、svg/ 这些目录。
10、这个方案适合什么，不适合什么
10.1、适合的场景
我认为它特别适合这些场景：
1. 技术分享 2. 架构方案汇报 3. 产品原型讲解 4. 专题演示材料 5. 需要很多图表、流程和代码片段的演示 6. 需要反复迭代、改版、打磨的长内容
尤其当你的内容不是 5 页，而是 30 页、50 页、80 页时，HTML 工程化的优势会越来越明显。
10.2、不适合的场景
它也不是万能的。
如果你的场景是：
• 需要多人在 PowerPoint 里协同编辑 • 需要大量复杂动画 • 需要和公司模板、母版、字体规范强绑定 • 需要交给完全不懂 HTML 的同事继续维护 • 上传平台会禁用 iframe 或 inline script
那传统 PPT 可能更合适。
还有一点要注意：有些平台为了安全，会禁用内联脚本或 iframe 的 srcdoc。如果目标平台限制很强，最好提前测试。必要时可以再导出 PDF，作为兜底版本。
11、我对这套工作流的总结
这次做完之后，我最大的感受是：HTML 演示文稿不是“用网页替代 PPT”，而是把演示文稿当成一个小型前端工程来管理。
它的核心不是某个炫酷效果，而是这几个边界：
1. 先定风格：让 AI 产出多个视觉方向，人来确认最终基调。 2. 先做播放器原型：翻页、全屏、页码、自适应缩放先跑通。 3. 每页独立 HTML：开发阶段好迭代，AI 也更容易局部修改。 4. 统一 CSS 和 SVG 图形系统：保证几十页看起来像同一份作品。 5. manifest 管页序：不要依赖文件名和目录排序。 6. 最后单文件打包：开发时多文件，交付时一份 HTML。
如果用一句话概括：
PPT 更像文档工具，HTML Slide Deck 更像演示系统。前者适合快速做页，后者适合长期维护复杂技术表达。
对我来说，这套方式最大的价值不是“看起来更酷”，而是它把内容制作过程变得更工程化：
• 可以拆分 • 可以复用 • 可以验证 • 可以自动打包 • 可以持续迭代
这也是我认为未来很多技术分享、方案汇报、产品演示都可以尝试 HTML 化的原因。
