عند عدم إرجاع صورة في توليد الصور: افحص الاستجابة أولاً قبل إعادة المحاولة، 4 خطوات للتقييم لتجنب الخصم المتكرر

ملاحظة من الكاتب: عند استدعاء واجهة توليد الصور، عدم وجود صورة في الاستجابة لا يعني أن الطلب فشل، ولا يعني أنه لم يُخصم منك شيء. يقدّم هذا المقال طريقة من 4 خطوات تفحص الاستجابة أولًا ثم تقرر هل تعيد المحاولة، مع كود Python جاهز للاستخدام.

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

هذا ليس دليلًا عامًا عن إعادة المحاولة. في نماذج توليد الصور التي تُحاسَب بحسب عدد الطلبات، قد يترتب على كل طلب رسوم. خذ مثلًا النموذج gpt-image-2.6-all الذي أُضيف إلى APIYI بتاريخ 2026-11-12، فهو يُحاسَب بالطلب الواحد بسعر $0.025. وإذا أعدت المحاولة بعد استجابة فارغة دون أي فحص، فقد تدفع المبلغ مرة أخرى.

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

---

النقاط الأساسية عند عدم عودة صورة من طلب توليد الصور

لنبدأ بالخلاصة. إذا لم يُرجع طلب توليد الصور أي صورة، فلا تعتبر المشكلة مشكلة شبكة وحسب، بل افحص محتوى الاستجابة بترتيب ثابت. يلخّص الجدول التالي الخطوات الأربع لهذا الأسلوب في التشخيص.

الخطوة	ما الذي نفحصه	التصرف عند الإجابة بـ “لا”	الفائدة
الخطوة 1	هل نجح طلب HTTP؟	التعامل معه وفق رمز الحالة، وعدم الانتقال إلى الخطوات التالية	التمييز بين فشل طبقة الطلب ومشكلة في طبقة المحتوى
الخطوة 2	هل تحتوي الاستجابة على بيانات صورة أو رابط URL للصورة؟	الانتقال إلى الخطوة 3	إن وُجدت الصورة ينتهي الفحص، فلا تُعاد المحاولة بالخطأ
الخطوة 3	هل تحتوي الاستجابة على رسالة خطأ؟	إن وُجد خطأ فيُعالج وفق نوعه	تجنّب الدفع المتكرر مقابل طلب فاشل حتمًا
الخطوة 4	التأكد من عدم وجود صورة ولا خطأ	إعادة المحاولة مرة واحدة فقط	إبقاء التكلفة الإضافية ضمن حدود متوقعة

لماذا لا يجوز إعادة المحاولة فورًا عند عدم عودة صورة

طلب توليد الصور يختلف عن المحادثة النصية العادية؛ فتكلفة الطلب الواحد أعلى، كما أن النتيجة لا تكون دائمًا “كل شيء أو لا شيء”. فقد يكون الخادم أنهى التوليد فعلًا، لكن الشفرة عندك لم تقرأ الصورة من الحقل الصحيح. وقد يكون الطلب نفسه رُفض، والاستجابة تذكر السبب صراحةً. وفي الحالتين تؤدي إعادة المحاولة الفورية إلى نتيجة سيئة: في الأولى ستدفع مرتين مقابل الصورة نفسها، وفي الثانية ستدفع مرارًا مقابل طلب محكوم عليه بالفشل.

لنأخذ مثالًا بسعر gpt-image-2.6-all حسب الطلب، وهو $0.025. كل إعادة محاولة عمياء تعني دفع $0.025 إضافية. فإذا عاملت الاستجابة الفارغة على أنها تذبذب في الشبكة وكتبت حلقة تكرار متتالية، فإن 3 محاولات إضافية تكلّفك $0.075، وقد لا تحصل مقابلها على أي صورة صالحة. لذلك فإن النظر في الاستجابة قبل إعادة المحاولة هو في جوهره فحص شبه مجاني تجريه قبل أن تنفق المال.

منطق الحكم: اقرأ الاستجابة أولًا ثم قرر إعادة المحاولة

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

