مراجعة الكود الآلية في 2026: اجعلها تعمل على كل PR دون شراء مقعد

مراجعة الكود الآلية هي وظيفة تكامل مستمر (CI) ترسل الـ diff الخاص بك إلى نموذج لغوي، وتنشر النتائج على الأسطر المتأثرة، وتُفشل فحص الحالة عندما تجد شيئًا خطيرًا. الطريقة لتشغيل ذلك على كل طلب سحب دون اشتراك لكل مقعد هي استضافة ذاتية لأداة مفتوحة المصدر: انسخ سير عمل مكوّنًا من حوالي خمسة عشر سطرًا إلى مستودعك، وأضف مفتاح API واحدًا، وادفع فقط مقابل الرموز التي يستهلكها كل مراجعة. لا يوجد عدد مقاعد للشراء، لأنه لا يوجد مقعد. التنفيذ المرجعي الذي نحتفظ به هو مستودع Orca-Code-Review — عام، ومرخّص بموجب MIT، ومنذ إنشائه في 25 يونيو 2026 وهو الكود الذي يقف خلف إجراء GitHub المسمى OrcaCode Review. تحدد وصفة التوجيه المرفقة مرحلة المراجعة الافتراضية لتستخدم DeepSeek V4 Flash، وحَكَم التحقق المستقل ليستخدم GLM-5.3، وكلاهما يمكنك تغييره. يستعرض هذا المقال ما يعمل فعليًا عند كل push، وما تقوم بتهيئته، وما تكلفته بالرموز، وأنماط الفشل التي ستواجهها في الأسبوع الثاني.

النسخة المختصرة. كل عملية دفع تحصل على مراجعة واحدة. تُنشر النتائج مباشرة على الأسطر المتغيّرة. نتائج P0 و P1 تُفشِل الفحص وتمنع الدمج؛ أما التشغيل النظيف فيمر. يمكنك إعادة المراجعة عند الطلب بالتعليق على /orcacode-review. سير العمل موجود في مستودعك؛ منطق المراجعة موجود في الإجراء المنشور؛ اختيار النموذج موجود في وصفة توجيه يمكنك تعديلها في مساحة العمل الخاصة بك. يقرأ المراجع الفرق وملفات المستودع ولا ينفّذ أبدًا كود الـ PR الخاص بك. والتحفظ الصريح من البداية: إنه يلتقط أخطاء حقيقية ولا يزال يفوته ما يحتاج إلى إنسان يعرف لماذا الكود على هذا النحو.

• سير عمل واحد + سر واحد + فاتورة رموز. لا ترخيص لكل مقعد في أي مرحلة.

• الأداة مفتوحة المصدر. انسخها، وافرعها، ودققها، وثبّتها على SHA للالتزام.

• النموذج هو إعداد، وليس مورّدًا. غيّر المراجع عبر تعديل وصفة التوجيه، وليس بإعادة كتابة YAML أو ترقية الإجراء.

• الاختلافات الضخمة لا تكلف شيئًا. يعمل حارس الحجم قبل النموذج.

• يقرأ كودك، ولا ينفذه أبدًا.هذه هي خاصية الأمان التي تجعل pull_request_target آمنًا للاستخدام تمامًا.

كيف تعمل مراجعة الكود الآلية في الواقع

كل نظام مراجعة آلي هو نفس المكونات الثلاثة بأثواب مختلفة: حدث، ومنفذ، ومراجع.

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

العداء هو GitHub Actions على ubuntu-latest. تحتاج الوظيفة إلى ثلاثة أذونات: وصول للقراءة إلى المحتويات، وصول للكتابة إلى طلبات السحب (لنشر التعليقات المضمنة)، ووصول للكتابة إلى المشكلات (لنشر الملخص وتنظيف التعليقات القديمة).

المراجع هو نموذج لغوي. يجلب الإجراء رأس الـPR، ويجمع الفرق وسياق المستودع الذي يختاره المحرك، ويرسل ذلك إلى نموذج المراجعة. النتيجة هي مجموعة من الملاحظات، كل منها موسومة بدرجة خطورة ومرتبطة بملف وسطر. ينشرها الإجراء كتعليقات PR مضمّنة، ويكتب تعليقًا ملخصًا واحدًا في منطقة علامات في أعلى وصف الـPR، يُستبدل في مكانه عند كل push.

