AWS Builder Center

Builder Center

三分钟博客变幻灯片 — Kiro + Slidev 实战

三分钟博客变幻灯片 — Kiro + Slidev 实战

把博客文章的链接提供给 Kiro，三分钟左右拿到一份带主题的成型幻灯片 — 无需手动调版面，可导出为 PowerPoint、PDF 或 PNG。背后是 Slidev、一套定制主题、为指标和时间线设计的 Vue 组件，以及一份把制作标准形式化下来的 Steering 文件。

Haowen Huang

痛点

你读到一篇不错的技术博客，正想把内容做成一份 PPT，分享给团队、Meetup 或者公司内部。一般流程是这样的：
  • 打开 PowerPoint 或 Keynote
  • 把段落复制粘贴成项目符号
  • 找配图、调字号、调对齐
  • 一两个小时的设计工作，内容其实早就有了
如果直接通过对话就能完成呢？把链接丢给 AI Agent，它读完文章，挑好结构，套上一致的主题，把成品交到你手上。这就是这个项目要解决的事情。

项目里有什么

这是一个基于 Slidev 的 PPT 生成工程，专门为 Kiro  驱动而设计。核心组成：
  • theme-aws-dark/ — 一套定制 Slidev 主题，自带暗色渐变背景，以及三个为内容服务的 Vue 组件（StatCard、Timeline、ComparisonTable）
  • ppt-aws-theme-demo/ 与 ppt-aws-theme-demo-cn/ — 中英文参考模板，把所有可用布局都演示了一遍
  • .kiro/steering/skill.md — 一个 Steering 文件，把约定告诉 Kiro：目录命名、语言识别、内容密度、什么场景用哪个布局
  • 预置的 Mermaid 架构图代码片段 — 常见云上场景（基础 Web 应用、Serverless、AI Agent、数据管道）都有现成模板，Agent 直接复制改名字就能用，不需要从零画图
最终效果：用一句中文请求，拿到一份成型的 PPT。

工作流

第一步：把链接发给 Kiro

在工作区里打开 Kiro，发一条消息：
把这篇博客文章转成 PPT：
https://builder.aws.com/content/3EcuvO5GFJY06xS7DyCvk6KQMKk/
或者带上要求：
把这篇博客文章转成不超过 20 页的 PPT：
https://builder.aws.com/content/3EcuvO5GFJY06xS7DyCvk6KQMKk/
输入就这一句，剩下的交给 Kiro。

第二步：Kiro 在背后做了什么

Agent 内部跑的是一条确定性流水线：
  1. 抓取页面。 先用默认模式抓一次；如果页面是 JavaScript 重型 SPA（builder.aws.com、Substack、Medium 都属于这种），自动切换到渲染模式，用真实浏览器引擎再抓一次。
  2. 识别语言。 如果原文以中文为主 → 设 lang: zh；否则 → lang: en。主题的正文字体和 Mermaid 标签字体会跟着自动切换。
  3. 读参考模板。 在动笔之前，先打开 ppt-aws-theme-demo/slides.md 以及 pages/ 里的所有章节文件，把语法、布局、组件都过一遍。
  4. 新建项目目录。 命名约定是 ppt-{规范化的主题名}/ — 永远不动模板，也不在根目录里写文件。
  5. 生成幻灯片。 封面页、四张章节分隔页、十多张内容页、结束页。如果内容长，会拆到 pages/ 下分章节管理。
  6. 选对组件。 单个数字 → 用 StatCard；时间序列 → 用 Timeline；A vs B 对比 → 用 ComparisonTable；一张幻灯片上超过四个数字 → 退回普通 Markdown 表格。
整条流水线跑完一份二十页的 PPT，大概三分钟左右。

第三步：本地预览

Kiro 会输出一行命令：
1
npm install && npx slidev ppt-{主题名}/slides.md
跑一次，开发服务器就在 http://localhost:3030/ 起来了，带热更新 — 改任何幻灯片文件，浏览器自动刷新。
/presenter/ 是演讲者模式，/overview/ 是缩略图全览。

第四步：迭代

想把某一页拆开？想换一个数字突出来？想给收尾页换个背景渐变？说一句就行：
成本那一页文字太多了，拆成两页。
收尾那一节用森林色渐变。
把那张柱状图换成 Timeline，列出三个突破点。
Kiro 改对应的 Markdown 文件，开发服务器自动捡起改动。

第五步：导出 PowerPoint

PPT 调好之后，直接导出成 PowerPoint 文件：
1
npx slidev export ppt-{主题名}/slides.md --format pptx
或者导出 PDF：
1
npx slidev export ppt-{主题名}/slides.md
第一次导出会提示安装 playwright-chromium，同意一次之后会缓存下来，后续不再要装。

完整流程：四条命令搞定 URL 到 PPTX

仓库克隆好、npm install 跑过一次之后，以后每次把博客转成 PPT，都是同样的四步。假设明天你拿到一个新链接，比如 https://example.com/my-new-post。

1. 把链接发给 Kiro

