Banana Slides 開源 AI 簡報產生器：自架前你該知道的三個代價

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

市面上多數 AI 簡報工具走的是「選範本、填欄位、拼版型」這條路，把現成的版面配置餵給你。Banana Slides（GitHub：Anionex/banana-slides，AGPL-3.0，約 1.5 萬星）走的是另一條：它把每一頁簡報交給 Google 的圖像生成模型 nano banana pro 直接「畫」出來，再讓你用口語修改。這條路線看起來最自由，也最有設計感，但它不是把簡報軟體搬上雲端那麼簡單。

如果你是因為「開源、可自架」這幾個字而找到它，那麼在架起來之前，有三件事會直接改變你的判斷：自架不等於離線、漂亮的頁面是用可編輯性換來的、以及它的 AGPL 授權會決定你能不能拿它做生意。這篇就從這三個面向把它講清楚，讓你在花時間架設之前，先有足夠的資訊做判斷。

它是怎麼把簡報「畫」出來的

先講機制，因為這是 Banana Slides 跟其他 AI 簡報工具最根本的差別。

傳統的 AI 簡報產生器（包含很多你聽過的雲端服務）大致是拿範本庫裡的版型，把 AI 生成的文字塞進去，所以你會覺得成品「長得都很像」。Banana Slides 的 README 在「項目緣起」裡寫得很明白：作者發現 nano banana pro 生成的頁面「品質、美感、一致性都做得非常好，且幾乎能精確渲染 prompt 要求的所有文字」，於是決定用它來做一個「原生」的 AI 簡報應用。它的 GitHub 主題標籤裡也掛著 text2image，這個詞已經把路線說清楚了。

換句話說，每一頁簡報對這個工具而言，是一張被圖像模型渲染出來的高擬真圖片，而不是一份由文字方塊、形狀、圖表拼起來的原生投影片。這也是為什麼它敢標榜「風格高度自訂」：因為風格是模型畫出來的，不是範本限定的。

Pin

README 列出的創作路徑有三條：給它一個想法（一句話），它會自動生出大綱和逐頁描述；或你直接餵大綱、逐頁描述進去；也可以上傳 PDF、Docx、Markdown、純文字當素材，後端會解析出重點、圖片連結和圖表資訊當作生成素材，連文件裡的圖片都會自動匯進專案的素材庫重複使用。生成完之後的修改也走同一套口語邏輯，例如「把第三頁改成案例分析」「把這個圖換成圓餅圖」，支援框選局部重繪和整頁重畫兩種粒度。

Pin

它還掛了一個把成品轉成「講解影片」的功能：把每一頁的描述丟給 AI 生口語化旁白，再配上語音和字幕輸出 MP4，支援中英日多音色。要注意的是，這個功能一樣是走雲端 TTS，等於在你的 API 帳單上再多一條語音合成的費用，不是本機朗讀。

這條路線的代價會在後面幾節慢慢浮現。先記住一個前提：Banana Slides 的「漂亮」是建立在「頁面是一張圖」這個事實上，而這件事同時決定了它的可編輯性邊界。

自架 Docker，不等於離線私有

很多人看到「開源、Docker Compose 一鍵啟動」會直覺以為：裝在自己機器上，資料就不出門了。這裡要修正這個直覺。

翻開 repo 的 .env.example，第一段就是 AI_PROVIDER_FORMAT，可選 gemini、openai、volcengine、anthropic、lazyllm，後面跟著一整排 provider 的 API key 欄位：GOOGLE_API_KEY、OPENAI_API_KEY、ANTHROPIC_API_KEY、DOUBAO_API_KEY、QWEN_API_KEY、GLM_API_KEY 等等。意思是，簡報的「頁面渲染」這件最核心的事，是透過你填的雲端 API key 去呼叫外部圖像生成模型完成的。更細的配置還能把文字模型、圖片模型、圖片描述模型拆開，各用各的 provider，所以實際上一份簡報可能同時經過兩、三家雲端服務，這在算成本和評估隱私時都要算進去。