البوابة هي فحص حالة. لا يعرف GitHub معنى «مراجعة»؛ فهو لا يعرف سوى ما إذا كان فحص المراجعة ناجحًا. يمكنك جعل البوابة حقيقية من خلال تعيين هذا الفحص كشرط إلزامي في حماية الفرع. هذه هي آلية منع الدمج بأكملها — لا استدعاءات لواجهة برمجة التطبيقات الإدارية، ولا تسميات، مجرد فحص إلزامي فاشل.

ما الذي لا يحدث: لا شيء ينفّذ كود الـPR. المحرك يقرأ فقط. هذا الثابت الوحيد هو ما يجعل المميّز pull_request_target، وهو المشغّل، آمنًا للاستخدام مع مفتاح API مدفوع.

الأداة مفتوحة المصدر هي العامل المميّز

كل ما سبق ينطبق على كثير من الأدوات. لكن ما لا ينطبق على معظمها هو أن هذا الشيء بأكمله قابل للفحص والاستضافة الذاتية، وهو ما يوفّره لك مستودع Orca-Code-Review. إنه مستودع GitHub عام بترخيص MIT (باستخدام JavaScript، أُنشئ في 25 يونيو 2026) يحزم المراجعة كإجراء GitHub مركّب قابل لإعادة الاستخدام بالإضافة إلى مثبّت، وهو نفس الكود الذي تطبيق OrcaCode Review المستضافيشغّله.

اقضِ عشر دقائق في الشجرة ويمكنك تسمية كل جزء يمس PR الخاص بك:

• action.yml — الإجراء المركّب، حوالي خمسة عشر مدخلًا موثّقًا. لا توجد أسماء نماذج مضمّنة بشكل ثابت في أي مكان فيه.

• workflows/orca-code-review.yml — مثال على سير عمل المستهلك، وهي الأسطر الخمسة عشر تقريبًا التي تنسخها في .github/workflows/.

• recipes/ — DSL التوجيه. هنا يتم اختيار النموذج فعليًا.

• rules/ — سُلَّم الخطورة (P0–P3)، وشكل المخرجات الإلزامي، وتوجيه للاتفاقيات يُدخل وثيقة اتفاقيات المشروع في المراجعة كبيانات مرجعية غير موثوقة.

• scripts/ — مرشح الدقة (L1 بالإضافة إلى مُقيِّم L2)، وحارس الفروقات، وبوابة الدمج، وتقرير التشغيل، وعداد الرموز. كل منها عبارة عن ملف .mjs صغير وسهل القراءة مع اختبارات.

• skills/setup-orca-code-review — المهارة التي يضعها المثبّت في وكيل البرمجة لديك، وتشمل التثبيت وإعادة التكوين واستكشاف الأخطاء وإصلاحها وإلغاء التثبيت.

• .claude-plugin/ — ما يسمح لـ Claude Code بتثبيت المهارة كإضافة ذاتية التحديث.

التثبيت عبارة عن سطر واحد يعلّم ذكاءك الاصطناعي ما هو المنتج ثم يتوقف:

npx @orcarouter/code-review

تكتشف الواجهة السطرية (CLI) وكلاء البرمجة الذين تستخدمهم — يغطي الفهرس 36 منصة، من Claude Code وCursor وCodex وOpenCode وWindsurf إلى GitHub Copilot وGemini CLI وAmazon Q Developer وCline وRooCode وغيرها — وتُثبّت المهارة ثم تُسلِّمك الأمر. بعدها تسأل وكيلك بلغة بسيطة: «أعد إعداد OrcaCode Review في هذا المستودع،» «احجب P0 فقط،» «لماذا لم تعمل المراجعة؟» وتتكفل المهارة بدورة الحياة: فهي تكتب سير العمل، وترشدك خلال إعداد مفتاح API، وتضبط البوابة، ولا تطرح إلا الأسئلة التي تخصك أنت وحدك.

يمكن لكلود كود تثبيت المهارة كإضافة بدلاً من ذلك، مما يبقيها محدّثة مع تحرّك المستودع:

/plugin marketplace add Continuum-AI-Corp/orca-code-review

/plugin install orca-code-review

لا يوجد وكيل إطلاقًا؟ دورة الحياة نفسها هي مجرد أوامر فرعية — initيكتب سير العمل، reconfigureيغيّر قواعد الحظر وحدود الاختلاف، doctorيشخّص المراجعات التي لا تعمل أو لا تُنشر، uninstallيزيله (مع إزالة الفحص المطلوب أولًا). المهارة هي الباب الأمامي، وليست الباب الوحيد. أو اربطه يدويًا: انسخ سير العمل، وأضف سرًا واحدًا باسم ORCAROUTER_API_KEY، وحدّد review كفحص مطلوب.

