استخدام المراجعة المدعومة بالذكاء الاصطناعي
يشرح هذا الدليل كيف تطلب من وكلاء المراجعة مراجعة طلب سحب، وكيف تنشر النتيجة على GitHub.
ابدأ مراجعة بالذكاء الاصطناعي
قسم بعنوان “ابدأ مراجعة بالذكاء الاصطناعي”- افتح طلب السحب وانتقل إلى لسان نظرة عامة
- افتح ⋯ (مزيد من الإجراءات) في صف الإجراءات واختر اسأل الذكاء الاصطناعي
لا يظهر البند إلا حين يكون طلب السحب مفتوحًا، فهو إجراء يسبق الدمج. الزر نفسه يُعرَض باسم اسأل الذكاء الاصطناعي في الحالة الفارغة للسان مراجعة، قبل أن توجد أي مراجعة.
يبدأ Control Center خط الأنابيب pr_review المُنشأ مع مساحة العمل، ويفتح لسان
مراجعة لطلب السحب حتى تتابعه. يقوم خط الأنابيب بما يلي:
- يفتح مساحة المراجعة الخاصة بطلب السحب، وفي شجرة عملها المعزولة يُسحب الطلب عند مرجع head
- يوزّع المراجعين حسب مستوى المراجعة في مساحة العمل، ثلاثة افتراضيًا (الوكلاء المُنشَؤون مع مساحة العمل qa وarchitect وengineer، بالتوازي). لا يُكشَف عن اللغة ولا عن المجال
- يكلّف الوكيل القائد (CEO) بتجميع نتائجهم في استعراض موجّه
- يُنهي: يصنّف النتائج في سلال الإجماع ويحسب الحكم. حين يبلغ ارتباط مساحة
المراجعة
awaiting approval، يظهر النشر على GitHub في لسان المراجعة
عمق المراجعة هو مستوى المراجعة لمساحة العمل: light (مراجع واحد)،
وbalanced (ثلاثة، وهو الافتراضي)، وthorough (الخمسة جميعًا، مع متخصصَي
الأمان والأداء). يُضبط من الإعدادات ← مساحة العمل ← عام، على بطاقة سياسة
مساحة العمل. المستوى الأخف يودع عدد النتائج نفسه، ويُبرز عددًا أقل منها في
الصدارة.
ينشر المراجعون كلهم في مساحة المراجعة الواحدة لطلب السحب، وهذا ما يجعل نتائجهم قابلة للمقارنة. انظر مراجعة بالذكاء الاصطناعي لترى كيف تتركّب الأجزاء.
يأتي pr_review بمشغّل يدوي فقط. لينطلق عند كل طلب سحب يُنشر، أضف مشغّلًا
بنفسك. انظر
إرسال وكلاء مراجعة.
وتستطيع أيضًا بدء مراجعة من GitHub نفسه، من غير مشغّل لخط الأنابيب: اذكر بوت
الخادم على طلب السحب، أو أضف الوسم ai-review. انظر
التحدث إلى Control Center من طلب سحب على GitHub.
إذا قال إشعار منبثق «هناك مراجعة قيد التشغيل بالفعل لطلب السحب هذا»، فهناك مراجعة جارية. ابقَ في لسان مراجعة، أو افتح خطوط الأنابيب لتجدها.
اقرأ النتائج
قسم بعنوان “اقرأ النتائج”يسجّل المراجعون النتائج في عُقد مراجعة داخل مساحة المراجعة. تحمل كل عقدة:
| الحقل | الوصف |
|---|---|
| النوع | bug، suggestion، recommendation، question أو ticket |
| الأولوية | P0 (حرج) إلى P3 (ملاحظة طفيفة) |
| الفئة | security، stability، data_integrity، correctness، performance أو maintainability |
| الملف والسطر | موضع ارتكاز النتيجة |
| الشفرة الأصلية | الشفرة التي تتناولها النتيجة |
| الشفرة المقترحة | الإصلاح المقترح |
| الثقة | مدى ثقة المراجع |
| الحالة | open ثم consensus-ready ثم resolved أو dismissed |
لا تبلغ النتيجة consensus-ready إلا حين يؤكّدها مراجع نظير. لا يستطيع الوكيل تأكيد نتيجته هو، فرأي مراجع واحد لا يترقّى من تلقاء نفسه.
يعرض لسان مراجعة قائمة النتائج، ويمكن تصفيتها حسب النوع والحالة، مع مفتاح للنتائج المتجاهَلة، إلى جانب المُخرَج الذي نشره الوكيل المُجمِّع. العرض الحتمي — المجموعات، ولوحة المحاور المتعددة، وفروق العقد والفروق البصرية — يُحسب على الخادم ولا سطح له في التطبيق. انظر حوسبة المراجعة لما تنتجه هذه الجولة.
افحص لوحة الخلافات
قسم بعنوان “افحص لوحة الخلافات”حين يرسّخ مراجعان نتيجتين على الملف والسطر نفسهما ويقيّمانهما تقييمًا شديد
الاختلاف — بفارق مستويين أو أكثر في الأولوية، أو يسمّيها أحدهما bug والآخر
suggestion — تظهر لوحة الخلافات فوق قائمة النتائج. اقرأها أولًا: هناك يفترق
رأي المراجعين، وهناك يكون حكمك أجدى ما يكون.
اقرأ الحكم
قسم بعنوان “اقرأ الحكم”حين يُنهي الوكيل القائد، يحسب حكمًا:
| الحكم | المعنى |
|---|---|
| Ship | لم يُعثر على ما يعيق |
| Hold | مسائل ينبغي معالجتها قبل الدمج |
| Block | مسائل حرجة يجب إصلاحها |
يحمل الحكم درجة ثقة مجمّعة، وتعداد النتائج لكل أولوية.
ثم تنضم محاور المراجعة إلى الحكم، ولا تستطيع إلا أن تجعله أشد. محور عليه
بوابة وفشل يفرض Block. ومحور عليه بوابة لم يكتمل (partial) أو لم يستطع
العمل أصلًا (unavailable) يفرض Hold على الأقل. غياب الدليل لا يتحوّل إلى
بوابة خضراء.
انشر المراجعة على GitHub
قسم بعنوان “انشر المراجعة على GitHub”النشر خطوة منفصلة، ويُقصَد أن يبادر بها المستخدم. يُبقي خط الأنابيب pr_review
المراجعة داخل Control Center، ولا يرسلها إلى GitHub.
- في لسان مراجعة، انتظر حتى يظهر النشر على GitHub
- اضغط النشر على GitHub
يرسل Control Center مراجعة واحدة على GitHub. تُتخطى النتائج المحلولة أو
المتجاهَلة أصلًا. يضم الزر كل نتيجة مفتوحة متبقية، وعند Ship يقدّم
APPROVE. (أداة MCP publish_review_to_github ما زالت تفترض النتائج التي
أكّدها الأقران فقط، ولا تُصدِر موافقة إلا إذا مرّرت approve_on_ship.) النتائج
التي تحمل مرساة ملف وسطر تصبح تعليقات مضمّنة، وما عداها يُطوى في متن الملخص،
ويحمل كل منها تذييل “— Control Center AI review” حتى يبقى المصدر واضحًا.
يُقدَّم حكم Block بصفة REQUEST_CHANGES، وHold بصفة COMMENT، وShip
بصفة APPROVE من هذا الزر. ثم يقرأ الإشعار المنبثق منشور. تُنشر المراجعة
بهوية تطبيق الخادم.
إذا رفض GitHub مرساة مضمّنة لأن السطر ليس جزءًا من الفروق، تُرسَل المراجعة كلها من جديد وكل نتيجة مطوية في المتن، حتى لا يسقط شيء في صمت.
خطوط الأنابيب المضمّنة الأخرى ترسل إلى GitHub مباشرة: ينتهي كل من
cross_review وpr_triage وticket_to_pr وpre_merge_gate بخطوة تعليق.
pr_review وحده يُبقي ناتجه لديك.
أرسل المراجعين بنفسك
قسم بعنوان “أرسل المراجعين بنفسك”للتحكم في الأدوار التي تراجع طلب السحب والملفات التي ينظر فيها كل دور، استخدم
أداة MCP dispatch_reviewers داخل مساحة مراجعة قائمة، أو أضف عُقد مراجعين إلى
خط أنابيب. المساران، مع توقيع الأداة بحذافيره، في
إرسال وكلاء مراجعة.