كيف تعمل مراجعة الكود بواسطة Claude Code فعليًا: الفروقات، الـ Hooks، وما يكتشفه الوكيل

مراجعة Claude Code للكود: الدليل العملي لمراجعات طلبات السحب (PR) الوكيلية

يمكن لـ Claude Code مراجعة طلب سحب (pull request) أو فرق (diff) محلي بالطريقة التي يقوم بها مهندس أول متمرّس — قراءة الملفات المُغيَّرة، وتتبّع مواقع الاستدعاء، وفحص الاختبارات، وإعادة نتائج مُرتَّبة بحسب الخطورة مع اقتراحات للإصلاح. هذا الدليل يتناول بشكل خاص استخدام Claude Code (أداة سطر الأوامر الوكيلية من Anthropic) لمراجعة الكود: كيفية تشغيلها، كيفية توجيه الطلبات (prompting) لها بشكل جيد، كيفية أتمتتها على كل commit أو PR، وكيفية ربطها بخط أنابيب عمل الفريق (pipeline).

ما تعنيه "مراجعة Claude Code" فعليًا

هناك أمران مختلفان تمامًا يسمّيهما الناس "مراجعة كود Claude". الأول هو طلب من Claude في واجهة محادثة أن ينظر إلى مقتطف كود تلصقه. الثاني — وهو موضوع هذا الدليل — هو تشغيل Claude Code، أداة سطر الأوامر الوكيلية من Anthropic، على فرق (diff) حقيقي أو طلب سحب (pull request) داخل مستودعك الفعلي.

هذا الفرق مهم للغاية. عندما يراجع Claude Code فرقًا (diff)، فهو لا يُحلّل بشكل منعزل مقتطفًا مُلصقًا. إنه وكيل مستقل يمكنه فتح الملفات، وتتبّع عمليات الاستيراد (imports)، وقراءة تعليمات مشروعك في CLAUDE.md، وفحص الاختبارات المجاورة، وفهم السياق الكامل للتغيير قبل أن يُصدر أي نتيجة واحدة. هذا الوعي عبر الملفات المتعددة هو ما يجعل المُخرَج مفيدًا حقًا بدلًا من أن يكون عامًا.

يتوفر Claude Code كأداة سطر أوامر تُثبِّتها محليًا (npm install -g @anthropic-ai/claude-code)، أو كوكيل يعمل في بيئة اختبار سحابية معزولة (sandbox) — سنتحدث عن كلا النهجين لاحقًا. يغطي التوثيق الرسمي من Anthropic التثبيت والإعداد الأولي.

سير عمل /review خطوة بخطوة

يأتي Claude Code مع أمر شرطة /review مُصمَّم خصيصًا لهذه المهمة. فيما يلي سير العمل الكامل من الفرق (diff) إلى مُخرَج قابل للتنفيذ.

الخطوة 1 — وجِّه Claude Code إلى الفرق (Diff)

لديك عدة طرق لتزويده بالتغييرات التي تريد مراجعتها.

التغييرات المُهيَّأة (staged) (أمر /review):

/review

داخل جلسة Claude Code، يبدأ أمر الشرطة /review مراجعة تغييراتك. هذا هو سير العمل المحلي الأكثر شيوعًا: قم بتهيئة عملك (stage)، وشغِّل /review، وشاهد النتائج قبل الالتزام (commit). (سلوك الأمر الدقيق يتطور — راجع توثيق Claude Code من Anthropic للحصول على الصيغة الحالية.)

نطاق git معيّن: يمكنك أيضًا أن تسأل الوكيل بلغة طبيعية — على سبيل المثال، "راجع الفرق بين main وهذا الفرع، وأشِر إلى أي أخطاء أو تراجعات." بما أن Claude Code يمكنه تشغيل أوامر git بنفسه، فسيُنتج الفرق للنطاق الذي تحدده ويراجعه. هذا مفيد عند مراجعة فرع ميزة قبل فتح PR، ويتجنب الاعتماد على أي صيغة علامات (flags) دقيقة.

رابط طلب سحب على GitHub: إذا كان مشروعك مُهيَّأ باستخدام GitHub CLI، يمكن لـ Claude Code جلب فرق PR مباشرة. تُقدِّم رابط PR أو رقمه في طلبك، ويستخدم الوكيل gh لسحب الفرق مع وصف PR، مما يمنحه سياق النية بالإضافة إلى الكود.

الخطوة 2 — تحميل السياق

قبل إصدار النتائج، يقرأ Claude Code السياق الذي يحتاجه لتقييم الفرق بشكل صحيح:

• CLAUDE.md — ملف تعليمات مشروعك، الذي يمكن أن يحدد مجالات تركيز المراجعة، والأنماط الممنوعة، وقواعد البنية المعمارية، أو اتفاقيات الفريق. هذا هو رافعتك الأساسية لتخصيص ما ينتبه الوكيل إليه.
• الوحدات المستوردة والمُستدعِيات (Callers) — إذا كانت دالة مُغيَّرة مُستدعاة من عشرة مواقع، يقرأ الوكيل مواقع الاستدعاء تلك لفحص ما إذا كان التغيير متوافقًا مع الإصدارات السابقة (backward-compatible).
• الاختبارات الموجودة — يقرأ ملفات الاختبار لفهم العقد المقصود للكود المُغيَّر، ولملاحظة عندما ينقص المنطق الجديد التغطية.
• ملفات الإعدادات — تساعد ملفات مثل eslint وtsconfig وpyproject.toml وما شابهها الوكيل على فهم قواعد الفحص (linting) المُطبَّقة فعليًا في CI، حتى لا يُكرِّر النتائج التي تكتشفها أدواتك بالفعل.

الخطوة 3 — التحليل

تُغطي مسارات تحليل Claude Code عدة أبعاد في الوقت نفسه:

• الصحة (Correctness) — أخطاء منطقية، أخطاء off-by-one، إشارات فارغة (null dereferences)، افتراضات خاطئة عن الخوارزمية
• الأمان — مخاطر الحقن (injection)، بيانات اعتماد مكشوفة، إلغاء تسلسل غير أمن (unsafe deserialization)، فحوصات ترخيص مفقودة
• الموثوقية — معالجة أخطاء مفقودة، رفض وعود (promise rejections) غير معالَج، حالات حدّية غير مُتوقَّعة
• قابلية الصيانة — منطق مُكرَّر، تسمية غير واضحة، توثيق مفقود لسلوك غير واضح
• تغطية الاختبارات — مسارات كود مُضافة دون اختبارات مقابلة لها

الوكيل لا يُشير فقط إلى سطر؛ بل يشرح لماذا تُعتبر النتيجة مهمة وما هو الأثر المُحتمل في حال إطلاقها.

الخطوة 4 — نتائج مُهيكَلة

المُخرَج هو قائمة من النتائج، كل واحدة تتضمن:

• تصنيف خطورة (عادةً: حرِج / تحذير / اقتراح)
• إشارة إلى الملف والسطر
• تفسير بلغة واضحة للمشكلة
• إصلاح مُقترَح — غالبًا مقتطف كود جاهز للتطبيق

بشكل افتراضي، تظهر النتائج في الطرفية (terminal). لاستخدام الفريق يمكنك إعادة توجيهها: مرِّرها إلى ملف، أو نشرها كتعليقات PR عبر gh pr comment، أو استخدام hook لكتابتها في سجل مراجعة مشترك.

تتبع مراجعة Claude Code خط أنابيب مُهيكَل — من إدخال الفرق عبر تحميل السياق والتحليل إلى النتائج المُرتَّبة واقتراحات الإصلاح، مع تمكين الـ hooks للأتمتة الكاملة.

مثال عملي: فرق حقيقي، مراجعة حقيقية

لتوضيح الفكرة بشكل ملموس، هذا فرق بايثون بسيط وما تُظهره مراجعة Claude Code له.

الفرق (Diff):

# Before
def get_user(user_id):
    result = db.query(f"SELECT * FROM users WHERE id = {user_id}")
    return result[0]

# After (in PR)
def get_user(user_id):
    result = db.query(f"SELECT * FROM users WHERE id = {user_id}")
    if result:
        return result[0]
    return None

