دليل التحرير متعدد الجولات في Nano Banana 2.1: 3 عناصر لإعادة الإرسال تضمن عدم فقدان التفاصيل عند تعديل الصور على جولتين متتاليتين

ملاحظة المؤلف: يشرح هذا المثال المتكامل، الذي يبدأ باستبدال التاج بقبعة حمراء وينتهي بتحويل القلب الوردي إلى أزرق، كيفية إعادة سجل المحادثة والصورة من الجولة السابقة وتوقيع التفكير في كل جولة من جولات التحرير المتعددة باستخدام Nano Banana 2.1، لضمان إجراء تعديلات موضعية من دون فقدان نتائج الجولات السابقة.

يواجه كثير من المطورين المشكلة نفسها عند استخدام gemini-nano-banana-2.1 لتعديل الصور للمرة الأولى: تكون نتيجة الجولة الأولى ممتازة، لكن عند محاولة ضبط تفصيل صغير في الجولة الثانية، تُمحى تعديلات الجولة السابقة أو يُعاد رسم الصورة بأكملها بأسلوب مختلف. يشرح هذا المقال الطريقة الصحيحة لإعادة البيانات في التحرير متعدد الجولات باستخدام Nano Banana 2.1، لتتمكن من إجراء تعديلين متتاليين على الصورة من دون فقدان التفاصيل.

هذا المقال ليس شرحًا نظريًا آخر، بل يركز على مثال عملي قابل لإعادة التنفيذ: في الجولة الأولى، نستبدل التاج على رأس الشخصية بقبعة حمراء؛ وفي الجولة الثانية، نغيّر القلب الوردي إلى أزرق فقط، مع الإبقاء على القبعة الحمراء. سنعرض الشيفرة الكاملة لطلبي الجولتين، ونوضح البيانات التي يجب تضمينها في كل جولة.

الفائدة الأساسية: بعد قراءة هذا المقال، ستفهم آلية عمل التحرير متعدد الجولات في Nano Banana 2.1، وستعرف العناصر الثلاثة التي يجب إعادتها مع كل طلب، كما ستتمكن من استخدام الشيفرة مباشرة لإجراء تعديلات متتابعة على أجزاء محددة من الصورة.

النقاط الأساسية للتحرير المتواصل في Nano Banana 2.1

لنضبط المفهوم أولًا. ما يُسمّى «التحرير متعدد الجولات الأصلي» في Nano Banana 2.1، والأدق أن نسمّيه «التحرير المتواصل»: كل جولة هي طلب مستقل إلى API. ويبدو أن النموذج «يتذكر» ما عُدّل في الجولة السابقة لأنك تعيد تضمين السياق كاملًا في الطلب، لا لأن الخادم يحفظ الجلسة نيابةً عنك.

لماذا «تفقد» التعديلات المتعددة المراحل في Nano Banana 2.1 بعض التفاصيل؟

من الأخطاء الشائعة أن ترسل في الجولة الثانية جملة واحدة مثل «غيّر القلب الوردي إلى الأزرق»، ثم ترفق الصورة الأصلية. في هذه الحالة، سيظل النموذج يرى الصورة الأصلية التي يظهر فيها التاج، ومن الطبيعي أن يُبقي عليه، فتختفي القبعة الحمراء التي أُضيفت في الجولة الأولى. ومن الأخطاء أيضًا إرفاق صورة الجولة الأولى وحدها من دون سجل المحادثة. عندها سيحصل النموذج على نسخة القبعة الحمراء، لكنه لن يعرف أن لون القبعة أو شكلها عُدّل للتو عمدًا وأنه يجب الحفاظ عليهما؛ لذلك قد يغيّرهما عرضًا في الجولة الثانية.

الطريقة الأكثر موثوقية هي إعادة التفاعل الكامل للجولة الأولى ضمن سجل المحادثة: ما قاله المستخدم، والصورة التي أعادها النموذج، والتوقيع المرفق بردّه. وتصف وثائق Google الرسمية سيناريو التعديلات المتعددة المراحل على الصور بالطريقة نفسها؛ إذ يستعين النموذج بالتوقيع في سجل المحادثة لمواصلة سياق الاستدلال، وبذلك يغيّر الجزء الذي حددته فقط.

بنية الطلبات للتحرير متعدد الجولات في Nano Banana 2.1

تتكوّن قيمة contents في الطلب الثاني من مصفوفة مرتّبة زمنيًا، وتضم ثلاثة أجزاء على الأقل: رسالة المستخدم في الجولة الأولى (الصورة الأصلية مع التعليمات)، وردّ النموذج في الجولة الأولى (يتضمن الصورة الناتجة والتوقيع)، وتعليمات المستخدم الجديدة في الجولة الثانية. النقطة الأهم هي إعادة تمرير جزء ردّ النموذج «كما هو»؛ فلا تكتفِ باستخراج بيانات الصورة بصيغة Base64 وإعادة تركيبها، وإلا فقد يضيع حقل التوقيع أثناء التحويل.

بدء سريع للتحرير متعدد الجولات في Nano Banana 2.1

