c-CRAB، المعيار المرجعي لوكلاء مراجعة الكود: ما الذي يقيسه، وما الذي توصّل إليه، وماذا يعني 41.5% فعليًا

وكيل مراجعة كود ومراجع بشري فحصا نفس طلب السحب وأثارا نفس الملاحظة. تطبيق تعليق الوكيل يصلح الخلل؛ والاختبار ينجح. وكل مقياس تشابه نصي احتسبه المؤلفون صنّف مراجعة الوكيل على أنها غير مرتبطة أساسًا بمراجعة الإنسان: BLEU-4 0.00, ROUGE-L 7.02, chrF 20.74, تشابه التضمين 54.59. نفس الملاحظة، بكلمات مختلفة، والطريقة المعيارية لتقييم المراجعة لم تستطع أن ترى أنهما متفقان. هذا المثال الواحد هو الحجة وراء c-CRAB (تُنطق "سي-كراب")، معيار وكيل مراجعة الكود المنشور كـ arXiv:2603.23448.

يقيّم c-CRAB وكلاء مراجعة الكود، وليس وكلاء كتابة الكود. عند تقديم طلب سحب — قد يصدر من إنسان أو من وكيل برمجي — يُنتج وكيل المراجعة مراجعةً، ويعطي c-CRAB تلك المراجعة درجةً بناءً على ما إذا كان العمل بها يُفضي إلى إصلاحٍ صحيحٍ سلوكيًا. وقد صمم هذا المعيار باحثو هندسة البرمجيات: Yuntong Zhang وZhiyuan Pan وImam Nur Bani Yusuf وHaifeng Ruan وRidwan Shariffdeen وAbhik Roychoudhury، وهو يقيّم أربع أدوات: PR-Agent وDevin وClaude Code وCodex. أحد المؤلفين منتسب إلى SonarSource، والورقة صريحة بشأن ما يعنيه ذلك وما لا يعنيه، بكلماتها الخاصة: «الآراء والاستنتاجات المعبَّر عنها في هذه الورقة هي آراء المؤلفين وحدهم ولا تمثل السياسات الرسمية أو التأييد من SonarSource. علاوةً على ذلك، فإن النتائج المقدَّمة هنا مستقلة، ولا ينبغي تفسيرها على أنها تقييم لجودة منتجات SonarSource.»

ملاحظتان قبل التفاصيل. بعض المقالات الصادرة عن جهات خارجية تسمّي العمل نفسه “CR-bench”؛ وهو المعيار نفسه، وهذه الصفحة تستخدم c-CRAB طوال الوقت. كل شكل بياني أدناه هو نتيجة أبلغت عنها الورقة نفسها، قُرئت اليوم من الورقة وحزمة النسخ المتماثل — وليست إعادة تشغيل مستقلة — والتفسير هو تفسيرنا بالإضافة إلى النقاش العملي الذي أثارته الورقة بالفعل. وليس أيٌّ من ذلك توجيهًا من البائعين الذين جرى تقييم أدواتهم. وإذا كنت لا تزال تتردد في تشغيل وكيل مراجعة الكود من الأساس، فإن دليل المشتري الخاص بنا حول وكلاء مراجعة الكود هو نقطة البداية الأفضل؛ هذه الصفحة تتناول كيفية قياس تلك الوكلاء.

لماذا يقيّم c-CRAB المراجعات بالاختبارات وليس بحَكَم LLM؟

الطريقة المعتادة لتقييم وكيل مراجعة الكود هي مقارنة مراجعته بمراجعة إنسان، وذلك باستخدام نموذج لغوي كبير (LLM) كحَكَم أو مقياس للتشابه النصي. يرفض مؤلفو c-CRAB كلتا الطريقتين. فهم يجادلون بأن التحكيم عبر LLM يعاني من التحيز وعدم الاستقرار والحساسية تجاه الموجّهات، مما يجعل التقييم القابل للتكرار والمتسق أمرًا صعبًا. وتُظهر دراسة الحالة أعلاه ما تقيسه مقاييس السلاسل النصية فعلًا: الصياغة وليس الفعالية. ففي طلب السحب الخاص بمكتبة python-telegram-bot، قالت مراجعة Codex نفس ما قاله الإنسان، لكن BLEU-4 وROUGE-L لم يستطيعا التعرف على ذلك.

