PPT as Code：用网页高效做出比PPT还惊艳的演示文稿！！

开源skill在评论区就能找到

AI 做出来的 PPT 太丑。

排版问题太多。

你本来想偷个懒，结果修着修着发现，还不如自己重做一遍。

更烦的是，PPT 这种东西，看起来只是“排几页内容”，真做起来却经常一做就是几个小时。

最后你会发现，时间不是花在表达上，而是花在和工具拉扯上。

这也是我越来越觉得，很多演示其实不该继续用“文件思维”做。

尤其是当你开始想要这些东西的时候，传统 PPT 会越来越别扭：

• 一页不是“切过去”，而是像网页一样滑进来
• 一个标题和一张图，不是死切，而是有节奏地接力出现
• 演示不是一个文件，而是一个能发链接、能改主题、能版本管理的网页资产

这也是 PPT as Code 真正好的地方。

它不只是“更酷”，也不只是“程序员的仪式感”。

它真正厉害的地方在于：把一次性的演示文件，变成一套可复用、可迭代、可扩展的内容资产。

这篇文章全程干货，带你用网页高效做出比PPT还惊艳的演示文稿！

推荐把本文直接喂给 Codex / Cursor / Claude Code，让它先把骨架搭起来，你再去改内容、风格和节奏。

这篇文章的结构很简单：

1. 先把 PPT as Code 的底层模型讲清楚。
2. 再给你一个最小可运行版本的 prompt。
3. 再讲怎么把它升级得更像 PPT（PPT as code基础篇）
4. 最后给你高级玩法和框架选择（PPT as code进阶）

一、问题定义：你到底在写什么

市面上教程一上来就讲动画。

这很容易把人带歪。

因为“像 PPT 一样的分页展示”，本质上不是某个 fadeIn，也不是某个 slide-up 特效，而是这五个东西：

• container：演示容器，也就是你的舞台
• slides：每一页内容
• index：当前页索引
• controls：按钮、键盘、分页器、URL
• motion：切换时怎么动

只要这五件事在，你的演示系统就成立了。

动画只是最后一层。

真正的底层，是状态切换。

所以别再把它理解成“轮播图”了。

传统那种 jQuery slideshow 思路，更多是在做 banner，不是在做演示系统。

今天你真正该看的是更现代的能力：transform、transition、scroll-snap、History API、WAAPI、View Transition API，以及 reveal.js 这种已经把整套演示能力打包好的框架。

二、做一个今天就能跑的最小版本

先别想着高级转场。

先把最小闭环跑通。

这个最小版本只需要三件事：

• 一页一页地组织内容
• 用按钮和键盘切页
• 用 transform + transition 做出稳定的分页动画

如果你手写，它的骨架其实可以被压到一句话：

每一页都是一个 section，每次切页只改 currentIndex，再用 CSS 根据当前索引决定每页的位移和透明度。

你没必要在正文里啃一大段源码。更高效的方式，是直接把下面这个 prompt 丢给你的 AI 编程工具。

生成最小可运行的 HTML 分页演示：

请帮我生成一个单文件 HTML demo，用来模拟类似 PPT 的分页展示动画。要求：

1. 只输出一个完整的 HTML 文件，包含内联 CSS 和内联 JavaScript。
2. 页面语言是中文，主题偏克制、现代、像产品发布页，不要廉价赛博朋克。
3. 演示区域默认 16:9，桌面端居中显示，移动端自动切换为更适合竖屏的比例。
4. 至少包含 4 页 slide，每页都有标题和一小段说明文字。
5. 每一页都用 section 表示，所有 slide 共用同一个 viewport。
6. 需要支持“上一页 / 下一页”按钮。
7. 需要支持键盘左右方向键和 PageUp / PageDown 切页。
8. 切页动画优先使用 transform 和 opacity，不要用 top / left 做大范围动画。
9. JavaScript 里只维护一个 currentIndex 或等价状态，不要写得过于复杂。
10. 当前页要有明显激活态，非当前页可以适当降透明度。
11. 必须补 prefers-reduced-motion 的降级处理。
12. 代码结构尽量清晰，变量命名直白，适合二次修改。

输出时请额外在代码上方，用 6 到 10 行简要解释这个 demo 的结构：HTML 负责什么，CSS 负责什么，JS 负责什么，我后续应该先改哪几块。