فيما يلي مثال لاستدعاء Gemini مباشرةً بتنسيق generateContent الأصلي، باستخدام Python ومكتبة requests. اخترنا هذا التنسيق بدلًا من تنسيق chat المتوافق مع OpenAI، لأن التحرير متعدد الجولات يتطلب إعادة تمرير توقيع التفكير thought signature وجزء الصورة، ويتيح التنسيق الأصلي الحفاظ على البنية الأصلية لهذه الحقول بأكبر قدر ممكن.

قائمة التحضيرات

مثال مختصر جدًا: استبدال التاج بقبعة حمراء في الجولة الأولى

الجولة الأولى هي طلب عادي لتحرير صورة: رسالة واحدة من المستخدم تتضمن الصورة الأصلية والتعليمات. والأهم هو حفظ محتوى النموذج المُعاد كاملًا لاستخدامه في الجولة التالية.

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 كاملًا، لا بيانات الصورة وحدها. قد تتضمن الأجزاء الموجودة داخل هذا الكائن نصًا وصورة وحقل 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. تأكد من بقاء القبعة الحمراء في صورة الجولة الثانية، ومن تغيّر لون القلب فقط، ثم ادمج الكود في سير عملك.

نصائح لصياغة تعليمات الجولة الثانية

لا يعتمد التعديل المتتابع «لجزء محدد فقط» على إعادة البنية فحسب، بل تؤثر فيه أيضًا طريقة صياغة التعليمات. ننصح بتوضيح ثلاثة أمور في تعليمات الجولة الثانية: الصورة التي سيُبنى عليها التعديل، والجزء المراد تغييره، والعناصر التي يجب أن تبقى كما هي. مثلًا، ستكون عبارة «استنادًا إلى الصورة السابقة، غيّر القلب الوردي إلى الأزرق فقط، مع إبقاء القبعة الحمراء وبقية التفاصيل كما هي» أكثر ثباتًا من مجرد قول «غيّره إلى الأزرق».

كذلك، لا تُرفق الصورة الأصلية مرة أخرى في الجولة الثانية. فالصورة الأصلية موجودة بالفعل في user1، وإذا أعدت إرفاقها في user2، فقد يعتبرها النموذج مرجعًا جديدًا، فيعود إلى نسخة التاج.

مقارنة بين ثلاث طرق لإعادة إرسال السياق في التحرير متعدد الجولات باستخدام Nano Banana 2.1

لتوضيح سبب ضرورة اكتمال «العناصر الثلاثة»، سنقارن بين ثلاث طرق شائعة. يصف الجدول التالي سلوك كل طريقة وصفًا عامًا، ليسهل عليك تحديد الطريقة التي يستخدمها كودك.

تحليل المقارنة

تحليل الطريقة A: تمتاز الطريقة A بسهولة تنفيذها، إذ يُرسل كل طلب على حدة. لكن النموذج لا يرى نتيجة الجولة الأولى إطلاقًا، ما يعني إجراء تعديل جديد من جولة واحدة. أما إعادة إرسال السجل الكامل، فتتيح للنموذج متابعة التعديل انطلاقًا من نتيجة الجولة الأولى.

تحليل الطريقة B: تستهلك الطريقة B حجمًا أقل في الطلب، إذ لا ترسل سوى صورة واحدة. لكن النموذج لا يعرف أن «القبعة الحمراء تعديل مقصود»، كما لا يحصل على التوقيع، لذلك لا يوجد ضمان لاتساق التفاصيل المحلية. وفي حالات مثل التصاميم التي تحتاج إلى تنقيح متواصل أو الصور الرئيسية للمنتجات في المتاجر الإلكترونية، تظل الطريقة C الخيار الأكثر موثوقية.

💡 نصيحة للاختيار: إذا كان نشاطك يتطلب جولتين متتاليتين من التعديل أو أكثر، فننصحك باعتماد الطريقة C مباشرةً. يمكنك تشغيل الطرق الثلاث ومقارنة الصور الناتجة باستخدام الشفرة نفسها على APIYI apiyi.com؛ وستكون الفروق واضحة جدًا.

اختيار Nano Banana 2.1 من بين طُرز السلسلة نفسها

تضم سلسلة Nano Banana على APIYI عدة طُرز، ويُعد التحرير المتواصل استخدامًا متقدمًا لقدرات التحرير. يساعدك الجدول التالي على اختيار الطراز المناسب من السلسلة.

استكشاف الأخطاء الشائعة في التحرير متعدد الجولات باستخدام 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 الأصلي، وتتيح استدعاء سلسلة Nano Banana ونماذج رائدة أخرى باستخدام مفتاح API واحد. كما تعتمد التسعير حسب الاستخدام، ما يجعلها مناسبة للاختبار على نطاق صغير أولًا، ثم الانتقال تدريجيًا إلى بيئة الإنتاج.

📚 مراجع

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 في عرض النصوص: مقارنة عملية عبر 5 مجموعات من الملصقات وقائمة اختيار: يقال إن عرض النصوص في 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 ملايين شخص؟ دليل من خطوتين لإنشاء صور سياحية ساخرة زائفة بأسلوب وثائقي باستخدام GPT Image 2.5: حلّل فيديو Wytse Koetse الساخر عن باريس؛ ابدأ بكتابة موجهات منظمة باستخدام GPT، ثم أنشئ دفعة واحدة لقطات ثابتة شبه وثائقية بنبرة «إعلان سياحي زائف» باستخدام gpt-image-2.5-sunburst أو gemini-nano-banana-2.1.