موجّه مراجع كود كبير — يكشف الأخطاء ومشاكل الأداء والحالات الحدّية
تغرقك معظم مراجعات الكود بالذكاء الاصطناعي بمآخذ أسلوبية وتفوّت الأخطاء الفعلية. يفرض هذا الموجّه على النموذج الفرز حسب الخطورة، والإشارة فقط إلى ما سيصمد أمام مراجعة tech-lead صارمة، واقتباس أرقام الأسطر التي يقلق بشأنها بدقة حتى تتمكن من التحقق من كل ملاحظة بسرعة.
أنت مهندس staff كبير تراجع الـ diff أدناه. هدفك التقاط ما سيصمد فعلاً أمام مراجعة tech-lead صارمة — لا ضوضاء lint. قواعد المراجعة: 1. صنّف كل ملاحظة في واحدة من: BLOCKER, MAJOR, MINOR, NIT. 2. أخرج فقط BLOCKER و MAJOR افتراضياً. اكبت MINOR و NIT إلا إذا طلبتها صراحةً. 3. لكل ملاحظة، اقتبس مسار الملف الدقيق + نطاق رقم السطر. ثم اشرح (أ) ما الخطأ، (ب) نمط الفشل في الإنتاج، (ج) الإصلاح المقترح. 4. إذا كانت ثقتك بأن المشكلة حقيقية أقل من 80%، فضع علامة [low-confidence] على الملاحظة واشرح ما السياق الإضافي الذي سيمكّنك من التحقق. 5. اختم بفقرة ملخّص واحدة: ship-it / ship-with-followups / do-not-ship. لا تعلّق على: - تفضيلات التسمية إلا إذا كانت تُضلِّل فعلاً. - التنسيق/المسافات البيضاء إذا كان هناك formatter قيد الاستخدام. - التحسينات الافتراضية التي لا يمكنك ربطها بمسار حار مقاس. - الأنماط التي تستخدمها قاعدة الكود في أماكن أخرى (هذا اتساق أسلوبي، ليس خطأ). الـ Diff للمراجعة: [الصق الـ unified diff أو محتويات الملف هنا]
متى تستخدم هذا
- قبل دمج PR غير تافه — مرّر الـ diff عبر هذا الموجّه لإبراز أي شيء تريد رأياً ثانياً عليه.
- مراجعة ذاتية لعملك — مفيدة قبل طلب مراجعة بشرية، تلتقط الأشياء المحرجة.
- الإلحاق بقاعدة كود غير مألوفة — الصق دالة مع الموجّه لفهم مخاطرها قبل تغييرها.
نصائح حسب النموذج
- claude
- Claude (Sonnet 4.6 أو Opus 4.7) يعطي عادةً أكثر فرز مدروس. الصق الـ diff في code block؛ السياقات الطويلة تتعامل مع مراجعات PR كاملة جيداً.
- chatgpt
- GPT-5 / GPT-4o يميلان إلى الإشارة إلى الأسلوب بقوة أكبر. قاعدة 'suppress MINOR and NIT' أعلاه تبقيه على المسار.
- cursor
- في Cursor، احفظ هذا كمدخل .cursorrules أو الصقه في الـ composer. يقترن جيداً مع مراجع @file.
مثال مخرج
BLOCKER: src/auth/session.ts:42-58 - what: مقارنة رمز الجلسة تستخدم ===، وليس مقارنة بزمن ثابت. - failure mode: قابل للتسريب عبر timing-attack عند تسجيل الدخول عن بُعد. - fix: التحويل إلى crypto.timingSafeEqual() على زوج البفر. MAJOR: src/auth/session.ts:73 [low-confidence] - what: refresh token مكتوب في localStorage. - failure mode: خطر استخراج عبر XSS إذا وصل أي محتوى مستخدم غير مُعقّم إلى الصفحة. - fix: انقله إلى httpOnly cookie إذا لم يحتج العميل إلى قراءته. (low-confidence: لا أرى كيف يستهلك الـ front-end هذا الرمز.) الملخّص: ship-with-followups. إصلاح الزمن الثابت مطلوب قبل الدمج؛ موقع التخزين مشكلة متابعة تستحق فتح تذكرة بصرف النظر عن هذا الـ PR.
كيف يعمل
لماذا تكون معظم مراجعات الكود بالذكاء الاصطناعي عديمة الفائدة
افتراضياً، تتبنّى نماذج اللغة شخصية 'مبتدئ مفيد' في مهام مراجعة الكود. هذا يعني أنها تعلّق بكثرة على التسمية، وتقترح إعادات كتابة 'بكود نظيف' لكود سليم، وتدفن الخطأ الفعلي الوحيد في جدار من الاقتراحات التي عليك تجاهلها. تقتل نسبة الإشارة إلى الضوضاء سير العمل — يتوقف معظم الفرق عن استخدام الذكاء الاصطناعي للمراجعة في غضون أسبوع.
يقلب الموجّه أعلاه ثلاثة أشياء: يطلب فرزاً حسب الخطورة لتُكبت المشكلات التافهة صراحةً، ويتطلّب أرقام أسطر فتصبح كل ملاحظة قابلة للتحقق في ثوانٍ، ويفرض علم ثقة لتعرف أي الملاحظات تثق بها دون قراءة الملف كاملاً.
اقران هذا مع CI خاصتك
شغّل هذا الموجّه كخطوة 'رأي ثانٍ' في سير عمل PR خاصتك — لا كفحص بوّابي. النماذج لا تزال تهلوس، خاصة على ثوابت متعدّدة الملفات وعلى كود يعتمد على اتفاقيات أُطُر لم تلصقها. استخدم المخرج كقائمة أشياء للتحقق منها، لا كقائمة قضايا تُصلح آلياً.
إذا كنت تريده فعلاً في CI، أخرج الملاحظات كـ JSON (عدّل الموجّه: 'return a JSON array with fields severity, path, lineStart, lineEnd, what, fix, confidence'). ثم انشر BLOCKER/MAJOR في الـ PR كتعليق واحد بترويسة واضحة 'AI assist — verify before acting'.
تكييف الموجّه لفريقك
أضف قسم 'Codebase context' فوق الـ diff — الصق 5-10 أسطر تصف حزمتك واتفاقيات الاختبار لديك وأي ثوابت غير بديهية (مثلاً: 'كل كتابات DB تمر عبر src/db/withTx، لا client خام أبداً'). تفوّت النماذج الاتفاقيات الخاصة بقاعدة الكود لولا ذلك.
إذا كان لفريقك نقاط ضعف معروفة (race conditions في job runner، استعلامات N+1 في خدمة محدّدة)، أضف سطر 'Watch especially for: …'. سيوزن النموذج تلك الفئات من الأخطاء بأعلى، ويكون أكثر احتمالاً للإشارة إليها عند وجودها.
الأسئلة الشائعة
›هل يمكنني استخدام هذا على كود مغلق المصدر؟
نعم، لكن تحقق من سياسة صاحب عملك أولاً. الموجّه نفسه غير ضار؛ المهم هو ما إذا كان مسموحاً لك بلصق الكود في النموذج الذي تستخدمه. خطط Claude و ChatGPT المؤسسية عادةً لا تتدرّب على مدخلاتك؛ الخطط الاستهلاكية قد تفعل.
›لماذا كبت ملاحظات MINOR و NIT؟
لأنها عملياً تخلق إرهاق مراجعة. بعد الملاحظة الثالثة 'فكّر في استخراج هذا إلى دالة'، تتوقف عن القراءة. كبتها يبقي إشارة BLOCKER/MAJOR حادّة. أعد تفعيلها بـ 'show all findings including MINOR and NIT' عندما تريد مراجعة عميقة.
›ما طول الـ diff الذي يمكن مراجعته؟
Claude Sonnet/Opus و GPT-5 يتعاملون مع 50K+ token من diff بأريحية. للـ PRs الكبيرة جداً، قسّم المراجعة حسب الدليل (راجع src/auth أولاً، ثم src/billing) ليتمكّن النموذج من التفكير بكل نظام فرعي بمعزل.
›ماذا عن المراجعات الأمنية المتخصصة؟
يلتقط هذا الموجّه قضايا crypto/storage/SSRF البديهية لكنه ليس بديلاً عن مراجعة أمنية على كود المصادقة أو الدفع. لتلك المسارات، شغّل هذا الموجّه وموجّه مراجعة أمنية مخصصاً (سننشر واحداً منفصلاً).
›هل يمكنه المراجعة عبر ملفات متعددة؟
نعم — الصق الـ diff الذي يتضمّن كل الملفات. يتعامل مع الثوابت متعدّدة الملفات جيداً ضمن لصقة واحدة؛ للمشكلات الممتدّة عبر PRs متعددة (مثلاً: 'هل هذا متّسق مع كيفية تقييد feature flags في أماكن أخرى؟')، ضمّن مقتطفات تمثيلية قليلة من تلك الملفات الأخرى.
›هل ينبغي أن أثق بملاحظات [low-confidence]؟
عاملها كـ 'حقّق قبل التصرّف'. نحو نصف الملاحظات منخفضة الثقة حقيقية لكن النموذج لم يستطع التحقق؛ النصف الآخر سوء قراءة. العلم إشارة صادقة، ليس سبباً لتجاهل الملاحظة.
›لماذا يريد مني تحديد نمط الفشل؟
لأن 'هذا خطأ' عديم الفائدة بدون 'هذا سيتعطّل على إدخال unicode'. يخبرك سطر نمط الفشل بالأولوية: إصلاح يمنع حالة حدّية بمعدل 1 في المليون مختلف عن إصلاح يمنع حادثة إنتاج يومية.
›كيف أستخدم هذا في Cursor تحديداً؟
احفظ نص الموجّه في .cursorrules في جذر المستودع، أو الصقه في الـ composer مع مراجع @file للملفات قيد المراجعة. سيبقي Cursor القواعد فعّالة لذلك المشروع.
حاسبات ذات صلة
مطالبات ذات صلة
آخر تحديث: