open-slide 上手：让 AI Agent 写 PPT，关键不是模板，是把幻灯片变成代码工程

PPT 这件事，最耗人的常常不是“写什么”，而是“怎么摆”。标题大一点还是小一点，图表往左还是往右，代码块会不会挤爆一页，配色有没有跑偏，改三轮之后版式还在不在。

Marp、Slidev、Reveal.js 已经把“用代码做幻灯片”这条路跑通了：人写 Markdown 或 HTML，框架渲染成 deck。但 open-slide 的重点不是再造一个 Markdown 幻灯片工具。它的判断更直接：既然现在很多人已经用 Claude Code、Cursor、Codex 写代码，那幻灯片也可以变成 Agent 能理解、能修改、能迭代的代码工程。

它把每一页幻灯片定义成 React 组件，运行时负责画布、缩放、导航、热重载、演示和导出；Agent 负责写组件、排版、处理反馈。真正有意思的不是“AI 能生成 PPT”，而是 PPT 从一个不可审计的视觉文件，变成了可以 git diff、可以批注、可以让 Agent 按规范修改的工程资产。

open-slide 和 Slidev 不是一类问题

很多人看到 open-slide，第一反应会拿它和 Slidev 比。这个比较有用，但要先分清边界。

Slidev 更适合人写。你用 Markdown 写内容，加一点 frontmatter、组件和 CSS，就能快速做技术分享。它的核心优势是输入轻、写起来快、对人友好。

open-slide 更偏向 Agent 写。它不把 Markdown 作为主要抽象，而是把每一页做成零参数 React 组件，渲染在固定的 1920 × 1080 画布里。你失去了 Markdown 的简洁，但换来完整布局自由度：一页可以是任意 React 组件树，可以精确控制字号、间距、动画、图表、代码块、背景和装饰元素。

最小页面长这样：

TSX

import type { Page } from '@open-slide/core';

const Cover: Page = () => (
  <div
    style={ {
      width: '100%',
      height: '100%',
      background: '#0f172a',
      padding: '0 160px',
      display: 'flex',
      alignItems: 'center',
    } }
  >
    <h1
      style={ {
        fontSize: 160,
        fontWeight: 900,
        color: '#f8fafc',
      } }
    >
      The Big Idea
    </h1>
  </div>
);

export default [Cover] satisfies Page[];

这对人来说比 Markdown 重，但对 Coding Agent 来说正合适。Agent 本来就擅长 React、inline style、组件拆分和约束修改。open-slide 只是把“写页面”这套能力迁移到“写幻灯片”。

最小上手：先跑一个工作区

open-slide 的脚手架很直接：

BASH

npx @open-slide/cli init my-slide
cd my-slide
pnpm dev

开发服务器启动后，浏览器打开本地地址就能看到 deck。脚手架会预配置 Agent Skills，尤其是给 Claude Code 的工作流。你可以直接让 Agent 生成一套关于某个主题的幻灯片，也可以手动编辑 slides/<id>/index.tsx。

项目结构大致会围绕 slides 目录展开：

TEXT

my-slide/
├── slides/
│   └── product-demo/
│       └── index.tsx
├── assets/
├── package.json
└── CLAUDE.md

最关键的是 slides/<id>/index.tsx。open-slide 会通过 Vite 插件自动发现这些 deck，开发时热重载，构建时输出静态文件。

如果你想让 Agent 做第一版，可以这么发任务：

TEXT

帮我做一套 8 页技术分享，主题是“为什么 Agent 需要可审计的工具层”。
风格克制、浅色背景、适合工程团队内部分享。
每页只讲一个观点，代码示例不要超过 12 行。

好的提示不是“帮我做个酷炫 PPT”，而是把使用场景、页数、视觉方向、文本密度和受众说清楚。Agent 做幻灯片，最怕没有边界；没有边界，它就会把所有东西堆上去。

两个核心 Skill：让 Agent 先读规则，再写页面

