تصحيح الأخطاء بالذكاء الاصطناعي ينجح أكثر حين تعطي النموذج ما تعطيه لزميل بجوار مكتبك: الخطأ كاملًا، والكود الذي أطلقه، وما توقعته، وما حدث بدلًا منه، وما استبعدته مسبقًا. النموذج لا يستطيع تشغيل برنامجك ولا رؤية بياناتك، فكل ما يعرفه عن الخلل يأتي مما تلصقه. وأنفع عادة منفردة أن تطلب السبب قبل الإصلاح.
الصق كل شيء، لا الخطأ فقط
التبويبان التاليان يصفان الخلل نفسه. سكربت يقرأ ملف CSV مُصدَّرًا من Excel وينهار بالخطأ KeyError: 'email'، مع أن الملف فيه عمود email بوضوح.
الخطأ KeyError يعني أن القاموس لا يحتوي مفتاحًا اسمه 'email'. يمكنك تجنب الخطأ باستخدام .get()، التي تُرجع None بدلًا من إطلاق خطأ:
email = row.get("email")
أو افحص أولًا:
if "email" in row:
email = row["email"]
الرد الأول صحيح في شرح معنى KeyError، ونصيحته ضارة هنا. مع row.get("email") يختفي الانهيار، ويصبح كل بريد None. أجاب النموذج عن النسخة الأشيع من الخطأ لأن ذلك كل ما وصفه الموجّه.
نجح البلاغ الكامل بسبب سطرين. عبارتا "العمود الأول وحده يفشل" و"محفوظ من Excel بصيغة CSV UTF-8" هما الدليلان اللذان يشيران إلى علامة ترتيب البايتات، ولا يوجد أي منهما في رسالة الخطأ. نادرًا ما تعرف أي تفاصيلك هو الدليل، ولهذا تلصقها كلها.
الأشياء الخمسة التي يجب تضمينها
- الخطأ كاملًا. الـ traceback كله أو مخرجات الطرفية كلها، لا إعادة صياغتها. أرقام الأسطر وسلسلة الاستدعاءات تُظهر أين بدأ الفشل، وكثيرًا ما يكون على بعد بضعة إطارات من المكان الذي ظهر فيه.
- الكود الذي أطلقه. الدالة الفاشلة والكود الذي يستدعيها. إذا ذكر الخطأ سطرًا، فتأكد أن ذلك السطر ضمن ما تلصقه.
- المتوقع مقابل الفعلي. جملة لكل منهما. وفي الأخطاء التي لا رسالة خطأ لها (مخرجات خاطئة، أو صفحة فارغة، أو استعلام بطيء)، هذا هو بلاغ الخلل كله.
- بيئتك. إصدار اللغة، ونظام التشغيل، وإصدارات إطار العمل والمكتبات حين يمكن أن تهم. أخطاء الترميز والمسارات والتواريخ تعتمد كثيرًا على المنصة.
- ما جرّبته مسبقًا. هذا يمنع النموذج من اقتراحه مجددًا، ونتيجة كل محاولة دليل. عبارة "حذف جزء البريد يجعله يعمل" حصرت خلل CSV في عمود واحد.
اطلب السبب قبل الإصلاح
طلب الإصلاح يدعو النموذج إلى تغيير الكود حتى يختفي الخطأ. أما طلب السبب فيطلب منه الاستدلال على سبب حدوث الخطأ، والإصلاح يتبع ذلك. اطلب قائمة قصيرة مرتّبة بالأسباب مع طريقة لفحص كل منها، ثم شغّل الفحوص بنفسك. هذا القالب يفعل ذلك:
TypeError: Cannot read properties of undefined (reading 'map')function UserList() {
const [users, setUsers] = useState();
useEffect(() => {
fetch("/api/users")
.then((res) => res.json())
.then((data) => setUsers(data));
}, []);
return (
<ul>
{users.map((u) => (
<li key={u.id}>{u.name}</li>
))}
</ul>
);
}- المكوّن يُعرض قبل وجود أي بيانات.
useState()تبدأ بالقيمةundefined، وReact يعرض المكوّن مرة قبل تشغيل الـ effect، فتُستدعىusers.mapعلىundefined. هذا وحده ينتج خطأك بالضبط، في كل تحميل. الفحص: أضفconsole.log(users)قبلreturnمباشرة. إذا طبعundefinedوتبعه الخطأ فورًا، فهذا هو السبب. - الواجهة تُرجع شيئًا غير المصفوفة. لو أرجعت كائنًا مثل
{ users: [...] }، لكان الخطأ مختلفًا (users.map is not a function)، فهذا ليس الخطأ الذي ألصقته. لكنه قد يكون المشكلة التالية بعد إصلاح السبب 1. الفحص:console.log(data)داخل.thenالثانية. - الطلب يفشل. ليس معنيًا بعد: لأن العرض الأول يطلق خطأ، لا يشغّل React الـ effect أبدًا، فلا يُرسل الطلب أصلًا. الفحص: تبويب Network لا يُظهر أي طلب
/api/users، وهذا يؤكد السبب 1 أيضًا.
يفعل الرد شيئًا تتجاوزه الإجابة التي تبدأ بالإصلاح: يستبعد أسبابًا لأن الخطأ الذي كانت ستنتجه يختلف عن الخطأ الذي ألصقته، أو لأن الكود لا يصل أصلًا إلى حيث تحدث. ولهذا أيضًا يهم نص الخطأ الدقيق. طلب ذكر الأسباب من النموذج قبل أن يجيب شكل خفيف من سلسلة التفكير: الاستدلال يأتي أولًا والنتيجة تستند إليه.
اصنع نسخة مصغّرة تُعيد إنتاج الخلل
النسخة المصغّرة (minimal reproduction) هي أصغر برنامج ما زال يُظهر الخلل: بيانات مكتوبة مباشرة بدلًا من استدعاء قاعدة بيانات، ودالة واحدة بدلًا من الوحدة كلها. بناؤها يكشف الخلل كثيرًا قبل أن تسأل أحدًا، لأن كل قطعة تحذفها إما تُبقي الخلل (لم تكن معنية) أو تُخفيه (كانت معنية). وإن لم يكشفه، فالنسخة المصغّرة هي الموجّه المثالي: قصيرة بما يكفي ليقرأ النموذج كل سطر، وخالية من كود غير ذي صلة قد يجعله يطارد المشكلة الخاطئة.
إذا كان الخلل يعتمد على البيانات، فضمّن بضعة صفوف تسبّبه. يستطيع النموذج الاستدلال على [{"id": 1, "name": null}]، ولا يستطيع الاستدلال على "بعض الصفوف في بيئة الإنتاج".
عندما تتوقف الإصلاحات عن العمل
إذا فشل الإصلاح الثالث للنموذج بالطريقة نفسها، فطلب إصلاح رابع لن يأتي غالبًا بنتيجة أفضل. أمران يساعدان أكثر:
- أعطه دليلًا جديدًا. أضف سطر طباعة أو تسجيل يُظهر القيم الفعلية عند نقطة الفشل، وشغّله، والصق المخرجات. الدليل الذي يناقض نظرية النموذج أسرع طريق إلى نظرية أفضل.
- ابدأ محادثة جديدة. محادثات تصحيح الأخطاء الطويلة تمتلئ بنظريات متروكة ونسخ قديمة من الكود، وقد يظل النموذج يبني عليها. محادثة جديدة فيها الكود الحالي، والخطأ، والأدلة، وسطر يقول "مستبعد مسبقًا: كذا وكذا" تذهب أبعد غالبًا في رد واحد.
احذر الإجابات الواثقة عن سلوك المكتبات. قد يصف النموذج خيارًا أو دالة غير موجودة، وراجع هلوسة الذكاء الاصطناعي لتعرف كيف تتحقق. وعندما لا يكون الكود معطّلًا لكنك لا تفهم لماذا يفعل ما يفعله، يكون موجّه لشرح الكود الأداة الأنسب.
الأسئلة الشائعة
كيف أطلب من ChatGPT أو Claude إصلاح الكود؟
الصق رسالة الخطأ كاملة والكود الذي أطلقها، ثم أضف ثلاثة أسطر قصيرة: ما توقعته، وما حدث بدلًا منه، وما جرّبته مسبقًا. اطلب السبب الأرجح وطريقة تأكيده قبل أن تطلب الإصلاح. عبارة "أصلح هذا" وحدها تعطيك إصلاحًا للنسخة الأشيع من الخطأ، وقد لا تكون نسختك.
هل ألصق مشروعي كله في الذكاء الاصطناعي؟
لا. الصق الدالة التي يحدث فيها الخطأ، والكود الذي يستدعيها، وعينة من البيانات التي تتلقاها. والأفضل من ذلك أن تختصر المشكلة إلى أصغر برنامج ما زال يُظهرها. الملفات غير ذات الصلة تبطئ الإجابة وتعطي النموذج أماكن أكثر يبحث فيها عن مشكلة غير موجودة.
لماذا يُخفي إصلاح الذكاء الاصطناعي الخطأ لكن البرنامج لا يعمل مع ذلك؟
الإصلاح عالج العَرَض. مثلًا، استبدال row["email"] بـ row.get("email") يوقف KeyError، لكن إذا كان المفتاح مفقودًا بسبب خطأ في مرحلة سابقة، فكل بريد صار الآن None بصمت. طلب السبب أولًا، مع طريقة لتأكيده، يتجنب الإصلاحات التي تُخفي المشكلة فقط.
ماذا أفعل إذا ظل الذكاء الاصطناعي يقترح إصلاحات لا تعمل؟
توقف عن طلب الإصلاحات وأعطه أدلة بدلًا منها. أبلغه بما غيّرته كل محاولة، وأضف سطر طباعة أو تسجيل يُظهر القيم الفعلية، والصق مخرجاته. وإذا طالت المحادثة، فابدأ محادثة جديدة بملخّص نظيف: الكود، والخطأ، والأدلة، والإصلاحات المستبعدة.
