تكشف تجربة اعتمدت على 28 حالة تصحيح أخطاء برمجية أن أداء وكلاء الذكاء الاصطناعي المتخصصين في الشيفرة البرمجية لا يتحدد فقط بمدى قدرتهم على "كتابة الكود"، بل بحجم السياق المتاح لهم عن المشروع والخطأ والقيود المفروضة والسلوك المتوقع. فحين يفتقر الوكيل إلى هذه المعطيات، ترتفع احتمالات الفشل بشكل ملحوظ.
الفكرة المركزية: في مهمة تصحيح الأخطاء، لا يكفي أن يقترح النظام حلاً معقولاً في مظهره؛ بل عليه أن يعيد بناء الصورة الكاملة للموقف، بدءاً من معمارية المشروع، مروراً بتاريخ التعديلات، وصولاً إلى خطوات إعادة إنتاج الخلل، والتبعيات البرمجية، وسجلات التشغيل، والحالات الاستثنائية، والنتيجة المرجوة. وبدون هذه العناصر، يقع الوكيل غالباً في واحد أو أكثر من الأخطاء التالية:
• اقتراح تصحيح يبدو منطقياً لكنه يُطبَّق في الموضع الخاطئ. • تعديل أجزاء من الشيفرة لا علاقة لها بالحادثة الأصلية. • إخفاء العرَض الظاهر للمشكلة بدل معالجة سببها الجذري. • إحداث ارتداد (Regression) يؤثر في مسار آخر من التطبيق. • تقديم تفسير مقنع في ظاهره، بينما يستند التشخيص إلى افتراضات غير مُتحقق منها.
ماذا يعني هذا عملياً؟ للحصول على نتائج أفضل عند استخدام أدوات مثل Claude Code أو Cursor أو Copilot أو أي وكيل برمجي مشابه، ينبغي التعامل مع الطلب كـ"تذكرة تصحيح أخطاء" منظمة، لا كطلب فضفاض من قبيل "أصلح هذا الخطأ". وتشمل حزمة السياق الجيدة عادة: العرَض الدقيق للمشكلة (رسالة الخطأ كاملة، الرابط المتأثر، السلوك الملاحَظ)، والنتيجة المتوقعة، وخطوات إعادة الإنتاج، والشيفرة ذات الصلة، وسجلات التشغيل وتتبعات الأخطاء، والتغييرات الأخيرة التي طرأت على المشروع (تحديث تبعية، نشر جديد، إعادة هيكلة، قاعدة عمل جديدة)، إضافة إلى القيود الواجب احترامها ومعايير قبول الحل. وتتقاطع هذه الخلاصة مع ممارسات تصحيح أخطاء وكلاء الذكاء الاصطناعي التي تُوصي بتسجيل الطلبات والمعطيات بدقة، ومقارنة النتيجة الفعلية بالسلوك المتوقع بشكل صريح، ثم التحقق من التغييرات المُدخلة.
قالب موجّه قابل لإعادة الاستخدام يمكن اعتماده في مشاريع الويب والأتمتة: أنت مكلَّف بتحليل خطأ برمجي، دون تعديل الشيفرة قبل الحصول على موافقة. سياق المشروع: البنية التقنية / الإصدار والبيئة / الملفات أو الوحدات المعنية / التغييرات الأخيرة. العرَض الملاحَظ: السلوك الفعلي / رسالة الخطأ الكاملة / التكرار / خطوات دقيقة لإعادة الإنتاج. السلوك المتوقع: (يُحدَّد هنا). العناصر المتاحة: سجلات التشغيل / تتبع الأخطاء / مقتطفات من الشيفرة / الاختبارات القائمة / البيانات أو الطلبات المعنية. القيود: ما لا يجب تعديله / التوافقية المطلوبة / المخاطر المعروفة. الإجراء المطلوب: ١. صياغة الفرضيات مرتبة حسب احتمالية صحتها. ٢. تحديد المعلومات الناقصة والاختبارات الكفيلة بالتحقق منها. ٣. تحديد السبب الجذري الأكثر ترجيحاً، مع التمييز بين الوقائع والافتراضات. ٤. اقتراح تصحيح أدنى في صيغة "diff". ٥. تحديد اختبارات عدم الارتداد الواجب تنفيذها. ٦. عدم إدخال أي تعديل قبل الموافقة.
في بيئة تحريرية ثنائية اللغة كالمنصات المشابهة لمنصتنا، غالباً ما ترتبط الأعطال المتعلقة بموجزات RSS والفهرسة والبيانات الوصفية لتحسين محركات البحث وعرض النصوص العربية (RTL) أو أتمتة النشر ببعضها البعض ولا تكون معزولة. لذا يُستحسن تزويد الأداة، إلى جانب وصف الخطأ، بالرابط العلني ورابط لوحة التحكم المعنيَّين، والشيفرة المصدر المعروضة (HTML)، ولقطة من أدوات فحص المتصفح إن أمكن، ولغة النص واتجاهه ونوع المحتوى المتأثر، ومقتطفات من سجلات الخادم والواجهات البرمجية والمهام المجدولة، ومثال ناجح وآخر فاشل للمقارنة، وآخر تعديل طرأ على القالب أو الإضافات أو قواعد إعادة التوجيه أو الأتمتة المستخدمة. وبهذا الشكل، ينتقل دور الذكاء الاصطناعي من مولّد تصحيحات عشوائية إلى مساعد تحقيق فعلي، خصوصاً أن اختبارات تُنتَج بسرعة عبر الذكاء الاصطناعي قد تنجح جميعها ظاهرياً بينما يمرّ خطأ حقيقي دون رصد، وفق ما أشارت إليه تحليلات حول اختبارات البرمجيات المولَّدة بالذكاء الاصطناعي، حين تكتفي هذه الاختبارات بالتحقق من بنية الشيفرة بدل السلوك الفعلي للمنتج.
المصدر : https://intelligences.articlophile.net/articles/i/...