这能帮你快速拿到一个能改内容、能试节奏、能直接录屏或发链接的演示底座。

三、PPT基础篇

最小版本能跑，但还不像一套真正能讲的演示系统。

如果你想把它做得更像 PPT，通常还要补五个能力。

1. 进度条和分页圆点

这两个东西不是为了显得专业。

它们的真正作用，是让观众知道“我讲到哪了”。

你不一定要自己手写这套 UI。更省事的方式，是在最小 demo 跑通之后，继续给 AI 下第二轮 prompt

基于我现在这个单文件 HTML 分页演示 demo，继续增强，但不要推倒重写。请只在现有结构上新增这些能力：

1. 顶部或底部加一个进度条，根据当前页数计算百分比。
2. 加一组分页圆点，点击圆点可以跳到对应 slide。
3. 当前页的圆点要有激活态。
4. 保留原有按钮和键盘切页逻辑。
5. 不要引入任何第三方库。
6. 尽量复用现有 currentIndex 状态，不要新造一套并行逻辑。
7. 保持视觉风格统一，避免加很多无关装饰。

输出时请先告诉我：这次新增功能分别属于“状态可视化”还是“导航能力”，并标出我后续如果想删减，应该优先删哪一块。

2. URL 同步

如果你要把这份演示直接发成网页，URL 同步几乎是必补项。

这样观众刷新后还能回到当前页，你也能把第 5 页单独发给别人

但对创作者来说，重点不是背 API，而是把需求说清楚。

请基于当前 HTML 分页演示，增加 URL 同步能力，但不要破坏现有按钮、键盘和动画逻辑。要求：

1. 当前页变化时，把 URL 更新为类似 #slide-1、#slide-2 这样的 hash。
2. 页面首次加载时，如果 URL 里已经有 hash，就直接定位到对应页。
3. 浏览器前进后退时，演示要能跟着同步切页。
4. 不要引入路由库，不要引入框架。
5. 保持实现尽量简单，优先使用原生 History API 或 hash 方案。
6. 请告诉我：这种 URL 同步更适合“可分享演示链接”，还是“上台播放模式”，以及为什么。

3. Fragment，也就是一页内部逐步显现

这是 PPT 里非常常见的能力。

标题先出来，再出来第一条，再出来第二条。

它的关键不在于动画，而在于节奏控制。

观众不是一次看见整页，而是跟着你的叙述节拍走。

请在我现有的 HTML 分页演示上，增加类似 PPT fragment 的能力。要求：

1. 同一页内某些元素可以逐步显现，而不是一进页就全部显示。
2. 右方向键或下一步操作时，优先显示当前页还没出现的 fragment。
3. 只有当前页 fragment 全部显示完，才真正翻到下一页。
4. fragment 的默认动画要克制，优先用 opacity 和轻微位移，不要夸张飞入。
5. 需要兼容 prefers-reduced-motion。
6. 输出时请给我一个最小示例：标题常驻，三条 bullet 逐条出现。
7. 请额外解释：为什么 fragment 的本质是“页内步骤状态”，而不是“单纯多几个 class”。

4. 媒体预加载

一旦你的演示开始放大图、视频、iframe，资源加载可能会造成卡顿

这段prompt帮你解决这个问题：

请帮我优化一个 HTML 分页演示，让它在图片和视频较多时切页更稳。要求：

1. 优先考虑预加载当前页、前一页、后一页的重资源。
2. 不要一口气把所有页面的资源都提前加载。
3. 如果某一页资源还没准备好，给出简单的 loading 占位。
4. 不要引入打包工具或复杂工程化方案，只讨论原生前端里最实用的做法。
5. 请把建议分成三类：必须做、建议做、可选做。

5. 移动端适配

如果你的演示只是投屏，那手机适配可以晚一点。

但只要你准备发链接，移动端就不是可选项。至少要想清楚两件事：

• 桌面端是不是保持 16:9
• 手机端是不是要切成 9:16 或者允许内容重排

请基于现有 HTML 演示，补一套移动端适配方案。要求：

1. 桌面端保持 16:9 的发布会式演示观感。
2. 手机端不要简单缩小整张 slide，而是优先保证可读性。
3. 可以根据屏幕尺寸切换为更接近 9:16 的布局。
4. 需要考虑移动浏览器视口高度变化。
5. 不要做成完全两套页面，而是尽量复用一套结构。
6. 输出时请说明：哪些是必须改的，哪些只是锦上添花。

