المشكلة التي يحلها هذا البرومبت
تغيّرت طبيعة عمل المطوّر في العامين الأخيرين بشكل جذري. صار توليد الكود هو الجزء السهل، بينما انتقل العبء الحقيقي إلى ما بعده: لماذا انهار هذا الطلب في الإنتاج؟ ولماذا يعمل الكود على جهازي ويفشل عند العميل؟ كمية الكود التي تدخل المشاريع يوميًا تضاعفت، وتضاعف معها عدد الأعطال التي لا يعرف أحد مصدرها بدقّة.
والمشكلة أن معظمنا يتعامل مع الذكاء الاصطناعي في هذه اللحظة بأسوأ طريقة ممكنة: نلصق رسالة الخطأ ونكتب "أصلح هذا". فيأتي الرد بإصلاح يبدو واثقًا ومقنعًا، نطبّقه، ويختفي الخطأ ظاهريًا… ثم يعود بعد أسبوع بصيغة مختلفة، لأن ما عولج كان العَرَض لا السبب. التخمين المُنمّق ليس تشخيصًا.
محقّق الأخطاء البرمجية: من رسالة الخطأ إلى إصلاح مُختبَر
هذا البرومبت يفرض على النموذج منهجية المحقّق بدل منهجية المُخمّن. بدل أن يقفز مباشرة إلى حل، يُطلب منه أولًا أن يقرأ رسالة الخطأ ويحدّد السطر الذي بدأ منه العطل فعليًا — وهو غالبًا ليس السطر الأخير في تتبّع المكدس، وهنا يضيع وقت كثير.
بعدها يُخرج لك ثلاث فرضيات مرتّبة حسب الاحتمال، ولكل فرضية اختبار سريع يؤكّدها أو ينفيها خلال دقائق، ثم السبب الجذري الأرجح مشروحًا كسلسلة أحداث من المُدخل الأولي حتى لحظة الانهيار. ولا ينتهي عند الإصلاح: يكتب لك اختبار انحدار يفشل مع الكود القديم وينجح مع الجديد، ويشير إلى مواضع أخرى قد يتكرّر فيها النمط نفسه، ويقترح إجراءً وقائيًا واحدًا يمنع عودة هذا الصنف من الأخطاء.
جرّب البرومبت الآن: محقّق الأخطاء البرمجية: من رسالة الخطأ إلى إصلاح مُختبَر
كيف تستخدم هذا البرومبت؟
انسخ البرومبت كاملًا إلى ChatGPT أو Claude أو Gemini، ثم املأ الحقول بين الأقواس المربّعة قبل الإرسال. الحقول ليست شكلية: لغة البرمجة وإطار العمل، نص الخطأ كما ظهر حرفيًا، الكود الذي يظهر في تتبّع المكدس، السلوك المتوقّع مقابل الفعلي، خطوات إعادة الإنتاج، البيئة، وما تغيّر مؤخرًا في المشروع.
أهمّ ثلاثة حقول هي: نص الخطأ كاملًا دون اختصار، والكود المرتبط به، وحقل "ما تغيّر مؤخرًا". هذا الأخير تحديدًا يختصر نصف وقت التشخيص، لأن معظم الأعطال المفاجئة تعود إلى تحديث مكتبة أو نشر جديد أو تغيير في الإعدادات. واملأ أيضًا حقل "ما جرّبته بالفعل" حتى لا يعيد عليك النموذج حلولًا فشلت.
بعد وصول الإجابة، لا تقفز إلى قسم الإصلاح مباشرة. شغّل الاختبار السريع المقترح للفرضية الأولى، ثم أخبر النموذج بالنتيجة. هذه الدورة القصيرة — فرضية، اختبار، نتيجة — هي ما يحوّل الجلسة من محادثة إلى تحقيق حقيقي.
نصائح للحصول على أفضل النتائج
لا تختصر تتبّع المكدس. الأسطر التي تبدو لك تفاصيل داخلية من المكتبة هي غالبًا موضع السبب الجذري. الصقه كاملًا، حتى لو بدا طويلًا.
أجب عن أسئلة النموذج بدل تجاهلها. البرومبت يسمح له بطرح سؤالين محدّدين عند نقص المعلومات، وهذه الأسئلة هي الفرق بين تشخيص مبني على دليل وآخر مبني على احتمالات عامة.
تعامل مع الأخطاء المتقطّعة بشكل مختلف. إن كان العطل يظهر أحيانًا فقط، اذكر في خطوات إعادة الإنتاج كم مرّة ظهر ومتى وتحت أي حِمل — فهذا يوجّه التحليل نحو التزامن والحالة المشتركة والبيانات الحدّية بدل المنطق البسيط.
ابدأ باختبار الانحدار لا بالإصلاح. شغّل الاختبار الذي كتبه النموذج على الكود القديم أولًا، وتأكّد أنه يفشل. اختبار ينجح قبل الإصلاح لا يثبت شيئًا، وستكتشف بهذه الخطوة وحدها ما إذا كان التشخيص صحيحًا.
جرّب وشارك نتائجك
البرومبت يعمل مع ChatGPT وClaude وGemini، ومع أي لغة أو إطار عمل — فهو يعتمد على المنهجية لا على تفاصيل تقنية بعينها. جرّبه على أقرب عطل مفتوح لديك الآن، ويفضّل أن يكون واحدًا من تلك الأعطال التي "أصلحتها" سابقًا وعادت.
وإن وصلت إلى سبب جذري لم تكن تتوقّعه، شاركه معنا — فأكثر ما يفيد المطوّرين العرب هو قصص التشخيص الحقيقية، لا قوائم الحلول الجاهزة. تصفّح بقية برومبتات شبّيك لمزيد من الأدوات العملية في البرمجة والإنتاجية.