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

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

طريقة المراجعة

1. الوظيفة

• الكود يفعل ما طُلب فقط، ولم يضف ميزات أو ملفات أو صفحات لم تُطلب.
• جرّبته فعلًا على جهازك أو بيئة الاختبار، ولم تكتفِ بقول الأداة إنه «يعمل».
• الحالات الحدّية مغطّاة: قائمة فارغة، عنصر واحد، قيم كبيرة جدًا، تواريخ في مناطق زمنية مختلفة.
• لم يحذف الكود أو يعطّل شيئًا كان يعمل (تحقّق من الملفات التي عُدِّلت ولم تتوقّع تعديلها).
• لا دوال أو مكتبات «مختلَقة» غير موجودة فعلًا.

2. التحقق من المدخلات

• كل ما يأتي من المستخدم (نماذج، روابط، ملفات، رؤوس الطلب) يُعامل كغير موثوق.
• التحقق يتم في الخادم، لا في المتصفح فقط؛ تحقّق المتصفح راحة للمستخدم لا حماية.
• لكل حقل: النوع، الطول الأقصى، الصيغة المسموحة، وهل هو إلزامي.
• الاستعلامات إلى قاعدة البيانات مُعلَّمة المعاملات (parameterized)، لا نصوص مركّبة من مدخلات المستخدم.
• ما يُعرض من مدخلات المستخدم في الصفحة يُهرَّب (escaped) ولا يُدرج كـHTML خام.
• رفع الملفات محدود بالنوع والحجم، ولا يُنفَّذ أي ملف مرفوع.

3. تسجيل الدخول والصلاحيات

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

4. الأسرار

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

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

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

6. الأخطاء والسجلات

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

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

• للتغيير اختبار واحد على الأقل للمسار السعيد وواحد لمسار الرفض (مستخدم غير مخوّل، مدخل غير صالح).
• الاختبارات تفشل فعلًا حين تكسر الكود عمدًا (اختبار لا يفشل أبدًا لا يختبر شيئًا).
• الأداة لم «تصلح» اختبارًا فاشلًا بتعديل الاختبار ليتوافق مع الخطأ.
• كل الاختبارات السابقة ما زالت تنجح.

8. إتاحة الوصول (للواجهات)

• عناصر تفاعلية حقيقية (زر للأفعال، رابط للتنقّل) لا عناصر عامة بنقرة مضافة.
• كل حقل له عنوان مرتبط به، ورسائل الخطأ مقروءة لقارئ الشاشة.
• يمكن الوصول إلى كل شيء بلوحة المفاتيح، ومؤشّر التركيز ظاهر.
• الصور لها نص بديل، والتباين كافٍ.
• الاتجاه من اليمين إلى اليسار صحيح في الصفحات العربية، واللغة معلنة في الصفحة.

9. النشر

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

مثال مشروح 1: مسار يعرض حجزًا

// GET /api/bookings/:id
app.get('/api/bookings/:id', async (req, res) => {
  const booking = await db.bookings.findById(req.params.id);   // [1]
  res.json(booking);                                           // [2]
});

const SMS_API_KEY = 'sk_live_EXAMPLE_ONLY';                    // [3]

// GET /api/bookings/:id
app.get('/api/bookings/:id', requireLogin, async (req, res) => {   // [1]
  const booking = await db.bookings.findById(req.params.id);
  if (!booking || booking.patientId !== req.user.id) {              // [2]
    return res.status(404).json({ error: 'Not found' });
  }
  res.json({                                                        // [3]
    id: booking.id,
    date: booking.date,
    status: booking.status,
  });
});

const SMS_API_KEY = process.env.SMS_API_KEY;                        // [4]

مثال مشروح 2: نموذج تواصل

// POST /api/contact
app.post('/api/contact', async (req, res) => {
  const { name, phone, message } = req.body;                  // [1]
  await db.query(
    "INSERT INTO messages (name, phone, message) VALUES ('" +
    name + "', '" + phone + "', '" + message + "')"           // [2]
  );
  res.send('Thanks ' + name);                                 // [3]
});

// POST /api/contact  (rateLimit: illustrative, use your framework's limiter)
app.post('/api/contact', rateLimit({ max: 5, perMinutes: 10 }), async (req, res) => {
  const name = String(req.body.name || '').trim();                 // [1]
  const phone = String(req.body.phone || '').trim();
  const message = String(req.body.message || '').trim();
  const phoneOk = /^[0-9+ ]{7,20}$/.test(phone);
  if (!name || name.length > 80 || !phoneOk || message.length > 1000) {
    return res.status(400).json({ error: 'invalid_input' });
  }
  await db.query(                                                  // [2]
    'INSERT INTO messages (name, phone, message) VALUES ($1, $2, $3)',
    [name, phone, message]
  );
  res.json({ ok: true });                                          // [3]
});

برومبت المراجعة الذاتية

استخدمه بعد أن تكتب الأداة الكود، في محادثة جديدة أو مع أداة ثانية. النتيجة مساعدة لك لا حكم نهائي؛ القرار لمن يراجع.

راجع الكود التالي كمراجع أمان صارم. لا تعِد كتابته كاملًا.
1) اشرح ما يفعله في 5 أسطر.
2) لكل مسار: هل يتحقّق من تسجيل الدخول؟ من الملكية أو الدور؟
3) أين تُستخدم مدخلات المستخدم دون تحقّق أو دون تهريب؟
4) هل توجد أسرار أو إعدادات مكتوبة في الكود؟
5) ماذا يحدث عند فشل كل عملية خارجية؟
6) ما الاختبارات الثلاثة الأهم التي تنقص؟
رتّب الملاحظات من الأخطر إلى الأقل، واذكر رقم السطر.
الكود: [الصق الكود بعد استبدال أي مفتاح أو بيانات حقيقية بقيم وهمية]

متى تتوقّف وتطلب مختصًا

• المنصة تخزّن بيانات صحية أو مالية أو بيانات قاصرين.
• تستقبل مدفوعات أو تدير أرصدة.
• بنيت نظام تسجيل دخول أو تشفير بنفسك بدل استخدام خدمة أو مكتبة معروفة.
• لم تستطع فهم شرح الأداة لجزء حسّاس من الكود.
• ظهر سلوك غريب لا تفسير له في السجلات أو في قاعدة البيانات.

قائمة الإنجاز قبل الدمج

• فهمت ما يفعله الكود وجرّبته بنفسك.
• المدخلات مفحوصة في الخادم، والاستعلامات بمعاملات.
• كل مسار يتحقّق من الهوية ومن الملكية أو الدور، وجرّبت الوصول بمستخدم آخر.
• لا أسرار في الكود أو في كود المتصفح أو في السجلات.
• الاعتماديات الجديدة حقيقية وضرورية ومصانة.
• رسائل الخطأ لا تكشف تفاصيل تقنية.
• اختبار نجاح واختبار رفض على الأقل، وكل الاختبارات السابقة تنجح.
• الواجهات قابلة للاستخدام بلوحة المفاتيح وبقارئ الشاشة.
• النشر له نسخة احتياطية وطريقة تراجع.
• إن كانت البيانات حساسة: موعد مراجعة أمنية احترافية محدّد.