كيف تصحّح الأخطاء في تطبيق بناه الذكاء الاصطناعي: منهج عملي

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

يغطي هذا الدليل الحلقة كاملة، مع جولة سريعة في أدوات المطور في المتصفح لغير المطورين.

حلقة التصحيح

كل إصلاح لخطأ، سواء قام به شخص أو الذكاء الاصطناعي، يتبع الحلقة نفسها:

1. أعد الإنتاج — اجعل الخطأ يحدث بشكل موثوق.
2. لاحظ — اجمع رسالة الخطأ وما كان التطبيق يفعله.
3. صِف — أعطِ الذكاء الاصطناعي خطوات دقيقة، والنتيجة المتوقعة، والنتيجة الفعلية.
4. أصلح — دع الذكاء الاصطناعي يغيّر شيئًا واحدًا.
5. تحقق — كرر الخطوات الدقيقة وتأكد من الإصلاح، ومن أنه لم يكسر شيئًا قريبًا منه.
6. ارجع إن لزم — إذا ساءت الأمور، فتراجع وحاول من جديد بمعلومات أفضل.

معظم الوقت الضائع في التطبيقات التي بناها الذكاء الاصطناعي يأتي من تخطي الخطوات 1 و2 و5: أن تقول «إنه معطّل»، أو أن تقبل تغييرًا دون اختباره، ثم تطلب إصلاحًا آخر فوق تغيير معطّل.

الخطوة 1: أعد إنتاج الخطأ

الخطأ الذي يمكنك تفعيله عند الطلب نصف مُصلَح. حاول أن تجد أقصر مجموعة من الخطوات التي تسببه.

اسأل نفسك:

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

اكتب الخطوات كقائمة مرقمة قصيرة. ستلصقها في الموجّه لاحقًا.

الخطوة 2: اقرأ رسالة الخطأ

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

لا تحتاج إلى فهمها؛ بل تحتاج إلى نسخها بدقة. فالرسالة «Cannot read properties of undefined (reading 'name')» تخبر الذكاء الاصطناعي بأن الكود توقّع بيانات ما (غالبًا حجزًا أو مستخدمًا) لم تكن موجودة. أما وصف مثل «خطأ undefined غامض» فيضيع تلك المعلومة.

بعض الأخطاء الشائعة، مع ترجمة تقريبية:

• أخطاء undefined / null — الكود توقع بيانات لم تصل. غالبًا حالة تحميل، أو قائمة فارغة لم يعالجها الكود.
• 404 Not Found — الصفحة أو عنوان الواجهة البرمجية غير موجود. غالبًا خطأ مطبعي في مسار، أو رابط إلى صفحة أُعيدت تسميتها.
• 401 Unauthorized / 403 Forbidden — الطلب لم يكن مسجّل الدخول، أو المستخدم غير مسموح له بهذا الإجراء.
• 500 Internal Server Error — تعطّل كود الخادم. السبب الحقيقي موجود في سجلات الخادم، لا في المتصفح.
• أخطاء CORS — منع المتصفح طلبًا إلى نطاق آخر. عادةً مشكلة في إعدادات جهة الخادم.

الخطوة 3: استخدم أدوات المطور في المتصفح

كل متصفح سطح مكتب لديه أدوات مطور مدمجة («devtools»). وهي تُظهر ما تفعله الصفحة خلف الكواليس. في Chrome وEdge وFirefox، انقر بالزر الأيمن في أي مكان على الصفحة واختر Inspect (فحص)، أو اضغط F12 (أو Cmd+Option+I على جهاز Mac). وفي Safari، فعّل قائمة Develop من إعدادات Safari أولًا.

تحتاج إلى ثلاثة تبويبات فقط.

Console

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

Network

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

