文章目录
- 1、前言
- 2、快速上手：最终怎么使用
- 3、整体思路：先定风格，再做内容，最后打包
-
- 3.1、第一步：先用 AI 出配色和视觉参考
- 3.2、第二步：基于原型固定播放体验
- 3.3、第三步：规划每一页呈现什么
- 4、目录结构：为什么每页单独一个 HTML
-
- 4.1、独立页面更适合迭代
- 4.2、统一 CSS 保证整体一致
- 4.3、manifest 决定页序
- 5、运行架构：它为什么能像 PPT 一样翻页
-
- 5.1、外层播放器负责翻页
- 5.2、键盘翻页靠 keydown 事件
- 5.3、iframe 里的页面也能通知外层翻页
- 6、自适应缩放：为什么 4K 屏不会小成一块
- 7、视觉层：为什么 HTML 反而更好看
-
- 7.1、CSS 变量能形成真正的主题系统
- 7.2、SVG 很适合做复杂架构图
- 7.3、组件化样式让页面更统一
- 8、制作过程：AI 适合做什么，人必须守什么
-
- 8.1、AI 适合做发散和机械实现
- 8.2、人必须守住内容判断和最终审美
- 9、最终打包：为什么不要直接 cat 合并
-
- 9.1、开发阶段使用多文件
- 9.2、交付阶段使用单文件
- 10、这个方案适合什么，不适合什么
-
- 10.1、适合的场景
- 10.2、不适合的场景
- 11、我对这套工作流的总结
🍃作者介绍：AI 应用负责人/AI产品架构师，阿里云专家博主。专注 LLM 应用开发、Agent 系统设计、具身智能与工业 AI 落地。日常在大模型训练、Coding Agent 工具链、AI 产品商业化等方向持续输出实战内容。 🦅个人主页：@逐梦苍穹 🐼GitHub主页：https://github.com/XZL-CODE ✈ 您的一键三连，是我创作的最大动力🌹
1、前言
最近我需要针对“企业级 AI 混合云参考架构”和“AI 原生研发”这类偏复杂的技术主题，准备一份演示材料。内容本身比较重：既有混合云、数据不出域、大模型网关，也有 Vibe Coding、SDD、机密推理这些概念。
按照以往经验，这类材料大概率会直接做成 PPT。但真正做起来，会遇到几个很典型的问题：
所以这次我换了一个思路：用 HTML 来做类似 PPT 的演示文稿。
不是把网页写成文章，也不是把 PPT 截图贴进网页，而是做一个“HTML Slide Deck”：每一页是一份独立 HTML，外面有一个播放器 index.html 统一加载、翻页和控制；等内容全部沉淀好之后，再用 JS 脚本把几十份 HTML、CSS、JS、SVG 全部打包成一个最终单文件 HTML。
这篇文章就复盘这个过程，重点讲清楚三个问题：
2、快速上手：最终怎么使用
先说结果，不先讲原理。
这套方案最终会得到一个可以直接双击打开的 HTML 文件：
终稿html/
└── AI架构演示_单文件版.html
打开以后就是一个横向演示文稿：
- 空格 / →：下一页
- ←：上一页
- Home / End：跳到第一页 / 最后一页
- F：全屏
- 页面右下角有页码
- 底部有进度条
- 直接用 #页码 可以跳转，比如 xxx.html#12
重新打包也很简单：
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
这个原型只需要解决几个核心问题：
只要这个原型稳定，后面 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>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>封面</title>
<link rel="stylesheet" href="../assets/deck.css">
</head>
<body class="slide-page">
<section class="slide center cover">
<!– 当前页内容 –>
</section>
<script src="../assets/slide.js"></script>
</body>
</html>
这一页自己可以打开，放进播放器里也能展示。
4.2、统一 CSS 保证整体一致
每页独立，不代表每页各写一套风格。
所有页面都统一引用：
<link rel="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: "小结 & 讨论" },
];
这样做有两个好处：
5、运行架构：它为什么能像 PPT 一样翻页
这套方案的运行方式可以理解成：
外层 index.html 是播放器，内层 slides/xx.html 是当前幻灯片。
5.1、外层播放器负责翻页
index.html 里有一个全屏 iframe：
<iframe id="stage" title="slide"></iframe>
翻页时并不是滚动页面，而是切换 iframe 里加载的 HTML：
function go(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();
} else if (k === "ArrowLeft" || k === "PageUp" || k === "ArrowUp") {
e.preventDefault();
prev();
} else if (k === "Home") {
go(0);
} else if (k === "End") {
go(n – 1);
} else if (k === "f" || k === "F") {
fs();
}
});
这就是 空格、方向键、F 全屏这些能力的来源。
5.3、iframe 里的页面也能通知外层翻页
有一个细节：如果用户点了一下幻灯片内容，焦点可能进入 iframe。此时键盘事件会先被内层页面捕获。
所以每一页也引入 slide.js，它会把翻页动作转发给父级播放器：
function send(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) + ")";
它的含义是：
这和普通响应式网页不太一样。
普通网页追求内容随屏幕重排；演示文稿更追求“版面关系稳定”。所以对复杂图表页来说，缩放比重排更可靠。
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: 16px 17px 15px;
box-shadow: var(–shadow);
}
所有表格都使用同一套 .tablewrap。
所有重点提示都使用 .callout。
这样后面新增页面时，只要复用这些组件，视觉就不会散。
8、制作过程：AI 适合做什么，人必须守什么
这个过程中，AI 很有用，但不能把所有判断都交给 AI。
8.1、AI 适合做发散和机械实现
我会让 Codex / Claude Code 做这些事：
- 输出几套配色参考
- 生成页面原型
- 根据讲稿拆分页面结构
- 写 SVG 架构图
- 调整 CSS 细节
- 写打包脚本
- 做关键词扫描和格式检查
这些工作要么偏发散，要么偏机械，要么偏重复，AI 的效率很高。
8.2、人必须守住内容判断和最终审美
但这几件事必须人来拍板：
比如这次做 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
打包脚本做几件事：
核心差异是：
// 多文件开发版
stage.src = "slides/" + slides[i].f;
// 单文件交付版
stage.srcdoc = slides[i].html;
这一个变化，让最终文件不再依赖 slides/、assets/、svg/ 这些目录。
10、这个方案适合什么，不适合什么
10.1、适合的场景
我认为它特别适合这些场景：
尤其当你的内容不是 5 页，而是 30 页、50 页、80 页时，HTML 工程化的优势会越来越明显。
10.2、不适合的场景
它也不是万能的。
如果你的场景是：
- 需要多人在 PowerPoint 里协同编辑
- 需要大量复杂动画
- 需要和公司模板、母版、字体规范强绑定
- 需要交给完全不懂 HTML 的同事继续维护
- 上传平台会禁用 iframe 或 inline script
那传统 PPT 可能更合适。
还有一点要注意：有些平台为了安全，会禁用内联脚本或 iframe 的 srcdoc。如果目标平台限制很强，最好提前测试。必要时可以再导出 PDF，作为兜底版本。
11、我对这套工作流的总结
这次做完之后，我最大的感受是：HTML 演示文稿不是“用网页替代 PPT”，而是把演示文稿当成一个小型前端工程来管理。
它的核心不是某个炫酷效果，而是这几个边界：
如果用一句话概括：
PPT 更像文档工具，HTML Slide Deck 更像演示系统。前者适合快速做页，后者适合长期维护复杂技术表达。
对我来说，这套方式最大的价值不是“看起来更酷”，而是它把内容制作过程变得更工程化：
- 可以拆分
- 可以复用
- 可以验证
- 可以自动打包
- 可以持续迭代
这也是我认为未来很多技术分享、方案汇报、产品演示都可以尝试 HTML 化的原因。
| 🚀 持续探索 AI 与前沿技术 分享大模型应用、软件开发实战与行业洞察。 欢迎关注 【龙哥AI】，加入 7000+ 技术同行的交流圈！ 🌟 探索技术边界，让开发更有效率 |  |
