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 批量做出“假旅遊廣告口吻”的僞紀實靜幀。