README 自己也提醒 nano banana pro 的 API 費用較高，呼叫成本要自己拿捏。更進一步，連它標榜的「可編輯 PPTX 匯出」想做到更好的還原度，都還要另外去百度智能雲申請一組 BAIDU_API_KEY 填進去（對應 issue #121）。

所以正確的理解是：你自架的是「編排層與儲存層」，頁面本身是被雲端模型畫出來的。你的簡報大綱、素材、頁面描述，最後都會送到你選的那家圖像 API。這對多數自架者其實是合理的取捨（你本來就用這些 API），但如果你的情境是「想把公司機密簡報完全留在內網、一行都不能外送」，那這個工具不是你想像中的那種離線方案。這個「自架不等於本地處理」的陷阱，在 JadeAI 這類同樣主打自架的 AI 工具上也重複出現過：儲存落在自家伺服器，不代表 AI 運算也在本地。選 provider 時也要留意：README 推薦的 AIHubMix 是一個第三方聚合代理（連結帶有 aff 聯盟參數），你等於把內容多過一手給中間人，要自己評估這層信任。

漂亮的頁面，是用可編輯性換來的

既然每一頁都是被模型畫出來的圖，那「匯出成 PPTX 之後還能不能改字」就變成一道工程難題。這是 text2image 路線的固有代價。

README 的功能列表第五項把這件事講得很誠實，標題就掛著「Beta 迭代中」：它的可編輯匯出是「把匯出圖像轉成高還原度、背景乾淨、可自由編輯圖像和文字的 PPT 頁面」。注意這個描述，它說的是「把圖像轉成」可編輯元素，是一個事後重建的工程，不是「一開始就是原生可編輯的物件」。對應的 issue #121 就是追蹤這個功能的進度。

對讀者而言，這代表兩件事。一方面，如果你的需求是「生成完之後還要大量手動改字、調數字、換公司 logo」，你要知道這條路線的匯出還原度仍在迭代，不要期待它跟傳統簡報軟體一樣隨手可改。另一方面，如果你相反，要的是「快速產出一份視覺夠水準、當下能直接上場報告」的成果，那這個取捨對你可能是值得的。

這也是它跟同類開源專案 ppt-master 剛好相反的地方。ppt-master 走的是「把 PowerPoint 原生物件（形狀、圖表、動畫、備註）還給你」的路線，原生可編輯是它的主軸；Banana Slides 走的是「先用圖像模型把頁面畫到漂亮，再想辦法還原可編輯性」。兩條路沒有誰對，但你該根據自己「事後要不要改」來選，而不是看誰星數高。如果你只是想要一個不挑設計、能快速把文字變投影片的雲端服務，那 SlideBot AI 這類範本路線反而門檻更低，不必非得自架。

README 自己也列了一張跟 Google NotebookLM 的對照表，把兩者的差異歸納成幾個定位點：NotebookLM 免費版有浮水印、頁數上限十五頁、生成後不能再加素材，而 Banana Slides 標榜無頁數上限、生成後能自由加素材、能框選和口頭修改。這張表是作者自己的定位陳述，點出了一個真實的選擇邏輯：如果你卡在 NotebookLM 的頁數上限或浮水印，自架一個 text2image 工具確實是一條出路，代價就是前面說的那些雲端 API 成本與授權義務。

部署前要先對的三個設定點

要把整套跑起來得自備付費 API key 與 Docker，動手之前可以先從 README 與 .env.example 抓出三個最容易踩雷的設定點，免得照著網路介紹文裝完卻連不上。

