2025 年 9 月 – TrilightLabs

接上篇文字换成 Vue 框架来做前端搭建。Gradio 有个缺陷，没法灵活调整左侧任务栏卡片，因为涉及到删除管理操作，点击加载历史内容。框架存在局限，而Vue 能够很好的解决这个问题。

顺便一提，还是Cursor+Claude 好用，是真正再理解你的意思去解决问题，Qoder有点兜圈子，回头还是原地杵。

以下是效果图，比我预期完成的更好。这次的效果比 Gradio 完成度更高，之前存在卡片未对齐，文本摆放不美观的问题。

我实现了以下功能：

添加了Nano banana edit 编辑模型API （触发条件就是只要用户上传图像）
左侧列表排序逻辑最新的越靠前，可以删除任意卡片
生成的效果图可以点击下载，显示图像分辨率字样
Canvas 原生局部重绘组件
支持双图混合输入

知识点-使用图床将图像传入编辑模型

因为都在本地调试，除了接入好 Nano banana edit 编辑模型外，要接入图床，这样能够实现图像传输到编辑模型。图像的传输格式选择是 Base 64，同时接入Kie.ai 提供的免费图床 API 。对此，一个图像编辑需求功能才算正常跑通。

Cursor+claude 图片局部重绘遇到无法编辑图像

诊断为Canvas污染机制，当Canvas中绘制了跨域图片时，浏览器会将整个Canvas标记为”tainted”

我们的流程：AI图片 → 加载到Canvas → 用户涂抹 → 导出Base64 → 上传到图床

失败点：在导出Base64这一步失败了

Cursor+claude 是如何解决的

预防措施（图片加载阶段）

预处理图片：在加载到Fabric.js之前，先将图片转换为干净的Base64数据
避免污染源：不使用crossOrigin，通过Canvas重绘创建同源数据
完全控制：所有图片都经过我们的干净Canvas处理

兜底措施（导出阶段）

直接导出：先尝试正常的toDataURL()
重绘导出：如果失败，使用Canvas重绘技术
服务器端：如果还失败，发送数据到服务器合成（预留）

技术流程

原始图片URL → createCleanImageBase64() → 干净的Base64 → Fabric.js

以上图片的局部重绘得以解决。

Fabric.js 会出现已知的画笔漂移

去掉Fabric.js，改用vue原生的 Canvas 局部重绘。

后续考虑后续增加 Seedream 的模型API、腾讯混元3.0 模型的API接入，这个后续再研究，相信是个更有意思的事情……

该工具流程主要是面向需求量集中，使用人群面向团队内部，小组群体。方便管理者统一核算成本。下面分享我使用的开发工具是阿里最近推出 Qoder（使用的是 Qwen 大模型），接入 Gemini-nano-banana的api ，并通过 Gradio 框架搭建一个简单的 web 界面。

1、通过Qoder编写一个简单的web文生图界面

新用户 1000 个积分，我的使用感受下来是能够满足基本的功能搭建，我是没有任何代码阅读能力的，所以全程都是从一个视觉设计师的角度来请求命令，产生的 bug 较多。当通过一条命令要求生成小猫图片后，1000 个积分已经消耗完毕。完成的界面效果图如下：

这个界面左侧是任务列表，右侧是对话列表（上半部分是当前任务的生成记录，下半部分是输入框），可以上传图片、局部重绘，以及底部的提示词范本。这还是基本效果，细节布局还待优化，耗时1天搭建。

2、我是如何接入 Gemini-nano-banana 的 API ？

一开始我尝试使用 Google AI studio 获取 api，提供 api 的示例样本给到 Qoder，测试下来能够调用成功，但是会出现 404，通过排查发现是要升级到计费账户，也就是需要国外注册地的 Google 账号，同时你要使用到境外的信用卡才能订阅。

这一步就走不通。选择用了第三方的API接口，我使用的是 https://kie.ai/zh-CN ,一个中国人做的，包含了很多大模型的接口（Chatgpt、VEO3、midjourney、Runway、flux kontext……）最便捷的还是付款方式非常方便，支持支付宝…..

这是 Nano banana api 接口信息：https://kie.ai/nano-banana?model=google%2Fnano-banana-edit

它包含三个类型：生图模型、编辑模型、高质量模型，也就是说完成从生图需求到编辑图像需求，再到高质量图像的需求你需要接入这三个API的配置信息。

还有一个注意的地方，我使用的调用方式是 Query Task（Get），使用 Create Task（post）会遇到 404 问题。总的来说接入还算比较顺滑。

3、国产编程模型使用感受

使用过 Trae、Curse-Claude对比 Qoder 我觉得是体验感受是这样的，Curse-Claude > Qoder > Trae。我的命令请求都不是站在程序员角度发出的，这对大模型的中文的理解能力也有一定的挑战，我认为使用 Curse claude调试 bug 是最省心的，我用它来开发 iOS 应用程序，Trae 每次修 bug 都会说修正好了（实际上并没有），平均时间要花费3天。同样的问题，同样的提问请求下 Curse-Claude 能在1天就修完所有Bug。

Qoder 使用下来对文本理解能力很强，能够主动通过测试监控结果找到 bug，这点做的很赞。但是在每次调试 bug 过程中，总会请求不同的端口测试，上下文关联较弱。即使说清楚指定一个端口测试依然会在后续多轮测试中忘记，有待加强。附上我对它狂哄的交流记录：

就到这里，还有很多功能和 bug 需要修复。

我觉得正因为有了 Nano-banana、即梦这类模型精准的修改能力，出错也越来越少。非常适合在游戏美术团队中使用，特别是前期的新项目筹备需要大量试错，尝试不同的风格。基于这个场景下通过 N8N.io 这类自动化工具接入 Nano-banana-API，并给场景原画、角色立绘、道具设计、图标设计等等进行一些批量生成的定制化工作流。甚至编写不同的需求信息，一并交给Agent 进行排序生成管理，设定命令触发时间，通过视觉大模型检阅生成效果，不满足要求继续触发生成，而设计师只需要在第二天打开云盘审核筛选，优化生成命令，这将会是一个游戏视觉设计师与AI新的协作方式。