Gemini 图生图编辑指南：App、API 与最佳模型怎么选

可以。Gemini 现在已经能做图生图编辑，而且对大多数用户来说，最稳妥的默认路线就是 Nano Banana 2。 截至 2026 年 3 月 22 日，真正需要先判断的，不是“Gemini 到底支不支持图片编辑”，而是你应该走 Gemini App、Gemini API，还是在需要更高质量时升级到 Nano Banana Pro。

这点之所以重要，是因为当前搜索结果里，Google 把答案拆在了几类不同页面里。Gemini 图片生成文档 讲能力和代码，Gemini Apps 帮助页 讲 App 内怎么编辑，产品博客又在讲 Nano Banana 2 为什么变成了当前默认路线。单独看每一页都不算错，但对真正想“拿一张图让 Gemini 改一下”的人来说，仍然需要自己把这些信息拼起来。

更直接的结论其实很简单。如果你只是想上传图片、改背景、改服装、做多图融合，而且不想写代码，就优先走 Gemini App。如果你要做可重复工作流、保存上下文、多轮精修、加重试和日志，或者把图片编辑能力接进自己的产品，就优先走 Gemini API。而 Nano Banana Pro 更像是高要求成品或 App 内 Pro 重做的升级路线，不是所有人默认都该先上 Pro。

要点速览

如果你只想先拿到结论，先看这张表就够了。

这类关键词最关键的两个日期，是 2026 年 2 月 26 日，也就是 gemini-3.1-flash-image-preview 上线的时间；以及 2026 年 10 月 2 日，Google 在 deprecations 页面 上给 gemini-2.5-flash-image 标出的计划关闭时间。所以，今天最合理的默认建议通常不是最旧最便宜的那条线，也不是最贵的 Pro，而是先从 Nano Banana 2 开始。

Gemini 已经能做图生图编辑，但你该走哪条路取决于你在哪里工作

表面上看，这像是一个单一功能问题，但 Google 现在实际上把这项能力放在了至少两种完全不同的产品面里。在 Gemini App 里，图片编辑是一种面向普通用户的交互流程：你上传图片，告诉 Gemini 要改什么，继续追改，甚至可以上传多张图生成一个新场景。按当前帮助页的说法，App 里的生成和编辑主线是 Nano Banana 2，而付费用户还可以在图片生成后走 Nano Banana Pro 的重做路径。

在 Gemini API 里，逻辑就更像开发者工作流。Google 的官方图片文档把它明确写成 text-and-image-to-image：你把图片和指令一起发给模型，模型再返回修改后的图片。文档同时还强调，多轮对话式编辑是推荐做法。这就意味着，如果你在意状态延续、上下文保留、显式尺寸控制、重试和可观测性，那么 API 路线才是更自然的答案。

最容易犯的错误，就是把 App 和 API 混为一谈，以为两边的可用性、价格和限制是一回事。其实不是。Gemini Apps 当前帮助页写得很明确：免费用户下载图片的输出是 1K，付费订阅则是 2K。而 Google 在 2026 年 2 月 26 日的开发者博客里又明确写到，Nano Banana 2 在 Google AI Studio 中使用时，需要付费 API key。所以，有人说“Gemini 改图是免费的”，有人说“Gemini 改图是付费的”，两边可能都没说错，只是说的不是同一个产品面。

这也是为什么这篇文章要先解决“走哪条路”再讲提示词细节。如果你已经知道自己是开发者，请直接跳到 API 那一节。如果你只是想把现有照片换个背景、换个物件、混合几张图，Gemini App 往往是更快的起点。

开始编辑前，先把 Gemini 图片模型选对

这类文章最容易过期的地方，就是模型路线。把 Google 当前的文档、定价页和生命周期页面放在一起看，结论其实很清楚：gemini-3.1-flash-image-preview 是当前默认路线，gemini-3-pro-image-preview 是高阶路线，而 gemini-2.5-flash-image 虽然还活着，但已经明显属于 legacy 线路。

这并不意味着 2.5 完全没意义。如果你只关心官方最便宜的 1024 输出，它今天仍然有存在感。但只要你的问题变成“现在搭一个新工作流，默认该从哪一条开始”，或者你在意更高的输出尺寸、更新的默认工作方式、以及不要建在一个已经宣布退场的模型线上，那答案就会变成 Nano Banana 2。