وهناك تفصيل يُهمل كثيرًا: الخطوة الثانية تفحص «بيانات الصورة أو رابطها». تختلف أماكن عودة الصورة باختلاف شكل الواجهة. بعض الواجهات تضعها في الحقل b64_json أو url داخل المصفوفة data، وبعضها يكتب رابط الصورة داخل نص content في رسالة المحادثة. فإذا كانت شفرة التحليل لديك لا تتعرف إلا على أحد الشكلين، فستحكم خطأً على استجابة تحتوي صورة بأنها فارغة. وهذا من أكثر أسباب إعادة المحاولة غير الضرورية شيوعًا.

---

تفكيك أنواع الاستجابات عند عدم عودة صورة من توليد الصور

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

نوع الاستجابة	الخصائص المميزة	هل أُنتجت صورة؟	المعالجة الموصى بها
فشل على مستوى الطلب	رمز حالة HTTP ليس من الفئة 2xx	لا	عالج الخطأ بحسب رمز الحالة، وصحّح مشكلات المصادقة والمعاملات قبل إعادة الإرسال
توليد ناجح (بنية منظمة)	يوجد b64_json أو url في data	نعم	استخرج الصورة مباشرة ولا تعد المحاولة
توليد ناجح (مضمَّن في النص)	يحتوي content في الرسالة على رابط صورة	نعم	استخرج الرابط بتعبير نمطي (regex) ولا تعد المحاولة
استجابة ناجحة تحمل معلومات خطأ	نجاح HTTP، لكن جسم الاستجابة يحتوي على error أو شرح للرفض	لا	اقرأ سبب الخطأ، ثم عدّل الموجه أو المعاملات
استجابة فارغة فعلًا	نجاح HTTP، بلا صورة وبلا خطأ	لا	سجّل الاستجابة الخام، ثم أعد المحاولة مرة واحدة
انتهاء مهلة الطلب	لم يتلقَّ العميل أي استجابة	لا يمكن التأكد	لا تعد الإرسال تلقائيًا، وراجع السجلات والفواتير أولًا

لماذا ينبغي فحص حالة الطلب قبل إعادة المحاولة عند انتهاء المهلة؟

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

في مثل هذه الحالات، من الأفضل أولًا زيادة المهلة بشكل مناسب، ثم تسجيل وقت الطلب ومعاملاته عند حدوث انتهاء المهلة، ومراجعة سجلات الاستدعاء في لوحة التحكم لمعرفة الحالة الفعلية للطلب. وبعد التأكد من عدم وجود سجل ناجح، يمكنك إعادة الإرسال يدويًا، وهذا أكثر أمانًا بكثير من ترك البرنامج يكرر الطلب تلقائيًا.

الاستجابات التي تحمل معلومات خطأ تُعالَج كأخطاء

بعض الاستجابات تكون حالة HTTP فيها ناجحة، لكن جسمها يحتوي على كائن خطأ، أو يشرح النموذج في النص سبب عدم قدرته على التوليد، كأن يكون الموجه قد فعّل مراجعة المحتوى. هذه الاستجابات لا تحتوي على صورة، لكن سببها مكتوب بوضوح، وإعادة إرسال الطلب نفسه ستعطي النتيجة نفسها تقريبًا.

الأسلوب الصحيح هو قراءة رسالة الخطأ وتحديد ما إذا كانت المشكلة في المعاملات أو في المحتوى أو عطلًا مؤقتًا في الخادم. مشكلات المعاملات والمحتوى تستلزم تعديل الطلب قبل إعادة إرساله، ولا تُنظر إعادة المحاولة بعد فترة انتظار إلا إذا أشارت رسالة الخطأ صراحةً إلى عطل مؤقت.

---

عند عدم عودة صورة من توليد الصور: افحص الاستجابة قبل إعادة المحاولة، دليل البدء السريع

سنستخدم Python لنوضّح كيف تضع هذا المنطق داخل الكود. يعتمد المثال واجهة متوافقة مع OpenAI، والنموذج المستخدم هو gpt-image-2.6-all. أما نقطة الاستدعاء وصيغة الاستجابة الدقيقتان، فارجع فيهما إلى وثائق APIYI الخاصة بهذا النموذج.

مثال مبسّط: افحص الاستجابة أولًا للتأكد من وجود صورة

