Nano Banana 2.1 多轮编辑教程：2 轮连续改图不丢细节的 3 个回传要素

作者注：用“皇冠换红帽、再把粉心改蓝”的完整案例，讲清 Nano Banana 2.1 多轮编辑每轮要回传的对话历史、上一轮图片和思维签名，实现局部修改不丢前一轮成果。

很多开发者第一次用 gemini-nano-banana-2.1 改图时都会遇到同一个问题：第一轮改得很好，第二轮想再微调一个小地方，结果上一轮的修改被“冲掉”了，或者整张图的风格被重画了一遍。本文将介绍 Nano Banana 2.1 多轮编辑的正确回传方式，帮助你实现 2 轮连续改图而不丢细节。

这不是又一篇概念科普，而是围绕一个可复现的案例展开：第一轮把角色头上的皇冠换成红帽，第二轮只把粉色爱心改成蓝色，同时保住红帽。我们会给出两轮请求的完整代码，并说明每一轮到底要带什么数据。

核心价值：读完本文，你将弄清 Nano Banana 2.1 多轮编辑的工作机制，知道每轮请求必须回传的 3 个要素，并能直接套用代码完成局部连续编辑。

Nano Banana 2.1 多轮编辑核心要点

先把概念说准确。所谓 Nano Banana 2.1 的“原生多轮”编辑，更严谨的说法是“连续编辑”：每一轮都是一次独立的 API 请求，模型之所以能“记住”上一轮改了什么，是因为你在请求里把上下文完整带回去了，而不是服务端替你保存了会话。

Nano Banana 2.1 多轮编辑为什么会“丢细节”

最常见的错误做法，是第二轮只发一句“把粉心改成蓝色”，再附上原始图片。这样模型看到的仍然是戴皇冠的原图，自然会把皇冠保留下来，第一轮的红帽也就消失了。另一种错误是只附上第一轮输出的图片、不带历史，此时模型虽然拿到了红帽版本，但并不知道这顶红帽是“刚刚刻意改出来、需要保留的”，容易在第二轮顺手改动帽子的颜色或形状。

真正稳定的做法，是把第一轮的完整交互当作对话历史传回去：用户说了什么、模型返回了哪张图、模型回复上附带的签名是什么。Google 官方文档对图片编辑的多轮场景也是这样描述的，模型通过历史中的签名延续推理上下文，从而只改你指定的局部。

Nano Banana 2.1 多轮编辑的请求结构

第二轮请求的 contents 是一个按时间顺序排列的数组，至少包含三段：第一轮的 user 消息（原图加指令）、第一轮的 model 回复（含输出图片和签名）、第二轮新的 user 指令。关键在于 model 回复那一段要“原样回放”，不能只抽出图片 base64 重新组装，否则签名字段很容易在转换中丢失。

Nano Banana 2.1 多轮编辑快速上手

下面用 Python 和 requests 库直接调用 Gemini 原生 generateContent 格式。之所以不用 OpenAI 兼容的 chat 格式，是因为多轮编辑需要回传 thought signature 和图片 part，原生格式能最大程度保留这些字段的原始结构。

准备工作清单

极简示例：第 1 轮把皇冠换成红帽

第一轮就是一次普通的图片编辑请求：一个 user 消息，里面放原图和指令。重点是把返回的 model 内容完整保存下来，下一轮要用。

import base64, requests

BASE_URL = "https://api.apiyi.com/v1"  # API易 统一接口，原生格式路径以文档中心说明为准
API_KEY = "YOUR_API_KEY"
MODEL = "gemini-nano-banana-2.1"
URL = f"{BASE_URL}/models/{MODEL}:generateContent"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}

img_b64 = base64.b64encode(open("origin.png", "rb").read()).decode()
user1 = {"role": "user", "parts": [
    {"inline_data": {"mime_type": "image/png", "data": img_b64}},
    {"text": "把角色头上的皇冠换成一顶红色的帽子，其他内容保持不变。"}]}

resp = requests.post(URL, headers=HEADERS, json={
    "contents": [user1],
    "generationConfig": {"responseModalities": ["TEXT", "IMAGE"]}}).json()
model1 = resp["candidates"][0]["content"]  # 原样保存，含图片和 thoughtSignature

这里最值得注意的是最后一行：model1 直接取 candidates[0].content 整个对象，而不是只取其中的图片数据。这个对象里的 parts 可能同时包含文字、图片和 thoughtSignature 字段，原样保存就不会遗漏任何一项。

完整示例：第 2 轮只把粉心改蓝，保留红帽

第二轮的核心就是拼装 contents：[user1, model1, user2]。下面的完整代码包含两轮调用、签名检查和图片保存，可以直接运行。

import base64
import requests