لذا فإن c-CRAB يفعل العكس تماماً. كل تعليق مراجعة بشري يتم تحويله إلى اختبار قابل للتنفيذ يلتقط المشكلة الأساسية. يُعتبر تعليق المراجعة صحيحاً إذا كان التعامل معه ينتج إصلاحاً صحيحاً سلوكياً — إصلاحاً يجعل الاختبار ينجح. كل حالة تأتي مع بيئة Docker قابلة للتنفيذ، لذا فإن قرار النجاح/الفشل يُتخذ بتشغيل الكود، وليس بسؤال نموذج آخر عن مدى تشابه نصين. لهذا يهم الأمر: وظيفة المراجعة هي تغيير ما يفعله المطور، والاختبار هو الإشارة الوحيدة للتقييم التي تقيس ذلك التغيير مباشرة.

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

كيف تم بناء المعيار، وما هي تكلفة مسار التحويل

c-CRAB مبني على مجموعة البيانات الموجودة inclusionAI/SWE-CARE، والتي توفر حالات طلبات السحب مع بيانات وصفية عن الالتزامات؛ مساهمة c-CRAB الخاصة هي الأوراكل، وليست مجموعة طلبات السحب. يعمل خط أنابيب المعالجة بأربعة مرشحات، وكل واحد منها يكلّف حالات. تعرض الورقة مسار التصفية كما يلي:

• مجموعة البيانات الأولية — 671 طلب سحب، 1,313 تعليقًا.

• تصفية المراجعات — 410 طلبات سحب، 595 تعليقًا. مصنّف LLM، تمت معايرته على مجموعة ذهبية من 100 تعليق مشروح يدويًا، يحتفظ فقط بالمشكلات القابلة للتحقق موضوعيًا ويتجاهل الملاحظات الحوارية أو الذاتية.

• بناء بيئة تنفيذية — 410 طلبات سحب، 595 تعليقًا. صورة Docker واحدة لكل طلب سحب، مع حل التبعيات بالرجوع إلى وكيل برمجي عند فشل الأتمتة.

• تحويل التعليقات باللغة الطبيعية إلى اختبارات — 339 طلب سحب، 481 تعليقًا. تُنشأ الاختبارات باستخدام GPT-5.2 ضمن حلقة تحسين موجَّهة بالتنفيذ تصل إلى ثلاث محاولات؛ لا يُحتفظ بالاختبار إلا إذا فشل على الكود الأصلي ونجح بعد الإصلاح.

• التحقق باستخدام وكيل برمجي — 184 طلب سحب (PR)، 234 تعليقًا. يحاول Claude Code على خلفية Sonnet-4.6 إصلاح الكود بناءً على تعليق المراجعة البشرية فقط؛ تُستبعد الحالات التي لا يستطيع فيها اجتياز الاختبار. هذه هي المجموعة النهائية.

حوالي 27% من طلبات السحب الأولية تنجو. وهذا هو الثمن الحقيقي للمعيار القائم على الاختبار، وهو أيضًا السبب في أن المجموعة المعيارية صغيرة وليست مترامية الأطراف. المجموعة الناجية: 184 حالة PR، 234 تعليق مراجعة مُتحقَّقًا منه، 1.27 اختبارًا لكل حالة، و418.1 سطرًا معدَّلًا لكل PR في المتوسط، و31.8 سطرًا لكل اختبار. قام اثنان من المعلّقين بشكل مستقل بتقييم ما إذا كان الاختبار المُولَّد يلتقط بدقة ملاحظة المراجع البشري، على 50 عينة، واتفقا في 84% من الحالات.

أحد التناقضات التي ستلاحظها إذا قرأت بدقة: جدول مجموعة البيانات يسرد 67 مستودعًا، بينما يقول قسم تهديدات الصلاحية: «184 حالة طلب سحب مع 234 أوراكل قابلة للتحقق عبر 56 مستودعًا». تقدم الورقة كلا الرقمين في مواضع مختلفة، ولن نأخذهما كمتوسط أو نختار الصالح منهما بصمت. يستخدم القراء هذا النوع من التفاصيل بالضبط للحكم على ما إذا كان المعيار يستحق وقتهم، لذا يتم إعادة إنتاج كليهما هنا كما نُشر.

النتائج، وكيفية قراءتها

معدل النجاح هو معدل نجاح الاختبارات الإجمالي: لكل حالة، هو نسبة اختبارات طلب السحب (PR) التي تنجح، والرقم الرئيسي هو المتوسط عبر الحالات. وتقدم الورقة، لكل أداة:

• Claude Code — 1,336 تعليقًا، 7.3 لكل PR — سلوكي 38.1%، بنيوي 30.7%، إجمالي 32.1%

• Devin — 1,344 تعليقًا، 7.3 لكل PR — سلوكي 31.0%، بنيوي 23.4%، إجمالي 24.8%