ما اعتقد مؤلف PR أنه أصلحه: خطأ KeyError عندما لا يُوجد مستخدم.

ما يُظهره Claude Code في المراجعة:

1. حرِج — حقن SQL (السطر 2): يُدرِج f-string القيمة user_id مباشرة في الاستعلام. قيمة مثل 1; DROP TABLE users;-- قد تُنفَّذ. الإصلاح: استخدام استعلامات مُعلَّمة (parameterized queries) — db.query("SELECT * FROM users WHERE id = ?", (user_id,)).

2. تحذير — انتشار ضمني لإرجاع None: المستدعون لـ get_user الذين لا يتحققون من None سيفشلون الآن عن بُعد. راجع ثلاث مواقع استدعاء (مُدرَجة بحسب الملف) تفترض أن كائن مستخدم يُعاد دومًا.

3. اقتراح — تعليق نوع (Typing) مفقود: يجب أن يكون نوع الإرجاع Optional[User] بحيث تتمكن بيئات التطوير المتكاملة (IDEs) وفاحصات الأنواع من اكتشاف حالة None عند مواقع الاستدعاء تلقائيًا.

4. اقتراح — اختبار مُضاف ولكن غير مكتمل: الاختبار الجديد test_get_user_not_found يفحص فقط أن None يُعاد؛ لا يتحقق من السلوك عندما يكون user_id هو 0 أو غير عدد صحيح.

المؤلف الأصلي رقَّع KeyError لكنه أدخل خطر انتشار None صامت ولم يلاحظ حقن SQL الموجود مسبقًا. اكتشف Claude Code كليهما — ووجدهما لأنه قرأ مواقع الاستدعاء، وليس فقط الفرق.

توجيه Claude Code لمراجعات أفضل

جودة المراجعة تتناسب طرديًا مع جودة السياق الذي تُقدّمه للوكيل. هذه الطلبات (prompts) والتقنيات تُنتج مُخرَجًا أفضل باستمرار.

استخدم CLAUDE.md لتحديد تعليمات دائمة

أكبر رافعة تأثير تكون في ملف CLAUDE.md لمشروعك. أضف قسم ## Review Guidelines:

## Review Guidelines
- We use parameterized queries everywhere. Flag any string interpolation in SQL.
- All public functions must have return-type annotations (Python) or JSDoc (JS).
- Security findings should always be severity: critical, not warning.
- We prefer explicit error returns over exceptions in the data layer.
- Do not flag import ordering — Black handles that automatically.

هذا يُعلِّم الوكيل مرّة واحدة، وكل مراجعة في المشروع تتوارث هذه القواعد دون الحاجة إلى إعادة الطلب.

قدِّم النية في الطلب (Prompt)

عند استدعاء مراجعة تفاعليًا، أخبر الوكيل بما تحاول PR تحقيقه:

/review This PR migrates our auth flow from JWT to session cookies. Focus on
session fixation, secure cookie attributes, and any places we might be leaking
the old JWT validation logic.

سياق النية يسمح لـ Claude Code بترتيب أولوية النتائج ذات الصلة بدلًا من إنتاج قائمة مراجعة موحّدة عبر كل الأبعاد.

اطلب تمريرة خاصة بالخطورة فقط أولًا

بالنسبة للفروق (diffs) الكبيرة، النهج ذو التمريرتين فعّال:

/review Pass 1: list only critical and warning severity findings with file+line.
No suggestions yet.

ثم، بعد الحصول على القائمة الحرِجة، اطلب تفاصيل الإصلاح لنتائج مُحدَّدة. هذا يتجنب مشكلة مُخرَج مراجعة يمتد 200 سطر يكون فيه الخطأ الحرِج مدفونًا بين اقتراحات الأسلوب.

اطلب تأكيد الفهم

للتغييرات المُعقَّدة:

Before reviewing, summarize what this diff is trying to do in two sentences,
then proceed with the review.

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

أتمتة المراجعات باستخدام الـ Hooks

