قائمة تحقق عملية لمراجعة الشيفرة المولّدة بالذكاء الاصطناعي قبل الدمج

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

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

لماذا تحتاج شيفرة الذكاء الاصطناعي إلى مراجعة مختلفة

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

1. الاعتماديات

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

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

2. الأسرار والمتغيرات العامة

ابحث في الفروقات (diff) عن المفاتيح والرموز وكلمات المرور، بما في ذلك ملفات الاختبار والأمثلة. ثم انظر إلى متغيرات البيئة ذات البادئات العامة مثل VITE_ أو NEXT_PUBLIC_ أو EXPO_PUBLIC_. فكل ما يحمل هذه البادئات يُنسخ إلى حزمة المتصفح وقت البناء. وقد يعيد المساعد تسمية سرٍّ بإحداها كي تعمل ميزة ما في المتصفح. ويستعرض هذا الدليل نسخة هذا الخطأ المتعلقة بمفتاح API الخاص بـ LLM.

3. أين يجري التحقق من الوصول

ابحث عن السطر الذي يقرّر ما إذا كان المستخدم الحالي مخوّلًا بهذا الإجراء. فإن كان في مكوّن React أو حارس مسار (route guard) أو زر مخفي، فهو ميزة لتجربة المستخدم لا للأمان. إذ يستطيع أي شخص استدعاء واجهتك البرمجية مباشرةً. يجب أن يجري التحقق على الخادم، مع كل طلب، مقابل المورد المطلوب: ليس فقط “هل هذا المستخدم مسجّل الدخول” بل “هل يملك هذا المستخدم هذه الفاتورة”.

انتبه إلى مسارات API الجديدة التي لا تمرّ بأي وسيط مصادقة (auth middleware) على الإطلاق، وإلى الخلفيات مثل Supabase أو Firebase حيث يمكن الوصول إلى قاعدة البيانات من المتصفح. فالحماية هناك هي قواعد قاعدة البيانات نفسها. وجدول Supabase بلا أمان على مستوى الصفوف (row level security) مفتوح لأي شخص يملك مفتاح anon العام الخاص بك.

4. المدخلات غير الموثوقة

تتبّع مدخلات المستخدم من نقطة دخولها إلى موضع استخدامها. فاستعلامات SQL المبنية بتجميع النصوص، وأوامر الصدفة المركّبة من حقول الطلب، ومسارات الملفات المأخوذة من معاملات الاستعلام، وHTML المعروض من محتوى المستخدم، وعناوين URL التي تُجلب نيابةً عن المستخدم، هي الأنماط الكلاسيكية للحقن واجتياز المسارات (path traversal) وXSS وSSRF. ولا يزال المساعدون ينتجونها، خصوصًا حين تفعل الشيفرة المحيطة شيئًا مشابهًا بالفعل.

// Looks harmless, is an injectiondb.query(`SELECT * FROM users WHERE email = '${req.query.email}'`); // Parameterizeddb.query('SELECT * FROM users WHERE email = $1', [req.query.email]);

5. الشيفرة غير المكتملة

تتوقف عمليات التوليد الطويلة أحيانًا قبل أن تكتمل. ابحث في التغيير عن العناصر المؤقتة: TODO، و“implement later”، و“rest of the code here”، والدوال التي تُرجع بيانات نموذجية مكتوبة مباشرةً، وبيانات الاعتماد الوهمية، والملفات ذات الأسماء مثل utils copy.ts. وابحث أيضًا عن الكتم الشامل للتحذيرات مثل // @ts-ignore، أو eslint-disable في أعلى الملف، أو any المستخدمة لإسكات مدقّق الأنواع. فهي كثيرًا ما تخفي بالضبط المشكلة التي عجز النموذج عن حلّها.

6. معالجة الأخطاء

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

7. الاختبارات

الاختبارات المولّدة تستحق القراءة سطرًا سطرًا. ومن المشكلات الشائعة: اختبارات لا تتحقق من أي شيء، واختبارات تحاكي (mock) الدالة نفسها التي تختبرها، وتأكيدات لا تتحقق إلا من أن دالة ما استُدعيت، و.only أو .skip منسية في الشيفرة. ومجموعة اختبارات ناجحة ليست دليلًا حتى تعرف أنها قادرة على الفشل. اكسر الشيفرة عمدًا مرة واحدة وانظر هل يلاحظ أي اختبار ذلك.

8. المهل الزمنية والاستدعاءات الحاجبة

استدعاءات HTTP الصادرة بلا مهلة زمنية حادثة إنتاج تنتظر اعتمادية بطيئة. فكثير من العملاء الشائعين ينتظرون إلى ما لا نهاية افتراضيًا، ومنهم requests في Python وhttp.DefaultClient في Go. وفي Node.js، تحجب عمليات الملفات المتزامنة أو تجزئة كلمات المرور داخل معالج الطلب كل الطلبات الأخرى على تلك العملية. ونادرًا ما تظهر هذه المشكلات في الاختبار المحلي لأن حاسوبك واعتمادياتك سريعة وخاملة.

9. الوصول إلى البيانات

ابحث عن الاستعلامات داخل الحلقات (مشكلة N+1)، ونقاط النهاية التي تُرجع القوائم بكل الصفوف دون ترقيم صفحات، وعملاء قواعد البيانات الذين يُنشؤون مع كل طلب بدلًا من مشاركتهم. وافحص عمليات الترحيل (migrations) بعناية أيضًا: فمزامنة المخطط التي تعمل عند بدء التشغيل، أو الترحيل الذي يحذف جدولًا ويعيد إنشاءه، قد يحذف بيانات الإنتاج مع النشر التالي.

10. ميزات LLM

إذا كان التغيير يستدعي نموذجًا، فتعامل مع مخرجات النموذج على أنها مدخلات غير موثوقة. لا ينبغي أبدًا تنفيذها أو دمجها في SQL أو عرضها كـ HTML خام. تحقّق من أن مفتاح API يبقى على الخادم، وأن المسار الذي يستدعي النموذج يتطلب مستخدمًا مسجّل الدخول وله حدّ لمعدّل الطلبات، وأن طول المخرجات محدود بسقف. وإذا كان لدى الوكيل أدوات، فتحقّق مما تستطيع تلك الأدوات فعله، وهل يمكن لنصوص من المستندات أو صفحات الويب توجيهها.

اجعلها روتينًا

عشرة فحوص لكل pull request عبءٌ كبير إن أُنجز يدويًا، والغاية من قائمة التحقق أن تتوقف عن الاعتماد على الذاكرة. ويمكن أتمتة معظم هذه البنود، جزئيًا على الأقل. وهذا يترك انتباهك للأمور التي لا تجيدها الأدوات، مثل ما إذا كان التغيير يفعل ما يحتاجه المنتج فعلًا.

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