open-slide 真正拉开差距的地方，是它把幻灯片写作规则做成了 Agent Skills。

/create-slide 是端到端生成流程。它会先问几个范围问题：主题和视觉方向、页数、文本密度、动画需求。然后选一个 kebab-case 的 deck id，规划页面结构，确定配色和字号，最后写入 slides/<id>/index.tsx。

/slide-authoring 更像技术规范。它告诉 Agent 1920 × 1080 画布怎么用，字号梯度怎么定，padding、留白、布局密度、垂直预算怎么控制。关键点是：幻灯片不滚动，超出 1080px 的东西会被裁掉。

这套设计比“直接让 LLM 输出 PPT”靠谱。因为它不是让模型凭感觉排版，而是先把隐性设计规则显式化：

TEXT

hero 标题：140–200px
主标题：72–110px
正文：32–44px
页面 padding：100–160px
一页只服务一个核心观点
不要把长段落塞进画布底部

这些规则在人类设计师脑子里是常识，但对 Agent 来说，必须写进工作流。否则它很容易生成一页看似信息丰富、实际投影时根本看不清的“字海”。

Inspector：让反馈落到源码里，而不是散在聊天记录里

只会生成第一版不够。PPT 的真实工作流是反复改：这个标题太大，那个图表颜色不对，第三页删掉一句，封面换个措辞。

open-slide 的 Inspector 解决的是反馈闭环。你在开发服务器里点击任意元素，可以给这个元素加评论，比如：

TEXT

把这行改成红色
标题换成“工具层比模型更影响 Agent 稳定性”
这一页文字太密，拆成两页

这些评论不是存在某个外部数据库里，而是以 @slide-comment 标记写进源码附近：

TSX

<div>
  {/* @slide-comment id="c-a3f2b1c0" ts="2026-05-05T..." text="..." */}
  <h1 style={ { fontSize: 80 } }>原标题</h1>
</div>

然后你在 Agent 里执行 /apply-comments，它会读取未处理评论，按上下文修改源码，完成后清理标记。

这个设计很工程化。评论跟着代码走，git diff 可见，团队协作时不会丢；Agent 修改的依据也清楚，不是从聊天记录里猜“你刚才说的那个标题是哪一页”。

更重要的是，人类反馈终于能精确指向元素。传统“AI 做 PPT”的坏体验，是你只能说“第三页再高级一点”，模型就开始大范围重画。Inspector 的点选评论，让改动可以小步、局部、可审计。

运行时：它不是只能预览，还能演示和导出

open-slide 的运行时能力够完整。

开发阶段有 Vite 热重载，改代码或 Agent 写入后能快速刷新。它还有 Slide Manager，用文件夹和 emoji 管理多个 deck，适合你做了一堆内部分享、产品方案、客户演示之后继续维护。

演示阶段支持键盘导航、全屏播放、激光笔、Presenter Mode。Presenter Mode 里可以看当前页、下一页、speaker notes 和计时器，这说明它不是只面向“网页预览”，而是真考虑上台讲。

交付阶段支持导出静态 HTML 和 PDF：

BASH

pnpm build

构建结果可以放到 Vercel、Cloudflare Pages、Netlify、Zeabur，或者任何静态托管服务。没有服务端运行时，也不要求听众安装什么东西。

这点很实用。很多 AI PPT 工具最大的问题是锁在自己的编辑器或云端链接里；open-slide 输出的是普通静态产物，源码也在你的仓库里。

用它做一套技术分享，工作流应该怎么跑

建议不要一上来就让 Agent “自由发挥”。可以按四步走。

第一步，写 brief。

TEXT

主题：Agent 工具层为什么需要审计
受众：20 人工程团队内部分享
页数：8 页
风格：浅色、克制、工程感，不要赛博霓虹
文本密度：轻，每页最多 3 个要点
必须包含：问题背景、失败案例、架构图、落地清单
不需要：复杂动画、花哨转场

