幻灯片制作看似简单，实则触及了Agent应用开发的核心议题：Agent的产出应以何种形态交付？open-slide项目提供了一个深刻答案：将内容本身转化为代码，让框架来消化代码运行的复杂性。这一思路，值得每一位Agent开发者深入思考。

如今，让大模型生成文本或代码已不新鲜。但当你要求一个Agent“制作一份关于某主题的幻灯片”时，挑战才真正开始。

挑战的根源在于，幻灯片是高度视觉化的产物——布局、比例、字体、配色、动画，每一项都直接影响最终呈现效果。大模型擅长内容生成，却难以精确控制视觉渲染。常见的模板填充方案相当局限：预定义PPTX模板，让模型在预留区域填充文字。这种方法极其僵化——微调布局需修改模板本身；添加动画或更换配色，又必须回到图形工具中手动操作。

更深层的矛盾在于：模板方案迫使Agent从事其不擅长的工作——在限定框架内填空，而非发挥其编写代码的核心能力。

让 Agent 写 React，而不是填空

这正是open-slide的设计哲学。它没有发明新的幻灯片描述语言，也不要求用户学习新语法，更不依赖PowerPoint或Keynote的封闭格式。它选择让每一页幻灯片都成为一个React组件，让Agent直接编写React代码。

这个选择至关重要。Agent的核心能力正是生成代码——编写JSX、编排组件、控制样式、管理状态。将“幻灯片”重新定义为“一组按序渲染的React组件”，Agent就能以最熟悉的方式，完成原本需要专用工具的任务。

open-slide的使用流程极为直接：

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

通过脚手架生成的目录结构中，每组幻灯片对应slides//下的独立目录。目录内的index.tsx文件导出三部分：设计系统（包含配色、字体、字号等）、全局样式关键帧、以及一组页面组件。每个页面组件即一页幻灯片，它们被渲染在固定的1920×1080画布上。

框架的职责是提供画布、导航、热重载、演示模式和导出工具。而Agent的职责，就是编写这些页面组件。两者分工明确，界限清晰。

设计系统即代码

在传统幻灯片工具中，设计系统是菜单里的选项——选择一个主题，再挑选配色。但在open-slide里，设计系统是一个导出的JavaScript对象：

export const design: DesignSystem = {
  palette: { bg: '#0a0e14', text: '#e6edf3', accent: '#6ee7ff' },
  fonts: {
    display: "'JetBrains Mono', 'Menlo', 'Consolas', monospace",
    body: "'Inter', -apple-system, BlinkMacSystemFont, system-ui, sans-serif",
  },
  typeScale: { hero: 132, body: 34 },
  radius: 6,
};

这段代码直接定义了视觉风格，而非“引导用户去菜单选择”。Agent可根据演讲主题直接生成配色方案——讲解深度学习时采用深色背景搭配荧光绿高亮，介绍产品发布时则使用浅色背景配合品牌色。当配色方案成为代码，Agent可以像修改任何代码一样调整它，完全无需打开图形界面。

页面组件本身也是纯粹的React代码：

const Page1: Page = () => (
  

    

      
标题
      
内容
    
  
);

这里没有复杂的模板语法，没有占位符，也没有“请在此处填入摘要”式的注释。Agent直接生成最终内容，并同时控制这些内容在画布上的精确位置和样式。

从“生成→导出”到“生成→预览→迭代”

基于模板的工作流通常是线性的：写完内容 → 导出文件 → 预览 → 发现问题 → 回到模板修改 → 重新导出。每一步都涉及不同工具间的切换。

open-slide将这个流程压缩为一个闭环：Agent生成幻灯片 → 开发服务器实时预览 → 用户在预览页面上点击元素并附加评论 → 运行/apply-comments指令 → Agent读取评论并修改对应组件 → 页面刷新。整个过程都在浏览器和终端内完成，无需切换上下文。

这一能力得益于内置的页面审查器。在开发模式下，点击幻灯片上的任意元素都可附加自然语言评论，例如“将这个标题改为蓝色”、“缩小正文字号”、“将Logo移至右上角”。这些评论会以@slide-comment标记的形式写入源代码。运行/apply-comments指令后，Agent会读取所有待处理评论，逐一修改对应组件代码，然后清除标记。

