lark-paper-to-ppt

name	lark-paper-to-ppt
description	将学术论文、论文 PDF、arXiv/DOI、或 lark-paper-reader-codex 生成的飞书论文读书文档整理成一份有用的飞书 Slides/PPT。用于把一篇或几篇论文变成可讲述、可复习、可分享的演示文稿，重点是提炼主线、选择论文原图、讲清方法、实验结果、insight 和局限；触发语境包括：把论文做成 PPT、做一份 paper slides、把这些 reader 文档整理成演示文稿、做文献汇报 slides、把同主题论文用 PPT 呈现。

lark-paper-to-ppt

把论文变成一份有用的 PPT：不是摘要搬运，而是帮用户用图片、方法、结果和 insight 讲清楚这篇论文或这一组论文为什么重要。

Core Taste

先判断最值得讲的主线，再决定内容如何上 slide。论文结构只是素材库，不是 PPT 结构。

每页都应该让读者更理解论文，而不是只知道论文里出现过某个段落、公式或表格。不要机械套固定页型，不要把每篇论文压成同一种摘要卡片，也不要为“完整覆盖”牺牲讲述效果。

做 deck 前先在草稿里写一个很短的 story spine：

这篇/这组论文的问题是：
以前的方法卡在：
作者们的关键想法是：
它通过什么机制实现：
最有说服力的证据是：
我读完应该记住：

PPT 顺着这个 spine 走。删掉不服务这条主线的细节。

What To Put On Slides

优先使用论文原图，尤其是能解释任务、方法、实验结论和案例的图。图片放进去之后必须配上解释：这张图在证明什么、为什么重要、和主线有什么关系。

选图时按讲述价值，而不是按 Figure 编号：

• 能一眼说明问题设置的图。
• 方法总览图、pipeline 图、architecture 图。
• 最能支撑论文 claim 的主结果图表。
• 消融、诊断、可视化案例。
• 失败案例或局限相关图片。

少放大段文字。少放公式，除非公式本身是方法的核心。少放完整表格，除非表格能支撑一个明确结论。必要时可以重画简化图，而不是硬塞论文原图。

对于多篇相关论文，按同一个研究问题的推进来组织，而不是“论文 A 一页、论文 B 一页”平铺。每篇论文只承担它最有价值的角色：定义问题、提出机制、提供证据、暴露局限、或给出新的优化路径。

Source Preference

优先使用 lark-paper-reader-codex 已经生成的飞书论文读书文档，因为其中通常已有中文导读、方法解释、图注、关键实验和局限。若用户只给 PDF、arXiv、DOI 或本地论文文件，先用现有论文读取能力取得标题、摘要、正文结构、图片与关键结论，再制作 slides。

实际访问飞书文档、搜索云空间、创建 Slides 时，使用 lark skill 并遵守其中的认证、读取、图片和 Slides 命令规则。

Build Flow

1. 找到输入论文或 reader 文档。第一次读取飞书文档先 fetch outline，再只拉关键章节或关键词片段；不要一上来全量搬运。
2. 写 story spine。它是 deck 的骨架，不是交付物。
3. 从 reader 文档或 PDF/source 中挑图。每张图都要能服务一个 slide 判断。
4. 生成 8-12 页左右的飞书 Slides，除非用户明确要更短或更长。宁可少而清楚，不要堆。
5. 创建前先 dry run；创建后 fetch Slides XML，检查页数、图片数量、本地图片占位符是否已替换。
6. 最终回复给飞书 Slides 链接、使用的源文档、页数、图片数，以及没有完成的校验。

Technical Details

创建飞书 Slides、下载文档图片、插入图片、校验 XML 时读取 references/lark-slides-technical.md。只在实际制作或调试 PPT 时读取它；用户只是讨论思路时不要加载。