在工作区里打开 Kiro，发一句：
把这篇博客文章转成 PPT：
https://example.com/my-new-post 
Kiro 会新建一个目录，比如 ppt-my-new-post/，完成后把项目路径回复给你。

2. 浏览器里预览

1
npx slidev ppt-my-new-post/slides.md
服务起在 http://localhost:3030/，热更新已经打开 — 每次改动都会自动刷新。用它来快速过一遍幻灯片，找出要调整的地方。

3. 迭代

继续在对话框里跟 Kiro 沟通。比如：
第 7 页文字太多，拆成两页。
把成本那一节换成 Timeline，列出三个里程碑。
收尾页用森林色渐变。
Kiro 改对应的 Markdown 文件，浏览器自动刷新。

4. 导出 PowerPoint

停掉开发服务器（Ctrl+C），然后：
1
npx slidev export ppt-my-new-post/slides.md --format pptx
第一次导出时，Slidev 会提示安装 playwright-chromium，按 y 同意一次，之后会缓存下来，再也不会问。
文件会出现在 ppt-my-new-post/ppt-my-new-post-export.pptx。用 PowerPoint 或 Keynote 打开即可。搞定。

常用命令速查表

目的命令
链接转 PPT在 Kiro 对话框里发链接
本地预览npx slidev ppt-{主题}/slides.md
导出 PPTXnpx slidev export ppt-{主题}/slides.md --format pptx
导出 PDFnpx slidev export ppt-{主题}/slides.md
导出 PNG 图片npx slidev export ppt-{主题}/slides.md --format png
整个工作流就这些。不用再记别的。

一个真实的例子

Example to generate a pptx file with a blog post link #1
昨天我把这条链接丢给 Kiro：
https://builder.aws.com/content/3CQFzc91nM9sGkfHRbpjo4eXojf/deploying-openclaw-on-amazon-ec2-a-developers-perspective 
大约三分钟之后，ppt-openclaw-aws-ec2/ 已经躺在那了，17 张幻灯片，按章节组织：
章节内容
Part 1：什么是 OpenClaw功能、动机、能拿到什么
Part 2：架构Mermaid 架构图、设计取舍、成本估算、前置条件
Part 3：部署指南美国区一键部署、参数、SSM 隧道、其他区域配置
Part 4：配置与 FAQ常用操作、排错、要点回顾
从链接到能跑起来的 PPT，整体大约三分钟。手动调版面的工作量是零。代码块自动语法高亮。
Example to generate a pptx file with a blog post link #2
后面的 FAQ 页把四个常用操作塞进一个干净的双列布局 — bash 片段直接列在那里，对齐完全自动：
Example to generate a pptx file with a blog post link #3

走进 skill.md：整套流程的大脑

.kiro/steering/skill.md 是规则真正落到纸面上的地方。Kiro 在这个工作区里每开一次新对话都会自动加载它，所以规则在多次对话之间保持一致。值得花点时间看看里面写了什么 — 这些约束就是把"链接转 PPT"这件事变成可重复操作的关键。
文件分成七大块：

1. 工作目录策略

  • 每份新 PPT 都放进独立的 ppt-{规范化主题名}/ 目录
  • 参考模板（ppt-aws-theme-demo/、ppt-aws-theme-demo-cn/）只读，绝不改动
  • 永远不在工作区根目录写文件
  • 主题路径默认是 theme: ../theme-aws-dark

2. 博客抓取策略

一条确定性的回退链，处理各种不稳定页面：
  • 先尝试 webFetch(url, mode="full")
  • 如果返回内容过小（<500 字节）、像登录墙、或者只有导航栏 → 自动改用 mode="rendered"（真实浏览器引擎，能执行 JavaScript）
  • 两次都失败 → 直接告诉用户原因，并给出替代方案（让用户粘贴正文、或者换个链接）
  • 文件里列出了已知必须用 rendered 模式的站点：builder.aws.com、Substack、Notion、一些有 Cloudflare 防护的博客。规则里特别强调：抓取失败时绝不能瞎编内容。

3. 语言识别与国际化

  • 原文以中文为主 → lang: zh
  • 否则 → lang: en
  • 用户显式覆盖优先级最高（"用中文" / "make it in Chinese"）
  • 设了 lang: zh 后，正文字体栈自动切到 PingFang SC / HarmonyOS Sans SC / Noto Sans SC，Mermaid 标签字体也跟着切
  • 文件里还提供了一套备用字体配置，给 Google Fonts 访问慢的地区用

4. 中文版的商标合规

当 lang: zh 时，Steering 文件里给出了把英文模板转中文时的替换表：
英文原文中文目标
AWS LambdaLambda
AWS web app亚马逊云科技 Web 应用
AWS services亚马逊云科技服务
built on AWS在 Amazon Web Services 上构建
Amazon Bedrock、Amazon EC2、Amazon S3 这些完整服务名保留。lang: zh 时主题会自动隐藏 AWS Logo 和页脚，但内容里要不要出现品牌字样，仍然由 Agent 把关。

5. 八步执行流程

