Руководство по многоэтапному редактированию в Nano Banana 2.1: 3 элемента для повторной передачи, чтобы редактировать изображение в 2 раунда подряд без потери деталей

Примечание автора: на полном примере «заменяем корону красной шапкой, а затем меняем розовое сердечко на синее» разберём, как в каждом раунде редактирования Nano Banana 2.1 передавать историю диалога, изображение с предыдущего раунда и подпись рассуждений. Так локальные изменения не затрут результаты предыдущего раунда.

Многие разработчики при первом редактировании изображения с помощью gemini-nano-banana-2.1 сталкиваются с одной и той же проблемой: в первом раунде всё получается отлично, но при попытке слегка подправить деталь во втором изменения из предыдущего раунда пропадают или стиль изображения меняется целиком. В этой статье мы расскажем о правильном способе передавать данные между раундами редактирования Nano Banana 2.1, чтобы вносить изменения в два последовательных раунда и не терять детали.

Это не очередная обзорная статья с объяснением общих понятий — мы разберём наглядный пример, который можно воспроизвести: в первом раунде заменим корону на голове персонажа красной шапкой, а во втором изменим только розовое сердечко на синее, сохранив красную шапку. Мы приведём полный код запросов для обоих раундов и объясним, какие данные нужно передавать в каждом из них.

Главная польза: после прочтения вы поймёте, как устроено многошаговое редактирование в 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

Ниже показано, как напрямую вызывать Gemini в формате generateContent с помощью Python и библиотеки requests. Мы не используем совместимый с OpenAI формат chat, потому что для многошагового редактирования нужно передавать обратно подпись thought и части с изображениями. Нативный формат лучше всего сохраняет исходную структуру этих полей.

Что подготовить

Минимальный пример: в первом раунде заменяем корону на красную шляпу

Первый раунд — обычный запрос на редактирование изображения: одно сообщение user, в котором передаются исходное изображение и инструкция. Главное — полностью сохранить содержимое ответа модели: оно понадобится в следующем раунде.

import base64, requests

BASE_URL = "https://api.apiyi.com/v1"  # APIYI 统一接口，原生格式路径以文档中心说明为准
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. Если сохранить объект целиком, ничего не потеряется.

Полный пример: во втором раунде меняем только розовое сердечко на синее, сохраняя красную шапку

Суть второго раунда — собрать contents в таком порядке: [user1, model1, user2]. Ниже приведён полный код: в нём есть оба вызова, проверка подписи и сохранение изображений. Его можно запустить как есть.

import base64
import requests

BASE_URL = "https://api.apiyi.com/v1"  # 通过 APIYI 调用，原生格式路径以 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]

🚀 Быстрый старт: сначала рекомендуем выполнить этот код с двумя раундами, используя бесплатный тестовый лимит на APIYI apiyi.com. Убедитесь, что на изображении round2 красная шапка осталась на месте, а изменился только цвет сердечка, — и затем подключайте решение к своему рабочему процессу.

Как формулировать инструкции во втором раунде

Чтобы при последовательном редактировании изменить только нужную часть изображения, важно не только правильно передать структуру, но и точно сформулировать инструкцию. Во втором раунде рекомендуем указать три вещи: какое изображение нужно изменить, что именно изменить и что должно остаться без изменений. Например, «На основе предыдущего изображения замени только розовое сердечко на синее, а красную шляпу и остальные детали оставь без изменений» — гораздо надёжнее, чем просто «Сделай синим».

Кроме того, во втором раунде не нужно повторно прикреплять исходное изображение. Оно уже есть в user1. Если добавить его ещё раз в user2, модель может принять его за новый эталон и вернуться к варианту с короной.

Сравнение трёх способов передачи данных при многоэтапном редактировании в Nano Banana 2.1

Чтобы показать, почему важно передавать «все три компонента», сравним три распространённых варианта. В таблице ниже описаны типичные результаты каждого способа — так вам будет проще определить, какой вариант используется в вашем коде.

Разбор сравнения

Способ A: его главное преимущество — простота реализации: каждый раунд представляет собой отдельный запрос. Но модель не видит результат первого раунда, поэтому фактически заново выполняет однораундовое редактирование. При передаче полной истории во втором раунде можно продолжить работу над результатом первого.

Способ B: этот вариант экономит место в запросе — передаётся только одно изображение. Но модели неизвестно, что красная шапка появилась в результате намеренного изменения, и у неё нет подписи. Поэтому сохранить локальную согласованность не гарантируется. Для задач, требующих последовательной точной доработки, например дизайна или главных изображений товаров для интернет-магазина, способ C надёжнее.

💡 Как выбрать: если в вашем сценарии нужно провести более двух раундов редактирования, сразу используйте способ C. На APIYI apiyi.com можно запустить все три варианта с одним и тем же кодом и сравнить результаты — разница будет очевидна.

Как выбрать Nano Banana 2.1 среди моделей серии

На APIYI доступно несколько моделей серии Nano Banana. Непрерывное редактирование — продвинутый сценарий работы с функциями редактирования. Таблица ниже поможет сориентироваться в моделях серии.

Частые проблемы при многошаговом редактировании в Nano Banana 2.1

На практике большинство случаев, когда результат «теряет изменения», сводится к нескольким типичным причинам. Ниже — список для проверки. При поиске проблемы проверьте каждый пункт.