أبسط طريقة هي أن تفحص حقل الصورة بعد وصول الاستجابة. إذا وُجدت صورة ينتهي الأمر، وإن لم توجد تنتقل إلى خطوات التشخيص:

from openai import OpenAI

client = OpenAI（
    api_key="YOUR_API_KEY"，
    base_url="https://api.apiyi.com/v1",  # واجهة APIYI المتوافقة مع OpenAI
）

resp = client.images.generate（
    model="gpt-image-2.6-all"，
    prompt="一只坐在窗台上的橘猫，水彩风格"，
）

item = resp.data[0] if resp.data else None
if item and （item.b64_json or item.url）:
    print（"已拿到图片，不要重试"）
else:
    print（"响应里没有图片，先打印原始响应再决定"）
    print（resp.model_dump（））

لا يتجاوز هذا الكود بضعة عشر سطرًا، لكنه يتفادى أكثر الأخطاء شيوعًا: إعادة الإرسال دون النظر إلى المحتوى. أما الإخفاقات على مستوى HTTP فيرميها الـ SDK على شكل استثناء، ويمكنك التقاطها في الطبقة الخارجية باستخدام try ومعالجتها بحسب رمز الحالة، بدل الدخول مباشرة في حلقة إعادة المحاولة.

مثال كامل: 4 خطوات للتحقق مع إعادة محاولة واحدة كحد أقصى

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

import re
import requests

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://api.apiyi.com/v1"  # عنوان الواجهة الموحدة لـ APIYI
MODEL = "gpt-image-2.6-all"
IMG_URL_RE = re.compile（r"https？://\S+？\.（？:png|jpe？g|webp）"， re.I）


def find_images（body）:
    """التحقق في الوقت نفسه من حقل data المهيكل ومن روابط الصور داخل content المحادثة"""
    images = []
    for item in body.get（"data"） or []:
        if item.get（"url"）:
            images.append（item["url"]）
        elif item.get（"b64_json"）:
            images.append（"base64-image"）
    for choice in body.get（"choices"） or []:
        content = （choice.get（"message"） or {}）.get（"content"） or ""
        images += IMG_URL_RE.findall（content）
    return images


def generate_with_check（prompt， max_retry=1）:
    for attempt in range（max_retry + 1）:
        try:
            resp = requests.post（
                f"{BASE_URL}/images/generations"，
                headers={"Authorization": f"Bearer {API_KEY}"}，
                json={"model": MODEL， "prompt": prompt}，
                timeout=300，
            ）
        except requests.Timeout:
            # عند انتهاء المهلة لا يمكن معرفة هل ولّد الخادم الصورة وحاسب عليها، لذا لا نعيد الإرسال تلقائيًا
            return {"status": "timeout"， "action": "check_logs_first"}

        # الخطوة 1: هل نجح طلب HTTP؟
        if resp.status_code ！= 200:
            return {"status": "http_error"， "code": resp.status_code，
                    "detail": resp.text[:500]}

        try:
            body = resp.json（）
        except ValueError:
            return {"status": "bad_json"， "detail": resp.text[:500]}

        # الخطوة 2: هل تحتوي الاستجابة على بيانات صورة أو رابط صورة؟
        images = find_images（body）
        if images:
            return {"status": "ok"， "images": images}

        # الخطوة 3: إذا وُجدت رسالة خطأ فنعاملها كخطأ ولا نعيد المحاولة
        if body.get（"error"）:
            return {"status": "api_error"， "error": body["error"]}

        # الخطوة 4: بعد التأكد من غياب الصورة والخطأ معًا، وبعد تسجيل الاستجابة الأصلية، تُسمح إعادة المحاولة
        print（f"第 {attempt + 1} 次请求无图片，原始响应：{str（body）[:300]}"）

    return {"status": "empty_after_retry"， "action": "stop_and_report"}


result = generate_with_check（"一只坐在窗台上的橘猫，水彩风格"）
print（result）

