NanoBananaEditor：把Gemini装进浏览器的AI图像工作室

从"香蕉能做什么"说起

2024年末，Google悄悄上线了一个被社区昵称为"Nano Banana"的Gemini图像生成能力——它能文生图、能局部编辑、还能记住对话上下文做多轮调整。速度快、价格低、效果惊艳。但Google没有给它一个独立的产品界面，用户只能通过API调用。

独立开发者 markfulton 看到了这个机会。他把Nano Banana的能力打包成了一款完整的浏览器端编辑器——NanoBananaEditor，星标数从0飙升到700+只用了不到一个月，在GitHub Trending上引发了一波关注。

这个项目的核心价值很简单：让任何人都能零门槛使用Gemini图像能力，不需要写代码，不需要翻墙，只需要一个浏览器。

NanoBananaEditor界面

技术架构：前端纯静态，后端只有一条边函数

NanoBananaEditor 的架构极其精简，整个服务端只有一条 Supabase Edge Function。

浏览器（React + Zustand + Konva）
    │
    │ POST /functions/v1/nano-image
    │ Authorization: Bearer {session}
    │ x-gemini-key: {optional user's own key}
    ▼
Supabase Edge Function: nano-image
    ├─ 验证用户会话（要求邮箱已验证）
    ├─ 校验模型、尺寸、数量参数
    ├─ 扣减积分（用户自带API Key时跳过）
    ├─ 调用 Gemini（@google/genai generateContent）
    ├─ 失败或空结果时自动退款
    ├─ 写入 usage_log
    └─ 返回 { images[], text, credits, balance, usage, grounding }

前端技术栈：

React 18 + TypeScript（Vite 构建）
Zustand：全局状态管理（含画布、笔刷、历史记录）
Konva：Canvas 渲染层（缩放、平移、画笔蒙版、对比滑块）
Tailwind CSS + Radix UI：界面组件库
React Query：服务端状态
IndexedDB（idb-keyval）：历史记录本地持久化
Supabase JS：认证与 Edge Function 调用

为什么架构这么"轻"？ 作者在 Architecture 文档中写道："Nothing else runs on a server." 前端构建后是一个纯静态包，可以部署到 Cloudflare Pages、Vercel、Netlify 任意平台。唯一的运行时依赖是 Supabase Edge Function 和 Gemini API。这让部署成本极低，也让项目本质上是一个"前端 + API 代理"的组合。

核心功能详解：每个功能都是实际痛点

1. 文生图：不止于"输入文字，得到图片"

NanoBananaEditor 支持三个模型档位：

模型	ID	输出尺寸	参考图上限	搜索接地	思考模式
Nano Banana 2 Lite	gemini-3.1-flash-lite-image	1K	14张	✗	Fast/Deep
Nano Banana 2	gemini-3.1-flash-image	512/1K/2K/4K	10张	✓	Fast/Deep
Nano Banana Pro	gemini-3-pro-image	1K/2K/4K	6张	✓	始终开启

支持分辨率：512px 草稿到 4K 成品，21种比例（包含超宽屏 21:9 和超竖屏 1:8）。

不同于普通文生图工具的关键能力：

搜索接地：提示词中可以加入需要实时信息的部分（如"今天北京的天气"、"昨天的比分"），系统自动调用搜索填补真实数据，让AI图像创作不再"凭空捏造"
思考模式：Fast（快速草稿）vs Deep（深度推理），用户可自行权衡速度与质量

2. 蒙版编辑：Photoshop级别的局部改图

这是 NanoBananaEditor 最有技术含量的部分。Gemini 本身没有独立的对象擦除/局部重绘（inpainting）端点，作者通过一个巧妙的三图法实现：

发送原图
发送原图 + 紫色半透明遮罩（用户涂抹区域）
发送纯黑白掩码（白色=需修改区域，黑色=保留区域）

Gemini 看到这三张图后，会"理解"紫色区域是编辑指令，输出对应区域的修改结果。

用户可通过画笔和橡皮擦控制蒙版范围，支持缩放画笔大小（[ ] 快捷键），操作体验接近 Photoshop 但门槛低得多。

3. 多轮对话式编辑

当开启"记住对话链"时，每次编辑请求会携带前两轮对话的历史记录——前序提示词作为 User Turn，前序图片作为 Model Turn。这让"先文生图 → 再加一句'背景调暖一点'"这样的自然语言编辑流程成为可能。

4. 版本历史：每次生成都是一棵分支树

历史记录保存在 IndexedDB，刷新页面不丢失。每个历史项保存：完整输入参数、模型名称、输出图片、接地来源、积分消耗。用户可以随时回到任意历史节点继续编辑，形成分支路径。

5. 自带 API Key：零成本尝鲜

用户可以在 Settings 中粘贴自己的 Gemini API Key（来自 Google AI Studio）。Key 仅存在本地 localStorage，每次请求通过 HTTPS 直接发给 Supabase Edge Function，服务器端不存储。这是一个"用户付自己的账单"的模式，降低了项目运营者的积分成本压力。

自部署：从零到跑起来需要什么？

根据官方文档，需要以下组件：

依赖	说明
Node 18+	构建前端
Supabase 项目（免费层）	认证、积分管理、Edge Function
Supabase CLI	部署迁移和函数
Gemini API Key	来自 Google AI Studio
Stripe 账户（可选）	出售积分包

部署步骤（简化版）：

# 1. 克隆安装
git clone https://github.com/markfulton/NanoBananaEditor.git
cd NanoBananaEditor
npm install && cp .env.example .env

# 2. 填 Supabase 配置
# 编辑 .env: VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY

# 3. 推送数据库迁移
supabase login
supabase link --project-ref YOUR-PROJECT-REF
supabase db push

# 4. 设置 Gemini Key（永远不要放 .env）
supabase secrets set GEMINI_API_KEY=AIza...

# 5. 部署 Edge Function
supabase functions deploy nano-image

数据库迁移自动创建：user_credits 表（含扣减/增加积分函数）、Stripe 表、usage_log 表。新用户注册自动获得 5 个免费积分。

可选的 Stripe 积分包：创建一次性 Price → 配置 src/stripe-config.ts → 设置 Webhook → 部署 stripe-checkout 和 stripe-webhook 函数。

部署难度评估： 中等。主要门槛是 Supabase 生态的熟悉度（Edge Function 本质上是 Deno/TypeScript），以及 Stripe Webhook 的正确配置。没有 Docker 支持，纯手动配置，对于没有 Supabase 经验的开发者约需 30-60 分钟。

争议与局限

1. "Nano Banana"是内部代号还是正式名称？

Google 官方从未将 Gemini 图像模型命名为"Nano Banana"。这是社区对 Gemini Flash 图像能力的非官方昵称。项目名称和品牌建立在这个内部代号上，存在被商标争议的风险。作者可能有意为之——用接地气的名字降低认知门槛，同时规避与大厂正面竞争。

2. Gemini 的图像能力是否真的领先？

在某些评测中，Gemini 的图像生成在文字渲染（text-in-image）和复杂空间关系理解上优于 DALL-E 和 Midjourney。但其 inpainting 能力（蒙版编辑）是通过三图法"曲线救国"实现的，并非原生支持，存在效果不稳定的上限。

3. 无 GPU 需求的代价

纯前端方案省去了 GPU 成本，但意味着用户完全依赖 Google 的服务器。生成速度受网络延迟和 Gemini 服务端排队影响，4K 分辨率输出可能需要较长时间。没有本地推理选项。

4. AGPL-3.0 许可证的商业影响

项目采用 AGPL-3.0 许可证。如果第三方修改并提供服务，需开源修改版本。这对于商业闭源集成是一个限制，但对于只是想自建服务的个人和小型团队影响不大。

行业意义：中间件思维的正确姿势

NanoBananaEditor 的成功折射出一个趋势：AI 能力正在从"需要集成的底层"变成"可以直达用户的产品"。 markfulton 没有训练模型、没有维护 GPU 集群，只是把 Google 的 API 能力用更好的 UX 包装了一遍，就获得了 700+ Stars。

这验证了一种"AI 中间件"模式的价值：

找准一个强能力（Gemini 图像）
补齐一个强需求（好用的 Web UI）
用开源降低信任门槛（任何人都可以审计代码）

对于想在 AI 图像领域做产品的人，NanoBananaEditor 是一个极好的参考项目——代码量适中，架构清晰，涵盖认证、支付、API 集成、Canvas 交互等完整链路。

项目信息

Stars: 715 | Forks: 165
License: AGPL-3.0
技术栈: React 18 + TypeScript + Vite + Tailwind + Zustand + Konva + Supabase
官方部署地址: https://nanobananaeditor.dev
GitHub: https://github.com/markfulton/NanoBananaEditor

NanoBananaEditor：把Gemini装进浏览器的AI图像工作室

从"香蕉能做什么"说起

这个项目的核心价值很简单：让任何人都能零门槛使用Gemini图像能力，不需要写代码，不需要翻墙，只需要一个浏览器。

NanoBananaEditor界面

技术架构：前端纯静态，后端只有一条边函数

NanoBananaEditor 的架构极其精简，整个服务端只有一条 Supabase Edge Function。

浏览器（React + Zustand + Konva）
    │
    │ POST /functions/v1/nano-image
    │ Authorization: Bearer {session}
    │ x-gemini-key: {optional user's own key}
    ▼
Supabase Edge Function: nano-image
    ├─ 验证用户会话（要求邮箱已验证）
    ├─ 校验模型、尺寸、数量参数
    ├─ 扣减积分（用户自带API Key时跳过）
    ├─ 调用 Gemini（@google/genai generateContent）
    ├─ 失败或空结果时自动退款
    ├─ 写入 usage_log
    └─ 返回 { images[], text, credits, balance, usage, grounding }

前端技术栈：

React 18 + TypeScript（Vite 构建）
Zustand：全局状态管理（含画布、笔刷、历史记录）
Konva：Canvas 渲染层（缩放、平移、画笔蒙版、对比滑块）
Tailwind CSS + Radix UI：界面组件库
React Query：服务端状态
IndexedDB（idb-keyval）：历史记录本地持久化
Supabase JS：认证与 Edge Function 调用

核心功能详解：每个功能都是实际痛点

1. 文生图：不止于"输入文字，得到图片"

NanoBananaEditor 支持三个模型档位：

模型	ID	输出尺寸	参考图上限	搜索接地	思考模式
Nano Banana 2 Lite	gemini-3.1-flash-lite-image	1K	14张	✗	Fast/Deep
Nano Banana 2	gemini-3.1-flash-image	512/1K/2K/4K	10张	✓	Fast/Deep
Nano Banana Pro	gemini-3-pro-image	1K/2K/4K	6张	✓	始终开启

支持分辨率：512px 草稿到 4K 成品，21种比例（包含超宽屏 21:9 和超竖屏 1:8）。

不同于普通文生图工具的关键能力：

搜索接地：提示词中可以加入需要实时信息的部分（如"今天北京的天气"、"昨天的比分"），系统自动调用搜索填补真实数据，让AI图像创作不再"凭空捏造"
思考模式：Fast（快速草稿）vs Deep（深度推理），用户可自行权衡速度与质量

2. 蒙版编辑：Photoshop级别的局部改图

这是 NanoBananaEditor 最有技术含量的部分。Gemini 本身没有独立的对象擦除/局部重绘（inpainting）端点，作者通过一个巧妙的三图法实现：

发送原图
发送原图 + 紫色半透明遮罩（用户涂抹区域）
发送纯黑白掩码（白色=需修改区域，黑色=保留区域）

Gemini 看到这三张图后，会"理解"紫色区域是编辑指令，输出对应区域的修改结果。

用户可通过画笔和橡皮擦控制蒙版范围，支持缩放画笔大小（[ ] 快捷键），操作体验接近 Photoshop 但门槛低得多。

3. 多轮对话式编辑

4. 版本历史：每次生成都是一棵分支树

5. 自带 API Key：零成本尝鲜

自部署：从零到跑起来需要什么？

根据官方文档，需要以下组件：

依赖	说明
Node 18+	构建前端
Supabase 项目（免费层）	认证、积分管理、Edge Function
Supabase CLI	部署迁移和函数
Gemini API Key	来自 Google AI Studio
Stripe 账户（可选）	出售积分包

部署步骤（简化版）：

# 1. 克隆安装
git clone https://github.com/markfulton/NanoBananaEditor.git
cd NanoBananaEditor
npm install && cp .env.example .env

# 2. 填 Supabase 配置
# 编辑 .env: VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY

# 3. 推送数据库迁移
supabase login
supabase link --project-ref YOUR-PROJECT-REF
supabase db push

# 4. 设置 Gemini Key（永远不要放 .env）
supabase secrets set GEMINI_API_KEY=AIza...

# 5. 部署 Edge Function
supabase functions deploy nano-image

数据库迁移自动创建：user_credits 表（含扣减/增加积分函数）、Stripe 表、usage_log 表。新用户注册自动获得 5 个免费积分。

可选的 Stripe 积分包：创建一次性 Price → 配置 src/stripe-config.ts → 设置 Webhook → 部署 stripe-checkout 和 stripe-webhook 函数。

争议与局限

1. "Nano Banana"是内部代号还是正式名称？

2. Gemini 的图像能力是否真的领先？

3. 无 GPU 需求的代价

4. AGPL-3.0 许可证的商业影响

行业意义：中间件思维的正确姿势

这验证了一种"AI 中间件"模式的价值：

找准一个强能力（Gemini 图像）
补齐一个强需求（好用的 Web UI）
用开源降低信任门槛（任何人都可以审计代码）

项目信息

Stars: 715 | Forks: 165
License: AGPL-3.0
技术栈: React 18 + TypeScript + Vite + Tailwind + Zustand + Konva + Supabase
官方部署地址: https://nanobananaeditor.dev
GitHub: https://github.com/markfulton/NanoBananaEditor

NanoBananaEditor

社区活跃度

NanoBananaEditor：把Gemini装进浏览器的AI图像工作室

从"香蕉能做什么"说起

技术架构：前端纯静态，后端只有一条边函数

核心功能详解：每个功能都是实际痛点

1. 文生图：不止于"输入文字，得到图片"

2. 蒙版编辑：Photoshop级别的局部改图

3. 多轮对话式编辑

4. 版本历史：每次生成都是一棵分支树

5. 自带 API Key：零成本尝鲜

自部署：从零到跑起来需要什么？

争议与局限

1. "Nano Banana"是内部代号还是正式名称？

2. Gemini 的图像能力是否真的领先？

3. 无 GPU 需求的代价

4. AGPL-3.0 许可证的商业影响

行业意义：中间件思维的正确姿势

社区活跃度

NanoBananaEditor：把Gemini装进浏览器的AI图像工作室

从"香蕉能做什么"说起

技术架构：前端纯静态，后端只有一条边函数

核心功能详解：每个功能都是实际痛点

1. 文生图：不止于"输入文字，得到图片"

2. 蒙版编辑：Photoshop级别的局部改图

3. 多轮对话式编辑

4. 版本历史：每次生成都是一棵分支树

5. 自带 API Key：零成本尝鲜

自部署：从零到跑起来需要什么？

争议与局限

1. "Nano Banana"是内部代号还是正式名称？

2. Gemini 的图像能力是否真的领先？

3. 无 GPU 需求的代价

4. AGPL-3.0 许可证的商业影响

行业意义：中间件思维的正确姿势