← كل المقالات
UseCase

استخدم Claude Code Review كبوابة لطلبات السحب عبر CLAUDE.md وREVIEW.md

A warm editorial vector scene of a GitHub-style pull request passing through two labeled markdown gates, CLAUDE.md and R

أطلقت Anthropic ميزة Code Review لـ Claude Code في 9 مارس 2026، ومعها رقم كفيل بأن يجعل أي مدير هندسي يتوجّع: داخل Anthropic، زاد إنتاج الكود لكل مهندس بنسبة 200% خلال عام، وأصبحت المراجعة عنق الزجاجة (Anthropic). هذه هي القصة الحقيقية. البرمجة بالذكاء الاصطناعي لم تُزل عمل المراجعة. فقط نقلت نقطة الضغط.

الرد المفيد ليس: “دع Claude يراجع واجبه بنفسه.” هذه وصفة ممتازة لمصنع أخطاء مهذّب. الرد المفيد هو تحويل Claude Code Review إلى بوابة PR قابلة للتكرار، بقواعد يؤمن بها فريقك فعلاً.

توثيق الإعداد لدى Anthropic جعل هذا عملياً الآن. يستطيع المراجع تشغيل المراجعة بكتابة تعليق @claude review، وتقرأ Code Review ملفات CLAUDE.md في المستودع إضافة إلى ملف REVIEW.md في الجذر. تُعامل مخالفات CLAUDE.md كملاحظات من مستوى nit، بل يستطيع Claude أيضاً الإشارة إلى PR جعل CLAUDE.md قديماً أو غير دقيق (Claude Help Center). أما REVIEW.md فهو مكان قواعد المراجعة فقط، بما في ذلك المثال الذي تذكره Anthropic: “أي مسار API جديد يجب أن تكون له اختبارات تكامل.”

هذه الجملة وحدها هي المفصل. توقف عن مطالبة مراجعي الذكاء الاصطناعي بأن “ينتبهوا”. أعطهم قانون المستودع.

رسم تدفقي يوضح diff لطلب سحب يدخل إلى Claude Code Review، ثم ينقسم إلى وكلاء مراجعة متوازيين، يفحصون C

المشكلة: الذكاء الاصطناعي جعل مراجعة PR أكثر ضجيجاً

الجدل في المجتمع فوضوي لأن الطرفين على حق.

في نقاش Hacker News حول Claude Code Review، ضغط المطورون على السعر، والقيمة، والحقيقة المقلقة أن بائع ذكاء اصطناعي يبيع مراجعاً للكود المولّد بالذكاء الاصطناعي. أشار أحد المعلقين إلى أرقام Anthropic نفسها عن طلبات السحب الكبيرة وقرأها كإشارة تحذير بشأن جودة التطوير الوكيلي، بينما قال آخرون إن وجود زوج عيون ثانٍ وعميق هو بالضبط المكان الذي يبرر فيه الأداة تكلفتها (Hacker News).

على Reddit تظهر النسخة العملية أكثر من الجدال نفسه. في أحد النقاشات، سأل مطور إن كان الناس يثقون فعلاً بالكود الذي يولّده Claude بما يكفي لتجاوز المراجعة، لأن Claude يكتب أحياناً كوداً لا يفهمونه. جاءت الردود مباشرة: راجعه، تحقّق منه، أبقِ التغييرات صغيرة، ولا تتظاهر بأن التفويض يعني اختفاء المساءلة (Reddit). وفي نقاش آخر، ناقش الناس استخدام وكلاء ذكاء اصطناعي منفصلين لمراجعة مخرجات Claude، مع الاستمرار في فحص المراجعة نفسها مقابل قاعدة الكود (Reddit).

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

لكن لا ينبغي أن يكون صاحب الموافقة النهائية.

تقول Anthropic هذا صراحة. Code Review لا يوافق على PRs ولا يحظرها بنفسه. تبقى تدفقات المراجعة الحالية كما هي (Claude Help Center). لذلك “البوابة” هنا بوابة فريق: لا موافقة بشرية حتى يعمل Claude، وتُحل النتائج Important أو تُعفى صراحة، ويعالج صاحب PR القواعد الخاصة بالمستودع.

هذا ممل. ممتاز. البوابات المملة تمنع الحوادث.

الإعداد: ملفا Markdown، ومهمتان مختلفتان

لدى Claude Code Review سطحا ذاكرة مهمان.

CLAUDE.md هو سياق المشروع المشترك. ينطبق على جلسات Claude Code عموماً، لا على المراجعة فقط. توصي Anthropic باستخدامه للأوامر، والاتفاقيات، وملاحظات معمارية قصيرة، والقيود الصلبة، والمطبات المعروفة. كما توصي بإبقائه كثيف الإشارة، تقريباً أقل من 200 سطر، لأنه يُحمّل داخل السياق، حتى لو كان التخزين المؤقت للمطالبات يقلل تكلفة الرموز المتكررة في جلسات Enterprise (Claude Help Center).