第二步，让 /create-slide 生成第一版。先看结构，不要急着抠像素。第一轮重点判断：页顺序对不对、每页是不是一个观点、有没有明显跑题。

第三步，用 Inspector 在浏览器里点元素批注。标题太长就点标题；图表拥挤就点图表；代码块超出画布就点代码块。别在聊天里写一大段泛泛反馈。

第四步，跑 /apply-comments，让 Agent 局部修改。改完再看 git diff：它到底动了哪些组件、删了哪些文案、调了哪些样式。

这个流程的好处是，你不是把 PPT 扔给 AI 一次性赌结果，而是把它变成了“生成—批注—应用—复查”的工程循环。

代码 Agent 做 PPT，最容易翻车的地方

第一，字太多。Agent 写文章很容易写顺手，写幻灯片也容易把一页当博客段落。固定 1920 × 1080 画布不会滚动，超出就是超出。提示里要明确“每页最多 3 个要点”“正文不超过 60 字”。

第二，字号不稳。第一页 hero 160px，第二页标题 52px，第三页正文 20px，整套 deck 看起来就散了。最好让 Agent 在文件里定义统一 tokens：

TSX

const theme = {
  colors: {
    bg: '#f8fafc',
    text: '#0f172a',
    muted: '#64748b',
    accent: '#2563eb',
  },
  font: {
    hero: 150,
    title: 88,
    body: 38,
    caption: 26,
  },
  space: {
    pageX: 140,
    pageY: 110,
  },
};

第三，动画乱用。Agent 很喜欢加 motion、blur、gradient、shadow，结果投影时糊成一片。内部技术分享优先静态或微动，别让动画抢内容。

第四，代码块太长。代码页要像讲义，不要像 IDE 截图。能删注释就删，能省略就省略，核心代码保持 8–14 行更稳。

第五，品牌素材混乱。open-slide 有 Assets Manager 和 svgl logo 搜索，这是好事，但也意味着 Agent 很容易乱抓 logo。正式对外 deck 仍然要人工确认品牌授权和视觉规范。

和 PowerPoint、Keynote 怎么分工

open-slide 不是 PowerPoint 平替，也没必要硬说它会替代 Keynote。

PowerPoint / Keynote 适合强视觉、强手工、强品牌控制的场景。比如融资路演、发布会主视觉、客户定制方案，设计师能在画布上精修每个像素。

open-slide 更适合工程化内容：技术分享、内部培训、产品方案初稿、架构说明、研发周会、开源项目介绍、代码和图表较多的内容。它的优势不是“拖拽更顺”，而是“生成、修改、版本管理和协作更像代码”。

如果你习惯用 Markdown 快速写讲稿，Slidev 可能更轻。如果你已经把 Claude Code / Codex 当工作流核心，希望同一套 Agent 能写代码、写文档、写幻灯片，open-slide 更顺。

部署和团队协作：把 deck 当 repo 管

open-slide 最好按项目仓库来管，而不是当一次性生成物。

TEXT

slides-workspace/
├── slides/
│   ├── agent-tooling-2026/
│   ├── q2-product-review/
│   └── customer-demo-acme/
├── assets/
├── CLAUDE.md
├── package.json
└── pnpm-lock.yaml

团队内可以约几条规则：

TEXT

每个 deck 一个目录；
公共主题和 tokens 抽成 shared/theme.ts；
对外 deck 必须走人工 review；
Agent 修改后必须看 git diff；
PDF 导出前必须全屏预览一遍；
客户 logo 和截图必须确认授权。

如果要让 Agent 在服务器上常驻生成 deck，可以把 open-slide 工作区、字体、素材、导出目录和预览服务放到隔离环境。尤其是客户资料、内部路线图、财务数据，别直接丢给不受控的在线编辑器。

顺手提一嘴，这类“Agent 生成静态产物”的工作流，很适合单独放一台轻量服务器：跑 pnpm dev、预览构建、导出 PDF、保存客户素材，和主业务环境分开。雨云服务器用来做这种 Agent 内容工位成本比较可控，出问题也好回滚：