تشغيل /review يدويًا مفيد، ولكن المكسب الإنتاجي الحقيقي هو جعل المراجعة تلقائية — بحيث يُشغِّلها كل commit أو كل PR مفتوح دون أن يتذكّر شخص القيام بذلك. نظام الـ hooks في Claude Code يجعل هذا ممكنًا. (نظام الـ hooks مُغطًّى بعمق في دليل hooks الخاص بـ Claude Code — يركِّز هذا القسم بشكل خاص على حالة استخدام المراجعة.)

مراجعة تلقائية عند كل Commit

في ملف .claude/settings.json لمشروعك، أضف hook من نوع Stop:

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "claude -p 'Review the diff from the last commit (git diff HEAD~1 HEAD) and list any bugs, security issues, or regressions.'"
          }
        ]
      }
    ]
  }
}

مع وجود هذا، كل مرة يُكمِل Claude Code مهمة (بما في ذلك مهام البرمجة التي تنتهي بـ commit)، يُشغَّل الـ hook ويراجع الفرق الناتج. تظهر النتائج في طرفيتك فورًا بعد نزول الـ commit.

مراجعة تلقائية عند فتح PR

للتكامل مع CI، شغِّل Claude Code في نمط بلا واجهة (headless) (claude -p "<prompt>") داخل مهمّة GitHub Actions، وانشر النتيجة كتعليق PR. النمط أدناه توضيحي — تنشر Anthropic أيضًا إجراء GitHub Action رسميًا لـ Claude Code، لذا راجع توثيق Claude Code للحصول على إعداد CI الحالي والموصى به بدلًا من نسخ العلامات (flags) حرفيًا:

name: Claude Code Review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Install Claude Code
        run: npm install -g @anthropic-ai/claude-code
      - name: Run review
        run: |
          claude -p "Review the diff between origin/${{ github.base_ref }} and HEAD. \
          List bugs, security issues, and regressions, ranked by severity." > review.md
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
      - name: Post review as PR comment
        run: gh pr comment ${{ github.event.number }} --body-file review.md
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

هذا ينشر نتائج Claude Code كتعليق PR تلقائيًا عند كل دفعة (push). يُركِّز مراجعوك البشريون بعد ذلك اهتمامهم على النتائج التي أظهرها الوكيل مسبقًا، بدلًا من قضاء وقت المراجعة على العناصر التي يكتشفها Claude Code بشكل موثوق.

ما تكتشفه مراجعة Claude Code — وما يفوته

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

يتفوّق Claude Code في الصحة الآلية، وأنماط الأمان، والاتساق — بينما يبقى الحكم على المنتج، والتهديدات المستحدَثة، والموافقة على الامتثال مسؤوليات بشرية.

يكتشفها Claude Code بشكل موثوق:

• أخطاء off-by-one، وإشارات فارغة (null/undefined dereferences)، وتضارب الأنواع (type mismatches) الظاهرة في الفرق وسياقه المباشر
• أنماط أمان معروفة: حقن SQL، XSS، ثغرات CSRF، مراجع كائن مباشرة غير أمنة، تحقّق مُدخَلات مفقود، أسرار في الكود
• مخالفات الأسلوب والاتفاقيات المقابلة للقواعد المُحدَّدة في CLAUDE.md وملفات الإعدادات
• المنطق المُكرَّر — وعي الوكيل عبر الملفات المتعددة يعني أنه يلاحظ عندما تكون دالة أضفتها للتو موجودة بالفعل في وحدة مساعدة (utility module) في مسار مختلف
• معالجة الأخطاء المفقودة — رفض وعود (promise rejections) غير معالَج، عبارات except عارية، دوال قد تُعيد None أو undefined دون أن يتوقّع المُستدعي ذلك
• ثغرات تغطية الاختبارات لمسارات الكود المُحدَّدة المُضافة في الفرق

لا يُحل Claude Code محل الحكم البشري في:

