PaperBanana

快速结论

PaperBanana 适合愿意审核每个节点、需要快速起草论文方法图或概念图的研究者。本文对应的是 dwzhu-pku/PaperBanana 活跃社区分支，不是另建一个上游项目页面。它按 Apache 2.0 发布，通过 Retriever、Planner、Stylist、Visualizer 和 Critic 多 agent 流程，把方法描述与图注变成候选插图；也提供 Gradio、Streamlit 和命令行入口。截至 2026-07-21，仓库没有正式 GitHub Release，因此应按持续变化的研究代码评估，而不是按稳定桌面产品评估。

最关键的限制不是画面是否好看，而是图是否忠实。生成模型可能漏掉分支、交换箭头方向、改写变量、虚构模块，Critic 也不能证明科研正确性。输入还会发往用户选择的 Google、OpenAI、Anthropic 或 OpenRouter 等外部模型服务；未公开论文、审稿回复、专利材料和受限数据不能在未审条款前直接提交。仓库声明称 Google 已为特定工作流申请专利，并提示类似逻辑的第三方商业应用可能受限；这不是本站的法律结论，商业使用应让专业人员结合 Apache 2.0 的专利条款、贡献归属和实际实现另行审查。

核心功能

• 五角色流程：Retriever 找参考图，Planner 拆解内容，Stylist整理视觉要求，Visualizer 生成图片，Critic 迭代修改。
• 参考驱动：可使用 PaperBananaBench 参考集辅助构图；没有数据集时也能跳过 Retriever 的 few-shot 路径。
• 多种实验模式：支持直接生成、Planner 流程、带 Stylist 或 Critic 的组合，以及完整 agent 流程。
• 多模型配置：主视觉语言模型和图像生成模型可以分别选择，并通过 Google、OpenAI、Anthropic 或 OpenRouter Key 调用。
• 候选与精修：界面可并行生成多张候选，查看中间步骤，上传已有图继续修改，并导出 PNG 或 ZIP。
• 本地界面、外部推理：Gradio、Streamlit 和 CLI 可在本机启动，但模型请求是否离开设备取决于所选供应商。
• 社区持续开发：该分支继续增加模型选择、界面和技能入口，但没有正式 release 或稳定兼容承诺。

适合人群

• 已能判断方法图逻辑是否正确，只想缩短初稿排版时间的科研人员。
• 需要一次比较多种构图方向，再人工重画最终版本的论文作者。
• 想研究参考检索、多 agent 规划和视觉批评流程的开发者。
• 能管理 API Key、供应商条款、预算和敏感材料分类的实验室。
• 不适合希望“一次生成即可投稿”、无法人工核验图文关系，或不能把材料交给外部模型处理的团队。

使用场景

较合适的流程是先提供已经脱敏的方法摘要和简短图注，只生成低分辨率构图候选；研究者核对模块、数据流、符号、颜色含义与文字后，再挑一张精修。对于统计结果，应从原始数据和可复现代码生成基础图表，PaperBanana 只参与视觉整理，不应让图像模型重新“画”柱高、误差线、样本量或显著性标记。概念图也要逐项对照正文，尤其检查箭头方向、条件分支和负向关系。

保密材料要先做数据分类。配置文件虽可放在 gitignore 路径，避免 Key 误提交，但论文内容本身仍会进入所选模型供应商的请求。使用 OpenRouter 时还多了一层路由关系；是否保留输入、用于训练、经过哪个模型及保存多久，应以当时账号计划和供应商条款为准。专利申请文本、合作方数据、未披露实验结果或受伦理审批约束的内容，只有在机构确认允许后才能上传。

价格与版本

代码按 Apache 2.0 免费提供，仓库本身没有订阅费。真实成本来自外部模型调用、并发候选数量、图像分辨率、失败重试和人工校对。一次生成 20 个候选会明显增加请求量；高分辨率精修也可能使用不同计费档。先用一张脱敏样例记录调用次数和单图成本，再决定是否批量运行。