في هذه الشيفرة عدة قرارات تصميمية تستحق الانتباه. القيمة الافتراضية لـ max_retry هي 1، أي أن الصورة الواحدة تكلّفك طلبين كحد أقصى، وبذلك يكون سقف التكلفة معروفًا مسبقًا. أما فرع انتهاء المهلة فيُرجع النتيجة مباشرة بدل متابعة الحلقة، لأنك لا تستطيع التأكد وقتها من أن الرصيد لم يُخصم. وفي كل مرة تُعدّ فيها الاستجابة فارغة تُطبع الاستجابة الأصلية، لتتمكن لاحقًا من معرفة هل المشكلة في التحليل أم أن الخادم فعلًا لم يُنتج الصورة.

🚀 بداية سريعة: إذا أردت اختبار منطق الحكم هذا في بيئة تجريبية أولًا، يمكنك الحصول على رصيد اختبار مجاني من APIYI عبر apiyi.com، واستخدام مفتاح API نفسه لاستدعاء gpt-image-2.6-all وغيره من النماذج الرائجة. جرّب مسار الحكم كاملًا قبل ربطه بنشاطك الفعلي.

---

تكلفة إعادة المحاولة العمياء عندما لا ترجع صورة

قبل أن تكتب منطق الحكم في الشفرة، لا يدرك كثيرون الكلفة الحقيقية لعبارة «نعيد المحاولة بضع مرات». في الجدول التالي نفترض أن سعر gpt-image-2.6-all هو $0.025 لكل طلب، ونقارن بين استراتيجيتين: تكرار الطلب بلا تفكير، وفحص الاستجابة قبل إعادة المحاولة. المقارنة تقيس الإنفاق الإضافي على الصورة الواحدة.

استراتيجية المعالجة	أقصى عدد طلبات للصورة الواحدة	الإنفاق الإضافي في أسوأ حالة	ملاحظة عن المخاطر
بلا فحص، إعادة الطلب مرة واحدة عند الفشل	2	$0.025	قد تدفع مرتين لطلب أنتج الصورة فعلًا
بلا فحص، تكرار الطلب 3 مرات في حلقة	4	$0.075	تدفع مرارًا مقابل طلب محكوم عليه بالفشل
بلا فحص، التكرار حتى تظهر الصورة	غير محدد	بلا حد أعلى	يستمر الخصم عند الرفض بسبب مراجعة المحتوى
فحص الاستجابة أولًا، ثم إعادة المحاولة مرة واحدة بعد التأكد من غياب الصورة	2	$0.025	لا تتحمل التكلفة الإضافية إلا عند الاستجابة الفارغة فعلًا

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

وعند التوسع إلى توليد الصور بالدفعات، يتضاعف هذا الفرق. اضرب الـ $0.025 الزائدة على كل صورة في عدد الطلبات اليومية، وستجد مبلغًا كان يمكن تجنبه بالكامل.

---

مرجع الواجهات والنماذج عند عدم إرجاع صورة بعد التوليد

يختلف موضع الصورة في الاستجابة من نموذج إلى آخر ومن واجهة إلى أخرى، وهذا يؤثر مباشرة على دقة الحكم في الخطوة 2. يلخّص الجدول التالي أشهر أشكال الاستجابة مع نقاط التحقق الأساسية، لتتأكد أن كود التحليل لديك لا يتجاهل الصورة.

شكل الاستجابة	موضع الصورة	نقاط التحليل	المنصات المتاحة
واجهة توليد الصور (URL)	data[].url	انتبه إلى أن الرابط قد تكون له مدة صلاحية، لذا نزّل الصورة واحفظها بمجرد الحصول عليها	APIYI (apiyi.com)، وفق وثائق النموذج
واجهة توليد الصور (Base64)	data[].b64_json	فكّ الترميز واكتب الناتج في ملف، ولا تعتبره سلسلة فارغة بالخطأ	نفسه
صورة مضمّنة في واجهة المحادثة	choices[].message.content	استخدم تعبيرًا نمطيًا (regex) لاستخراج صورة Markdown أو الرابط	نفسه
الاستجابة المتدفقة (Streaming)	المحتوى الكامل بعد تجميع الأجزاء	انتظر حتى ينتهي التدفق وتُجمَّع الأجزاء كاملة، ثم تحقق من وجود الصورة	نفسه

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

---

الأسئلة الشائعة (FAQ)