المحرك الأساسي هو Ali​baba’s Open Code Review، مثبّت بإصدار دقيق ومرخّص بموجب Apache-2.0. يقرر OrcaCode كيفية المراجعة؛ ويقرر OrcaRouter أي نموذج يشغّلها. جدول المقارنة بين الاستضافة الذاتية والاستضافة المُدارة — ما يكلّفه “المجاني” فعليًا عند استضافة مراجِع مفتوح المصدر بنفسك — يتم تناوله في مقالنا حول مراجعة الكود المفتوحة.

ما الذي يتم تشغيله، بالترتيب، عند كل عملية دفع؟

من المفيد معرفة الترتيب، لأن كل خطوة يمكن أن تفشل أو تُتخطى بشكل مستقل:

• يعمل حارس الفروقات أولاً، قبل أن يقوم النموذج بأي شيء. إذا تجاوز فرق merge-base 512 كيلوبايت أو لمس أكثر من 300 ملف، يتم تخطي المراجعة ونشر إشعار. الافتراضي هو on-oversized-diff: fail، وبالتالي لا يمكن لفرق يتم حشره ليتجاوز الحدود أن يمر عبر بوابة إلزامية دون مراجعة. وهذا أيضًا هو التحكم في الإنفاق: فطلب السحب الضخم يكلف صفر رمز.

• يقوم المحرك بمراجعة الفرق. ممر واحد، تزامن لكل ملف يبلغ افتراضيًا 24، مع سقف زمني فِعلي يبلغ 20 دقيقة لكل ممر.

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

• تُطبَّق البوابة. نتائج P0 وP1 تفشل في الفحص؛ ملخص PR يحتسب كل نتيجة، بما في ذلك النتائج المكتومة من الفرق.

• يطبع العداد ما كلفته. العداد يُدخل سجلات احتساب الرموز لكل مكالمة — المطالبة، والإكمال، والرموز المخزّنة مؤقتًا، والنموذج الذي حدّده الموجّه — ويطبع جدول الإجماليات في سجل الوظيفة.

• تقرير تشغيل اختيارييرسل أعداد الخطورة وبيانات البوابة إلى مستوى التحكم في OrcaRouter من أجل لوحة معلومات التحليلات. لا يحمل أي رمز أو فرق أو نص نتيجة.

ما الذي تقوم بتكوينه فعليًا

هناك ثلاثة أسطح، ولكلٍّ منها نطاق تأثير مختلف تمامًا.

1. ملف سير العمل. سير العمل المستهلك رفيع عن قصد. المدخلات التي تستحق التعديل موجودة في الإجراء: block-on (أي مستويات الخطورة تُفشِل الفحص — الافتراضي P0,P1)، fix-first (التي توقف مراجعة شاملة مبكرًا)، auto-review-authors (قائمة سماح لمن يحصل على مراجعة تلقائية)، max-diff-kb و max-diff-files و on-oversized-diff (حارس الحجم)، timeout-minutes، concurrency، meter، و report. لكل واحد قيمة افتراضية موثقة، لذا فإن سير عمل جديدًا يتكون من خمسة أسطر من YAML بالإضافة إلى سر.

2. لوحة التحكم. مع settings: true (الافتراضي)، كل تشغيل يجلب إعدادات خاصة بالمستودع من OrcaRouter → Apps → OrcaCode Review: النموذج، وضع المراجعة، سياسة الدمج، مستويات الخطورة، الوضع الصامت، المراجعة الشاملة، معيار تقييم مخصص، والحواجز الوقائية. اضبط settings: "false" وملف سير العمل هو المرجع — لا يمكن لأي قيمة في لوحة التحكم تجاوزه. إذا لم تفتح وحدة التحكم أبدًا، فلن تفقد شيئًا من الإمكانيات؛ فقط تقوم بالتهيئة عبر YAML.