四、PPT as code进阶

做到这一步，你已经能用原生 HTML 搭出一套像样的分页演示了。

接下来真正要想清楚的，不是“还能不能更炫”，而是“哪种能力值得加，哪种能力该直接外包给框架”。

1. scroll-snap：适合滚动式演示，不适合替代一切分页控制

如果你做的是“一屏一屏滚动的长网页叙事”，CSS Scroll Snap 很合适。

我参考了MDN的web.dev,它讲得很清楚：给滚动容器加 scroll-snap-type，给子元素加 scroll-snap-align，浏览器就会在滚动结束后吸附到最近的对齐位置。

它适合：

• 一屏一屏往下滚的发布页
• 观众自己浏览的演示链接
• 偏叙事型，而不是偏控场型的内容

它不太适合：

• 你要精准控制每一下按键推进
• 你必须先 reveal 三次，再翻页
• 你每一页高度差异非常大

请帮我把当前的 HTML 分页演示，改造成更适合“观众自己滚动浏览”的 scroll-snap 版本。要求：

1. 使用现代 CSS Scroll Snap 写法，不要使用旧语法。
2. 每个 slide 至少占满一个视口高度。
3. 保持当前视觉风格，不要重做整套 UI。
4. 请解释这种方案和“按钮切页方案”最大的结构区别。
5. 请告诉我：什么场景适合 scroll-snap，什么场景反而不该用。

2. WAAPI：适合你需要 JavaScript 精准控场的时候

如果你只是做简单翻页，CSS 的 transition 已经够了。

但如果你要做这些事，WAAPI 会更舒服：

• 根据用户操作动态改动画时长
• 等一个数字滚动完，再出现下一层内容
• 多个元素跟同一条时间线推进

请帮我评估，当前这个 HTML 分页演示里，哪些动画适合继续用 CSS transition，哪些更适合改成 Web Animations API。要求：

1. 不要一刀切全改。
2. 只挑最适合 WAAPI 的 1 到 2 类动画做示例。
3. 优先选择需要更强时间控制、播放控制或链式触发的场景。
4. 输出时请分成三部分：继续保留 CSS 的、建议改 WAAPI 的、没必要做复杂的。

3. View Transition API：适合做更顺滑的镜头切换

这个 API 更适合做“旧视图和新视图之间的镜头感”。

它不是拿来替代你整套 slide 系统的。你的状态逻辑如果还没理顺，先上它只会更乱。

请基于我当前的 HTML 演示，评估 View Transition API 是否值得接入。要求：

1. 先判断这个项目是否真的适合同文档视图切换。
2. 如果适合，只给一个最小可用接法，不要大改架构。
3. 如果不适合，也请明确告诉我原因。
4. 请用“收益 / 复杂度 / 浏览器现实”三个维度来判断，而不是只讲 API 本身。

4.reveal.js：适合你不想自己重造整套演示轮子

如果你已经知道自己要的是一套完整 HTML 演示框架，reveal.js 还是非常稳。

它最有价值的，不是“功能很多”，而是很多你迟早会补的能力它都已经有了：

• Fragments：一页内部逐步显现
• Auto-Animate：相邻两页之间自动补间
• Markdown：直接用 Markdown 写 slide

请帮我用 reveal.js 搭一个最小可用的 HTML 演示原型，主题是产品发布式分页展示。要求：

1. 先用 reveal.js 官方推荐结构搭建，不要引入无关插件。
2. 至少包含 4 页 slide。
3. 第 2 页演示 fragment。
4. 第 3 页演示 auto-animate。
5. 第 4 页演示一页代码或数据排版，但风格要简洁。
6. 优先用 reveal.js 自带能力，不要为了炫技增加复杂定制。
7. 输出时请告诉我：如果我是内容创作者，不想长期维护自写逻辑，为什么 reveal.js 可能比原生手写更划算。

如何让网页 PPT 更美观、更风格化

很多人的网页 PPT，不是功能没做出来，是做出来了，但还是丑。

这个“丑”通常不是因为不会写 CSS，而是因为还在用“想到哪页修哪页”的方式做设计。网页 PPT 真正需要的，不是一页一页补救，而是一套先定死的视觉系统。

