مراجعة
وكيل مراجعة نافين: /inspect وأدلة وخطة معالجة مرقمة
5 أغسطس 2026 · 3 دقائق قراءة · فريق نافين
مراجعة كود خبيرة محلية: ثماني طبقات وتحليل بأدلة حقيقية وتقرير HTML واختيارات #1 قبل أي تعديل.
وكيل المراجعة في نافين ليس أداة فحص مع دردشة: إنه مراجع خبير يقرأ الفرق أو المشروع كاملا، ويشغّل الفحص والتدقيق النوعي والاختبارات ليثبت نتائجه، ثم يسلّم تقرير HTML مع خطة معالجة مرقمة. تختار #1 فينفذ الوكيل. لا شيء يُعدَّل دون موافقتك.
كيف تبدأ مراجعة
ثلاث بوابات، محرك واحد:
- وضع Review في الملحن + نص حر (يُسبق تلقائيا بأمر
/inspect). /inspect [مسار|diff|نطاق]لاستهداف مجلد أو ملف أو الفرق الحالي.- Actions ← Code review للتدقيق بنقرة واحدة.
النطاق الافتراضي ذكي: git status والفرق المرحّل وغير المرحّل والتغييرات الأخيرة. وفي المستودعات الكبيرة يعتمد الوكيل على الرسم البياني لتحديد المسارات الساخنة.
ثماني طبقات تحليل، لا قائمة تحقق
| الطبقة | ما يبحث عنه الوكيل |
|---|---|
| الصحة | أخطاء منطقية، null/undefined، معالجة الأخطاء، سباقات، مخاطر async |
| البيانات وSQL | SQL خام، غياب المعاملات الآمنة، N+1، معاملات، هجرات |
| عقود API | الأشكال، التفويض على المعالجات، mass assignment، تغييرات كاسرة |
| الواجهة | منافذ XSS، CSRF، تحققات مصادقة على العميل فقط، ثغرات التحقق من النماذج |
| روائح أمنية | حقن، أسرار، تشفير ضعيف، path traversal |
| الاختبارات والجودة | اختبارات ناقصة أو مكسورة أو متقلبة؛ بوابة جودة عند وجود السكربتات |
| الأداء | حلقات ساخنة، استعلامات غير محدودة، فهارس وترقيم صفحات ناقصة |
| قابلية الصيانة | كود ميت، كائنات ضخمة، تسمية، تبعيات ميتة |
القاعدة التي تغير كل شيء: الدليل
كل نتيجة يجب أن تتضمن الخطورة (من Critical إلى Info) والملف:السطر والأثر وإصلاحا ملموسا ومثالا حقيقيا: مقتطف كود مصاب، مخرجات اختبار فاشل، أو PoC صغير. لا كلام عام. للوكيل الحق في تشغيل ruff وeslint وtsc وmypy وpytest للتحقق مما يدعيه.
الختام: تقرير HTML + خيارات مرقمة
- يُكتب تقرير
review-report-[date].htmlويفتح تلقائيا في File Preview: ملخص تنفيذي بعدادات الخطورة، بطاقات نتائج، وخطة معالجة مرقمة (جهد S/M/L، خطر التأجيل، أول خطوة ملموسة). - في الدردشة: ملخص قصير وسؤال واحد - «بأي رقم نبدأ؟».
- المراجعة للقراءة فقط افتراضيا. تجيب
Start with #1فيتحول الوكيل إلى وضع البناء (/forge) لتنفيذ ذلك البند بالضبط. - على PR مفتوحة في GitHub، يمكن لأداة
pr_commentsنشر النتائج كتعليقات مراجعة (عبرgh).
حكم كمراجع حقيقي
تنتهي المراجعة بحكم: Approve أو Request changes مع الخطة المرقمة. إنه نفس عقد المراجعة البشرية الجادة - لكنه متاح عند الطلب وعلى كل فرق.
المراجعة + اللوحة المستقلة: الحلقة الكاملة
مع استقلالية اللوحة تصبح الحلقة: الوكيل يبرمج على فرع معزول ويفتح PR، تشغّل /inspect عليها، تختار المعالجات، فيتولاها الوكيل كمهام متتبعة. المراجعة لم تعد عنق زجاجة بل مرحلة في الخط.
الأسئلة الشائعة
هل تعدّل المراجعة كودي؟
لا، للقراءة فقط افتراضيا. لا تلمس الكود إلا إذا طلبت إصلاحا تلقائيا أو اخترت رقما من الخطة.
أي نموذج يُستخدم؟
دور التوجيه review (Settings ← Models ← Task routing): تختار النموذج الذي يراجع بمعزل عن الذي يبرمج.
هل تعمل على فرق أم على المشروع كله؟
كلاهما: الفرق الحالي افتراضيا، أو أي مسار مسمى.
مقارنة ببوت مراجعة SaaS؟
كل شيء يعمل محليا على جهازك وبمفاتيحك. التقرير ملف HTML مستقل داخل مشروعك، لا صفحة على سحابة أحد آخر.
حمّل نافين · الميزات · التوثيق
قراءات تالية موصى بها
- التدقيق الأمني العميق → وكيل أمن AppSec
- السبب الجذري المثبت → وكيل التصحيح
- دورة الوحدة الكاملة → وحدة الكود
- مهام تنفذ نفسها → اللوحة المستقلة
الخلاصة
مراجعة تثبت ما تدّعيه، وتسلّم تقريرا مقروءا، وتنتظر ضوءك الأخضر قبل لمس الكود: هذا هو الفرق بين لعبة ذكاء اصطناعي ومراجع تسمح له بدخول خط إنتاجك.