REVIEW.md مختلف. يعيش في جذر المستودع، ومخصص للمراجعة فقط. تقول وثائق Code Review لدى Anthropic إن محتواه يُحقن في كل وكيل مراجعة كتعليمات عالية الأولوية، وإنه المكان المناسب للتحكم في الشدة، وحجم ملاحظات nit، وقواعد التجاوز، والفحوص الخاصة بالمستودع، ومعايير التحقق، وسلوك إعادة المراجعة (Claude Code Docs).

هذا هو التقسيم الذي أستخدمه:

FilePurposeGood rulesBad rules
CLAUDE.mdذاكرة المشروع لكل عمل Claudeأوامر البناء، المعمارية، “استخدم Zod للتحقق من الطلبات”تواريخ طويلة، تفضيلات غامضة، توثيق API مكرر
REVIEW.mdسياسة مراجعة PR“مسارات API الجديدة تتطلب اختبارات تكامل”نصائح عامة مثل “اكتب كوداً نظيفاً”
CI configفرض حتمي قابل للتكرارTypecheck، اختبارات الوحدة، lint، فحوص الهجراتفحوص LLM فقط لأشياء يستطيع المترجم إثباتها

ضع السياق المستقر في CLAUDE.md. ضع ضغط المراجعة في REVIEW.md. ضع أي شيء حتمي في CI.

رسم جدول مقارنة مضغوط بثلاثة أعمدة معنونة CLAUDE.md وREVIEW.md وCI، يعرض قواعد السياق والمراجعة

بوابة حقيقية لمسارات API

افترض أن فريق backend يواصل شحن مسارات لديها اختبارات وحدة للمسار السعيد فقط، بلا تغطية تكامل. يلتقط المراجعون البشر هذا أحياناً. تجعل PRs المولّدة بـ Claude الأمر أسوأ لأن الوكيل بارع في إنتاج كود handler يبدو معقولاً، وسيئ في تذكّر ندوب الفريق الخاصة بالمراجعة.

ابدأ بـ CLAUDE.md:

# Project conventions

- API routes live in `src/routes`.
- Integration tests live in `tests/integration`.
- Use `requireAuth()` on non-public routes.
- Validate request bodies with Zod schemas from `src/schemas`.
- Run `pnpm test:integration` before marking API work complete.

ثم أضف REVIEW.md في الجذر:

# Code Review Rules

Treat these as Important unless stated otherwise.

## API routes

If a PR adds or changes a file under `src/routes/**`:
- Flag missing integration test coverage in `tests/integration/**`.
- Flag routes without explicit auth, unless the route is listed as public.
- Flag request bodies that are not validated with a Zod schema.

Do not accept unit tests as a substitute for route-level integration tests.

## Evidence bar

For every Important finding, cite the changed file and the missing or conflicting evidence.
If the claim depends on a convention, cite this REVIEW.md rule.

القسم الأخير مهم. يستطيع مراجعو LLM إنتاج هراء واثق. اشتراط الدليل يجبر المراجعة على ربط النتيجة بملف، أو سطر، أو سياسة صريحة. لن يلغي الإيجابيات الكاذبة، لكنه يغيّر شكل المراجعة من “إحساس” إلى “أرني.”

والآن يضيف PR التالي:

// src/routes/billing.ts
router.post("/billing/plan", async (req, res) => {
  const result = await updatePlan(req.body.planId);
  res.json(result);
});

