Edit Banana：把靜態圖轉成可編輯 DrawIO 的真實代價

它想解決的問題與真實適用對象

Edit Banana 的定位是「Universal Content Re-Editor」，目標是把固定內容變成可操作的資產。具體來說，你給它一張流程圖、多層級架構圖、技術示意圖或科學公式的截圖，它輸出一個 DrawIO XML 檔案，讓每個元素都能被拖曳、改樣式、修改文字。這解決的是文件工作流程中的一個痛點：圖一旦匯出成 PNG 或 JPEG，後續修改就得重畫。Edit Banana 想省掉這個重畫步驟。它的適用對象是那些經常處理圖表、且願意接受輸出格式為 DrawIO 的人。如果你慣用 Figma 或 Illustrator，那這個工具對你的價值會打折，因為它只輸出 DrawIO 格式。而如果你處理的是照片或自然影像，那也不是它的目標，README 示範的四個場景全部是結構化圖表。

背後的機制：SAM 3 加上多輪 VLM 重建

從 README 的 Key Features 段落可以看到，Edit Banana 的核心是 fine-tuned 的 SAM 3（Segment Anything Model 3），用來做圖表元素的「進階分割」。分割完成後，它依賴多模態大模型進行「多輪」處理，以重建圖的結構。README 提到的「Fixed Multi-Round VLM」暗示這不是一次性的端到端轉換，而是多個階段的組合：先分割出每個形狀、箭頭、文字區塊，然後讓視覺語言模型理解這些元素之間的邏輯關係，最後輸出成 DrawIO 的 XML 結構。這個架構的優點是，分割與理解分離，每個階段可以獨立除錯。缺點是，任何一個階段的誤差都會往下游累積。如果 SAM 3 把一個圓角矩形切成兩塊，後續的 VLM 可能就把一個節點重建為兩個。README 強調「1:1 restoration of shape stroke/fill and arrow styles」，這代表系統對樣式細節有專門的處理，但要做到 1:1，前提是分割必須近乎完美。

實際動手：安裝、設定與用法

README 的 Installation & Setup 與 Usage 章節在提供的材料中被截斷了，所以完整的安裝指令沒有出現。我們能確認的只有幾件事：專案使用 Python 3.10 或以上版本，README 的 badge 標示 Python 3.10+。另外它建議使用 CUDA GPU，這合理，因為 SAM 3 與多模態大模型在 CPU 上的推論速度會非常慢，但 README 沒有說明最低 VRAM 需求。專案結構包含 static/demo 資料夾，存放示範圖片與 GIF，這暗示你需要從原始碼建置，而不是透過 pip 安裝一個現成的套件。使用流程從 README 的示範 GIF 可以推測：上傳一張圖片，系統回傳 DrawIO XML，然後你可以下載或手動修補。但要注意，README 開頭有警告，GitHub 儲存庫目前落後於網頁服務。這表示你從原始碼自己架設的版本，功能可能比 editbanana.net 上的線上 demo 少，效能也可能較差。如果你想快速體驗，直接開瀏覽器上傳圖片會比自行部署更接近最新狀態。

授權與維護成本：AGPL-3.0 的雙面刃

儲存庫的 LICENSE 檔案標示為 AGPL-3.0，但 README 頂部的 badge 卻顯示 Apache 2.0。這是一個矛盾，而且不是小事。AGPL-3.0 與 Apache 2.0 的義務完全不同。AGPL-3.0 要求，如果你修改了程式碼並以網路服務形式提供給他人使用，你必須開放修改後的原始碼。Apache 2.0 沒有這個網路互動條款。當 README 與 LICENSE 檔案不一致時，實際適用的授權通常以 LICENSE 檔案內容為準，但這種不一致本身就會讓企業使用者卻步，因為法律風險不明。維護成本方面，專案最後一次 push 是 2026 年 9 月，但沒有列出任何 release。沒有 release 代表沒有穩定的版本標籤，你無法追蹤 API 是否在特定版本間改變。加上 GitHub 版本落後於網頁服務，這意味著開發團隊把主力放在線上平台，開源儲存庫更像是技術展示或學術發表的附屬品。如果你打算把 Edit Banana 整合進自己的產品，你必須自己承擔追蹤 main branch 變動的成本，而且無法依賴語意化版本控制。

真正的限制：它什麼時候會失靈