为什么 Nano Banana 2 是现在最稳的默认选择？不是因为它在所有维度上都最强，而是因为它对这类广义“Gemini 图生图编辑”问题给出了最平衡的答案。Google 自己把它定位为快速、高吞吐、多轮编辑、快速高级修改的默认路线，而价格页又给了它从 0.5K 到 4K 的尺寸档位。对大部分人来说，这意味着它既能拿来快速改图，也能在需要时拉高输出尺寸，而不必一开始就冲到 Pro。

什么时候该升到 Nano Banana Pro？通常有三种情况。第一，你做的是海报、信息图、菜单、界面草图这种 文字本身就很重要 的图片；第二，这张图本身价值很高，重新返工的人工成本已经比模型差价更贵；第三，你本来就在 Gemini App 里，已经用 Nano Banana 2 跑出了构图，但想用 Pro 做一版更精致的最终结果。

而 gemini-2.5-flash-image 现在更像是“有意识地选择便宜 legacy 路线”，而不是一个理所当然的默认起点。它今天还没退场，所以不能说它不能用；但如果你在 2026 年写一篇新工作流文章，却还把它当第一推荐，就已经偏离了 Google 当前自己的路线。

如果你想继续深入看 Nano Banana 2 的 API 使用细节，可以接着读本地配套页 Gemini Flash Image API 指南。

在 Gemini App 里改图，怎样用得顺而不是一直和界面较劲

Gemini App 是最快的无代码入口。按 Google 当前帮助页的说明，你可以直接进入 gemini.google.com，使用 Create image 或上传图片，然后告诉 Gemini 你要改什么。这个入口现在已经不只是“文字生成一张新图”，而是真正支持几类高频图生图任务：上传一张图做局部修改、上传多张图做融合，或者针对同一张图连续多轮微调。

这也是 Nano Banana 2 和旧版本 Gemini 图片体验最大的差别。Google 在 2025 年 8 月 26 日的 App 升级博客里，把新模型的卖点直接放在“人物或宠物形象更稳定”“换服装、换场景、换背景”“多图融合”和“多轮局部编辑”上。也就是说，Gemini App 里的图片编辑，现在已经不是一个纯演示性质的功能，而是越来越像普通用户可以直接用的图生图编辑工具。

App 里想提高成功率，最关键的不是写更长，而是写得更具体。比起说“帮我把这张图改得更好看”，更有效的写法是：“把这张照片里的墙面改成深绿色，保留家具布局、窗边光线和镜头角度不变。” 这种写法之所以更稳，是因为它同时告诉模型：要改什么，以及 哪些部分绝对不要改。

App 路线有三个现实限制需要先知道。第一，帮助页明确写着，这个功能是否可用，仍然受 Gemini App 所支持的语言和地区限制影响，所以有些用户遇到的问题根本不是提示词写得不好，而是产品面本身没完全开放。第二，Google 也写明，如果请求触发政策检测，系统可能会把图片移除或拒绝生成，这时候用户很容易误以为“模型坏了”。第三，当前 Gemini App 里创建或编辑的图片都带有 可见水印 和 SynthID，所以它不是那种完全无痕的消费级改图工具。

如果你是付费用户，最值得知道的技巧就是 Redo with Pro。也就是先让 Nano Banana 2 把构图和基本修改跑出来，再通过 App 里的三点菜单走 Nano Banana Pro 的重做路径。这个方式非常适合那种“方向已经对了，但最后一版还想更精致”的场景。

怎样在 Gemini API 里做图生图编辑

当你需要稳定工作流、显式控制、日志记录，或者把这项能力接到自己的产品里时，就该用 API。Google 现在的官方图片文档把图生图编辑写成标准的 generateContent 调用：你发送图片和文本指令，模型返回文字和图片 parts。对当前工作来说，最自然的默认模型就是 gemini-3.1-flash-image-preview。

真正重要的不是“发一张图，收一张图”这么简单。Google 在文档里明确说了，多轮对话式编辑才是推荐工作方式。因为真实图片编辑几乎都不是一锤定音的：你先把背景换掉，再让植物缩小一点，再调整颜色，再把文字换成另一种语言。如果你每次都把它当成一次完全独立的请求，你等于主动放弃了 Gemini 在连续编辑上的优势。

下面是一个简洁的 Python 例子，展示当前模型名和比较稳的局部改图写法：

python
import os
import base64
from google import genai
from PIL import Image

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
source = Image.open("living-room.png")