3. وصفة التوجيه — التي يغفل عنها الناس.لا يذكر الإجراء اسم نموذج أبدًا. بدلاً من ذلك، يحقن الحقائق الخام كترويسات طلب — الطبقة التي سُجِّل التشغيل بها، وما إذا كان المرور السابق قد وجد P0/P1، وعلامة عدسة عندما يكون الطلب هو الحكم L2 — وتقوم وصفة DSL الخاصة بموجّه مساحة العمل بتعيين تلك الترويسات إلى نموذج ملموس. تضع الوصفة الجاهزة المراجعة افتراضيًا على DeepSeek V4 Flash والحكم على GLM-5.3، وتوجّه الاثنين إلى نموذجين منفصلين عن قصد. تغيير النموذج الذي يراجع شفرتك هو تعديل على تلك الوصفة في مساحة العمل الخاصة بك: لا رفع لإصدار الإجراء، لا إعادة كتابة YAML، لا إعادة نشر.

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

كم تبلغ تكلفتها؟

لكل توكن، وليس لكل مقعد. أنت تختار النموذج على OrcaRouter، وتتم الفوترة على أساس التوكنات المستهلكة، وعداديجعل رقم كل تشغيلة مرئيًا بدلًا من أن يظل غامضًا. آليات GitHub، ومراجعة الكود المقننة في Copilot منذ 1 يونيو 2026، وكيفية اندراج المراجعين الخارجيين في هذا السير العمل موضحة في دليل مراجعة كود GitHub الخاص بنا. المقارنة الكاملة للتكلفة حقلًا بحقل — المنتجات القائمة على المقاعد مقابل تلك القائمة على التوكنات، مع مثال محلول — موجودة في مقارنة أدوات مراجعة الكود بالذكاء الاصطناعي، ومسألة تكلفة مراجعة واحدة بالتوكنات عندما يستكشف المراجع المستودع فعليًا (التمييز بين البوت والوكيل) في مقال وكلاء مراجعة الكود. ما تضيفه هذه المقالة هو شكل الفاتورة: فهي تتناسب مع الكود الذي تراجعه، لا مع عدد الأشخاص الذين يراجعونه.

هناك عنصران للتحكم في الإنفاق مهمان منذ اليوم الأول. في مستودع عام، pull_request_target يتجاوز بوابة موافقة الفروع في GitHub، ومفتاح المراجعة يُحتسب من المحفظة — يمكن لشخص غريب فتح طلب سحب وتشغيل مراجعات مدفوعة. قم بتعيين ميزانية للمحفظة مع تنبيهات على المفتاح، واضبط auto-review-authors على شيء مثل OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR بحيث لا تتم مراجعة المساهمين غير المعروفين تلقائيًا. وكما ذُكر، فإن حارس الاختلافات يعني أن طلبات السحب الضخمة لا تكلف شيئًا على الإطلاق.

ما الذي ينكسر؟

المراجعة الآلية هي CI. إنها تتعطل مثل CI، وأوضاع الفشل في الغالب ليست خطأ النموذج:

• لا يعمل سير العمل أبدًا. بالنسبة إلى pull_request_target، يُقرأ سير العمل من الفرع الأساسي — فسير العمل المضاف فقط في فرع الـPR لن يعمل حتى يتم دمجه. وتحقق أيضًا من أن التطبيق مفعّل، وأن auto_review مفعّل، وأن الـPR ليس مسودة (تُتخطى المسودات في وضع ready_for_review)، وأن الإجراءات (Actions) مفعّلة على المستودع (المستودعات المتفرعة تأتي معطّلة افتراضيًا).

• /orcacode-review لا يفعل شيئًا. يتطلب مشغّل التعليق أن يبدأ التعليق بأحد الأشكال الأربعة — /orcacode-review، /orcacode review، @orcacode-review، @orcacode review — وأن يكون المعلّق مالكًا أو عضوًا أو مساهمًا. المسافة البادئة تكسر التطابق. يتم تجاهل أمر المساهم الخارجي بصمت، عن قصد: إذ يشغّل الأمر سير عمل متميزًا يحمل المفتاح المدفوع.

• خطأ في المصادقة. اسم السر خاطئ أو أنه مفقود، أو تم إبطال المفتاح أو تجاوز الميزانية، أو تم تبديل سير العمل إلى pull_request (الذي لا يمكنه قراءة الأسرار من النسخ المتفرعة).

• الفحص أحمر مع إشعار “diff too large”. هذا هو حارس الحجم، يعمل كما تم تكوينه. قسّم طلب السحب، أو ارفع الحدود، أو اضبط on-oversized-diff: pass — واعلم أنه مع فحص إلزامي، فإن معنى pass هو أن طلب سحب كبيرًا بما يكفي سيمرّ مباشرة عبر البوابة دون مراجعة.

