banana-slides
Anionex/banana-slides加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一个很具体的场景：明天上午十点要在客户面前讲清楚新一代产品路线，而你手上只有一份写了三页的 Word 需求草稿。
传统做法是把文字丢进 PowerPoint，选个模板，然后开始"和排版搏斗"——字号不对、行距太挤、图和字挤在一起、改完第三页发现第一页的配色又显得不统一。等你终于把版式调顺了，PPT 里的配图还是那三张图库里的商务握手照。
Banana Slides（中文名"蕉幻"，取自 Google 的图像生成模型 nano banana 🍌）想解决的正是这个断层。它的做法有点激进：干脆不排版了，直接让图像模型把整页 PPT"画"出来。文字、图形、图表、留白，全部作为一张图交给 nano banana pro 生成。你给它的不是"第 3 页标题改成案例分析"，而是"把这页换成饼图风格"。
这就是它自称的「Vibe PPT」——不追求像素级可控的排版引擎，而是把 PPT 页面当作一张海报来创作。
作者 Anionex 在 README 的"项目缘起"里写得很直白：他先用 nano banana pro 试了几次 PPT 页面生成，发现效果"无论是质量、美感还是一致性都做得非常好"，于是决定干脆做一个原生的 AI PPT 应用。
这个判断背后有一个时代背景。2025 年底以来，图像生成模型的能力发生了质变——从"画个头像"进化到"能精确渲染 prompt 里的文字、能遵循参考图的风格、能生成带表格和图表的商业版面"。这直接动摇了 PPT 工具二十年来的商业模式：过去 PPT 软件卖的是"模板库 + 排版引擎"，而当模型能一次成图时，"模板"这件事本身就被绕过去了。
项目 2025 年 11 月 29 日创建，截至分析时已积累 15,819 Star、1,785 Fork、69 个 open issue，贡献者 18 人，License 为 AGPL-3.0。版本号停留在 v0.9.0 RC7（2026-09-05 发布），最近一次 push 是 2026-10-21，仍在活跃迭代。
有意思的是赞助商列表里出现了火山引擎，作者在 README 中写道"谷歌 nano banana pro 模型接口费用较高，请注意调用成本"——这提示了一个很现实的约束：这个项目的核心成本不在服务器，而在模型 API 调用费。
如果传统的 AI PPT 工具像模板填空——你从下拉框里挑一个版式，AI 往框里填字——那 Banana Slides 更像一间海报工坊：你把参考图、配色偏好、内容提纲交给画师，画师整张给你。
这个区别有实际后果：
有意思的是，项目同时在做一条"回头路"：Beta 版的可编辑 PPTX 导出，通过 backend/services/image_editability/ 这套相当复杂的模块（extractors.py 36KB、factories.py 33KB、text_attribute_extractors.py 27KB、hybrid_extractor.py 19KB）反向解析生成图中的文字与元素，重建为真正的 PowerPoint 文本框和形状。项目自己也在 README 里承认"复杂版式的还原可能存在偏差，请在交付前检查"。
从想法（一句话主题，AI 自动生成大纲 + 逐页描述）、大纲（结构化层级，可批量生成也可手改）、页面描述（最细粒度，逐页写）三条路径起步，任何一条都能用自然语言继续往下改。例如"把第三页改成案例分析"，大纲会被实时重写。
上传 PDF / DOCX / MD / TXT，后台用 markitdown + PyMuPDF + PyPDF2 解析出文本、图片链接和图表信息，解析出的图片会自动进入项目素材库。模板方面支持两种模式：统一模板（全套一个风格）和逐页独立模板（每页绑定不同模板），上传图片或 PDF 即可构建模板库，AI 会解析模板风格并自动匹配。
这是它最有辨识度的能力，分三层：整页重绘（"基于 nano banana pro 生成高清、风格统一的页面"）、框选局部重绘（overlay/replace，用户在图上划一块区域下指令）、智能擦除。技术上对应 backend/services/inpainting_service.py 与 image_editability/inpaint_providers.py（25KB，接了 Gemini、百度、火山四家 inpainting provider）。
| 导出格式 | 说明 |
|---|---|
| PPTX | 整页图片版；可开启淡入淡出等切换动画；16:9 默认比例 |
| 可编辑 PPTX（Beta） | 反解文字与元素为可编辑对象，支持 LaTeX 公式还原 |
| 标准导出 | |
| MP4 讲解视频 | AI 根据页面描述生成口语化旁白 + 字幕，多语言多音色 |
| 单页图片 | 便于二次加工 |
视频导出（tts_video_service.py 66KB）依赖 edge-tts、elevenlabs、FFmpeg/FFprobe，是一个相当完整的旁白合成链路。
项目不只有 Web UI。cli/banana_cli/ 提供了完整的 Typer CLI：创建项目、跑 workflow、导出、批量任务（JSONL 任务队列）、项目/页面/素材/模板管理，还支持 git 短 ID 前缀匹配（banana-cli projects get a1b2）。更值得注意的是 skills/banana-cli/SKILL.md——项目直接打包了 Agent Skill，让 AI Agent 可以把"生成一套 PPT"当成一个工具调用来做。
后端：Python 3.10+ / Flask 3 + SQLAlchemy + Alembic 迁移 + Pydantic 2。整体是典型的 Controller-Service 分层：
backend/
├── app.py # 应用工厂 + 路由注册
├── config.py
├── controllers/ # 11 个控制器（project 68KB、settings 59KB、export 26KB…）
├── services/ # 业务核心
│ ├── ai_service.py (65KB) 大纲/描述/图片 prompt 生成
│ ├── task_manager.py (122KB) 长任务编排与状态机
│ ├── export_service.py (93KB) PPTX/PDF/视频导出
│ ├── tts_video_service.py (67KB) 旁白与字幕
│ ├── prompts.py (83KB) 提示词工程
│ ├── ai_providers/ # provider 抽象层
│ │ ├── image/ (11 个 provider: openai/genai/lazyllm/codex/anthropic/volcengine/百度/rmbg…)
│ │ ├── text/ (5 个)
│ │ └── ocr/ (百度高精度 OCR + 表格 OCR)
│ └── image_editability/ # 可编辑 PPTX 反解引擎
├── models/ # 10 个 SQLAlchemy 模型（Project/Page/Task/Material/Settings…）
├── utils/ # pptx_builder(32KB)、pptx_math(15KB)、mask_utils、latex_utils
└── tests/ # unit(64 文件) + integration(13 文件)
前端：React + TypeScript + Vite + TailwindCSS + Zustand + i18next，代码量最大的 SlidePreview.tsx 有 192KB——预览/编辑页面承载了大量交互逻辑。测试用 Vitest + Playwright（含 e2e:ui）。
关键依赖扫描：google-genai、openai、anthropic、dashscope、zhipuai、volcengine-python-sdk、lazyllm——几乎国内外的模型厂商都接了。图像侧还有 onnxruntime（本地抠图）、opencv-python-headless、pillow、python-pptx、reportlab、PyMuPDF、edge-tts、elevenlabs。
测试密度值得表扬：backend/tests/unit/ 下 64 个测试文件，从 test_openai_oauth_controller.py 到 test_editable_pptx_equations.py、test_task_watchdog.py（30KB）、test_template_auto_match.py（19KB），覆盖相当细。package.json 里还有 test:docker、test:e2e、test:e2e:ui 三层验证脚本，以及 quick-check 一键 lint+test。
架构类型判定：三层架构（Controller → Service → Model），带 Provider 抽象工厂模式（AI 供应商可插拔）和 Task 异步编排（task_manager + task_watchdog 看门狗，负责长任务心跳与失败恢复）。
| 维度 | 评价 |
|---|---|
| 部署难度 | 低。docker compose up 即可，README 提供预构建镜像、雨云一键部署模板 |
| 环境配置 | 中。必须至少配一个 AI Provider 的 API Key，.env.example 有 5 种格式（gemini/openai/volcengine/vertex/lazyllm） |
| 资源占用 | 低。纯 CPU 即可，无 GPU 需求，4GB 内存 / 3GB 磁盘起步 |
| API 成本 | 高。nano banana pro 单次生图费用不低，页数越多越贵 |
| 学习曲线 | 低。自然语言交互本身就是交互方式 |
banana-cli workflows full --language zh --pages 8 一条命令跑完整流程，jobs.jsonl 支持批量队列，适合"一天出 50 份不同客户的提案"这类场景。README 明确写着："可自由用于个人学习、研究、试验、教育或非营利科研活动等非商业用途；闭源商业用途需获取授权。"AGPL 的传染性对企业客户是实质性的——很多公司连"内部使用"都要先过法务。如果要用它做商业化产品或对外服务，必须联系作者获取授权。这是它在企业市场最大的不确定性。
这是核心技术局限。普通 PPTX 导出中每页是整图，文字不可选、不可编辑。而 Beta 版可编辑 PPTX 走的是视觉反向工程路径——把生成图里的文字抠出来、位置还原成文本框。这条路在原理上就无法 100% 还原：字体、字号、字间距都是估计的，复杂版式（大量文本框、自定义图表、渐变底）必然走样。作者在 README 里用的是"高还原度""Beta 迭代中"这类措辞，态度是诚实的。
生图 API 是按次计费的。一份 20 页 PPT，如果每页生成 2-3 轮（初稿 + 局部重绘），实际调用量是 40-60 次。项目自带的 update_check_service.py 管的是版本检查，不是成本控制——没有 token/配额预算管理机制。对成本敏感的企业用户，这需要在应用层自己加限制。
v0.9.0-rc.7，RC 阶段意味着接口仍可能变。README 更新日志里密密麻麻的修复条目——"Codex 已连接但生图返回 400"、"PPTX 改造的 MinerU 目录不一致"、"讲解视频 FFprobe 路径错误"——也侧面说明稳定性在打磨中。
代码里有 test_reference_file_ssrf.py 这个测试文件，说明作者主动关注了 SSRF 风险（远程图片引用的 SSRF 修复记录在 RC5 更新日志里）。但项目要连 Gemini、OpenAI、火山、百度十余个外部服务，密钥管理、OAuth 令牌存储（openai_oauth_controller.py、settings.py 19KB）的安全性对安全敏感场景仍是需要审查的点。
默认推荐的 nano banana pro 走 Google GenAI，国内直连困难；README 后续才加入火山方舟、商汤 U1、DeepSeek 等国产 Provider 作为替代。国内用户需要主动切换 Provider，配置成本比"开箱即用"要高。
Banana Slides 代表了一个清晰的技术路线转变：AI PPT 的竞争焦点正在从"排版智能"转向"生成智能"。
当图像模型能一次性理解并渲染完整版面时，"文字框 + 样式模板"这套延续了二十年的 PPT 编程模型就变得不再最优。项目的 15.8K Star 不是空穴来由——它踩中了 Nano Banana 发布后的集体期待红利，知乎上"6.3K Star"的推文说明它确实在这波浪潮中成了爆款。
同时它也暴露了这条路线的软肋：整图生成天然与"可编辑"这对需求背道而驰。办公场景里 PPT 是要被人继续改的，而图片改一个字就得重画。这解释了为什么作者要投入那么多代码去写 image_editability/ 那套反解模块——那不是锦上添花，而是这条技术路线能否走通商业化的关键关口。
值得留意的是它同时在做两件方向相反的事：Agent 模式（开发计划中，AI 自动优化 PPT 内容和设计）和可编辑 PPTX 反解（进行中）。前者意味着生成逐步自动化，后者意味着成果逐步回归传统办公软件。如果两者能同时收敛，这个项目就有可能同时吃到"个人快速创作"和"企业流水线"两块市场。
从开源生态视角看，它还做了一件有意思的事——把 Agent Skill 打包进仓库。skills/banana-cli/SKILL.md 让 AI Agent 可以直接把"生成一套 PPT"当作工具调用。这可能比 Web UI 本身更有长尾价值：未来的 PPT 生成，很可能不再由人在 UI 里点，而是由 Agent 在后台批量调度。
适合：需要快速产出提案/教案/汇报的个人与中小团队；愿意为生图 API 付费；接受"整图 PPT + 有限可编辑"的形态。
不适合：需要像素级排版控制的大型企业 PPT；受 AGPL 传染顾虑的闭源商业产品；预算敏感的大批量生成场景。
推荐路径：先用 docker compose up 起一套，配火山方舟或商汤 U1 等国内可直连的 Provider，生成 5-8 页小样验证效果；再决定是否接入 banana-cli 做批量流水线。若最终需要真正的可编辑 PPTX，建议先用普通 PPTX 导出，在 PowerPoint 里核对内容准确性后再交付。
分析数据采集时间：2026-10-22 | GitHub API 实时数据：15819★ / 1785 Fork / 18 contributors / AGPL-3.0 / 架构：Flask + React + Vite