• قرارات المنتج والمتطلبات. هل يجب أن تُوجد الميزة، وهل تجربة المستخدم منطقية، وهل عقد API هو التجريد الصحيح — هذه تحتاج سياق أعمال لا يملكه أي وكيل.
• تهديدات أمان مُستحدَثة. يعرف الوكيل فئات الثغرات المعروفة؛ لا يبتكر نماذج تهديد خاصة ببيئة نشر تطبيقك أو منطق أعماله.
• الأداء على نطاق واسع. التحليل الثابت لا يمكن أن يحل محل مُخرَجات المُحلِّل (profiler) أو نتائج اختبار التحميل أو فهم أنماط حركة المرور الفعلية.
• الامتثال التنظيمي. GDPR وHIPAA وPCI-DSS وما شابهها تتطلب موافقة بشرية وغالبًا مراجعة قانونية. لا يمكن للمراجعة بالذكاء الاصطناعي أن تحل محلها.
• ديناميكيات الفريق وحوكمة البنية المعمارية. "هل ينتمي هذا إلى هذه الوحدة؟" أو "هل يجب أن نأخذ هذه التبعية؟" تحتاج سياقًا تنظيميًا.

التأطير الصحّي: تُزيل مراجعة Claude Code الجزء المُملّ من مراجعة الكود — اكتشاف الأخطاء الآلية، وفرض الاتفاقيات، والإشارة إلى الأنماط المعروفة السيئة — بحيث يُمكن لمراجعيك البشريين أن يُخصِّصوا انتباههم المحدود لقرارات الحكم التي تحتاج فعلًا حكمًا بشريًا.

دمج مراجعة Claude Code في خط أنابيب فريق

جعل فريق يستخدم المراجعة الوكيلية باستمرار يتطلب معاملتها كجزء أساسي من سير عملك، لا كإضافة اختيارية.

نموذج الطبقات الثلاث

خط أنابيب فريق يعمل بشكل جيد يمتلك ثلاث طبقات:

1. ما قبل الالتزام محليًا (Local pre-commit) — يُشغِّل المطوِّر /review قبل الدفع (push). إعداد الـ hook المذكور أعلاه يؤتمت هذا. النتائج في هذه الطبقة هي الأرخص للإصلاح.
2. بوابة CI — سير عمل GitHub Actions ينشر نتائج Claude Code كتعليق PR قبل تعيين أي مراجع بشري. يُعيَّن المراجعون البشريون فقط بعد نجاح مراجعة CI (بلا نتائج حرِجة).
3. تركيز المراجعة البشرية — يستخدم المراجعون البشريون تعليق Claude Code كدليل فرز. مهمتهم هي تقييم عناصر الحكم — تناسب البنية المعمارية، صحة المنتج، مقايضات الأداء — لا إعادة قراءة كل سطر بحثًا عن أخطاء طباعية.

مشاركة اتفاقيات CLAUDE.md

ملف CLAUDE.md هو طبقة الإعداد لسلوك مراجعة الوكيل. عامِله كالكود: التزم به (commit)، ضع له إصدارات (version)، راجع التغييرات عليه في PRs. عندما يتفق الفريق على أنه يجب أن يتوقف Claude Code عن الإشارة إلى نمط معيّن (لأن لديك فاحصًا لُغويًا (linter) له)، حدِّث CLAUDE.md ويُطبَّق التغيير على كل مراجعة مستقبلية.

ضبط عتبات الخطورة

يجد الفرق غالبًا أن معايرة الخطورة الافتراضية مُشوَّشة (noisy) في البداية. أضف تعليمات صريحة إلى CLAUDE.md للتحكم فيها:

## Review Severity Rules
- Only flag console.log as a warning if it is in a non-test, non-debug file.
- Import ordering is never a finding; Prettier handles it.
- Treat any hardcoded credential as critical regardless of context.
- Performance suggestions are informational only unless they affect O(n²) loops.

بعد بضعة أسابيع من الاستخدام، تجد معظم الفرق أن مستوى الضجيج (noise) ينخفض بشكل كبير بعد ضبط انتباه الوكيل على الأنماط التي تهم فعليًا في قاعدة كودها.

التعامل مع النتائج الإيجابية الخاطئة (False Positives)