• PR-Agent — 524 تعليقًا، 2.8 لكل PR — سلوكي 38.1%، هيكلي 19.8%، إجمالي 23.1%

• Codex — 324 تعليقًا، 1.8 لكل PR — سلوكي 38.1%، هيكلي 16.1%، إجمالي 20.1%

• إنسان — 234 تعليقًا، 1.3 لكل PR — 100% بحكم التصميم. كتب البشر المعيار المرجعي، لذا فإن هذا الصف هو مؤشر قياس وليس منافسًا.

اقرأ هذه الصفوف بعناية قبل اقتباس أيٍّ منها. إن عبارة “حوالي 40٪ فقط” من الملخص تمثل نسبة اتحاد: فقد اجتازت 41.5٪ من الاختبارات البالغ عددها 234 اختبارًا أداةٌ واحدةٌ على الأقل من الأدوات الأربع. وهي ليست درجة أي وكيل منفرد — أفضل درجة منفردة هي 32.1٪ لـ Claude Code — كما أنها لا تعني أن الأدوات الأربع معًا رصدت 40٪ من العيوب الحقيقية. يشرح القسم أدناه السبب.

الرقم الأكثر إثارة للاهتمام ليس الفائز. نشر كل من Claude Code وDevin أكثر من 1,300 تعليق — حوالي 7.3 لكل PR — ليصلا إلى 32.1% و24.8%. نشر Codex 324 تعليقًا، حوالي 1.8 لكل PR، ليصل إلى 20.1%. خط الأساس البشري هو 1.3 تعليق لكل PR. قم بالحساب: حوالي أربعة أضعاف حجم التعليقات يحقق أقل من ضعف معدل النجاح. الحجم ليس تغطية. المراجع الثرثار ليس نفس الشيء كالمراجع المفيد، وc-CRAB هو أول معيار أُعدّ لإظهار ذلك.

الفائدة تقطع في الاتجاه الآخر

معدلات النجاح المنخفضة تبدو كإدانة حتى تنظر إلى ما قاسه المؤلفون أيضًا. لقد فحصوا يدويًا 92 تعليقًا عبر 6 طلبات سحب (PRs) وقيّموا 84% منها كمفيدة (77 من 92) — PR-Agent 94%، Codex 88%، Devin 85%، Claude Code 78%. لذا فإن معظم التعليقات التي تفشل في اختبار c-CRAB ليست ضوضاء؛ بل إنها تتعلق بشيء لم يثره المراجع البشري. العينة صغيرة — 92 تعليقًا، 6 طلبات سحب — والورقة تقول ذلك، وعلينا أن نقوله أيضًا.

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

ما لا يمكن لـ c-CRAB رؤيته

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

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

تشغيله بنفسك

إذا أردت إعادة إنتاج الأرقام أو إضافة مُراجع خاصّ بك، فإن حزمة النسخ المتماثل متاحة للعموم على c-CRAB-Benchmark/dataset. ملف README هو التوثيق الفعلي، وهو صريح بشأن طبيعة هذا الأمر. الإعداد يتم عبر code>uv sync/code>؛ تحتاج إلى Docker و code>OPENAI_API_KEY/code> أو code>ANTHROPIC_API_KEY/code>، ويقرأ Claude Code أيضًا بيانات الاعتماد من code>~/.claude/.credentials.json/code>. كما تنشر المنظمة صور Docker الجاهزة للبيئات.

التخطيط: code>pipeline//code> يحتوي على منطق خط الأنابيب والموجهات، code>execution//code> أدوات بناء صور Docker ومساعدات وقت التشغيل، code>results_preprocessed//code> المجموعة الفرعية المنشورة من المعايير (410 حالات معالجة مسبقًا)، code>results_pipeline_funnel//code> ملفات JSONL الخاصة بـ stage0–stage4 وملخص القمع، و code>raw_results_compressed//code> النتائج الخام للتجارب.

إعادة إنتاج التشغيل الكامل تتكون من خمس خطوات: بناء بيئات Docker (code>execution.build_swe_care/code>)، توليد الاختبارات (code>run_testgen_full.sh/code>)، جمع المراجعات الأساسية (code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>)، تشغيل حل الوكيل (code>run_batch_agent_resolution.py/code>)، ثم التقييم (code>run_batch_tool_eval.py --tool <name>/code>). إذا أردت إضافة مُراجع خامس، فاعلم أن نقطة التوسعة ليست واجهة برمجة إضافات: مطالبات المراجعة الأساسية لكل أداة موجودة في code>run_batch_baselines.py/code>، ولا يوثّق ملف README طريقة أنظف — بل تقوم بتعديل ذلك السكربت.