• تعمل المراجعة لكن لا تظهر أي تعليقات. ثلاثة أسباب، كلها حميدة أو مُهيأة: التشغيل النظيف ينشر ملخصًا بدلاً من التعليقات المضمنة؛ الوضع الصامت يكتم P2 وقت النشر (ما زالا يحسبانه في البوابة والتقرير)؛ أو مرشح الدقة أسقط النتائج — L1 يُسقط النتائج التي لا يتطابق مقتطفها مع الالتزام، وL2 يُسقط المجموعات منخفضة الثقة. تخبرك أعداد الخطورة في سجل الوظيفة بأيها حدث.

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

عندما تكون المراجعة الآلية أداة خاطئة

{{1}}إنه خاطئ أكثر مما يعترف به موردو الأدوات.{{/1}} تجنب استخدامه عندما:

• المشكلة هي السياق، وليس الحجم. إذا كانت المراجعات بطيئة لأن المراجعين يحتاجون إلى فهم سبب كتابة الكود بهذه الطريقة، فإن قراءة LLM للـ diff تضيف القليل. ليس لديه ذاكرة لسلسلة نقاش الشهر الماضي ولا إدراك لتاريخ النظام.

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

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

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

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

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

الإيجابيات الكاذبة، وما الذي تُصلحه تصفية الدقة وما لا تُصلحه

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

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

الطبقة المحكِّمة (L2) تقضي على الادعاء المكرَّر والادعاء غير المدعوم: يقوم محكّم LLM بتجميع النتائج حسب السبب الجذري، ويحذف المجموعات التي تنخفض ثقتها دون عتبة المحكّم (الافتراضية 0.5). وهذا يعالج مشكلة “نفس الخطأ المُبلَّغ عنه بثلاث طرق” والنتيجة التخمينية.

ما لا تُصلحه أيٌّ من الطبقتين يستحق أن يُقال بصوتٍ عالٍ. نتيجة خاطئة ولكنهاواثقة تنجو من المُقيِّم — فالمُقيِّم نموذج لغوي كبير (LLM)، وكونُ النموذج يبدو واثقًا لا يعني أن النتيجة صحيحة. والمُقيِّم الذي يعمل على نفس نموذج المُراجِع يتفق مع نفسه، فيصبح الفحص خاملًا مع استمراره في الإبلاغ عن النجاح، ولهذا يوجّه الإعداد المُرفَق المُقيِّم إلى نموذج مختلف عن نموذج المُراجِع. ومعيار الخطورة مُتحفِّظ عن قصد — «عند التردد بين مستويين، اختر المستوى الأدنى» — مما يعني أن الخطأ الحقيقي ولكنه مشروط من المرجح أن يُسجَّل كتنبيه P2 بدلًا من P1 مانع. هذه هي المعايرة الصحيحة لأداة لا ينبغي أن تمنع كل شيء، لكنها معايرة: إنها تستبدل تفويت بعض العوائق المانعة بإنذارات كاذبة أقل. وملخّص PR يعدّ كل نتيجة دائمًا، لذا تظل نتائج P2 المخففة متاحة للقراءة. وإذا كان هذا التقايض غير مناسب لفريقك، فإن معيار الخطورة وعتبة المُقيِّم مجرد إعدادات، وليسا تذكرة دعم.

الخلاصة

بالنسبة لفريق يعتمد بالفعل على GitHub Actions، فإن الإطار مفتوح المصدر هو أرخص وسيلة للحصول على مراجعة آلية للكود في كل طلب سحب (PR): ملف سير عمل واحد، سر واحد، فاتورة رموز تتناسب مع الكود المراجع، واختيار نموذج تملكه. اشترِ منتجًا يُدفع عنه لكل مستخدم عندما تريد صفر مجهود تشغيلي وبائعًا تتصل به — ليس لأن المراجعة أفضل، بل لأنك تشتري مشكلة شخص آخر بدلاً من تشغيل مشكلتك الخاصة. وقبل أن تُعدّ أيًا من ذلك، اسأل: هل ستُقرأ المراجعة؟ يمكن للأداة أن تُنشئ المراجعة تلقائيًا، لكنها لا تستطيع أن تجعل أحدًا يقرأها.

هل تريد نفس المراجع دون تشغيله بنفسك؟ OrcaCode Review يشغّل هذه المنصة نفسها كتطبيق GitHub مستضاف — نفس المنهجية المفتوحة، نفس الرسوم لكل توكن، بدون مقاعد.