PaperBanana-CN：更适合中文科研场景的科研生图改图工作台：（支持完全自定义中转站与最新最强生图模型gpt-image-2）

Youcheng_Zong

508人浏览 · 2026-05-11 22:59:29

Youcheng_Zong · 2026-05-11 22:59:29 发布

面向中文科研场景的科研生图工作台：支持自定义中转站、`gpt-image-2` 与多模态分离配置

封面图
在论文写作、方法设计和实验展示的过程中，科研绘图往往并不只是“生成一张图”这么简单。实际工作里，常见流程通常是先让模型理解论文内容，再根据方法结构、变量关系和展示目标生成候选图，随后进行筛选、回退、继续精修，最后再导出可复用的结果。
如果工具只绑定单一官方接口，或者把文本理解与图像生成强行绑在同一条链路上，实际使用时往往会遇到接入不灵活、切换成本高、国内中转站兼容性差等问题。

基于这个使用背景，我整理并维护了一个更适合中文科研用户的版本：PaperBanana-CN。

项目定位

PaperBanana-CN 保留了 PaperBanana 面向学术插图自动化的基本思路，同时在使用方式上更偏向国内环境，重点包括：

支持第三方兼容服务与自建网关
支持多模态大模型与图像生成模型分离配置
提供全中文界面
支持候选图管理、继续精修、历史回放与导出
支持 gpt-image-2 等图像模型接入
支持 plot 类科研图表任务的工作流

它的核心定位并不是通用娱乐绘图，而是面向科研场景的图像工作台。也就是说，它更重视可控性、可复用性和链路透明度，而不是单次生成的“惊艳感”。

适用场景

主界面
PaperBanana-CN 比较适合以下几类任务：

场景	典型需求
论文图	方法框图、流程图、模块图、结构示意图
候选图生成	先快速生成多个草图，再人工筛选和收敛
继续精修	对已有候选图进行二次修改、重绘或局部调整
实验图表	需要生成科研风格的统计图、曲线图或组合图
中文科研工作流	希望界面、配置和说明更符合中文使用习惯

如果你的工作内容本身就需要“先理解，再规划，再出图，再精修”，这类工具通常会比单纯的文本生图界面更顺手。

设计思路

多模态大模型负责理解和规划

你可以让一个更适合文本理解的多模态模型负责读取论文内容、提取图意、规划结构、生成候选方案说明。这个环节更关注语义理解，而不是直接生成最终图像。

图像生成模型单独负责出图

图像侧则可以单独接入图像生成模型，例如 gpt-image-2，也可以接入其他兼容模型。这样做的好处是很直接的：文本链路和图像链路不需要来自同一个平台，服务可分别替换，成本和稳定性也更容易控制。

接入方式更适合国内环境

自定义模型配置
PaperBanana-CN 支持 OpenAI-compatible 和 Gemini-compatible 的第三方服务，也支持自建网关。
对于已经有自己的 API 服务、代理网关或统一接入平台的用户来说，不必为了使用工具额外迁移整套模型服务。

主要特性

特性	说明
全中文界面	适合中文科研用户直接使用，降低首次上手成本
自定义服务接入	可填写自己的 URL、API Key 和模型名
文本与图像分离	VLM 负责理解与规划，图像模型负责生成与精修
候选图管理	支持多候选预览、收藏、淘汰、回退与导出
继续精修	适合在已有图基础上继续修改，而不是每次重来
历史回放	可追踪生成过程，便于复现和比较
`plot` 支持	面向科研图表任务，支持统计图相关工作流
`gpt-image-2` 适配	可直接接入新一代图像生成模型

关于模型接入

实际使用中，最关键的不是“模型名写得多漂亮”，而是链路能否稳定接通。
PaperBanana-CN 的配置思路是将图像理解链路与图像生成链路分开，因此可以分别配置：

服务类型
Base URL
API Key
模型名

这样你可以根据自己的接入条件灵活组合，而不是被某一个官方平台锁死。

对于已经接好兼容网关的用户来说，这种结构会比较实用：
文本模型可以选更稳、更便宜的方案，图像模型则单独选生成效果更合适的方案。两者不必共享同一个供应商，也不必共享同一个接口形态。

关于 `gpt-image-2`

gpt-image-2 是当前图像侧比较值得关注的模型之一。
如果你的中转站已经支持这条链路，可以直接使用。

不过也需要客观看待一个现实问题：在部分中转站环境中，gpt-image-2 的稳定性并不总是理想，尤其当提示词较长时，可能会遇到超时、Cloudflare 或接口不稳定等情况。
这类问题通常不属于项目本身的功能边界，更接近服务链路兼容性与转发稳定性问题。因此，项目侧更适合做的，是尽量减少不兼容参数、拉长超时，并提供更清晰的配置与回退路径。