截至 2026-07-21，dwzhu-pku/PaperBanana 没有发布正式 Release。克隆 main 得到的是滚动代码，依赖、默认模型和界面可能改变。需要复现实验时，应固定 commit、Python 环境、依赖文件、模型名称、供应商、随机参数和输入素材，并保留原始输出。Apache 2.0 许可覆盖仓库代码不等于自动覆盖外部模型输出、参考数据、字体、第三方素材或所有专利主张。

国内访问与使用体验

本地界面能减少安装后的操作门槛，但首次配置仍需要 Python 环境、依赖、至少一个有效 API Key，以及可用的模型服务。PaperBananaBench 需要另行下载；没有数据集时可以运行，但参考检索能力会变化。中文方法描述可以输入，图中文字质量取决于所选模型，长标签、数学符号和中英文混排尤其容易出现拼写或排版错误。

把项目用于论文生产时，建议保存一份“图示事实清单”：每个模块叫什么、箭头从哪到哪、哪些步骤并行、哪些是可选路径、颜色代表什么。每轮生成后按清单逐项打勾，而不是只看整体观感。API Key 应使用环境变量或被忽略的本地配置，不要写进截图、Notebook 输出或共享日志；界面若供多人访问，还要额外加身份控制并限制上传内容。

优点

• 五角色流程把构图、风格和复查分开，适合产生可比较的论文图草案。
• 活跃社区分支提供 Gradio、Streamlit 与 CLI，试验入口较完整。
• 主模型与图像模型可分别配置，能够比较不同供应商组合。
• Apache 2.0 许可证明确，便于审查仓库代码的使用条件。
• 可查看流程中间结果和多轮变化，比只接收一张最终图片更容易定位错误。
• PaperBananaBench 与参考驱动模式适合研究学术图示生成方法。

不足

• 没有正式 Release，接口、依赖、默认模型和输出行为可能随 main 改变。
• 生成图没有科研正确性保证，Critic 也可能认可事实错误或视觉误导。
• 本地启动不代表本地推理，论文文本和图片可能发送给多个外部模型服务。
• 多候选和高分辨率调用会增加费用、等待时间与失败概率。
• 参考图可能带来风格模仿、素材来源和出版许可问题，仍需人工追溯。
• 仓库免责声明提到特定工作流已有专利申请，商业团队不能只看 Apache 2.0 就下结论。
• 图中文字、数学符号、统计量和复杂流程容易出错，最终稿通常仍需可编辑工具重制。

替代品对比

常见问题 FAQ

PaperBanana 是哪个仓库？

本文只对应活跃的 https://github.com/dwzhu-pku/PaperBanana 社区分支。它延续学术插图方法并持续开发，不需要为上游实现另建一个工具页面。

PaperBanana 有稳定版本吗？

截至 2026-07-21 没有正式 GitHub Release。若论文需要复现，应固定 commit 和完整模型配置，不要只记录“使用最新版”。

本地运行会把论文内容发出去吗？

会，除非你自行替换成完全本地的兼容模型路径。默认工作流通过配置的 Google、OpenAI、Anthropic 或 OpenRouter 等服务处理文本或图像，本地界面不等于数据留在本机。

生成的图可以直接用于投稿吗？

不建议。必须核对文字、变量、数值、箭头、流程顺序、引用和图注，并确认期刊的 AI 内容政策。统计图最好由数据和代码生成，不要依赖视觉模型重画数值。

Apache 2.0 是否消除了专利顾虑？

不能这样概括。Apache 2.0 含有针对贡献的专利许可条款，但仓库免责声明另称 Google 已为特定工作流申请专利。具体商业实现是否落入相关权利范围，需要专业法律审查。

总结

PaperBanana 的合理定位是“学术插图草案与研究框架”，不是自动保证正确的出版工具。选择它时应锁定 dwzhu-pku 活跃社区分支，记录无正式 Release 的版本风险，把外部模型供应商视为真实数据边界，并为每张图执行逐项事实核验。涉及未公开研究或商业部署时，还要分别审查保密条款、第三方素材、模型输出政策和仓库提到的专利申请，再决定能否进入正式流程。