最關鍵的是 API key。AI_PROVIDER_FORMAT 決定你走哪個 provider 陣營，最小配置選一個填 key 就能跑，但你要先決定內容送哪家雲端（隱私與成本都在這一步決定）。再來是埠號對不上。網路上流傳的介紹文寫的是前端 3000、後端 5000，但 repo 現在實際是前端 3011、後端 5011（README 的 Windows 說明也特別提醒這兩個 port 不能被佔用），照舊文會找不到服務。還有一個容易被忽略的點：想要可編輯匯出效果好一點，要再額外去百度智能雲申請 key 填到 BAIDU_API_KEY，這個成本和 provider API 是分開算的。

另外，桌面版目前有 RC3 安裝包可以下載（v0.9.0-rc.3，2026-08-05 發布），不想碰 Docker 的人可以先試桌面版再決定要不要自架服務。Docker 路線有兩種映像檔可選：用 Docker Hub 上預先建好的 anoinex/banana-slides-frontend 與 anoinex/banana-slides-backend（docker compose -f docker-compose.prod.yml up -d，省去本地建置），或從原始碼自己建。README 也提供一個叫「雨雲」的第三方一鍵部署方案，標榜免裝 Docker，但這等於把服務開在別人的雲端機房，你的簡報內容和 API key 都會落在那台機器上，是另一個要自己評估的信任點。

授權是 AGPL-3.0，商用要想清楚

repo 的 LICENSE 是標準的 GNU AGPL v3（661 行，與 FSF 官方原文一致，沒有額外的自訂附加條款）。這裡的關鍵是 AGPL 第 13 條：如果你把這個工具當成「透過網路提供給別人使用的服務」來部署，那麼你必須向那些使用者提供你這份（含修改的）完整源碼。

對個人自用、或公司內部部署，這條幾乎不構成負擔。但如果你想直接拿它架一個對外的 AI 簡報服務來做生意，AGPL 就是一個你必須正面面對的條件：能不能做，取決於你的服務形態會不會觸發揭露源碼的義務。這點要先想清楚，免得產品上線後才發現授權跟商業模式打架。有一個常見的誤解以為「開源」等於「隨便用」，但 AGPL 的網路條款正是特別設計來補住「把別人程式碼包成網路服務就能避開分享義務」這個漏洞，所以它比 MIT 或 Apache 這類寬鬆授權更需要在部署前讀過一次。

適合誰，會踩到什麼

把上面的代價整理成一個判斷框架。

適合的人：已經在用 Gemini 或 OpenAI 圖像 API、不在意把簡報內容送雲端、而且要的是「頁面夠漂亮、能快速上場」的成果。這類人拿 Banana Slides 會覺得它的風格自由度和口語修改很對胃口。

要猶豫的人：需要把機密內容完全留在內網、或是生成後還要大量手動改字改數字的人。前者卡在它本質是雲端渲染，後者卡在可編輯匯出還是 Beta。

還有一個跨所有開源工具的共同風險要點：它現在是 0.9.x 的 RC（候選版），從 2026 年七月到八月連發 rc.1、rc.2、rc.3 三個候選版，issue 也看得到 provider 配置相關的 bug 正在密集修（例如 #546 修火山方舟 Agent Plans 設定、#539 修打包桌面版 Qwen provider 失效）。活躍是好事，但「活躍且未到 1.0」也代表你今天架的版本，下週可能就有更動，要把「定期 pull 更新」算進你的維運成本。一個務實的判斷法是：如果你的使用場景是偶爾做一份簡報、壞了重拉就行，那 RC 階段完全可以接受；如果你要把它當成團隊每天依賴的生產工具，建議等它進入正式 1.0、或至少鎖定一個你驗過的版本別再 auto update，免得某次更新改了 provider 介面，你隔天早上的簡報就開天窗。

如果你看完這三個代價還是覺得值得，那就從桌面版 RC3 開始試一張投影片，別一開始就賭全套自架；先確認 nano banana pro 的渲染品質和 API 帳單你能接受，再決定要不要把整套服務搬上自己的機器。如果你的情境偏向機密內網或重度後製，那 ppt-master 這種原生可編輯路線，或傳統範本式工具，反而更貼合你的需求。