سيُشير Claude Code من حين لآخر إلى شيء بشكل غير صحيح. الاستجابة الصحيحة ليست رفض المراجعة كليًا — بل إضافة تعليمة خاصة بالمشروع إلى CLAUDE.md تتعامل مع النمط. بمرور الوقت هذا يُنشئ إعداد مراجعة خاصًا بالمشروع يزداد دقةً ويعكس معايير فريقك الفعلية.

تشغيل مراجعة Claude Code بدون تثبيت محلي

كل ما وُصف حتى الآن يفترض أن لديك Claude Code مُثبَّتًا ويعمل في طرفيتك. بالنسبة لكثير من الفرق — خصوصًا تلك على أجهزة شركات مُقيَّدة، أو بيئات Windows بدون WSL، أو المطوِّرين الذين يريدون المراجعة من نافذة متصفح — التثبيت المحلي يُشكِّل عائق احتكاك.

يُشغِّل Happycapy Claude Code في بيئة اختبار سحابية معزولة (sandbox) وآمنة مباشرة في متصفحك. تحصل على القدرة الكاملة للمراجعة الوكيلية — بما في ذلك تحميل السياق عبر الملفات، ودعم CLAUDE.md، وأمر /review — دون تثبيت أي شيء. هذا مفيد بشكل خاص لـ:

• مراجعة الكود على طلبات السحب من متصفح دون سحب الفرع محليًا
• الفرق التي تنتقل إلى مراجعة Claude Code والتي تريد بيئة مشتركة ومتّسقة قبل طرح التثبيتات المحلية
• الأجهزة المُقيَّدة حيث يتطلب تثبيت حزم npm عامة موافقة قسم تقنية المعلومات
• مراجعة مستودعات غير مألوفة حيث تريد تحميل السياق من الوكيل دون استنساخ المستودع بالكامل

إذا كنت تتساءل عن كيفية مقارنة Claude Code بالبدائل من ناحية القدرة الوكيلية، راجع Claude Code مقابل GitHub Copilot وClaude Code مقابل Cursor. وإذا كنت تريد فهم كيف يُشغِّل Happycapy Claude Code في سياق متصفح، يُغطِّي Claude Code على الويب البنية المعمارية.

ابدأ مجانًا على happycapy.ai

الأسئلة المتكررة

س: هل تعمل مراجعة Claude Code مع أي لغة؟

نعم. Claude Code ليس خاصًا بلغة معيّنة — يقرأ أي فرق (diff) نصّي ويُطبِّق تفكيرًا حول الكود الذي يحتويه. يميل إلى أن يكون أكثر دقّة في Python وTypeScript وJavaScript وGo وRust (لغات ذات تمثيل تدريب كبير)، لكنه يُنتج نتائج مفيدة على Ruby وJava وC# ومعظم اللغات الرئيسية الأخرى. بالنسبة للغات خاصة بمجال معيّن أو أُطُر عمل غير مألوفة، إضافة سياق في CLAUDE.md يُحسِّن المُخرَج بشكل كبير.

س: كيف يختلف /review عن مجرد طلب من Claude في محادثة أن ينظر إلى فرقي؟

الفارق الأساسي هو استخدام الأدوات الوكيلي وسياق المستودع. في محادثة، لا يرى Claude إلا ما تلصقه. أمر /review في Claude Code يسمح للوكيل بفتح الملفات، وتتبّع عمليات الاستيراد، وفحص الاختبارات، وقراءة اتفاقيات مشروعك — مُنتِجًا نتائج مُرتكزة على قاعدة الكود الفعلية بدلًا من المقتطف. بالنسبة للتغييرات الكبيرة أو المتشابكة، هذا الفارق جوهري.

س: هل ستكتشف مراجعة Claude Code الثغرات الأمنية؟

يكتشف بشكل موثوق فئات الثغرات المعروفة جيدًا: حقن SQL، وXSS، وثغرات CSRF، ومراجع كائن مباشرة غير أمنة، وأسرار مُثبَّتة في الكود (hardcoded)، وتعقيم مُدخَلات مفقود. هو أقل موثوقية على متجهات الهجوم (attack vectors) المُستحدَثة الخاصة بالتطبيق أو الثغرات التي تتطلب فهم بيئة نشرك. تعامل معه كفحص أمني شامل أوّلي، لا كاختبار اختراق (penetration test).