تعليق Claude Code Review الجيد يجب أن يقول شيئاً مثل:

  • Important: يضيف src/routes/billing.ts مسار POST جديداً بلا auth ظاهر.
  • Important: يقرأ جسم الطلب req.body.planId من دون تحقق عبر schema.
  • Important: لم يُضف اختبار تكامل مطابق تحت tests/integration/**.

المراجع البشري ما زال يقرر. ربما توجد middleware للمصادقة مطبقة أعلى في router. ربما يعيش اختبار التكامل في مجموعة عقود مولّدة. لا مشكلة. أدت البوابة عملها إذا أجبرت على هذه المناقشة قبل الدمج.

تشغيله من دون حرق المال

تعطي Anthropic ثلاثة أوضاع تشغيل للمستودع: مرة بعد إنشاء PR، بعد كل push، أو يدوياً. الوضع اليدوي يعني لا تكلفة حتى يعلّق أحدهم @claude review؛ بعد ذلك، تؤدي عمليات push الإضافية إلى تشغيل مراجعات تلقائياً لذلك PR (Claude Help Center).

بالنسبة لمعظم الفرق، لن أبدأ بخيار “بعد كل push”. تقول Anthropic إن Code Review يستغرق في المتوسط نحو 20 دقيقة ويكلف عموماً بين 15 و25 دولاراً لكل مراجعة، ويتوسع ذلك حسب حجم PR وتعقيده (Anthropic). هذا رخيص مقارنة بحادث إنتاج. وغالٍ مقارنة بتشغيل ESLint.

استخدم بوابة متدرجة:

  1. كل PR يشغّل CI العادي.
  2. PRs عالية المخاطر تحصل على @claude review.
  3. PRs الكبيرة، وتغييرات auth، وتغييرات المدفوعات، والهجرات، وتغييرات API العامة تتطلب مراجعة Claude قبل الموافقة البشرية.
  4. أعد مراجعة Claude بعد تغييرات كبيرة، لا بعد كل إصلاح خطأ مطبعي.
  5. البشر يملكون الموافقة النهائية.

قائمة تحقق خفيفة في GitHub PR تجعل البوابة صريحة:

## AI Review Gate

- [ ] CI is green.
- [ ] `@claude review` has run, or this PR is exempt.
- [ ] Important findings are fixed or explained.
- [ ] If this PR changes conventions, `CLAUDE.md` is updated.
- [ ] If this PR changes review policy, `REVIEW.md` is updated.

إذا كنت تفضل تشغيل Claude داخل سير عملك الخاص، تعرض وثائق GitHub Actions لدى Anthropic استخدام anthropics/claude-code-action@v1 وإعداد إضافة code-review، مع التحذير المعتاد باستخدام GitHub Secrets لمفاتيح API (Claude Code Docs). هذا المسار يعطيك تحكماً أكبر في CI. أما مسار Code Review المُدار فيعطيك المراجع الأعمق متعدد الوكلاء الذي تصفه Anthropic.

لا تخلط بينهما. أحدهما أتمتة قابلة للبرمجة. والآخر مراجع مدفوع يتعمق أولاً.

مخطط شجرة قرار لمشغلات المراجعة بفروع لـ PR صغير، وPR عالي المخاطر، وPR كبير، وعمليات push متكررة، وينتهي

الحيلة: اجعل Claude يراجع العقد، لا الأسلوب

ملفات REVIEW.md السيئة تبدو كحِكم كعكات الحظ:

Please ensure the code is clean, maintainable, secure, and well tested.

هذا سينتج عجينة كلامية.

ملفات REVIEW.md الجيدة ترمز الندوب:

## Database migrations

Flag as Important if:
- A migration adds a non-null column without a default on an existing table.
- A migration backfills data without batching.
- Application code starts reading a new column before the migration is deployed.

Skip:
- Formatting comments in generated Prisma client files.

هنا تصبح مراجعة الذكاء الاصطناعي مفيدة. هي لا تستبدل ذائقة مهندس senior لديك. إنها تعيد تشغيل الذاكرة المؤسسية للفريق على كل PR.

بعض القواعد التي تعمل جيداً:

## Re-review behavior

On the first review, report Important and Nit findings.
On later reviews of the same PR, suppress new Nits unless they are directly caused by the latest push.

## Test policy

Flag missing tests only when the changed behavior is observable through a stable public interface.
Do not request snapshot tests for purely visual copy changes.

## Security policy

Flag any new endpoint that:
- Accepts user input without validation.
- Performs authorization by trusting a user-provided account ID.
- Logs tokens, session IDs, API keys, or full request bodies.

لاحظ الغائب: “اجعل الكود أنيقاً.” يستطيع البشر الجدال حول الأناقة في المراجعة. يجب أن يفحص Claude العقود.

ما الذي تفوته النقاشات

تدور نقاشات HN وReddit حول سؤال واحد: هل يجب أن يراجع الذكاء الاصطناعي كود الذكاء الاصطناعي؟

سؤال خاطئ.

السؤال الصحيح هو: أي أجزاء من المراجعة أنت مستعد لجعلها صريحة؟

إذا كانت ثقافة المراجعة لديك تعيش في رؤوس المهندسين الكبار، فسيبدو Claude Code Review مزعجاً واعتباطياً. إذا كانت ثقافة المراجعة مكتوبة كقواعد مستودع، يصبح مضاعف قوة. يخبر CLAUDE.md Claude كيف يعمل المشروع. ويخبر REVIEW.md Claude ما الذي يرفض فريقك دمجه.

وهذا يجيب أيضاً عن شكوى “نكتب توثيقاً من أجل Claude”. نعم، يكتب المطورون الآن وثائق لوكيل. يبدو هذا سخيفاً إلى أن تدرك أن هذه الوثائق هي أيضاً مادة onboarding، وسياسة مراجعة، ووقاية من الحوادث. ملف CLAUDE.md الجيد هو أيضاً ملف أفضل للبشر بعنوان “كيف يعمل هذا المستودع”.

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

استخدم Claude Code Review كبوابة، لا كقاضٍ. اجعله يسأل الأسئلة المزعجة كل مرة:

  • أين اختبار التكامل؟
  • أين يُفرض auth؟
  • هل جعل هذا PR ملف CLAUDE.md غير صحيح؟
  • هل يستحق هذا الملف المولّد التعليق؟
  • هل هذه النتيجة مدعومة بالكود، أم مجرد حدس؟

هذا يكفي ليغطي تكلفته في PRs المناسبة.

جرّب الإعداد نفسه مع Claude Fable 5 على OneHop، بتبديل مباشر، وابدأ مع 10 دولارات مجاناً.

قراءة إضافية: بدء استخدام Claude Fable 5.