Q1: إذا لم يُرجع توليد الصور أي صورة، فهل يعني ذلك أنه لم يُخصم أي رسم؟

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

Q2: ما الفرق بين “فحص الاستجابة قبل إعادة المحاولة” وإعادة المحاولة العادية بالتراجع الأسي؟

التراجع الأسي يحدد “متى نعيد المحاولة”، ويناسب تحديد المعدل والأعطال المؤقتة في الخادم. أما فحص الاستجابة أولًا فيحدد “هل ينبغي أن نعيد المحاولة أصلًا”. في طلبات توليد الصور المحاسَبة لكل طلب، يجب أولًا التأكد من الحاجة الفعلية لإعادة المحاولة عبر خطوات التحقق الأربع، ثم تحديد توقيتها باستراتيجية التراجع. فالعلاقة بينهما تسلسلية، وليست بديلًا أحدهما عن الآخر.

Q3: متى أُطلق gpt-image-2.6-all وكم سعره؟

أُطلق gpt-image-2.6-all على APIYI بتاريخ 2026-11-12، بتسعير لكل طلب قدره $0.025. التسعير لكل طلب يعني أن كل طلب يُحتسب مستقلًا، وإعادة إرسال طلب أعاد استجابة فارغة ستكلفك رسمًا جديدًا. وهذا هو السبب المباشر لتأكيد المقال على فحص الاستجابة قبل إعادة المحاولة.

Q4: في أي الحالات يجب ألا نعيد المحاولة إطلاقًا عندما لا يُرجع توليد الصور أي صورة؟

هناك ثلاث حالات رئيسية:

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

Q5: كيف أتحقق بسرعة من صحة منطق الفحص لديّ؟

يُفضَّل تشغيل المسار الكامل في بيئة اختبار أولًا:

1. سجّل حسابًا في APIYI على apiyi.com واحصل على مفتاح API ورصيد اختبار مجاني.
2. اضبط `BASE_URL` في المثال الكامل الوارد في هذا المقال على `https://api.apiyi.com/v1`، ثم استدعِ gpt-image-2.6-all.
3. اختبر بموجه عادي وبموجه قد يُرفض، وراقب ما يُرجَع في كل فرع.

بعد التأكد من أن كل استجابة تقع في الفرع الصحيح، انتقل إلى ربطه بالنظام الفعلي.

Q6: ماذا أفعل إذا لم تظهر صورة حتى بعد إعادة المحاولة مرة واحدة؟

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

Q7: كيف أتحكم في تكلفة إعادة المحاولة عند توليد الصور بالجملة؟

أعطِ كل مهمة توليد صور عدّاد إعادة محاولة مستقلًّا، وثبّت الحد الأقصى لإعادة المحاولة في المهمة الواحدة عند مرة واحدة. ونوصي أيضًا بحساب «معدل الاستجابات الفارغة» على مستوى المهمة. إذا ظهرت استجابات فارغة بكثرة واضحة في دفعة معينة، فابدأ بفحص الموجّه ومنطق التحليل (parsing)، ولا ترفع عدد إعادة المحاولات بشكل عام.

---

عند عدم عودة صورة من طلب توليد الصور: افحص الاستجابة قبل إعادة المحاولة، النقاط الرئيسية

• غياب الصورة لا يعني غياب الخصم: في طلبات توليد الصور المحاسَبة لكل طلب، قد يكون الخادم قد احتسب الرسوم بمجرد معالجته للطلب.
• ترتيب الفحص ثابت: حالة HTTP ← بيانات الصورة أو الرابط ← رسالة الخطأ ← إعادة المحاولة بعد التأكد من غياب الصورة.
• إعادة محاولة واحدة فقط: إذا تأكدت من غياب الصورة وعدم وجود خطأ، فأعد المحاولة مرة واحدة فقط، فتبقى التكلفة القصوى متوقعة.
• لا تُعِد الإرسال تلقائيًّا عند انتهاء المهلة: لا يمكنك التأكد من حالة التوليد عند انتهاء المهلة، فراجع السجلات أولًا ثم قرّر هل ترسل الطلب مجددًا.
• غطِّ أكثر من موضع في التحليل: افحص حقل data وcontent في المحادثة معًا، حتى لا تعتبر الاستجابة فارغة خطأً.
• لإعادة المحاولة العمياء ثمن واضح: كل إعادة محاولة عمياء إضافية مع gpt-image-2.6-all تكلّفك $0.025 زيادة.
• جرّب أولًا على رصيد الاختبار: يمكنك تجربة آلية الفحص كاملة على رصيد الاختبار المجاني في APIYI (apiyi.com) قبل الإطلاق.