1. Потеря подписи: вы преобразовали ответ модели в собственную структуру данных, а затем собрали его заново. Из-за изменения регистра названий полей или уровня вложенности поле thoughtSignature не передалось. Решение: сохраняйте исходный объект content и передавайте его без изменений.
2. Неверно указана роль: если пометить ответ модели в первом раунде как роль user, модель воспримет собственный ответ как новое изображение, загруженное пользователем. Ответ модели должен оставаться с role: model.
3. Нарушен порядок: содержимое contents нужно располагать в хронологическом порядке: user1, model1, user2 и так далее. Не ставьте новую инструкцию в начало.
4. Смешаны форматы: если в предыдущем раунде использовался формат, совместимый с OpenAI, а в следующем вы перешли на нативный формат, при преобразовании полей может потеряться подпись. Для всего многошагового процесса лучше использовать единый нативный формат Gemini.
5. Слишком длинная история: чем больше раундов, тем больше изображений передаётся в запросе, а значит, растут его размер и время обработки. Если процесс занимает больше двух-трёх раундов, на ключевых этапах можно начать новую историю, приняв текущий результат за исходное изображение.

🎯 Технический совет: для начала выведите структуру parts из model1 и убедитесь, что поле thoughtSignature действительно присутствует. Затем проверьте, что в теле отправленного запроса второго раунда оно передано без изменений. В центре документации APIYI на apiyi.com есть примеры сборки запросов в нативном формате Gemini и ведения многошагового диалога — их можно использовать для проверки.

Часто задаваемые вопросы

Ключевые выводы о многоэтапном редактировании в Nano Banana 2.1

• По сути, это последовательное редактирование: каждый этап — отдельный запрос, а контекст сохраняется благодаря тому, что клиент передаёт его обратно
• Нужны все три элемента: полная история диалога, изображение из предыдущего ответа и подпись рассуждений
• Передавайте содержимое model без изменений: напрямую сохраняйте candidates[0].content, чтобы не потерять подпись
• Используйте нативный формат: структура contents в generateContent лучше всего подходит для передачи изображений и подписи
• Чётко указывайте, что нужно сохранить: во втором запросе уточните, «что изменить и что оставить без изменений» — так локальные правки получаются надёжнее
• Не прикладывайте исходное изображение повторно: во втором запросе оно может вернуть модель к версии до изменений
• Проверить можно с небольшими затратами: сначала протестируйте два этапа на бесплатном лимите APIYI apiyi.com, а затем запускайте в продакшене

Итоги

Главное, что нужно знать о многоэтапном редактировании в Nano Banana 2.1:

1. Механизм: так называемое многоэтапное редактирование — это последовательные запросы, при которых клиент передаёт контекст обратно. Считать, что сервер автоматически запоминает его, пока не стоит: это не проверено
2. Что передавать: второй запрос должен включать user1, неизменённый model1 (с изображением и подписью рассуждений), а также user2
3. Практические советы: используйте нативный формат Gemini, указывайте в инструкциях, что нужно сохранить, и не прикладывайте исходное изображение повторно в новом запросе

Если учитывать эти три момента, сценарий из двух последовательных правок — «заменить корону на красную шляпу, а затем перекрасить розовое сердечко в синий» — будет стабильно работать. Эту же структуру можно использовать и для большего числа этапов.

Рекомендуем быстро проверить результат через APIYI apiyi.com. Платформа поддерживает интерфейс, совместимый с OpenAI, и нативный формат Gemini. Одного API-ключа достаточно, чтобы вызывать модели 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. Центр документации APIYI: руководства по разработке для серии Nano Banana, реализации многоэтапного диалога и вызовам в нативном формате Gemini

8. Ссылка: docs.apiyi.com
9. Описание: содержит конечные точки для подключения, пути нативного формата и примеры формирования истории диалога — на них мы опирались при подготовке кода в статье

Автор: техническая команда APIYI
Технические вопросы: свяжитесь с нами через главную страницу сайта APIYI. Дополнительные материалы по подключению серии Nano Banana доступны в центре документации docs.apiyi.com

Читайте также

• Рендеринг текста в Nano Banana 2 и 2.1: сравнение на пяти наборах постеров и чек-лист по выбору: Все говорят, что Nano Banana 2.1 лучше отображает текст, но почему некоторые считают второе поколение точнее? Объясни на примере 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: полный разбор цен — 5 ключевых отличий от Nano Banana 2 и расчёт экономии: Разбор цен Nano Banana 2.1 на основе официальной страницы Google: цена вывода изображения снизилась вдвое, но подорожали входные токены и токены рассуждений, вырос расход для 4K и отменён тариф 0,5K; приведены затраты на одно изображение 1K/2K/4K, цены Batch, точка безубыточности и рекомендации по переходу.
• Одно изображение обмануло 3 миллиона человек? Руководство в 2 шага по созданию сатирического псевдодокументального туристического фото с помощью GPT Image 2.5: Разберите сатирическое видео Wytse Koetse о Париже: сначала с помощью GPT составьте структурированный промпт, а затем пакетно создайте псевдодокументальные стоп-кадры в духе фальшивой туристической рекламы с помощью gpt-image-2.5-sunburst или gemini-nano-banana-2.1.