response = client.models.generate_content(
    model="gemini-3.1-flash-image-preview",
    contents=[
        "Using the provided image, change only the blue sofa to a vintage brown leather chesterfield. "
        "Keep the pillows, room layout, camera angle, and lighting unchanged.",
        source,
    ],
)

for part in response.candidates[0].content.parts:
    if part.inline_data:
        with open("edited-room.png", "wb") as f:
            f.write(base64.b64decode(part.inline_data.data))

这个例子故意写得很窄，因为图生图编辑越具体越稳。更适合的做法通常不是写一个超级长的首发 prompt，而是在得到第一版结果之后，继续在同一轮会话里追问。Google 的文档也提供了 imageConfig，你可以显式设置 aspectRatio 和 imageSize，比如 1K、2K 或 4K，而不是只靠提示词去暗示模型。

API 路线还有两个很容易被忽略的现实点。第一，Google 当前价格页对仍在线的 Gemini 图片模型都写着 没有公开 free tier。第二，当前的 rate limits 页面 也说得很清楚：实际可用配额取决于你的 tier，应该以 AI Studio 里看到的当前值为准，而不是抄某篇博客里的固定 RPM 数字。所以，只要你是在做真实产品接入，就应该把它当成一个正式 API 来预算、限流和重试，而不是把它当成“App 改图能力的无成本外放版”。

如果你想继续看 Nano Banana 2 更完整的接入方式，下一篇应该读 Gemini Flash Image API 指南。如果你在意的是 legacy 路线何时该迁移，则更适合看 Gemini 2.5 Flash Image 替代方案。

哪些提示词写法更容易把 Gemini 改图做稳

很多 Gemini 改图失败，看起来像模型能力不够，其实是提示词太含糊。Google 在图片生成提示词指南里给出的核心原则非常直接：描述场景，不要只堆关键词。 对图生图编辑来说，这一点更重要，因为模型不仅要“生成一个结果”，还要尽量保住原图里那些你没有点名要改的东西。

第一种最有价值的模式，是 添加或移除一个元素。比较稳的写法是：描述原图、描述修改项、描述修改后的融合方式。比如：“使用这张猫咪照片，给它加一顶小小的针织巫师帽，让帽子看起来像自然地戴在头上，并且匹配原本柔和的窗边光线。” 关键不只是“加什么”，而是“这个新物件怎么融入原来的画面”。

第二种模式，是 只改一个区域。当你不希望模型把整张图都重写时，这种写法最稳。典型格式就是：“只把蓝色沙发改成复古棕色 Chesterfield，其他部分包括抱枕、房间布局和光线都不要变。” 这类 prompt 的优势在于，它明确告诉模型“修改范围”与“保护范围”。

第三种模式，是 风格迁移。这时你的目标不是“让它更好看”，而是“把一张图的质感、颜色、纹理，迁移到另一张图的主体上”。Gemini 当前支持多图输入，所以一个更实用的写法是：“使用图 1 的主体，但把图 2 的色调和绘画纹理应用到最终画面中，保持主体轮廓和构图清晰。” 这种说法比简单写一句“按第二张图风格做”更可靠。

第四种模式，是 多图融合。Google 当前文档对 Gemini 3 图片模型写明，总共可以支持 最多 14 张参考图。这意味着你可以做的远不止“单张照片小修小改”。更稳的写法是明确每一张图各自负责什么，比如：“把图 1 里的狗放到图 2 的篮球场里，保持狗的比例真实，匹配球场光线，并沿用图 2 的低机位视角。”

第五种模式，是 保护画幅和构图。Google 的提示词指南提到，编辑时 Gemini 通常会尽量保留原图比例，但并不代表它每次都完全按你想的来。如果画幅非常重要，最好直接写出来：“更新输入图片，但不要改变原始宽高比。” 如果你走 API 路线，最好再配合 imageConfig.aspectRatio 和 imageSize 一起显式控制。

更实用的心法其实就一句：强提示词不是越花哨越好，而是要同时说清楚 改哪里、保哪里、视觉逻辑保持什么不变。也正因为如此，完整场景描述通常比一串零散关键词更稳。

故障排查：Gemini 图片编辑为什么会失败，怎么修

第一个常见失败点，是 走错产品面，或者还在用旧模型思路。如果你看的还是 2.5 时代教程，然后发现设置项、模型名、默认输出都对不上，问题可能根本不是提示词。到 2026 年 3 月 22 日，当前默认故事已经是 Nano Banana 2，不是旧 preview 线。App 问题先按 App 的逻辑看，API 问题先按 API 文档看，别跨产品面排查。

