مراجعة الكود
راجع تغييرات الكود باستخدام الوكيل الفرعي Reviewer المدمج، والمراجعة متعددة النماذج، والإصلاحات بنقرة واحدة
يتضمن Verdent وكيلاً فرعياً مدمجاً يسمى Reviewer، مهمته الوحيدة هي مراجعة الكود الخاص بك. بعد إنهاء الكتابة، يكفي أن تشير إلى @Reviewer وسيقوم بفحص تغييراتك من زوايا متعددة وإخراج قائمة منظمة بالمشكلات مرتبة بحسب الخطورة. حدد أي عنصر تريد إصلاحه وسيقوم بتطبيق التغييرات تلقائياً—دون الحاجة لكتابة تعليقات أو البحث في الوثائق يدوياً.
كيفية تشغيل مراجعة الكود
الطريقة الأكثر مباشرة هي كتابة @Reviewer في المحادثة، تماماً كما تشير إلى زميل في فريقك:
@Reviewer please review the authentication logic I just wroteيقرأ Reviewer السياق الحالي تلقائياً ويبدأ المراجعة. يمكنك أيضاً استدعاء @Reviewer بدون أي تعليمات—وسيقرر بنفسه ما يجب فحصه.
بالإضافة إلى التشغيل اليدوي، يمكن للوكيل استدعاء Reviewer تلقائياً كخطوة VERIFY نهائية في سير العمل. بعد كتابة الكود، لا داعي للقلق بشأن ذلك—يستدعي النظام Reviewer للتحقق من صحة النتيجة.
كيف يبدو ناتج المراجعة
بعد المراجعة، ستظهر لك قائمة منظمة من النتائج (Findings). يتضمن كل عنصر:
- العنوان — وصف من سطر واحد للمشكلة
- الشرح التفصيلي — سبب كونها مشكلة وتأثيرها المحتمل
- مسار الملف + رقم السطر — انقر للانتقال مباشرة إلى الكود
- درجة الثقة — مدى تأكد Reviewer (من 0 إلى 1)
تُصنَّف المشكلات إلى ثلاث مستويات خطورة:
| الأولوية | المعنى | أمثلة نموذجية |
|---|---|---|
| P0 | حرجة، يجب إصلاحها | أخطاء منطقية، حقن SQL، تصعيد الصلاحيات |
| P1 | مهمة، ينبغي إصلاحها | حالات حدّية مفقودة، مشكلات أداء محتملة |
| P2 | اقتراح | أسلوب الكود، تحسينات القابلية للقراءة |
في الأعلى، يعرض ملخص مثل P0: 1 / P1: 3 / P2: 5 نظرة سريعة على توزيع درجات الخطورة. في النهاية، يقدم overall_explanation تقييماً عالي المستوى للتغييرات.
الإصلاح بنقرة واحدة
لا حاجة لتعديل كل مشكلة يدوياً. يتضمن كل عنصر من النتائج مربع اختيار:
- حدد المشكلات التي تريد إصلاحها (يدعم تحديد الكل)
- حدد Fix
- يطبّق Reviewer التغييرات تلقائياً
- تتحدّث الحالة إلى Fix done
في بعض الحالات، إذا قرر Reviewer أن التغييرات منخفضة الخطورة، فقد يحدد جميع المشكلات تلقائياً ويطلق الإصلاح دون الحاجة لتأكيد.
المراجعة التعاونية متعددة النماذج
من أقوى ميزات Reviewer هي مراجعة الكود متعددة النماذج—حيث تراجع نماذج ذكاء اصطناعي متعددة نفس الكود بالتوازي، تماماً كما لو كان لديك ثلاثة مهندسين من خلفيات مختلفة يقيّمون تطبيقك بشكل مستقل.
كيفية التفعيل
انتقل إلى الإعدادات ← المحادثة ← Reviewer ← فعّل "المراجعة متعددة النماذج".
أنماط اختيار النموذج
| النمط | الوصف |
|---|---|
| النمط الافتراضي | يختار Verdent تلقائياً أفضل مجموعة نماذج بناءً على تعقيد المهمة |
| نمط المستخدم | اختر يدوياً من 1 إلى 3 نماذج (يمكن الدمج بين Claude، GPT، Gemini) |
يمكنك اختيار 3 نماذج كحد أقصى. الأول هو المراجع الأساسي؛ والباقي مراجعون ثانويون. عدد أكبر من النماذج يعني تغطية أوسع لكن تنفيذاً أبطأ. بالنسبة للتغييرات البسيطة، يكفي عادةً نموذج واحد.
قواعد المراجعة (سياسات مراجعة مخصصة)
يرصد Reviewer الكثير من المشكلات الشائعة بشكل افتراضي، لكن كل فريق له معاييره الخاصة. تتيح لك قواعد المراجعة (Review Rules) تحديد إرشاداتك الهندسية مباشرة.
أين يتم الضبط
الإعدادات ← المحادثة ← Reviewer ← محرر قواعد المراجعة (محرر Monaco يدعم Markdown).
ما يمكنك تحديده
- يجب أن تستخدم جميع استعلامات SQL عبارات ذات معاملات، دون تجميع نصوص
- يجب أن تتضمن العمليات غير المتزامنة معالجة أخطاء صحيحة باستخدام try/catch
- ينبغي أن تستخدم مكونات React خاصية
memoعندما تكون الخصائص (props) مستقرة - يجب أن تتحقق جميع API العامة من صلاحيات المستخدم
تُدرج هذه القواعد تلقائياً في سياق Reviewer ويتم فحصها في كل مراجعة. تُطبَّق التحديثات تلقائياً بعد حوالي 500 مللي ثانية—دون حاجة للحفظ اليدوي.
سير العمل في الوقت الفعلي
خلال المراجعة، يمكنك ملاحظة تدفق شجرة العمل (Working Tree Stream) الخاص بـ Reviewer في الوقت الفعلي—يُظهر أي ملف يقرأه وأي منطق يحلّله. توسيعه يكشف شجرة المهام كاملة. يمكنك طيّه إذا كنت تفضّل عرضاً أبسط دون التأثير على النتائج.
حالات الاستخدام
الفحص النهائي للجودة
بعد تنفيذ منطق معقّد، شغّل @Reviewer لرصد الحالات الحدّية والأخطاء الدقيقة التي قد تكون فوّتتها بسبب التعب.
التحقق قبل طلب السحب
شغّل مراجعة قبل تقديم طلب سحب (pull request). أصلح جميع مشكلات P0/P1 أولاً لتقليل التراجع والتقدم المتكرر وتخفيف عبء المراجعة على زملائك.
تدقيق الأمان
أضف قواعد مراجعة مركّزة على الأمان (مثل "يجب تنقية جميع المدخلات من XSS") لضمان فحص كل تغيير تلقائياً وفق سياسات الأمان.
فرض معايير الفريق
رمّز قواعد ESLint، وقواعد تصميم API، ومعايير التسمية في قواعد المراجعة حتى يتبعها المساهمون الجدد تلقائياً دون الحاجة لتوجيه فريق كامل.
قرارات معمارية متعددة المنظورات
بالنسبة للتغييرات الكبرى، فعّل المراجعة متعددة النماذج للحصول على تقييمات مستقلة واكتشاف النقاط العمياء.
أداة تعليمية للمبتدئين
استخدم ملاحظات Reviewer كمادة تعليمية—فهم أهمية مشكلات P0 يُعلّم المبادئ الهندسية الأساسية بشكل أسرع من قراءة الوثائق.
ملاحظات
- نموذج واحد أم متعدد النماذج: توفر المراجعة متعددة النماذج تغطية أوسع لكنها أبطأ وأكثر تكلفة. بالنسبة للمهام البسيطة أو العاجلة، يكفي عادةً نموذج واحد.
- قيود الخطة المجانية: يمكن للمستخدمين المجانيين في نمط المستخدم اختيار النماذج فقط من مجموعة Eco Mode؛ النماذج المتقدمة تتطلب اشتراكاً.
- إيقاف النماذج: إذا تم إيقاف نموذج مختار، سيُعطَّل ويجب استبداله.
- قواعد المراجعة عامة: تُطبَّق على جميع المشاريع. إذا كانت قاعدة خاصة بمشروع معيّن، أضف ملاحظة توضيحية أو أزلها بعد الاستخدام.
- حالة BYOK: إذا كنت تستخدم مفتاح API الخاص بك، فإن انتهاء الصلاحية أو نفاد الرصيد سيُعطّل النماذج المقابلة ويتسبب في فشل المراجعة حتى يتم التحديث.