open-slide：AI Agent 做 PPT 的正确姿势——不是生成文件，而是写代码

open-slide 的「代码即幻灯片」叙事很性感，但作为实际工作流，有几个裂缝需要被正视。

1. 学习曲线的壁垒：这不是给「会用 AI」的人用的，是给「会写 React」的人用的

文章自己也承认「不会 React 的人用不了」，说这是 feature 不是 bug。但问题是：会做 PPT 的人（产品经理、市场、销售、讲师）恰恰是不会写 React 的人。而会写 React 的人，通常不需要做那么多 PPT。

目标用户被双重筛选了：既要懂前端开发，又要频繁做演示文稿。这个交集人群，真的撑得起 2800+ Stars 的社区吗？还是说，大部分 Star 来自「觉得概念很酷」的开发者，而不是真正持续使用的用户？

2. Agent 写代码 vs Agent 生成 PPT：效率真的更高了吗？

文章的核心主张是「让 Agent 写 React 代码，而不是生成 PPT 文件」。但这里有个隐性假设：Agent 写 React 代码的效率 ≈ 人类写 React 代码的效率。

现实是：

• 写一页 React slide 需要定义布局、样式、动画、素材引用，代码量可能几十行到上百行
• 用 Cursor / Claude Code 生成这些代码，需要多轮 prompt 调优
• 每一页都要单独写组件，一个 20 页的 deck 就是 20 个组件文件

对比传统 Markdown → PPT 工具：一页 Markdown 几十个字，Agent 一次生成 20 页。如果「代码化」带来的不是效率提升，而是更重的生成负担，那工作流改进在哪里？

3. 评论驱动迭代：理想丰满，现实骨感

Inspector 的设计很精妙——点击元素写评论，Agent 批量修改。但这里有几个未经验证的假设：

• 评论的粒度问题：「标题改成红色」可以执行，但「这页感觉不够大气」怎么翻译成代码？视觉品味和代码之间没有确定性映射。
• 上下文丢失：评论是离散的标记，Agent 批量修改时能否理解「这一页的整体氛围」？还是只会机械执行每个 comment？
• 修改的副作用：改一个标题颜色，会不会破坏相邻元素的布局？Agent 是否有全局一致性检查？

目前没有看到关于这些问题的系统性解决方案，只有「设计概念」。

4. 动画和交互：「可以用 Framer Motion」不等于「有动画」

文章提到「可以用 Framer Motion 等任意库做动画」，但 Framer Motion 不是 PPT 动画。PPT 的动画系统有：

• 进入/退出/强调效果（fade, fly, zoom, etc.）
• 路径动画
• 时间轴控制
• 点击触发 / 自动播放 / 延迟

Framer Motion 是 React 动画库，做这些需要手动编写动画逻辑、时间控制、状态管理。一个「飞入 + 淡入 + 延迟 0.3s」的效果，在 PPT 里点两下，在 open-slide 里可能要写 10 行代码。对于非动画设计师来说，这是巨大的能力缺口。

5. 2800 Stars 的可持续性： hype 还是 product-market fit？

两周 2800 Stars 在 GitHub 上确实亮眼，但需要注意：

• 这个项目的传播节点是 Twitter/X 上的技术 KOL 转发
• 作者本人是 Raycast 大使，有现成的开发者影响力
• 项目刚发布， Stars 和实际使用、留存、贡献完全是三个指标

历史上有很多「两周 Star 暴涨」的项目后来沉寂。关键问题是：3 个月后，还有多少人用这个工具做实际的演讲？还是只会出现在「2026 年 cool tools 合集」里被引用一次？

---

open-slide 的方向是对的——Agent-native 工具需要专用运行时，而不是通用工具的 AI wrapper。但「方向对」不等于「产品已经可用」。目前的 open-slide 更像是一个技术宣言（demonstration）而不是生产工具（production tool）。

真正的考验是：当一个不会写 React 的产品经理，试图用它做下周的路演 PPT 时，会发生什么？