• ابحث عن الصفوف الحمراء أو التي تحمل حالة 400 أو أعلى.
• انقر على الصف الفاشل لترى Response الخاص به. غالبًا ما يتضمن خطأ الخادم رسالة هناك أكثر فائدة من أي شيء على الشاشة.
• دوّن عنوان URL للطلب ورمز الحالة. فالجملة «طلب POST إلى /api/bookings أعاد 500» جملة مفيدة جدًا لتعطيها للذكاء الاصطناعي.

فعّل Preserve log إذا كان الخطأ يتضمن إعادة تحميل الصفحة أو إعادة توجيه، حتى لا تختفي الطلبات.

Elements

يُظهر تبويب Elements (أو Inspector) بنية الصفحة وأنماطها. وهو الأنفع لأخطاء التخطيط: مرّر المؤشر فوق عنصر لترى حجمه والمسافات حوله مُظللة. لا تحتاج إلى تعديل أي شيء هنا؛ يكفي أن تقول «التذييل بعرض 2000 بكسل على الجوال ويدفع الصفحة جانبًا».

الخطوة 4: افحص سجلات الخادم

بعض الأخطاء تحدث على الخادم، حيث لا يستطيع المتصفح رؤيتها. والخطأ 500 في تبويب الشبكة علامة كلاسيكية على ذلك. وسجلات الخادم، أي المخرجات النصية للخلفية أثناء تشغيلها، تحتوي عادةً على الخطأ الحقيقي مع stack trace (قائمة بالدوال التي كانت تعمل عند الفشل).

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

الخطوة 5: صف الخطأ للذكاء الاصطناعي

ضع ما جمعته في هذا الشكل:

في صفحة الحجوزات، مسجّل الدخول كعضو: نقرت Cancel على حصة الساعة 9:00 صباح الغد. المتوقع: يختفي الحجز وتصبح للحصة مكان فارغ إضافي. الفعلي: لا يتغير شيء على الشاشة. تُظهر وحدة التحكم TypeError: Cannot read properties of undefined (reading 'id') في BookingCard.tsx:31، ويُظهر تبويب الشبكة أن DELETE /api/bookings/123 أعاد 500. ابحث عن السبب وأصلحه، وتحقق من أن الإلغاء يعمل لعضو لديه حجز واحد ولعضو لديه عدة حجوزات.

لماذا يهم كل جزء:

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

إذا حاول الذكاء الاصطناعي الإصلاح مرتين وفشل، فاطلب منه الشرح قبل أن يغيّر أي شيء:

لا تغيّر الكود بعد. ما الذي تظن أنه يسبب هذا، وما الدليل الذي يدعم ذلك؟

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

الخطوة 6: تحقق، ثم افحص المحيط

عندما يقول الذكاء الاصطناعي إن الخطأ أُصلح، كرر الخطوات الدقيقة من الخطوة 1. ثم تحقق من الأشياء المحيطة به:

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

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

الخطوة 7: ارجع بدل التكديس

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

عادات جيدة تجعل التراجع سهلًا:

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

أنماط أخطاء شائعة في التطبيقات التي بناها الذكاء الاصطناعي

عندما لا تكون المشكلة خطأً

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

التصحيح في Mythex

لدى Mythex أدوات لكل خطوة من الحلقة:

• المعاينة (Preview) لإعادة إنتاج الخطأ، بما في ذلك إطار بحجم الهاتف.
• /test يجعل الوكيل يتنقل في معاينتك الحية كمستخدم، ويبلّغ عن المسارات المعطّلة.
• /fix يوجّه الوكيل نحو الأعطال تحديدًا.
• وضع Plan يجعل الوكيل يحقق ويشرح قبل أن يعدّل أي شيء.
• Code ← terminal يعرض سجلات الخادم لتطبيقك.
• Revert to this point على أي رد يعيد المشروع إلى نقطة الحفظ هذه.

إذا فشل النشر، فغالبًا ما يعرض حوار النشر خيار Fix with AI، الذي يقرأ مخرجات البناء أو سجلات التطبيق. راجع صحّح تطبيقك واستكشاف أخطاء النشر في الوثائق.

الأسئلة