每次生成 PPT 都按同样的顺序：
  • 完整读一遍参考模板（slides.md 加上 pages/*.md 全部）
  • 创建项目目录
  • 生成完整内容（封面、章节分隔、内容页、结束页）
  • 超过 10 张幻灯片时，拆到 pages/ 下分章节管理
  • 按需添加静态资源
  • 给出预览命令
  • 根据反馈迭代
  • 完成
第 1 步是硬性要求 — 每次都要重新读一遍模板，避免在多次对话之间走偏。

6. 内容创作规范

这一节最长，覆盖了一份 PPT 是"专业"还是"业余"的差距点：
  • 组件选型：单个数字用 StatCard，时间序列用 Timeline，A vs B 对比用 ComparisonTable，超出这三种场景就退回普通 Markdown
  • 架构图模板：五个预置 Mermaid 模板（基础 Web 应用、Serverless、简单 AI Agent、生产级 AI Agent、数据管道）。如果某个模板能覆盖 70% 的需求，直接复制改节点名，不要从零画
  • 布局选型：≤10 行内容用 default；长内容用 two-cols（带标题和滚动）；短的左右对照用 left-right；章节之间用 section
  • 内容密度：每页最多 7 条要点；超出就拆页，不要硬塞
  • 图表：每个 Mermaid 块 3-5 个节点，节点名要短，用 {scale: 0.7} 或 {scale: 0.8} 控制大小
  • 图标：优先用 emoji（🚀 ✅ 💡），少用未经验证的 <carbon:xxx />
  • 图片：优先用外部 URL，永远控制尺寸（{width=500px} 或 {width=60%}）
  • 不用动画：v-click、v-clicks、v-motion 全部禁用 — 它们会在 PDF/PPTX 导出时出问题，还会遮挡内容

7. 质量检查清单

收尾处是一份 20 多项的自查清单，Agent 在交付前会按它过一遍。包括"所有图片是否设了宽度"、"图表是否加了 scale"、"长内容是否用了 two-cols"、"是否完全没用动画"、"是否给出了预览命令"等等。
总结一下：这不是一份一次性的系统 Prompt，而是把 “什么样才算一份合格 PPT” 形式化下来一次，之后每次复用。这就是为什么同样一句话（"把这个链接转成 PPT"），在不同主题、不同语言、不同来源文章上都能跑出稳定一致的产出。
如果你要把这个项目改造成自己团队的版本，从 Steering 文件改起。换目录命名规则、换主题路径、加上自己的组件库 — 工作流的其他部分照常跑。

让这套流程跑得稳的几个设计决策

用 Steering 文件，而不是一次性 Prompt

约定写在 .kiro/steering/skill.md 里，每次对话开始时 Kiro 会自动读一遍。里面写清楚了：
  • 目录规则（永远新建 ppt-{主题}/，永远不改模板）
  • 语言识别逻辑（原文语言 → 对应 lang:）
  • 内容密度上限（每页最多 7 条要点，超出就切到 two-cols 布局）
  • 布局选型（default vs two-cols vs left-right 各自的适用场景）
  • 组件偏好（一个数字用 StatCard，多个数字用表格）
  • 博客抓取的回退链（默认模式 → 渲染模式 → 找用户问）
这种方式比一次性的 Prompt 稳，因为它能跨多次对话保持一致。

主题小而克制

theme-aws-dark/ 里只有八种布局、三个自定义组件。不是八十种，也不是三十种。Agent 不用在大量近似选项里挑，输出反而稳定。

预置架构图

大部分演讲需要的架构无非是：基础 Web 应用、Serverless API、AI Agent、数据管道。theme-aws-dark/snippets/architectures/ 里每一种都有现成 Mermaid 块。Agent 复制过来改改节点名，几乎不用从零画。

不用动画

Steering 文件里明令禁止 v-click、v-clicks、v-motion。动画在编辑器里看着炫，但在三个地方一定会出问题：PDF 导出、PPTX 导出、演讲者切换节奏。静态幻灯片是可预测的，这比花哨重要得多。

还能怎么用

同一套工作流，输入源不局限于博客链接：
  • 博客文章 URL
  • 直接粘贴的文章正文
  • 会议转写
  • 设计文档
  • README
只要是有结构的文字，Agent 都可以塑形成一份 PPT。
底层是 Markdown。主题是 Vue。构建工具是 Vite。所有东西都可编辑、可导出、可版本控制。没有专有文件格式，没有云端绑定，也没有"打开 PowerPoint 修一下格式"的尴尬。
试一下：克隆仓库，打开 Kiro ，发个链接。
1
2
3
git clone <this-repo>
cd kiro-slidev-ppt-maker
# 打开 Kiro，发：把这篇博客转成 PPT：<url>
对话本身就是工作流。
Example: Kiro generate pptx file with a blog post link #4

资源链接

  • 📦 代码仓库：github.com/hanyun2019/kiro-slidev-ppt-maker
  • 📖 Slidev：sli.dev
  • 🤖 Kiro：kiro.dev 
用 Kiro 和 Slidev 写就，献给所有不想再手动调版面的开发者。
# kiro# agentic-ide# agentic-ai# kiro-agent
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article