给 AI PPT 和静态内容生成单独开一台工作机 预览服务、字体素材、PDF 导出和客户资料隔离管理，别和主业务服务混跑。查看雨云服务器方案 →

一个实际案例：把产品方案做成 8 页 deck

假设你要做一套“新 Agent 控制台”的产品方案。不要直接说“做个高级 PPT”，可以这样组织任务：

TEXT

做一套 8 页产品方案 deck。
主题：Agent 控制台如何管理会话、工具权限、成本和审计。
受众：产品和工程负责人。
风格：浅色、信息密度中等、偏 B2B SaaS。
页面结构：
1. 封面：一句话主张
2. 当前问题：Agent 分散运行不可控
3. 架构图：会话、工具、模型、日志四层
4. 核心功能：权限、成本、审计、回放
5. 使用流程：创建任务到复盘
6. 对比：没有控制台 vs 有控制台
7. 落地计划：两周 MVP
8. 收尾：先管住执行链路

生成后，你重点看三件事。

结构是否成立。8 页是不是顺着问题、方案、落地走，而不是堆功能。

视觉是否统一。每页标题、背景、颜色、卡片样式是否像一套东西。

内容是否可讲。不要只看页面漂亮，试着从第一页讲到第八页，看有没有断点。

然后再用 Inspector 批注：第三页架构图改成四列；第五页流程减少一步；第六页对比表删掉长句；第八页标题换得更硬一点。

这套循环跑下来，open-slide 的价值会比“一键生成 PPT”清楚得多。

它现在还不适合什么

open-slide 还很新。项目 2026 年 4 月底创建，迭代很快，Star 涨得也快，但这意味着 API、skill、运行时细节都可能继续变化。生产团队要固定版本，别每次装 latest。

它也不适合完全不想碰代码的人。虽然 Agent 能写，但你至少要能看懂基本 React、能跑 pnpm、能看 git diff。否则出了版式问题，你只能继续求模型，控制感会差。

它更不适合高度精修的品牌大稿。代码生成能做出不错的工程感 deck，但复杂品牌视觉、细腻插画、发布会级动效，仍然应该交给专业设计流程。

还有一点：幻灯片变成代码以后，隐私和版权问题更容易被忽略。Agent 可能把客户截图、内部指标、第三方 logo 写进仓库。正式团队使用时，要把 assets 目录、导出文件、预览地址和仓库权限都管起来。

最后怎么看 open-slide

open-slide 值得关注，不是因为它喊了一句“AI 写 PPT”，而是因为它把 PPT 这件事拉进了 Agent 擅长的工作区：React 组件、源码修改、skills 规则、浏览器批注、git diff、静态构建。

这条路和传统 PPT 编辑器不是同一种体验。传统编辑器让人直接控制画布；open-slide 让人通过 Agent 和代码控制画布。前者适合精修，后者适合快速生成、持续迭代和团队工程化。

如果你的日常内容是技术分享、产品方案、架构说明、内部培训，而你已经在用 Claude Code、Cursor 或 Codex，那么 open-slide 很值得试。它不会让 PPT 自动变好，但它能把“做 PPT”从手工拖拽，改造成一个可提示、可批注、可 diff、可复用的 Agent 工作流。

open-slide 上手：让 AI Agent 写 PPT，关键不是模板，是把幻灯片变成代码工程

open-slide 和 Slidev 不是一类问题

最小上手：先跑一个工作区

两个核心 Skill：让 Agent 先读规则，再写页面

Inspector：让反馈落到源码里，而不是散在聊天记录里

运行时：它不是只能预览，还能演示和导出

用它做一套技术分享，工作流应该怎么跑

代码 Agent 做 PPT，最容易翻车的地方

和 PowerPoint、Keynote 怎么分工

部署和团队协作：把 deck 当 repo 管

一个实际案例：把产品方案做成 8 页 deck

它现在还不适合什么

最后怎么看 open-slide

文章目录

评论