BASE_URL = "https://api.apiyi.com/v1"  # 通过 API易 调用，原生格式路径以 docs.apiyi.com 为准
API_KEY = "YOUR_API_KEY"
MODEL = "gemini-nano-banana-2.1"
URL = f"{BASE_URL}/models/{MODEL}:generateContent"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}
GEN_CONFIG = {"responseModalities": ["TEXT", "IMAGE"]}


def call(contents):
    """发送一次 generateContent 请求，返回 model 回复的完整 content 对象"""
    r = requests.post(URL, headers=HEADERS,
                      json={"contents": contents, "generationConfig": GEN_CONFIG},
                      timeout=180)
    r.raise_for_status()
    return r.json()["candidates"][0]["content"]


def save_image(content, path):
    """从 model 回复中取出图片并保存"""
    for part in content.get("parts", []):
        data = part.get("inlineData") or part.get("inline_data")
        if data:
            open(path, "wb").write(base64.b64decode(data["data"]))
            return True
    return False


def has_signature(content):
    """检查回复中是否带有思维签名"""
    return any("thoughtSignature" in p or "thought_signature" in p
               for p in content.get("parts", []))


# ---------- 第 1 轮：皇冠 → 红帽 ----------
img_b64 = base64.b64encode(open("origin.png", "rb").read()).decode()
user1 = {"role": "user", "parts": [
    {"inline_data": {"mime_type": "image/png", "data": img_b64}},
    {"text": "把角色头上的皇冠换成一顶红色的帽子，其他内容保持不变。"}]}

model1 = call([user1])
save_image(model1, "round1_red_hat.png")
print("第 1 轮签名存在:", has_signature(model1))

# ---------- 第 2 轮：粉心 → 蓝心，保留红帽 ----------
user2 = {"role": "user", "parts": [
    {"text": "在上一张图的基础上，只把胸前的粉色爱心改成蓝色。"
             "红色帽子和其他所有细节保持不变。"}]}

# 关键：完整历史 + 原样回传的 model1（含上一轮图片与签名）
history = [user1, model1, user2]
model2 = call(history)
save_image(model2, "round2_blue_heart.png")
print("第 2 轮签名存在:", has_signature(model2))

# 如需第 3 轮，继续追加：history += [model2, user3]

🚀 快速开始：建议先在 API易 apiyi.com 用免费测试额度把上面两轮代码跑通，确认 round2 图片里红帽仍在、只有爱心变色，再接入自己的业务流程。

第 2 轮指令的写法技巧

连续编辑能不能“只改局部”，除了回传结构，指令写法也有影响。我们建议在第二轮指令里同时说清三件事：基于哪张图改、改哪里、哪些必须保持不变。例如“在上一张图的基础上，只把粉色爱心改成蓝色，红色帽子和其他细节保持不变”，比单纯一句“改成蓝色”要稳定得多。

另外，第二轮不要再重复附上原始图片。原图已经在 user1 里了，如果在 user2 里再放一次，模型可能会把它理解为新的参照对象，反而回到皇冠版本。

Nano Banana 2.1 多轮编辑三种回传方式对比

为了说明为什么必须“三要素齐全”，我们把常见的三种写法放在一起比较。下表是对不同回传方式行为的定性描述，便于你快速判断自己的代码属于哪一种。

对比解读

方式 A 对标分析：方式 A 的优点是实现最简单，每轮都是独立请求。但模型完全看不到第一轮的成果，等于重新做了一次单轮编辑。相比之下，完整历史回传能让第二轮站在第一轮的结果上继续修改。

方式 B 对标分析：方式 B 在请求体积上比较省，只传一张图。但模型缺少“红帽是刻意改出来的”这一上下文，也拿不到签名，局部一致性没有保障。对于需要连续精修的设计稿、电商主图等场景，方式 C 仍然是更稳妥的选择。

💡 选择建议：如果你的业务需要连续改两轮以上，建议直接采用方式 C。可以在 API易 apiyi.com 用同一套代码把三种方式各跑一遍，对比输出图，差异会很直观。

Nano Banana 2.1 与同系列模型的选择

API易 上的 Nano Banana 系列有多个型号，连续编辑属于编辑能力的进阶用法。下表帮助你在同系列中定位。

Nano Banana 2.1 多轮编辑常见坑排查

实际接入时，大部分“改丢了”的问题都能归结到几个固定原因。下面按出现频率整理成清单，排查时逐项核对即可。