---

الخلاصة

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

1. افحص قبل أن تدفع: فحص الاستجابة شبه مجاني، أما إعادة المحاولة العشوائية فتُحاسَب عليها في كل مرة.
2. اتبع 4 خطوات بالترتيب: هل نجح طلب HTTP؟ هل توجد صورة؟ هل توجد رسالة خطأ؟ ثم أعد المحاولة مرة واحدة فقط بعد التأكد من غياب الصورة.
3. ضع القواعد في الشفرة: حدّد عدد المحاولات، ولا تُعد الطلب تلقائيًا عند انتهاء المهلة، وسجّل الاستجابة الخام. بهذا تبقى التكلفة تحت السيطرة وتسهل متابعة المشكلات.

إذا كنت تستدعي نماذج صور تُحاسِب لكل طلب، فهذه الطريقة بسيطة، لكنها تحميك فعليًا من أن تُخصَم تكلفة الصورة نفسها مرتين. يُفضَّل أن تجرّب كل الحالات في بيئة اختبار أولًا، ثم تعتمدها كغلاف قياسي لاستدعاءات توليد الصور.

نوصي بالتحقق من منطق المعالجة هذا بسرعة عبر APIYI على apiyi.com، فالمنصة توفر واجهة متوافقة مع OpenAI ورصيدًا تجريبيًا مجانيًا، ويكفي مفتاح واحد لاستدعاء عدة نماذج رائجة مثل gpt-image-2.6-all.

---

📚 المراجع

1. مركز وثائق APIYI: شرح طريقة استدعاء النماذج وصيغة الاستجابة
2. الرابط: docs.apiyi.com

3. ملاحظة: راجع نقطة النهاية وحقول الاستجابة الخاصة بـ gpt-image-2.6-all، والمرجع هو الوثائق

4. مرجع OpenAI Images API: بنية الاستجابة القياسية لواجهة توليد الصور

5. الرابط: platform.openai.com/docs/api-reference/images
6. ملاحظة: لفهم معنى الحقلين url وb64_json داخل المصفوفة data

---

المؤلف: فريق APIYI التقني
للتواصل التقني: يسعدنا تواصلك معنا عبر الصفحة الرئيسية لموقع APIYI، ويمكنك الاطلاع على مزيد من مواد الربط في مركز الوثائق docs.apiyi.com

مقالات ذات صلة

• يعيد توليد الصور الخطأ 451 image_safety: تم حظر الصورة المُنشأة، وليس رفض مفتاح API (3 خطوات لاستكشاف الأخطاء وإصلاحها + تفسير إعادة الاختبار على 5 مجموعات من المستندات): عندما تُرجع واجهة الصور HTTP 451 ورمز الخطأ image_safety، فالمُفلتر هو «الصورة المُولَّدة»، وليس المفتاح أو الرصيد أو تحديد معدل الطلبات؛ تميّز هذه المقالة أولًا بين 451 و401 و429، ثم تشرح كيفية تعديل وصف المشهد بعد إعادة الاختبار وفقًا لوثائق APIYI.
• كيف تختار قناة GPT-Image: الفروق بين 3 فئات من القنوات — التحويل الرسمي والتحويل العكسي الرسمي (-all و-vip) — والأعطال السابقة و5 استراتيجيات احتياطية: مقارنة الفروق بين قنوات GPT-Image الثلاث (الرسمية المحوّلة و-all و-vip) من حيث التسعير والأحجام والتحرير الجزئي، ومراجعة الأعطال التاريخية من أبريل إلى أكتوبر 2026، وتقديم حل احتياطي قائم على "إعادة محاولة محدودة + قاطع دائرة + قناة بديلة".