Edit Banana 的 README 示範了四種場景：基本流程圖、多層級架構、技術示意圖、科學公式。這四種都具備清晰的邊界、規則的形狀與標準的文字排列。真實世界的圖表不會總是這麼乾淨。掃描的論文圖片可能帶有噪點、傾斜、或壓縮造成的偽影。手繪的草圖則缺乏規則形狀，SAM 3 的分割可能無法產生乾淨的向量邊界。另外，README 強調「準確的文字識別」，但沒有說明它支援哪些語言。如果輸入圖包含中文、日文或數學符號，辨識準確率可能下降，這直接影響輸出 XML 中文字的可編輯性。還有一個結構性限制：輸出格式只有 DrawIO XML。DrawIO 是 diagrams.net 的原生格式，但不是文件編輯的通用標準。如果你需要把結果轉成 SVG 或 PowerPoint 可編輯的形狀，你得自己寫轉換程式，而這個專案沒有提供。最後，多輪 VLM 處理意味著每次轉換都需要較長的推論時間，而且可能消耗大量 GPU 記憶體。對於單張圖的偶爾轉換，這個成本可以接受；但如果你要批次轉換數百張圖，你需要的基礎設施遠超過一個個人工作站。

替代方案：不是只有一種「重畫」策略

Edit Banana 的競爭對手不是其他圖表轉換工具，而是兩種更傳統的策略。第一種是人工重畫，直接在 DrawIO 或 PowerPoint 裡照著原圖重新繪製。這個方法耗時，但保證結果完全正確，因為人類理解圖的語意。第二種是向量化工具，例如 potrace 或 Adobe Illustrator 的影像描摹，它們把點陣圖轉成 SVG 路徑，但不會理解圖的結構。輸出的 SVG 只是曲線的集合，形狀之間的邏輯關係、文字內容與箭頭語意全部遺失。Edit Banana 試圖填補這兩者之間的空隙：它不只是向量化，而是重建語意結構。但它的代價是需要 GPU 與大型模型，而 potrace 可以在任何筆電上迅速執行。如果你的圖只是簡單的線條稿，potrace 這類工具更輕量、更可預測。如果你的圖是複雜的架構圖，人工重畫可能比除錯 Edit Banana 的輸出還快。Edit Banana 的價值在於中間地帶：圖的複雜度夠高，人工重畫太費工，但結構又足夠規則，讓模型有機會正確理解。

結論：先驗證四類場景，再決定是否採用

Edit Banana 是一個有明確技術主張的專案，它把 SAM 3 分割與多輪 VLM 結合，試圖解決圖表重繪的自動化問題。但它的 GitHub 版本不是產品，而是一個落後於線上服務的技術展示。採用它之前，你必須親自用你的圖表跑一次，確認輸出的 DrawIO XML 是否保留了你需要的邏輯關係與樣式細節。如果結果可接受，AGPL-3.0 的授權條款與沒有 release 的維護狀態仍然需要你承擔法律與升級風險。如果結果不理想，你至少學到一件事：這類工具目前的邊界在於結構化圖表，而不是任意影像。

編輯結論

Edit Banana 適合需要把論文或簡報中的靜態流程圖、架構圖轉成 DrawIO XML 的研究者與工程師，尤其是那些已經具備 GPU 環境、且能接受 AGPL-3.0 授權條款的人。不適合尋求生産級穩定輸出、或希望 GitHub 版本與線上服務功能同步的使用者。在採用前，你應該先確認三件事：第一，你的輸入圖是否屬於 README 示範的四類場景，超出這個範圍的轉換品質沒有保證。第二，你是否具備可運行 SAM 3 與多模態大模型的 CUDA 環境，純 CPU 推論的可用性未知。第三，你是否理解 AGPL-3.0 對服務端程式的網路互動條款，若你的專案會以網路服務形式提供修改版本，原始碼公開義務可能隨之而來。最後，GitHub 儲存庫落後於網頁服務，這意味著你從原始碼獲得的體驗，可能比 www.editbanana.net 上的示範差一截。若你只是偶爾需要轉換一張圖，直接使用線上服務更實際；若你想深入研究分割與重建的技術細節，那麼這個儲存庫提供了起點，但它不是一個開箱即用的產品。

官方來源

1. BIT-DataLab/Edit-Banana on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README