كيفية مراجعة الشيفرة التي كتبها الذكاء الاصطناعي

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

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

اضبط المراجعة على حجم المخاطرة

ليس كل تغيير يحتاج الاهتمام نفسه.

الخطوة 1: اعرف ما الذي تغيّر

قبل الحكم على الشيفرة، احصل على قائمة التغييرات:

• إذا كان المشروع في Git، فانظر إلى الفرق (diff): الملفات والأسطر التي تغيّرت منذ آخر commit. راجع كيفية استخدام Git مع تطبيق بُني بالذكاء الاصطناعي.
• أو اسأل الذكاء الاصطناعي مباشرة:

اذكر كل ملف غيّرته في آخر تعديل، واشرح لكل ملف في جملة واحدة ما الذي تغيّر ولماذا.

علامات التحذير في هذه المرحلة: ملفات لا علاقة لها بالطلب، أو ملفات محذوفة، أو تغييرات في الإعدادات أو الاعتماديات لم تطلبها.

الخطوة 2: اختبر السلوك أولًا

قراءة الشيفرة تخبرك بما يُفترض أن تفعله، أما الاختبار فيخبرك بما تفعله فعلًا. قبل القراءة:

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

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

الخطوة 3: تحقق من الصلاحيات على الخادم

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

لكل مسار أو دالة تقرأ البيانات أو تغيّرها، اسأل:

• هل تتحقق من أن المستخدم مسجَّل الدخول؟
• هل تتحقق من أن هذا المستخدم مسموح له بالوصول إلى هذا السجل تحديدًا؟
• هل هذا الفحص على الخادم، لا في الصفحة فقط؟

لكل مسار API أضفته أو عدّلته، اذكر فحص الصلاحيات الذي يقوم به على الخادم، واقتبس السطر. وأشِر إلى أي مسار لا يملك هذا الفحص.

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

الخطوة 4: ابحث عن الأسرار المكشوفة

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

راجع كيفية حماية مفاتيح API.

الخطوة 5: تحقق من المدخلات والأخطاء

• التحقق على الخادم. فحوص المتصفح يمكن تجاوزها. ينبغي أن يتحقق الخادم أيضًا من الحقول المطلوبة والأطوال والصيغ والقيم المسموح بها.
• استعلامات قاعدة البيانات تستخدم معاملات (parameters)، لا نصًا مبنيًا بدمج مدخلات المستخدم داخل الاستعلام.
• الأخطاء لا تُبتلع. كتلة try/catch لا تفعل شيئًا تُخفي الأعطال. ينبغي تسجيل الأخطاء، ويرى المستخدمون رسالة واضحة بسيطة.
• لا تُعرض التفاصيل الداخلية للمستخدمين — تتبّع المكدس (stack traces) وأخطاء قاعدة البيانات مكانها السجلات.

الخطوة 6: تحقق من أنها حقيقية

تنتج نماذج الذكاء الاصطناعي أحيانًا شيفرة تبدو صحيحة لكنها تشير إلى أشياء غير موجودة.

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

هل أضفت أي حزم جديدة؟ لكل واحدة اذكر الاسم الدقيق، وما وظيفتها، وهل يمكننا الاستغناء عنها.

الخطوة 7: تحقق من أنها تتلاءم مع الباقي

قد تعمل الشيفرة وتجعل التطبيق أصعب في التغيير لاحقًا:

• التكرار. المنطق نفسه منسوخ في أماكن عدة سيتباعد مع الوقت.
• الاتساق. ينبغي أن تتبع الأنماط التي يتبعها باقي التطبيق.
• الحجم. طلب من 20 سطرًا أنتج 600 سطر يستحق سؤالًا.
• الشيفرة الميتة. نسخ قديمة بقيت بجوار الجديدة.

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

أخطاء شائعة

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

قائمة التحقق

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

مراجعة الشيفرة في Mythex

• وضع الأسئلة (Ask mode) يجيب عن أسئلة حول الشيفرة دون تعديلها — مثالي لطلبات «اشرح كل تغيير» و«أي المسارات تفتقر إلى فحص صلاحيات». راجع الدردشة.
• عرض الشيفرة (Code view) يعرض شجرة الملفات والمحرر والطرفية في كل الخطط (للقراءة فقط في الخطة المجانية، وقابل للتعديل في Pro)، حتى تقرأ التغييرات بنفسك. راجع محرر الشيفرة.
• ‏/test يجعل الوكيل يتصفح المعاينة كمستخدم ويبلّغ عن التدفقات المعطلة.
• نقاط الاستعادة (Checkpoints) تتيح لك التراجع عن تغيير يفشل في المراجعة.

إذا كان مطور يراجع نيابةً عنك، فيغطي كيفية العمل مع مطور على تطبيق بُني بالذكاء الاصطناعي عملية التسليم؛ وإذا كشفت المراجعة عن خلل، فراجع كيفية تصحيح تطبيق بُني بالذكاء الاصطناعي.

الأسئلة