س: كيف أوقف المراجعة عن الإشارة إلى أشياء يتعامل معها فاحصي اللغوي (linter) بالفعل؟

أضف استثناءات صريحة إلى CLAUDE.md الخاص بك: "لا تُشِر إلى ترتيب الاستيراد — isort يتعامل مع هذا." أو "لا تُشِر إلى المسافات البيضاء الزائدة (trailing whitespace) — Prettier يفرض ذلك." تبني معظم الفرق هذه القائمة على مدى أسبوعين إلى ثلاثة من الاستخدام وتجد أن نسبة الإشارة إلى الضجيج تتحسن بشكل كبير.

س: هل يمكنني استخدام مراجعة Claude Code في monorepo متعدد اللغات؟

نعم. يمكنك تحديد نطاق المراجعة بمُعامِل مسار (path argument) أو نطاق فرق git يُغطّي فقط الدليل الفرعي الذي غيّرته. يمكنك أيضًا الحفاظ على أقسام مراجعة خاصة بلغة مُعيّنة في CLAUDE.md الخاص بك يقرأها الوكيل كجزء من تحميل سياقه.

س: ماذا يحدث إذا كان الفرق كبيرًا جدًا — مثلًا PR بـ 3000 سطر؟

بالنسبة للفروق الكبيرة جدًا، فكِّر في نهج التمريرتين: اطلب أولًا نتائج حرِجة وتحذيرية فقط (بلا اقتراحات)، وقم بفرزها، ثم اطلب تحليلًا كاملًا لملفات أو أنظمة فرعية محددة. بالنسبة لعمليات إعادة الهيكلة (refactors) الضخمة جدًا، تقسيم الـ PR هو الحل الأفضل — لكل من قابلية المراجعة البشرية والآلية.

س: هل مُخرَج المراجعة حتمي (deterministic)؟ هل سأحصل على النتائج نفسها مرّتين؟

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

س: كيف تتفاعل مراجعة Claude Code مع فاحصي اللغة (linters) وأدوات التحليل الثابت الموجودة؟

تُكمِّلها، لا تحل محلها. تكتشف فاحصات لغتك القواعد المُطبَّقة آليًا وسريعًا؛ يُضيف Claude Code فهمًا دلاليًا (semantic) — يمكنه تقييم ما إذا كانت دالة تفعل الشيء الصحيح، وهو ما لا يمكن لأي فاحص لغوي فعله. خط الأنابيب المثالي يُشغِّل الاثنين: فاحصات اللغة في hooks ما قبل الالتزام (سريعة، حتمية)، ومراجعة Claude Code في CI (أبطأ، دلالية). أمر /review يعرف إعدادات فاحص لغتك ويتجنب تكرار النتائج التي تُنتجها أدواتك بالفعل.

س: هل يمكنني تخصيص تنسيق مُخرَج المراجعة للنشر على Slack أو تذكرة (ticket)؟

نعم. يمكنك توجيه الوكيل لإخراج النتائج بتنسيق مُحدَّد — JSON، أو markdown، أو قالب يُطابق أسلوب تعليقات PR لفريقك. اجمع هذا مع نظام الـ hooks وسكربت shell صغير، وستحصل على خط أنابيب مراجعة مُؤتمَت بالكامل ينشر النتائج المُهيكَلة حيثما يتتبّع فريقك عمله.

ذو صلة: الغوص العميق في hooks الخاصة بـ Claude Code — أتمتة فحوصات ما قبل الالتزام، والفحص اللغوي، وسير العمل المخصَّص خارج نطاق المراجعة.

أدلة ذات صلة

• Claude Code Hooks: دليل المستخدم المتمرّس لأتمتة وكيلك
• بناء وكلاء مستقلين بـ Claude Code SDK: دليل عملي للمطوِّرين
• Claude Code مقابل GitHub Copilot: وكيل مستقل أم مُساعِد داخل المحرِّر؟
• Claude Code Web: كيفية تشغيل Claude Code في متصفحك (بلا تثبيت)