AI 做出来的 PPT 太丑。排版问题太多，本来想偷懒，结果修着修着发现还不如自己重做。更烦的是，PPT 看起来只是排几页内容，真做起来经常一做就是几小时——时间不是花在表达上，而是花在和工具拉扯上。

这也是为什么很多演示其实不该继续用"文件思维"做。

PPT as Code 的底层模型

市面上教程一上来就讲动画，很容易把人带歪。"像 PPT 一样的分页展示"，本质不是某个 fadeIn 或 slide-up 特效，而是这五件事：

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

只要这五件事在，演示系统就成立了。动画只是最后一层，真正的底层是状态切换。

最小可运行版本

只需要三件事：① 一页一页地组织内容；② 用按钮和键盘切页；③ 用 transform + transition 做出稳定的分页动画。

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

升级路径（5次迭代）

① 进度条和分页圆点：不是为了显得专业，而是让观众知道"我讲到哪了"。

② URL 同步：发成网页后，刷新能回到当前页，也能把某一页单独发给别人。用 History API 或 hash 方案。

③ Fragment（页内逐步显现）：标题先出来，再出来第一条，再出来第二条。关键不在动画，在于节奏控制——观众不是一次看见整页，而是跟着叙述节拍走。

④ 媒体预加载：一旦有大图、视频、iframe，资源加载可能造成卡顿。优先预加载当前页、前一页、后一页的重资源。

⑤ 移动端适配：桌面端保持 16:9，手机端优先保证可读性，切换为更接近 9:16 的布局。

框架选择

  • Scroll-snap：适合"一屏一屏往下滚的发布页"，不适合精准控制每下按键推进
  • WAAPI：需要 JavaScript 精准控场时用（动态改动画时长、数字滚动完再出现下一层、多元素跟同一条时间线）
  • View Transition API：适合做"旧视图和新视图之间的镜头感"，不是替代整套 slide 系统
  • reveal.js：适合不想自己重造整套演示轮子的情况，Fragment、Auto-Animate、Markdown 支持开箱即用

视觉系统的建立

很多人网页 PPT 做出来了但还是丑，不是因为不会写 CSS，而是因为用"想到哪页修哪页"的方式做设计。

先定四件事：字体系统、颜色系统、间距系统、组件系统。这四件事不先定，后面再多的动效只是在给混乱加速度。

字体最关键：标题用 personality 强的 display 字体，正文用耐读的 text 字体，数字和页码保持统一字宽或气质。Google Fonts CSS2 API 的 variable fonts 对网页 PPT 非常好用。

动效要有节奏：真正好看的网页 PPT，通常只在两个地方下重手——换页时的大动作 + 页内一两个关键元素的节奏动作，其他地方反而要克制。

先出 3 套风格方向再选：不要一上来就让 AI 写最终版，先让它出 3 套彼此差异大的方向，再选一套深化。

核心认知

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

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