1. 签名丢失：把 model 回复转换成自己的数据结构后再拼回去，字段名大小写或嵌套层级变了，导致 thoughtSignature 没传上去。解决办法是直接保存并回传原始 content 对象。
2. 角色写错：把第一轮的模型回复标成 user 角色，模型会把自己的输出当成用户上传的新图。model 回复必须保持 role: model。
3. 顺序颠倒：contents 必须按时间顺序排列，user1、model1、user2 依次出现，不能把新指令放在最前面。
4. 混用格式：前一轮用 OpenAI 兼容格式、后一轮改用原生格式，中间的字段转换容易丢签名。整个多轮流程建议统一使用 Gemini 原生格式。
5. 历史过长：轮次越多，请求里携带的图片越多，体积和耗时都会上涨。超过两三轮的长流程，可以考虑在关键节点把当前结果当作新原图重新开始一段历史。

🎯 技术建议：排查时可以先打印 model1 的 parts 结构，确认 thoughtSignature 字段确实存在，再检查发出的第二轮请求体里是否原样包含它。API易 apiyi.com 的文档中心有 Gemini 原生格式与多轮对话的拼装示例，可对照核对。

常见问题 FAQ

Nano Banana 2.1 多轮编辑核心要点 Key Takeaways

• 本质是连续编辑：每轮都是独立请求，上下文由客户端回传维持
• 三要素缺一不可：完整对话历史、上一轮输出图片、思维签名
• 原样回传 model 内容：直接保存 candidates[0].content，避免签名丢失
• 使用原生格式：generateContent 的 contents 结构最适合回传图片与签名
• 指令写清保留项：第二轮明确“只改哪里、哪些不变”，局部修改更稳
• 不重复附原图：第二轮附原图容易让模型回到修改前的版本
• 低成本验证：用 API易 apiyi.com 免费额度先跑通两轮再上线

总结

Nano Banana 2.1 多轮编辑的核心要点：

1. 机制：所谓多轮编辑是基于客户端回传的连续编辑，服务端自动记忆尚未验证，不应依赖
2. 回传内容：第二轮请求必须包含 user1、原样的 model1（含图片和 thought signature）以及 user2
3. 实践技巧：统一使用 Gemini 原生格式，指令中写明保留项，不在新一轮重复附上原图

掌握这三点后，“皇冠换红帽、再把粉心改蓝”这类两轮连续改图就能稳定复现，同样的结构也可以扩展到更多轮次。

推荐通过 API易 apiyi.com 快速验证效果，平台提供 OpenAI 兼容与 Gemini 原生格式接口，一个 API Key 即可调用 Nano Banana 系列及其他主流模型，按量计费，适合先小规模测试再逐步接入生产。

📚 参考资料

1. Google Gemini API 图片生成与编辑文档：官方多轮图片编辑说明
2. 链接：ai.google.dev/gemini-api/docs/image-generation

3. 说明：介绍图片编辑的请求结构和连续编辑的对话方式

4. Google Gemini API 思维签名文档：thought signature 机制说明

5. 链接：ai.google.dev/gemini-api/docs/thought-signatures

6. 说明：解释签名的作用以及在多轮请求中如何回传

7. API易 文档中心：Nano Banana 系列开发指南、多轮对话实现指南、Gemini 原生格式调用指南

8. 链接：docs.apiyi.com
9. 说明：包含接入端点、原生格式路径和历史拼装示例，是本文代码落地的对照依据

作者：APIYI 技术团队
技术交流：欢迎在 API易 网站首页联系我们，更多 Nano Banana 系列接入资料可访问 docs.apiyi.com 文档中心

延伸阅读

• Nano Banana 2 vs 2.1 文字渲染：5 组海报实测对比与选型清单:都说 Nano Banana 2.1 文字渲染更好，为什么有人觉得 2 代更准？用 5 组可复现的海报场景、验收标准和按次价格，讲清何时该换、何时不必换。
• Nano Banana 2.1 改进了什么？6 大升级拆解与 Nano Banana Pro 实力对比:Nano Banana 2.1 是 Nano Banana 2 的升级版，官方基准分数已超过 Nano Banana Pro，但实际出图真的能打赢吗？本文拆解 6 大改进点、官方与第三方评测数据，并给出 Nano Banana 2.1 与 Pro 的场景选型建议。
• Nano Banana 2.1 Pricing 价格全解析：对比 Nano Banana 2 的 5 个关键差异与省钱测算:基于 Google 官方定价页拆解 Nano Banana 2.1 Pricing：图片输出单价减半，但输入与思考 token 涨价、4K 消耗上升、取消 0.5K 档位。附 1K/2K/4K 单图成本、Batch 价格、盈亏平衡点和迁移建议。
• 一张图骗过 300 万人？用 GPT Image 2.5 做 AI 讽刺伪纪实旅游图的 2 步教程:拆解 Wytse Koetse 的巴黎讽刺视频。先用 gpt 写结构化提示词，再用 gpt-image-2.5-sunburst 或 gemini-nano-banana-2.1 批量做出“假旅游广告口吻”的伪纪实静帧。