# PPT as Code：用网页高效做出比PPT还惊艳的演示文稿！！
**作者**: Russell
**日期**: 2026-04-04T13:57:35.000Z
**来源**: [https://x.com/Russell3402/status/2040428571064484221](https://x.com/Russell3402/status/2040428571064484221)
---
> AI 做出来的 PPT 太丑。
排版问题太多。
你本来想偷个懒，结果修着修着发现，还不如自己重做一遍。
更烦的是，PPT 这种东西，看起来只是“排几页内容”，真做起来却经常一做就是几个小时。
最后你会发现，时间不是花在表达上，而是花在和工具拉扯上。
这也是我越来越觉得，很多演示其实不该继续用“文件思维”做。
尤其是当你开始想要这些东西的时候，传统 PPT 会越来越别扭：
- 一页不是“切过去”，而是像网页一样滑进来
- 一个标题和一张图，不是死切，而是有节奏地接力出现
- 演示不是一个文件，而是一个能发链接、能改主题、能版本管理的网页资产
这也是 PPT as Code 真正好的地方。
它不只是“更酷”，也不只是“程序员的仪式感”。
它真正厉害的地方在于：把一次性的演示文件，变成一套可复用、可迭代、可扩展的内容资产。
这篇文章全程干货，带你用网页高效做出比PPT还惊艳的演示文稿！
> 推荐把本文直接喂给 Codex / Cursor / Claude Code，让它先把骨架搭起来，你再去改内容、风格和节奏。
这篇文章的结构很简单：
先把 PPT as Code 的底层模型讲清楚。
再给你一个最小可运行版本的 prompt。
再讲怎么把它升级得更像 PPT（PPT as code基础篇）
最后给你高级玩法和框架选择（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 分页演示：
这能帮你快速拿到一个能改内容、能试节奏、能直接录屏或发链接的演示底座。
三、PPT基础篇
最小版本能跑，但还不像一套真正能讲的演示系统。
如果你想把它做得更像 PPT，通常还要补五个能力。
1. 进度条和分页圆点
这两个东西不是为了显得专业。
它们的真正作用，是让观众知道“我讲到哪了”。
你不一定要自己手写这套 UI。更省事的方式，是在最小 demo 跑通之后，继续给 AI 下第二轮 prompt
2. URL 同步
如果你要把这份演示直接发成网页，URL 同步几乎是必补项。
这样观众刷新后还能回到当前页，你也能把第 5 页单独发给别人
但对创作者来说，重点不是背 API，而是把需求说清楚。
3. Fragment，也就是一页内部逐步显现
这是 PPT 里非常常见的能力。
标题先出来，再出来第一条，再出来第二条。
它的关键不在于动画，而在于节奏控制。
观众不是一次看见整页，而是跟着你的叙述节拍走。
4. 媒体预加载
一旦你的演示开始放大图、视频、iframe，资源加载可能会造成卡顿
这段prompt帮你解决这个问题：
5. 移动端适配
如果你的演示只是投屏，那手机适配可以晚一点。
但只要你准备发链接，移动端就不是可选项。至少要想清楚两件事：
- 桌面端是不是保持 16:9
- 手机端是不是要切成 9:16 或者允许内容重排
四、PPT as code进阶
做到这一步，你已经能用原生 HTML 搭出一套像样的分页演示了。
接下来真正要想清楚的，不是“还能不能更炫”，而是“哪种能力值得加，哪种能力该直接外包给框架”。
1. scroll-snap：适合滚动式演示，不适合替代一切分页控制
如果你做的是“一屏一屏滚动的长网页叙事”，CSS Scroll Snap 很合适。
我参考了MDN的web.dev,它讲得很清楚：给滚动容器加 scroll-snap-type，给子元素加 scroll-snap-align，浏览器就会在滚动结束后吸附到最近的对齐位置。
它适合：
- 一屏一屏往下滚的发布页
- 观众自己浏览的演示链接
- 偏叙事型，而不是偏控场型的内容
它不太适合：
- 你要精准控制每一下按键推进
- 你必须先 reveal 三次，再翻页
- 你每一页高度差异非常大
2. WAAPI：适合你需要 JavaScript 精准控场的时候
如果你只是做简单翻页，CSS 的 transition 已经够了。
但如果你要做这些事，WAAPI 会更舒服：
- 根据用户操作动态改动画时长
- 等一个数字滚动完，再出现下一层内容
- 多个元素跟同一条时间线推进
3. View Transition API：适合做更顺滑的镜头切换
这个 API 更适合做“旧视图和新视图之间的镜头感”。
它不是拿来替代你整套 slide 系统的。你的状态逻辑如果还没理顺，先上它只会更乱。
4.reveal.js：适合你不想自己重造整套演示轮子
如果你已经知道自己要的是一套完整 HTML 演示框架，reveal.js 还是非常稳。
它最有价值的，不是“功能很多”，而是很多你迟早会补的能力它都已经有了：
- Fragments：一页内部逐步显现
- Auto-Animate：相邻两页之间自动补间
- Markdown：直接用 Markdown 写 slide
## 如何让网页 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 套彼此差异明显的风格方向，再选一套深化。
5. 再让 AI 按选定方向重写样式，不要让它碰太多结构
很多人让 AI 美化网页 PPT，最后把结构、内容、文案和样式一起改乱了，这里只让它重写样式层，从而最小化改动。
## 如何让 AI 帮你找配图
AI 在配图这件事上，至少可以帮你做四件事：
把文字内容翻译成视觉概念
把视觉概念翻译成检索关键词
帮你筛掉不合适的图片
如果图库里没有，再把最佳方向翻译成出图 prompt
也就是说，AI 不只是出图机器。
它首先是一个视觉研究助理。
1. 先让 AI 帮你想“这页应该配什么”，而不是立刻找图
同一句话，可以配很多种图。
比如“PPT as Code”这个主题，你可以配：
- 浏览器舞台
- 多张 slide 切换的系统图
- 传统幻灯片和网页状态的对照图
- 更抽象的“文件变系统”的视觉隐喻
先让 AI 把这些方向拆出来，你后面的找图效率会高很多
2. 再让 AI 产出“搜图包”，而不是只有一个词
如果你要找现成图片，最怕的不是搜不到。
最怕的是 AI 只给你一个大词，比如“technology presentation”，然后你一搜全是廉价科技蓝。
更有用的做法，是让 AI 一次给你完整的“搜图包”：
- 英文主关键词
- 替代关键词
- 应避开的词
- 图片方向
- 横竖比例
- 色彩倾向
3.找不到现成图，再让 AI 把方向翻译成出图 prompt
先经过上面那几轮拆解、搜图和筛图，最后留下来的那个方向，才适合被翻译
成最终 prompt
归根到底，手写、框架还是传统 PPT，并不是一道非此即彼的选择题，真正该先想清楚的是：你要交付的，究竟只是一次性的演讲文件，还是一套以后还能继续复用、修改、发布和生长的表达系统。
要是需求是商务路演，毕业答辩，传统 PPT 是不能被替代的
但一旦你的演示开始频繁出现在网页、内容平台、产品展示、个人网站，甚至需要和 demo、代码、组件、品牌样式长期打通，那它就不该再被当作一份“做完就结束”的幻灯片，而应该被当作一套持续积累的演示资产来经营。
也正因为这样，比起一味追求“看起来更高级”，更重要的其实是建立一套更成熟的表达判断。
不要拿大段代码堆出干货感，因为真正有价值的，往往不是贴了多少实现细节，而是你有没有能力把问题拆清楚，把边界说明确，把 AI、代码、结构和取舍组织成一个别人能立刻上手的方案。
不要滥用动效，也不要把“做了很多效果”误认为“讲得更好了”；动画、切换、交互的意义，从来都不是奖励作者自己，而是帮助观众更轻松地理解内容、跟上节奏、记住重点。
再往前一步，是否尊重 prefers-reduced-motion，是否照顾键盘用户，是否让焦点清晰可见，这些看上去像细节的地方，最后决定的其实不是技术完成度，而是你的作品到底是在服务表达，还是只是在展示技巧。
所以到最后，真正拉开差距的往往不是你选了哪种工具，而是你有没有把演示这件事看得更长远一点。
代码会越来越像材料，prompt 会越来越像起点，框架和工具也会不断更新，但对结构、节奏、可讲性和可维护性的判断，才是最难被替代的部分。
当你开始用这种眼光看待演示，你维护的就不再只是几页幻灯片，而是一整套能被反复调用、持续迭代、不断增值的内容能力。
## 相关链接
- [Russell](https://x.com/Russell3402)
- [@Russell3402](https://x.com/Russell3402)
- [7.2K](https://x.com/Russell3402/status/2040428571064484221/analytics)
- [web.dev](https://web.dev/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [9:57 PM · Apr 4, 2026](https://x.com/Russell3402/status/2040428571064484221)
- [7,219 Views](https://x.com/Russell3402/status/2040428571064484221/analytics)
- [View quotes](https://x.com/Russell3402/status/2040428571064484221/quotes)
---
*导出时间: 2026/4/5 03:07:46*