1. 先定视觉母板，不要一页一页临场发挥

最稳的做法不是先挑动画。

是先定这四件事：

• 字体系统
• 颜色系统
• 间距系统
• 组件系统

如果这四件事不先定，后面再多的动效也只是在给混乱加速度。

这也是为什么我建议你先让 AI 帮你出“视觉母板”，而不是直接让它生成十页 slide。你可以参考 reveal.js 的themes思路，先把演示当成一个有统一主题和尺寸约束的系统来处理，而不是一个个自由生长的页面。

2. 先把字体做好，气质会直接换一层

网页 PPT 最容易显得廉价的地方，不是配色。

是字体。

很多人一上来就默认系统字体，或者随手套一个“看起来高级”的 display font。结果标题和正文互相打架，数字也不稳，最后整份东西像拼起来的。

更稳的路线是：

• 标题用一套更有 personality 的 display 字体
• 正文用一套更耐读的 text 字体
• 数字、页码、统计值尽量保持统一字宽或至少统一气质

Google Fonts 的CSS2 API现在已经支持 variable fonts 了。对网页 PPT 来说，这非常好用，因为你不一定非要引很多字重，一套变量字体就能把标题、正文和数字的层级拉开。

3. 动效要有节奏，不要全靠“都动起来”

风格化不等于满屏动画。

真正好看的网页 PPT，通常只在两个地方下重手：

• 换页时的大动作
• 页内一两个关键元素的节奏动作

其他地方反而要克制。

如果你只是想让演示更顺滑，CSS 已经够用。

但如果你想做更有编排感的节奏，比如标题先压进来、数字后接、图片最后补上，那 GSAP 会很舒服。它本身就是框架无关的。对网页 PPT 来说，值钱的不是“用了 GSAP”，而是它能让你把多个元素的时间关系真的编排出来。

4. 先让 AI 出 3 套视觉方向，不要一上来让它直接写最终版

这是今天最好用的偷懒方法。

别一上来就说：“帮我把这个网页 PPT 做漂亮。”

这种 prompt 太空了，AI 最后通常会给你一个中规中矩、偏模板化的结果。

更好的做法是，先让它出 3 套彼此差异明显的风格方向，再选一套深化。

请基于我当前这个 HTML 演示项目，不直接生成最终页面，而是先给我 3 套彼此差异明显的视觉方向方案。要求：

1. 每套方案都要包括：设计关键词、适合的内容气质、标题字体建议、正文字体建议、主色 / 辅色 / 背景色、组件风格、动画节奏。
2. 三套方向不能只是换颜色，要有明显的风格差异。
3. 风格方向尽量朝“产品发布页 / 设计评论 / 商业杂志封面 / 信息可视化演示”这些成熟方向靠，不要默认赛博朋克紫色。
4. 输出时请告诉我：哪一套最适合“PPT as Code”这种偏理性、偏设计系统感的主题，为什么。
5. 不要直接写完整代码，先做视觉方案。

5. 再让 AI 按选定方向重写样式，不要让它碰太多结构

很多人让 AI 美化网页 PPT，最后把结构、内容、文案和样式一起改乱了，这里只让它重写样式层，从而最小化改动。

请基于我已经选定的视觉方向，重构当前 HTML 演示的视觉样式，但不要推倒现有内容结构和交互逻辑。要求：

1. 优先改 CSS，不要重写整套 HTML 和 JavaScript。
2. 用 CSS 变量先抽出颜色、圆角、阴影、间距、字号层级。
3. 保持 slide 数量、内容顺序、切页逻辑不变。
4. 目标气质是：克制、锋利、像高质量产品发布页，不要廉价科技风。
5. 请重点优化：标题层级、留白、背景、卡片质感、按钮、分页器、进度条。
6. 输出时请先解释：这次改动里，哪些是“风格层”，哪些是“结构层”，并确保你只动风格层。

如何让 AI 帮你找配图

AI 在配图这件事上，至少可以帮你做四件事：

1. 把文字内容翻译成视觉概念
2. 把视觉概念翻译成检索关键词
3. 帮你筛掉不合适的图片
4. 如果图库里没有，再把最佳方向翻译成出图 prompt

也就是说，AI 不只是出图机器。

它首先是一个视觉研究助理。

1. 先让 AI 帮你想“这页应该配什么”，而不是立刻找图

