tejaslinge/AI-PPT-Generator：Planner 和并行 Summarizer 把 PPT 生成服务化

tejaslinge/AI-PPT-Generator 不是一个简单本地脚本。它有 API spec、Docker/Make/Postgres/PgAdmin/Bot API 服务，也有 Basic Auth 保护 slides endpoints。更准确地说，它在把 AI PPT 生成做成后端服务。

这个项目的核心链路也很清楚：Planner agent 先根据请求生成标题和 slide plans，每一页带 search question 和 layout plan；Summarizer agent 再为每一页并行生成 title、content、type 和 citations；Generator 最后套主题、字体和布局，写出 PPTX，并更新数据库状态。

Planner 先决定整套稿子的方向

Planner agent 的价值在于先给每页一个问题和布局计划。这样 Summarizer 不是随机写几页，而是围绕已经分配好的 slide object 工作。

这一步决定 deck 是否有整体方向。没有 Planner，后面的并行生成很容易变成几段互不相关的摘要。

并行 Summarizer 是为了吞吐，也带来检查压力

源码里明确创建 tasks 并 parallel execution，每个 Summarizer 返回内容、类型和 citations。并行的好处是快，尤其当每页都要调用模型或搜索时；风险是每页语气和深度可能不一致。

项目用 response model 和 required fields 检查 title、content、type、citations，说明它在尝试把并行生成约束回结构化结果。

citations 让页面不只靠模型自信

Summarizer 返回 citations，模板里也有 _add_citations，会把来源放到 slide 底部。对自动生成的 PPT 来说，这比单纯输出要点更可靠：读者至少能知道这页内容从哪里来。

主题和字体进入 API 参数，说明它离产品更近

API spec 里有 predefined_theme、theme_colors、font_settings。后端不仅生成文字，还要接受主题、配色、字体这些显示参数，再由模板 helper 写入页面。

这让它比普通 demo 更接近产品服务：请求里能控制视觉，数据库能记录状态，Docker/Make 能帮助部署，Basic Auth 能保护接口。

它适合服务化生成，不适合追求轻量

AI-PPT-Generator 适合研究如何把 PPT 生成做成 API：规划、并行摘要、引用、主题、文件生成、数据库和认证都在。代价是系统更重，部署和维护成本更高。

如果目标是一个可集成的后端服务，这种重量有意义；如果只是个人临时生成几页 PPT，轻量 CLI 可能更合适。