ديكايا برو 2: مراجعة الشيفرة انطلاقا من عقد واختبار قابل للتنفيذ

مثال API مبسّط

كود Python توضيحي وليس إجابة فعلية. يأتي المفتاح من البيئة وتُعطّل المحاولات التلقائية. قد يترك انقطاع الاتصال النتيجة والتكلفة مجهولتين؛ لا تُعد الإرسال دون تحقق.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-pro-2",
    max_tokens=512,
    messages=[{"role": "user", "content": "أنشئ قائمة تحقق لمهمتي وافصل حقائق المصدر عن الافتراضات."}],
)
print(response.choices[0].message.content)

ابدأ بدالة صغيرة لها قاعدة عمل معلنة

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

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

حوّل التخمين عن السبب إلى اختبار يفشل أولا

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

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

اجعل سؤال التجربة محدودا وقابلا للفحص

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

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

وسّع السياق المدفوع حول العقود المتأثرة فقط

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

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

اضبط التكامل مع فصل التكرار عن المحاولة المقصودة

استخدم seller-pro-2 صراحة في طلب الواجهة، واحفظ المفتاح في متغير بيئة على الخادم، وحدد سقفا واضحا للإخراج. عطّل التكرار التلقائي في مكتبة بايثون بضبط max_retries=0 حتى تكون المحاولات مقصودة ومرئية في تدفقك. لا تنقل مستويات low وhigh وmax من هويات أخرى إلى برو 2، ولا تجعل شروط التجربة قاعدة غير مشروطة لكل طلب مدفوع أو لكل عميل.

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

اختم المراجعة بأدلة التنفيذ وحدودها

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

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

أسئلة وأجوبة

هل برو 2 هو نفسه seller-glm-5-3؟

لا. برو 2 نسخة معدلة ذات أساس GLM-5.3 معتمد الوصف، لكن معرّفه seller-pro-2 مستقل عن seller-glm-5-3. لا تستبدل أحدهما بالآخر تلقائيا عند توثيق مراجعة أو محاولة إعادة إنتاجها. سجّل الهوية الدقيقة والشروط المستخدمة لأن الإشارة إلى العائلة نفسها لا تثبت تطابق التهيئة أو الصلاحيات.

هل ينفّذ النموذج الاختبار الذي يكتبه؟

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

لماذا أختار مثالا صغيرا في العرض التجريبي؟

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

كيف أقيّم تعديلا يبدو صحيحا عند القراءة؟

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

المصادر

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

• ديكايا: توثيق التجربة والواجهة البرمجية
  dikaya.cc
• ديكايا: هويات النماذج وقدراتها
  dikaya.cc
• ديكايا: الأسعار وشروط الوصول
  dikaya.cc
• مكتبة بايثون: ضبط إعادة المحاولة
  github.com