同一句话，可以配很多种图。

比如“PPT as Code”这个主题，你可以配：

• 浏览器舞台
• 多张 slide 切换的系统图
• 传统幻灯片和网页状态的对照图
• 更抽象的“文件变系统”的视觉隐喻

先让 AI 把这些方向拆出来，你后面的找图效率会高很多

请基于这篇文章 / 这一页 slide 的内容，先不要直接生成图片，也不要直接搜图。先帮我做视觉拆解。要求：

1. 提炼这一页最核心的表达目标。
2. 给出 3 到 5 个不同的视觉隐喻方向。
3. 每个方向都要说明：适合传达什么、不适合传达什么、可能出现什么误解。
4. 请额外告诉我：哪一个方向最适合做封面，哪一个方向更适合做正文配图。
5. 输出要像一个创意总监在做前期视觉方向会，而不是像关键词列表。

2. 再让 AI 产出“搜图包”，而不是只有一个词

如果你要找现成图片，最怕的不是搜不到。

最怕的是 AI 只给你一个大词，比如“technology presentation”，然后你一搜全是廉价科技蓝。

更有用的做法，是让 AI 一次给你完整的“搜图包”：

• 英文主关键词
• 替代关键词
• 应避开的词
• 图片方向
• 横竖比例
• 色彩倾向

请基于我这页内容，帮我生成一个“找配图搜图包”。要求：

1. 先给出这页内容最适合的 1 个主视觉方向。
2. 再给出 8 到 12 个英文搜索关键词组合
3. 再给出 5 个应避开的关键词，避免搜出廉价、跑题或过度科技感的图。
4. 补充建议的图片比例、构图方向、主色倾向。
5. 如果你觉得这页更适合插画而不是照片，也请明确指出。
6. 输出时请按“封面搜图词 / 正文搜图词 / 应避开词 / 筛选标准”四块组织。

3.找不到现成图，再让 AI 把方向翻译成出图 prompt

先经过上面那几轮拆解、搜图和筛图，最后留下来的那个方向，才适合被翻译

成最终 prompt

请把我已经选定的这套视觉方向，翻译成一个适合图像模型的最终出图 prompt。要求：

1. 先写清楚主题和画面主体。
2. 再写清楚构图、色彩、材质、气质。
3. 明确写出不要出现什么。
4. 如果这是文章封面，请留出标题区。
5. 输出中英双语 prompt。
6. 风格要像设计评论杂志封面，而不是 AI 工具宣传图。

归根到底，手写、框架还是传统 PPT，并不是一道非此即彼的选择题，真正该先想清楚的是：你要交付的，究竟只是一次性的演讲文件，还是一套以后还能继续复用、修改、发布和生长的表达系统。

要是需求是商务路演，毕业答辩，传统 PPT 是不能被替代的

但一旦你的演示开始频繁出现在网页、内容平台、产品展示、个人网站，甚至需要和 demo、代码、组件、品牌样式长期打通，那它就不该再被当作一份“做完就结束”的幻灯片，而应该被当作一套持续积累的演示资产来经营。

也正因为这样，比起一味追求“看起来更高级”，更重要的其实是建立一套更成熟的表达判断。

不要拿大段代码堆出干货感，因为真正有价值的，往往不是贴了多少实现细节，而是你有没有能力把问题拆清楚，把边界说明确，把 AI、代码、结构和取舍组织成一个别人能立刻上手的方案。

不要滥用动效，也不要把“做了很多效果”误认为“讲得更好了”；动画、切换、交互的意义，从来都不是奖励作者自己，而是帮助观众更轻松地理解内容、跟上节奏、记住重点。

再往前一步，是否尊重 prefers-reduced-motion，是否照顾键盘用户，是否让焦点清晰可见，这些看上去像细节的地方，最后决定的其实不是技术完成度，而是你的作品到底是在服务表达，还是只是在展示技巧。

所以到最后，真正拉开差距的往往不是你选了哪种工具，而是你有没有把演示这件事看得更长远一点。

代码会越来越像材料，prompt 会越来越像起点，框架和工具也会不断更新，但对结构、节奏、可讲性和可维护性的判断，才是最难被替代的部分。

当你开始用这种眼光看待演示，你维护的就不再只是几页幻灯片，而是一整套能被反复调用、持续迭代、不断增值的内容能力。