这种交互模式对Agent应用开发具有重要参考价值：它意味着Agent的输出不再是“一次生成、不可干预”的最终产物，而是一个可反复迭代的半成品。用户通过简单点击和自然语言就能引导修改方向，Agent则通过修改代码来落实这些修改。这比“重新生成整个文档”高效得多，也精确得多。

固定画布带来的工程取舍

open-slide做出了几个关键的工程决策。其中最核心的是：所有内容都渲染在1920×1080的固定画布上，而非采用响应式布局。

这一决定在幻灯片场景下是合理的。幻灯片不是网页——它无需适应各种屏幕尺寸，其目标就是填满整个投影仪或显示器屏幕。固定画布让Agent可以精确控制每个元素的位置，无需考虑断点、媒体查询或容器查询。这对Agent生成的代码是巨大的简化——它只需关心在特定视口下的表现。

固定画布也带来了导出便利。一行命令就能导出为自包含的静态HTML或用于打印的PDF，因为渲染结果已是确定的1920×1080像素，无需额外的复杂排版引擎。

当然，固定画布的代价是它无法用于需要响应式的场景。如果内容的消费端既包括大屏演示也包括手机浏览，那么open-slide的模式就不再适用。这是它为自己划定的边界。

另一个工程取舍是：它需要Node.js和React构建工具链。这不像某些Markdown转幻灯片的方案那样“写个Markdown文件就能出结果”，open-slide的产物是一个需要构建的React应用。这意味着在CI/CD流程中需加入构建步骤，也意味着分发方式更偏向静态部署，而非简单的文件分享。

对 Agent 应用开发的启发

open-slide在短时间内获得大量关注，证明它解决了真实痛点。但该项目更大的价值，在于它示范了一种模式：当Agent需要生成结构化的视觉内容时，与其让Agent去适应某种特定的内容格式（如模板填充），不如让内容格式去适应Agent的能力范围（即代码生成）。

这种模式的适用范围远超幻灯片。任何需要Agent生成带有布局、样式和交互的内容的场景——无论是技术报告、数据看板、产品页面还是教学材料——都可借鉴类似思路：为Agent提供一个固定的画布运行时，让Agent使用通用的编程语言（如React/JSX）来生产内容，而非去学习一套专用的模板语言。

这样做有几个实际优势：

第一，Agent在生成代码时，可利用编程语言的全部表达能力——条件渲染、循环、组件组合、状态管理——无需在模板语法中做出妥协或折中。

第二，迭代修改的成本极低。要修改一个元素的样式，Agent只需调整对应的样式属性，无需重新运行完整的生成流程。

第三，版本控制自然成立。幻灯片就是代码，代码就可以进行diff对比、代码审查和回滚操作。基于模板的方案很难实现这一点。

落地的边界

当然，这种模式在落地时也需考虑几个问题。

首先是安全性。Agent会编写任意的React代码，这些代码最终会被渲染到浏览器中。如果Agent的代码生成过程不慎混入恶意负载——例如在JSX中嵌入XSS攻击代码——就会导致安全问题。open-slide目前依赖于Agent自身的安全性（即假设Agent不会故意生成恶意代码），但在生产环境下，可能需要额外的代码沙箱或内容安全策略来加固。

其次是对构建流程的依赖。每次Agent修改幻灯片代码后，都需要重新构建才能看到效果。虽然热重载让这个过程几乎是瞬间完成的，但在导出和部署环节，仍然需要完整的构建流程。如果目标是快速分享一个文件，而不是部署一个站点，这个步骤就显得有些重量级了。

最后是生成的稳定性。Agent在生成React组件时，能否每次都产出结构合理、没有错误的代码？如果Agent生成的组件在构建时报错（比如忘了导入模块、拼错了属性名），修复错误本身就会打断创作流程。框架可以在错误边界处理上做更多工作，但这个风险需要开发者自己评估和把控。

回过头看，幻灯片制作似乎是一件小事，但它恰恰触及了Agent应用开发中一个更本质的问题：Agent生产的内容，究竟应该是什么形态？open-slide给出的回答是：让内容以代码的形态存在，并用框架来消解代码运行时带来的复杂度。这个思路，确实值得每个做Agent应用开发的人多看两眼。