قبل أن تستنسخه، هناك حقيقتان إضافيتان. الورقة مرخّصة بموجب CC BY 4.0؛ وصفحة المستودع لا تنص على ترخيص للكود، لذا لا تفترض وجود أي ترخيص. كما أن الورقة لا تنشر أي أرقام لتكلفة التشغيل أو استهلاك الرموز (tokens) لتشغيل المعيار — وهذا غير منشور، لذا لن نخترعه. وما يلمح إليه خط الأنابيب: صورة Docker واحدة لكل طلب سحب (PR) عبر 184 مثيلًا، بالإضافة إلى مرحلة حلّ الوكيل، ليس أمرًا يمكن إنجازه في جلسة عصرية على حاسوب محمول.

ما يعنيه هذا لأي شخص يطلق خط أنابيب المراجعة

حجة c-CRAB الأساسية هي أن حكم نموذج اللغة الكبير (LLM) هو مصدر غير موثوق. إذا لم تتمكن من بناء مصادر قابلة للتنفيذ — ومعظم الفرق لا تستطيع — فإن أفضل تخفيف متاح هو ألا تدع الحكم يعمل على النموذج الذي أنتج المراجعة أبدًا. الحكم الذي يشارك نموذج المراجع يتفق مع نفسه، وتتحول خطوة التحقق إلى ختم مطاطي لا يزال يعيد رقمًا.

هذا هو بالضبط الفشل الذي تَقي منه وصفة التوجيه الكامنة خلف المراجع الذي نُصدره — وهو توازٍ تصميمي مع نقد c-CRAB، وليس نتيجة قياس أداء. يُشغِّل الإطار حَكَمًا من نماذج LLM على أي حال، كجولة ثانية تجمّع النتائج، وتُسجّل لكل مجموعة درجة 0–1 لمعرفة ما إذا كانت عيبًا ملموسًا في هذا التغيير، وتُسقط كل ما يقلّ عن العتبة. أمّا الوصفة التي تحكمه، code>recipes/orcacode-review.dsl.yaml/code>، فهي ملف عام. لا يذكر الإجراء اسم أي نموذج أبدًا: فهو يستدعي اسمًا مستعارًا للموجّه، والوصفة هي التي تقرر. كما هو مُهيَّأ، تتكون الوصفة من أربعة أسطر — الإعداد الافتراضي للمراجع هو code>deepseek/deepseek-v4-flash-0731/code>، وقاعدة تطابق الترويسة code>x-cr-lens: judge/code> تُرسل جولة الحَكَم إلى code>z-ai/glm-5.3/code>، من مورِّد مختلف. وتنصّ الوصفة بكلماتها على أن الحَكَم «يجب ألّا يذكر اسم نموذج الإعداد الافتراضي»، لأنه على نموذج المراجع نفسه «يتفق مع نفسه، فتصبح الجولة خاملة مع أنها ما تزال تُبلِّغ عن النجاح».

الحَكَم من بائع مختلف يقلّل من التوافق الذاتي؛ لكنه لا يحوّل حُكم نموذج اللغة الكبير (LLM) إلى اختبار. لم يختبر c-CRAB مُراجعنا، ولن نوحي بخلاف ذلك.OrcaCode Review ينفّذ تمريرة مراجعة بالإضافة إلى حَكَم تحقّق مستقل، لكل توكِن وليس لكل مقعد، وكل مطالبة فيه علنية — لذا يمكنك توجيهه إلى معيار مثل هذا والحصول على رقمك الخاص بدلاً من رقمنا.

خلاصة القول

c-CRAB هو أول معيار لمراجعة الكود البرمجي يمكنك الوثوق في نتائجه إلى حد كبير لتعني ما تقوله: لا تُعتبر المراجعة ناجحة إلا إذا أدى العمل بها إلى إصلاح الكود. الأرقام الرئيسية منخفضة حقًا — أفضل أداة واحدة 32.1%، والاتحاد 41.5% — لكنها تقيس التداخل مع المخاوف التي أثارها البشر، وليس جودة المراجعات، وتُظهر بيانات الفائدة أن معظم التعليقات هي إشارة حقيقية. الدروس الدائمة هي تلك التي يدافع عنها الورقة نفسها: الحجم ليس تغطية، والوكلاء والبشر ينظرون إلى أشياء مختلفة، والطريقة الصحيحة للنشر هي التعاون بين الإنسان والوكيل. والمعيار مفتوح، لذا الخطوة التالية الصادقة هي تشغيل مراجعك الخاص عليه والحصول على رقمك الخاص.