第二个失败点，是 你其实想局部修改，却给了模型“全图重写”的自由。像“帮我把这张图改好看一点”这样的说法，对模型来说几乎等于允许它重做整张图。更稳的写法是：“只把墙面改成深绿色，家具布局、光线和镜头角度保持不变。” 如果 Gemini 总在过度改图，往往不是它不会做，而是你的 prompt 没有把保护范围说清楚。

第三个失败点，是 多轮编辑之后的一致性漂移。Google 自己的提示词指南就提到，如果角色一致性开始变差，最有效的修法通常不是继续在同一个对话里救火，而是带着更完整的描述，重新开一轮新对话。听上去有点反直觉，但很多时候它比在已经“跑偏”的上下文里继续修要省时间。

第四个失败点，是 画幅或裁切和预期不一样。在 App 里，这通常表现为结果被重新构图，或者重要主体的位置被改了。在 API 里，修法更直接：显式设置尺寸和比例。如果画面框架本身就是刚性要求，最好同时在提示词里强调“不要改变原始宽高比”。

第五个失败点，是 运维层面的不稳定。社区里关于旧版 Gemini 图片预览模型的反馈说明了一件很现实的事：即便当前模型线已经更成熟，图片生成也仍然是 API，不是永远完美的确定性函数。如果你要把它接进真实产品，超时、重试、日志和回退策略都应该提前设计，而不是等到线上偶发错误时才开始补。

第六个失败点，是 App 里的功能触发或政策判断被误认成“模型不会做”。一些社区反馈显示，用户看到的是“这张图没改出来”，但根因可能是功能触发路径不对、地区限制、或者安全策略判定。因此，遇到看似离谱的拒绝时，先确认该功能在你当前地区和产品面是否开放，再在显式的 create-image 或图片编辑入口里重试，而不是第一反应就认定模型本身不支持。

常见问题

Gemini 现在真的能做图生图编辑吗，还是主要还是文生图？
可以，而且已经不是边缘能力。Google 当前文档明确支持 text-and-image-to-image 编辑，Gemini App 帮助页也支持上传图片编辑和多图融合。

现在最适合做 Gemini 图片编辑的模型是哪一个？
对大多数人来说，gemini-3.1-flash-image-preview 是最稳的默认起点，也就是现在的 Nano Banana 2 路线。它兼顾了速度、价格和工作流连续性。

什么时候该上 Nano Banana Pro？
当图片里文字特别重要、你要做更高价值成品、或者返工成本已经明显高于模型差价时，再升到 gemini-3-pro-image-preview 会更合理。在 Gemini App 里，也可以把它理解为“重做最终成品”的升级路径。

Gemini 图片编辑是免费的吗？
要看你说的是哪个产品面。Gemini App 有自己的免费和付费规则；而 Google 当前价格页里，仍在线的 Gemini 图片 API 模型都没有公开 free tier。如果你要看更完整的拆分，可以接着读 Gemini 图片免费额度。

我能不能对同一张图连续多轮编辑？
可以，而且 Google 的当前文档明确推荐这种做法。Gemini App 和 Gemini API 都支持连续 refinement。

最常见的提示词错误是什么？
不是写得太短，而是写得太泛。真正能提高成功率的，是同时说清楚要改什么、什么必须保持不变，以及新的元素应该如何融入原图的光线、风格和构图。

结论

这类关键词最容易讲成一句空话：“Gemini 支持图片编辑。” 真正有用的答案不是这个，而是 你应该用哪条 Gemini 路线来完成你手上的改图任务。

如果你只想快速无代码改图，走 Gemini App。如果你要做稳定、可追踪、可多轮精修的工作流，走 Gemini API。对大多数工作，先从 Nano Banana 2 开始；只有在文本渲染、成品质量或高价值图片任务真的值得时，再升级到 Nano Banana Pro。而 gemini-2.5-flash-image 更适合被理解成“仍在线但已经偏 legacy 的最便宜路线”，而不是 2026 年的新默认答案。

这也是当前 page one 里仍然缺的东西：大家都在证明 Gemini 能改图，但很少有人先把“该走哪条路”讲清楚。只要你选对产品面、用当前模型名、再用编辑者的方式而不是关键词堆砌的方式去写提示词，Gemini 的图生图编辑已经足够实用了。