Skip to content

كيف تجعل Claude Code يعمل لفترات طويلة

مقدمة

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

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

في صيف 2025، كتب مطور أسترالي يُدعى Geoffrey Huntley (وهو أيضًا مزارع أغنام) سكريبت bash من 5 أسطر. كان السكريبت بسيطًا: إعادة تشغيل Claude Code باستمرار وإطعامه نفس المهمة. أطلق عليه اسم "Ralph Wiggum"، على اسم شخصية Simpsons التي تستمر في المحاولة ولا تستسلم أبدًا.

هذا السكريبت البسيط أحدث ضجة في وادي السيليكون. في أسبوعين فقط، حصلت المشاريع ذات الصلة على أكثر من 7000 نجمة على GitHub. استخدمه الأشخاص لإنشاء 6 مشاريع كاملة بين عشية وضحاها، وأنجزوا عملًا بعقد بقيمة 50,000 دولار بتكلفة API تبلغ 297 دولارًا فقط، بل واستخدموه لبناء لغة برمجة كاملة في 3 أشهر.

السؤال الأساسي الذي يحلّه هذا الفصل هو: كيف تجعل Claude Code يعمل باستمرار مثل مطور حقيقي حتى تكتمل المهام فعليًا.


المبدأ الأساسي: لماذا يتوقف الذكاء الاصطناعي "في وقت مبكر جدًا"؟

قبل مناقشة الطرق المحددة، افهم السبب الجذري أولاً.

حكم الذكاء الاصطناعي على الاكتمال غير موثوق

نماذج اللغات الكبيرة (LLMs) لديها نقطة ضعف أساسية: لا يمكنها الحكم بشكل موثوق على ما إذا كان العمل قد اكتمل فعلًا.

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

لذلك نحتاج إلى نظام خارجي لتحديد الاكتمال الحقيقي بدلاً من الاعتماد على الإحساس الداخلي للذكاء الاصطناعي.

الفكرة الأساسية للحل

الحل الأساسي هو إبقاء الذكاء الاصطناعي يعمل داخل "حلقة".

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

هذه الفكرة يمكن تنفيذها بأشكال عديدة، من سكريبتات bash البسيطة إلى أنظمة التنسيق المعقدة، لكن الجوهر هو نفسه.


الطريقة 1: حلقة While True في Bash (الطريقة الأكثر بدائية)

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

أبسط تنفيذ هو 5 أسطر فقط:

bash
#!/bin/bash
while true; do
    cat PROMPT.md | claude
done

كيف تعمل

تدفق السكريبت مباشر. الخطوة 1 تقرأ وصف المهمة من PROMPT.md. الخطوة 2 تُشغّل Claude Code وتمرر وصف المهمة. الخطوة 3 يعمل Claude ويُخرج النتائج. الخطوة 4 يخرج Claude بعد الانتهاء. الخطوة 5 تُعيد الحلقة التشغيل تلقائيًا وتعود إلى الخطوة 1، مما يخلق دورة لا نهائية ما لم تقاطع يدويًا بـ Ctrl+C.

المزايا والعيوب

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

لكن العيوب واضحة: لا يمكنها الحكم على الاكتمال الحقيقي، قد تدور إلى الأبد، لا توجد ضمانات أمان، ويمكن أن تهدر استدعاءات API.

مثال على الاستخدام الفعلي

أولاً، أنشئ ملف PROMPT.md لوصف مهمتك. على سبيل المثال، إعادة هيكلة وحدة مصادقة المستخدم:

markdown
# المهمة: إعادة هيكلة وحدة مصادقة المستخدم

المتطلبات:
1. استخراج كل منطق المصادقة في فئة AuthService مستقلة
2. إضافة اختبارات وحدة، تغطية > 80%
3. تحديث الوثائق ذات الصلة

عند نجاح جميع الاختبارات وتحديث الوثائق، أخرج: المهمة اكتملت

ثم أنشئ وشغّل سكريبت الحلقة:

bash
chmod +x loop.sh
./loop.sh

نسخة محسنة أكثر أمانًا

لتجنب الحلقات اللانهائية، أضف حدًا أقصى للتكرارات:

bash
#!/bin/bash
MAX_ITERATIONS=50
iteration=0

while true; do
    iteration=$((iteration + 1))
    echo "=== التكرار $iteration/$MAX_ITERATIONS ==="

    cat PROMPT.md | claude

    if [ $iteration -ge $MAX_ITERATIONS ]; then
        echo "تم الوصول إلى الحد الأقصى للتكرارات، التوقف"
        break
    fi

    sleep 5  # تأخير صغير لتجنب حدود معدل API
done

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


الطريقة 2: إضافة Ralph Wiggum (التوصية الرسمية)

Ralph Wiggum هو إضافة رسمية من Anthropic مبنية خصيصًا للمهام طويلة التشغيل. سُمي على اسم شخصية Simpsons، ويمثل روح "الاستمرار في المحاولة رغم الفشل".

الآلية الأساسية: Stop Hook

جوهر Ralph هو Stop Hook. عندما يريد Claude الخروج، يعترض Stop Hook إشارة الخروج. ثم يتحقق النظام: هل تضمنت المخرجات علامة اكتمال محددة؟ إذا لم يُعثر على علامة، يُعاد حقن الموجه الأصلي وتبدأ جولة أخرى. فقط عندما تُكتشف علامة الاكتمال يُسمح لـ Claude بالخروج.

هذا يضمن أن Claude لا يتوقف لمجرد أنه "يشعر أنه قريب بما فيه الكفاية". بل يجب أن يكمل المتطلبات المحددة بوضوح.

التثبيت

Ralph Wiggum هو إضافة رسمية لـ Claude Code ويمكن تثبيتها بطريقتين.

الخيار 1: التثبيت من سوق الإضافات الرسمي (موصى به)

bash
# تشغيل في Claude Code
claude

# إضافة سوق الإضافات الرسمي
/plugin marketplace add anthropics/claude-code

# تثبيت Ralph Wiggum
/plugin install ralph-wiggum@claude-code-plugins

# التحقق من التثبيت
/plugin

الخيار 2: التثبيت مباشرة من GitHub

bash
# الدخول إلى مجلد الإضافات
cd ~/.claude/plugins/

# استنساخ مستودع الإضافة
git clone https://github.com/anthropics/ralph-wiggum-plugin.git

بعد التثبيت، يمكنك استخدام:

  • /ralph-wiggum:ralph-loop - بدء الحلقة
  • /ralph-wiggum:cancel-ralph - إلغاء الحلقة
  • /ralph-wiggum:help - عرض المساعدة

الاستخدام الأساسي

استخدم /ralph-wiggum:ralph-loop:

bash
/ralph-wiggum:ralph-loop "Build a todo API with CRUD operations, input validation, and tests.
             Output <promise>COMPLETE</promise> when everything is done." \
  --max-iterations 50 \
  --completion-promise "COMPLETE"

شرح المعاملات

أهم معاملين هما --max-iterations و --completion-promise.

--max-iterations يحدد الحد الأقصى للسلامة. القيم الموصى بها عادة هي 20-100. حتى لو لم يكتمل، يتوقف Ralph عند هذا الحد لمنع الإنفاق اللانهائي على API.

--completion-promise يحدد نص علامة الاكتمال، والذي يجب أن يكون صريحًا وفريدًا. يعامل Ralph المهمة كمكتملة فقط عندما تحتوي مخرجات Claude على تلك العلامة. استخدم علامات واضحة مثل COMPLETE أو TASK_DONE، وتجنب الكلمات الغامضة.

أفضل ممارسات كتابة الموجهات

كتابة موجهات جيدة هي مفتاح نجاح Ralph.

الموجهات السيئة عادة لا تحدد معايير اكتمال. على سبيل المثال، "اكتب todo API" قد يؤدي بالذكاء الاصطناعي لإخراج هيكل أولي والتوقف، بدون اختبارات أو تحقق أو وثائق.

الموجهات الجيدة يجب أن تتضمن متطلبات مرحلية ومعايير قبول واضحة. على سبيل المثال:

وصف المهام المرحية أولاً. المرحلة 1 هي الوظائف الأساسية مع جميع نقاط نهاية CRUD: POST /todos إنشاء، GET /todos قائمة، GET /todos/:id جلب واحد، PUT /todos/:id تحديث، DELETE /todos/:id حذف. المرحلة 2 هي التحقق من المدخلات: العنوان لا يمكن أن يكون فارغًا، حالة الاكتمال يجب أن تكون منطقية. المرحلة 3 هي الاختبارات: كتابة اختبارات لكل نقطة نهاية، بتغطية > 80%.

ثم تحديد معايير القبول: جميع الاختبارات ناجحة، الكود يجتاز الفاحص، README يتضمن وثائق API.

أخيرًا تحديد علامة اكتمال فريدة: <promise>TODO_API_COMPLETE</promise>.

هكذا يعرف Claude بالضبط ماذا يفعل ومتى يكون الاكتمال حقيقيًا.

المزيد من قوالب الموجهات

إليك قوالب مهام شائعة يمكنك استخدامها مباشرة أو تعديلها.

القالب 1: ترحيل الاختبارات (Jest -> Vitest)

text
/ralph-wiggum:ralph-loop "
ترحيل جميع الاختبارات في هذا المشروع من Jest إلى Vitest:
- الحفاظ على كل منطق الاختبار بدون تغيير
- تحديث ملفات التكوين (vite.config.js, vitest.config.js)
- استبدال واجهات برمجة Jest الخاصة (مثلاً jest.mock -> vi.mock)
- التأكد من نجاح جميع الاختبارات
- إزالة تبعيات Jest ذات الصلة

معايير القبول:
- npm test ينجح بالكامل
- لا توجد تبعية Jest في package.json
- المشروع يبنى بنجاح

الإخراج بعد الاكتمال: <promise>VITEST_MIGRATION_COMPLETE</promise>
" --max-iterations 40 --completion-promise "VITEST_MIGRATION_COMPLETE"

القالب 2: تحسين UI/UX (الأولوية للهاتف)

text
/ralph-wiggum:ralph-loop "
تحسين UI/UX لهذا المشروع إلى تطبيق تعلم لغات متطور بأولوية الهاتف:
- توحيد المسافات والفراغات (استخدام وحدة أساسية 4px)
- إنشاء تسلسل هرمي واضح للخطوط (عنوان/نص أساسي/نص مساعد)
- توحيد أنماط البطاقات والقوائم والمكونات المشتركة
- إضافة تنقل سفلي (الرئيسية/تعلم/اختبار/تقدم/إعدادات)
- ضمان جودة العرض على الهاتف

معايير القبول:
- npm run build ينجح
- لا توجد أخطاء TypeScript
- الصفحات الرئيسية تعرض بشكل صحيح على الهاتف

الإخراج بعد الاكتمال: <promise>UI_UX_COMPLETE</promise>
" --max-iterations 25 --completion-promise "UI_UX_COMPLETE"

القالب 3: إضافة تعليقات TypeScript بالجملة

text
/ralph-wiggum:ralph-loop "
إضافة تعليقات نوع TypeScript لجميع الدوال في المشروع:
- إعطاء الأولوية لمجلد src/
- إضافة أنواع لمعاملات الدوال وقيم الإرجاع
- تجنب any، استخدم أنواع ملموسة أو unknown
- إضافة تعريفات الأنواع الضرورية

معايير القبول:
- npm run typecheck ينجح
- لا توجد تعليقات @ts-ignore أو @ts-any
- الكود يعمل بشكل صحيح

الإخراج بعد الاكتمال: <promise>TYPES_ADDED</promise>
" --max-iterations 30 --completion-promise "TYPES_ADDED"

القالب 4: تطوير ميزات بتوجيه TDD

text
/ralph-wiggum:ralph-loop "
تنفيذ وظيفة الدفع باستخدام TDD:
1. كتابة الاختبارات أولاً (checkout.test.ts)
2. تشغيل الاختبارات (يجب أن تفشل)
3. كتابة الحد الأدنى من الكود لنجاح الاختبارات
4. إعادة الهيكلة والتحسين
5. التكرار حتى تنجح جميع الاختبارات

متطلبات الميزة:
- قائمة عناصر سلة التسوق
- حساب رسوم الشحن
- تطبيق كوبونات الخصم
- التحقق من نموذج الدفع

معايير القبول:
- جميع الاختبارات ناجحة (npm test checkout.test.ts)
- تغطية الكود > 80%
- لا توجد أخطاء ESLint

الإخراج بعد الاكتمال: <promise>CHECKOUT_COMPLETE</promise>
" --max-iterations 25 --completion-promise "CHECKOUT_COMPLETE"

القالب 5: توحيد نمط الكود

text
/ralph-wiggum:ralph-loop "
توحيد نمط الكود في جميع أنحاء المشروع:
- تنسيق جميع الملفات باستخدام Prettier
- توحيد اصطلاحات التسمية (المتغيرات camelCase، المكونات PascalCase)
- إزالة الاستيرادات والمتغيرات غير المستخدمة
- توحيد علامات الاقتباس للنصوص (علامات اقتباس مفردة)
- توحيد نمط الفواصل المنقوطة (بدون فواصل منقوطة)

معايير القبول:
- npm run lint ينجح
- نمط كود متسق
- البناء ينجح

الإخراج بعد الاكتمال: <promise>STYLE_UNIFIED</promise>
" --max-iterations 20 --completion-promise "STYLE_UNIFIED"

حالات واقعية

حدثت حالة مشهورة في هاكاثون Y Combinator، حيث استخدم فريق Ralph Loop. في الساعة 11 مساءً، حددوا مهمة: تنفيذ MVPs لـ 6 مواصفات منتج بالتسلسل وإصدار علامات اكتمال محددة لكل منها. حددوا الحد الأقصى للتكرارات بـ 200 وذهبوا للنوم.

في الصباح التالي، كان لديهم 6 مشاريع جاهزة للعرض، وتكلفة API كانت 297 دولارًا فقط. هذه هي قوة Ralph: أثناء نومك، الذكاء الاصطناعي يستمر في العمل.

حالة أخرى جاءت من Boris Cherny (قائد Claude Code). باستخدام Ralph وOpus 4.5، أنجز 259 طلب سحب في 30 يومًا، شاملة 497 التزامًا، بإضافة 40,000 سطر وحذف 38,000 سطر. والأكثر إثارة أن كل ذلك أنتجه Claude Code بدون كتابة كود يدويًا.

حالة أكثر جرأة هي لغة البرمجة CURSED. منشئ Ralph، Geoffrey Huntley، استخدم Ralph Loop على مدار 3 أشهر لبناء لغة برمجة كاملة بشكل مستقل. كلماتها المفتاحية تستخدم عامية الجيل Z (مثل slay، sus، based)، والأهم من ذلك أنها تتضمن تنفيذًا كاملاً لمترجم LLVM ومكتبة قياسية ودعمًا جزئيًا للمحرر. هذا يوضح الإمكانات الحقيقية لـ Ralph Loop: إذا قدمت هدفًا واضحًا، يمكنه الاستمرار في العمل لأشهر حتى يكتمل مشروع معقد فعلًا.

المزيد من الحالات الواقعية

إعادة هيكلة مشروع مؤتمتة

استخدم أحد المطورين Ralph لإعادة هيكلة مشروع قديم ذي كود فوضوي وبدون اختبارات ووثائق مفقودة. المهام المسندة كانت:

  1. إضافة اختبارات للكود الموجود
  2. إعادة الهيكلة خطوة بخطوة، مع ضمان نجاح الاختبارات بعد كل تغيير
  3. تحديث الوثائق

عمل Ralph طوال عطلة نهاية الأسبوع. بحلول يوم الاثنين، كان هناك 47 التزامًا، هيكل كود أنظف، تغطية اختبارات 75%، ووثائق API كاملة. التكلفة كانت حوالي 12 دولارًا.

فلسفة Ralph

يعكس Ralph ثلاث فلسفات أساسية.

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

الثانية هي الفشل كبيانات. كل فشل في الاختبار هو فرصة للتحسين؛ لا تخف من الفشل، تعلم منه.

الثالثة هي المحاولة المستمرة: استمر في المحاولة حتى ينجح. هذه هي روح Ralph.

متى يكون Ralph مناسبًا أو غير مناسب

معرفة أين يناسب Ralph يساعد في توفير الوقت والتكلفة.

سيناريوهات مناسبة لـ Ralph

هذه المهام لها معايير اكتمال واضحة وملائمة للتكرار التلقائي:

السيناريوالسبب
ترحيل الاختباراتإطار هدف واضح، يُتحقق منه بنجاح الاختبارات
إعادة هيكلة كبيرةيمكن تعريف قواعد إعادة هيكلة محددة
ترحيل إطار عملالترحيل الناجح يُتحقق منه بكود يعمل
إضافة تعليقات أنواع بالجملةيكتمل عندما ينجح فحص الأنواع
تحسين تغطية الاختباراتنسبة التغطية موضوعية
إنشاء وثائقوثائق API يمكن التحقق منها تلقائيًا
توحيد UI/UXيمكن تعريف قواعد تصميم ملموسة
إصلاح أخطاء مع خطوات إعادة إنتاجشرط النجاح قابل للاختبار

سيناريوهات غير مناسبة لـ Ralph

هذه المهام تتطلب حكمًا بشريًا أو استكشافًا:

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

قائمة مراجعة القرار

اسأل نفسك ثلاثة أسئلة:

  1. هل يمكنني تحديد معايير اكتمال صريحة؟ إذا لا، فغير مناسب
  2. هل توجد طريقة تحقق موضوعية؟ (اختبارات/بناء/فحص أنواع) إذا لا، فغير مناسب
  3. هل تتطلب هذه المهمة تغذية راجعة بشرية مستمرة؟ إذا نعم، فغير مناسب

إذا كانت الإجابات الثلاث "لا"، فدع Ralph يعمل.


الطريقة 3: Ralph المُحسّن

هذا تنفيذ مُحسّن من المجتمع لـ Ralph الرسمي. مشروع frankbria/ralph-claude-code يضيف آليات أمان أقوى.

ميزات إضافية

يضيف Ralph المُحسّن عدة ميزات أمان إضافية.

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

ثانيًا تحديد المعدل. الافتراضي هو 100 تشغيل/ساعة، مما يمنع فواتير API غير المنضبطة إذا تسبب خطأ في حلقات لا نهائية. يمكنك تعديل هذا الحد.

ثالثًا قاطع الدائرة الذكي. إذا اكتشف النظام علامة الاكتمال 5 مرات متتالية، يتوقف قسريًا. هذا يمنع الحالات النادرة التي تفشل فيها الحلقات في الإنهاء بشكل صحيح.

رابعًا لوحة معلومات في الوقت الفعلي. يوفر Ralph المُحسّن لوحة معلومات سطر أوامر تعرض التكرارات الحالية وتقدم المهمة والتكلفة المقدرة.

التثبيت

قم بتثبيت Ralph المُحسّن بالاستنساخ من GitHub:

bash
git clone https://github.com/frankbria/ralph-claude-code.git
cd ralph-claude-code
./install.sh

سكريبت التثبيت يضبط الملفات والتكوين المطلوبين تلقائيًا.

الاستخدام

استخدام Ralph المُحسّن يتخطوتين. أولاً تهيئة المشروع باستخدام ralph-setup:

bash
ralph-setup my-project

هذا ينشئ ملفات التكوين المطلوبة في المشروع. ثم بدء الحلقة باستخدام ralph loop:

bash
ralph loop

ملف التكوين

يستخدم Ralph المُحسّن .claude/ralph-config.json:

json
{
  "maxIterations": 50,
  "rateLimitPerHour": 100,
  "completionPromise": "TASK_COMPLETE",
  "exitSignal": "EXIT_NOW",
  "costAlertThresholds": [10, 50, 100]
}

maxIterations هو الحد الأقصى لعدد الحلقات. rateLimitPerHour هو الحد الأقصى للمعدل بالساعة. completionPromise هو نص علامة الاكتمال. exitSignal هو إشارة الخروج الصريحة. costAlertThresholds يحدد مستويات تحذير الميزانية.


الطريقة 4: فرق الوكلاء (وكلاء متوازيون متعددون)

عندما تكون المهام كبيرة بما يكفي، فإن Claude واحد لا يكفي؛ أنت بحاجة إلى "تعاون فريق".

فرق الوكلاء هي قدرة متقدمة تسمح لعدة نسخ من Claude بالعمل بالتوازي والتنسيق من خلال قوائم مهام وتبعيات مشتركة. هذا مناسب للمشاريع الكبيرة جدًا. في تجربة Nicholas Carlini، أنتج 16 وكيلاً متوازيًا أكثر من 100,000 سطر كود في أسبوعين وبنوا مترجم C قادر على ترجمة نواة Linux.

فرق الوكلاء أكثر تعقيدًا، وسنغطيها بالتفصيل في القسم التالي: "3.3 فرق الوكلاء: تعاون متعدد الوكلاء".


الطريقة 5: المهام الخلفية (Ctrl+B)

هذه طريقة تنفيذ غير محظورة بسيطة وعملية.

التشغيل الأساسي

الاستخدام مباشر. عندما يبدأ Claude مهمة، اضغط Ctrl+B لدفعها إلى الخلفية.

على سبيل المثال، تقول: "شغّل مجموعة الاختبارات الكاملة." يبدأ Claude في التشغيل. تضغط Ctrl+B، فيجيب Claude: "تم دفع المهمة إلى الخلفية (المعرف: task_abc123)." ثم يمكنك المتابعة: "في غضون ذلك، حلل ملف السجل هذا." يمكن لـ Claude تحليل السجلات بينما تستمر الاختبارات في الخلفية.

عرض المهام الخلفية

هناك عدة طرق للتحقق من المهام الخلفية. استخدم /tasks لعرض جميع المهام مع معرف المهمة والحالة ووقت البدء. اضغط Ctrl+T للحصول على ملخص سريع للحالة. يمكنك أيضًا إعادة مهمة إلى المقدمة لفحص المخرجات الحية.

السيناريوهات المناسبة

المهام الخلفية مناسبة للمواقف النموذجية:

أولاً، الاختبارات طويلة التشغيل. المجموعات الكاملة قد تستغرق عشرات الدقائق، والوضع الخلفي يتجنب الحظر.

ثانيًا، بناء المشاريع الكبيرة. يمكن لخطوط أنابيب البناء أن تعمل بينما تواصل عملك الآخر.

ثالثًا، عمليات الملفات الدفعية مثل إعادة التسمية والتنسيق بالجملة.

رابعًا، أي شيء لا تريد انتظاره بشكل متزامن.


آليات السلامة: منع الحلقات اللانهائية

أي نظام حلقات آلي يجب أن يتضمن حماية، وإلا قد يخرج عن السيطرة.

حدود صارمة

الحماية الأساسية هي تعيين --max-iterations (الحد الأقصى لعدد الحلقات). هذا إلزامي. بغض النظر عن حالة الاكتمال، تتوقف المهمة عند هذا الحد وتمنع الإنفاق غير المحدود على API.

يمكنك أيضًا فرض حدود زمنية، مثلاً التوقف التلقائي بعد 4 ساعات. ويمكنك أيضًا تعيين تنبيهات ميزانية تتوقف وتُعلم عند عتبات الإنفاق (مثلاً 10 دولار، 50 دولار، 100 دولار).

الكشف الذكي

يمكنك إضافة كشف ذكي للحلقات الميتة. مثلاً، التحقق مما إذا كانت الالتزامات الأخيرة تتضمن تغييرات ذات معنى:

bash
if [ $(git diff HEAD~5 | wc -l) -eq 0 ]; then
    echo "لا توجد تغييرات جوهرية في آخر 5 التزامات، حلقة محتملة"
    exit 1
fi

إذا كانت الفروقات الأخيرة ضئيلة، قد يكون النظام عالقًا ويجب أن يتوقف مع تنبيه.

تنبيهات التكلفة

تعيين عتبات تنبيه التكلفة في التكوين:

json
{
  "costAlertThresholds": [10, 50, 100],
  "alertAction": "pause_and_notify"
}

عندما يصل الإنفاق إلى 10 أو 50 أو 100 دولار، يتوقف النظام ويُعلم حتى تتمكن من تحديد ما إذا كنت تريد المتابعة.

نقاط تفتيش يدوية

للمهام المهمة، أضف نقاط تفتيش يدوية:

bash
if [ $((iteration % 10)) -eq 0 ]; then
    read -p "تم إكمال $iteration تكرارًا. المتابعة؟ (y/n)" answer
    if [ "$answer" != "y" ]; then
        break
    fi
fi

هذا يتوقف كل 10 تكرارات للتأكيد، مما يسمح بالتدخل البشري في الوقت المناسب.


بنية عملية: منتدى BBS كامل باستخدام Ralph Loop

دعنا نستخدم مثالاً كاملاً لإظهار قوة Ralph Loop. سنقوم ببناء نظام منتدى BBS من الصفر، يشمل مصادقة المستخدم والنشر ومركز الملفات الشخصية ولوحة تحكم المشرفين.

هدف المشروع

بناء نظام منتدى BBS كامل الوظائف يتضمن:

ميزات جانب المستخدم:

  • تسجيل المستخدم وتسجيل الدخول وتسجيل الخروج
  • تصفح قائمة المشاركات (ترقيم الصفحات)
  • عرض تفاصيل المشاركة
  • نشر مشاركات جديدة
  • ميزة التعليقات
  • مركز الملفات الشخصية (عرض مشاركاتك، تحديث الملف الشخصي)

ميزات لوحة تحكم المشرفين:

  • تسجيل دخول المشرف
  • إدارة المستخدمين (حظر/إلغاء الحظر)
  • إدارة المشاركات (حذف/تثبيت)
  • إدارة التعليقات
  • إحصائيات النظام

مجموعة التقنيات:

  • الخلفية: Node.js + Express + SQLite
  • الواجهة: React + React Router + Axios
  • المصادقة: JWT token
  • التنسيق: Tailwind CSS

التحضير

أولاً ثبت إضافة Ralph Wiggum:

bash
claude /plugins:add ralph-wiggum

بدء Ralph Loop

الآن شغّل Ralph Loop لبناء المشروع بالكامل:

bash
/ralph-wiggum:ralph-loop "
Please build a complete BBS forum system from scratch using TDD.

Project structure requirements:
- backend/ directory: Express API server
- frontend/ directory: React frontend app
- both directories have their own tests

Backend requirements:
- use Express framework
- SQLite storage (better-sqlite3)
- JWT auth (jsonwebtoken + bcrypt)
- user table: id, username, password, email, role, createdAt
- post table: id, title, content, authorId, category, pinned, createdAt
- comment table: id, content, postId, authorId, createdAt

Backend API endpoints:
- POST /api/auth/register - user register
- POST /api/auth/login - user login
- GET /api/posts - get post list (pagination + category filter)
- GET /api/posts/:id - get post detail
- POST /api/posts - create post (auth required)
- PUT /api/posts/:id - edit post (author or admin)
- DELETE /api/posts/:id - delete post (author or admin)
- POST /api/posts/:id/comments - add comment (auth required)
- GET /api/user/profile - get profile (auth required)
- PUT /api/user/profile - update profile (auth required)
- GET /api/admin/stats - admin statistics (admin only)
- GET /api/admin/users - user list (admin only)
- PUT /api/admin/users/:id/ban - ban user (admin only)

Frontend page requirements:
- /login - login page
- /register - register page
- / - home page (post list)
- /post/:id - post detail
- /new - publish post
- /profile - profile center
- /admin - admin panel (admin permission required)

Admin panel features:
- user management (view, ban, unban)
- post management (view, delete, pin)
- comment management (view, delete)
- system statistics (user count, post count, comment count)

TDD requirements:
- write tests first, then implementation
- each feature must have corresponding tests
- backend uses Jest, API tests cover all endpoints
- frontend uses Vitest, component tests cover major features
- auth middleware must have tests

Acceptance criteria:
- npm test (backend) passes
- npm test (frontend) passes
- frontend starts and works correctly
- backend API responds correctly
- proper permission isolation between normal users and admin
- code passes ESLint checks

Output after completion: <promise>BBS_SYSTEM_COMPLETE</promise>
" --max-iterations 150 --completion-promise "BBS_SYSTEM_COMPLETE"

الوقت المتوقع

بناءً على التعقيد:

إذا تمت البرمجة يدويًا: حوالي 40-60 ساعة (بما في ذلك تصميم قاعدة البيانات ونظام المصادقة وتكامل الواجهة/الخلفية والاختبار)

باستخدام Ralph Loop:

  • النسخة الأساسية (الوظائف الأساسية): حوالي 3-5 ساعات
  • النسخة الكاملة (لوحة تحكم المشرفين + اختبارات): حوالي 6-10 ساعات

مراقبة التقدم

أثناء عمل Ralph Loop، يمكنك مراقبة التقدم بعدة طرق:

عدد التكرارات: يعرض Ralph التكرار الحالي والحد الأقصى، مما يساعد في تقدير الوقت المتبقي.

السجلات: يمكنك رؤية ما يفعله Claude الآن، مثل تصميم قاعدة البيانات وكتابة واجهات API وبناء المكونات وإصلاح الأخطاء.

حالة الاختبارات: تُعرض نتيجة كل تشغيل اختبار. الاختبارات الناجحة تزداد والفاشلة تتناقص. عندما تبدأ الإخفاقات في الانخفاض، يقترب المشروع من الاكتمال.

التحقق بعد الاكتمال

بعد أن يُخرج Ralph علامة الاكتمال، قم بالتحقق يدويًا:

bash
# اختبارات الخلفية
cd backend
npm test

# اختبارات الواجهة
cd frontend
npm test

# بدء الخلفية
cd backend
npm start

# بدء الواجهة (في طرفية أخرى)
cd frontend
npm run dev

افتح المتصفح واختبر:

  1. سجّل مستخدمًا جديدًا
  2. سجّل الدخول
  3. تصفح المشاركات
  4. انشر مشاركة جديدة
  5. أضف تعليقًا
  6. افتح مركز الملفات الشخصية
  7. سجّل الخروج وسجّل الدخول كمشرف (الحساب الافتراضي: admin/admin123)
  8. اختبر ميزات لوحة تحكم المشرفين

ملاحظات

Ralph Loop قوي، لكن ضع هذه النقاط في الاعتبار:

أولاً، الموجهات الأكثر تفصيلاً تعطي نتائج أفضل. الموجهات الغامضة تتطلب تكرارات أكثر للتصحيح.

ثانيًا، عيّن حدود تكرار معقولة. أنظمة BBS معقدة؛ يوصى بـ 100 تكرار على الأقل.

ثالثًا، يُوصى بـ TDD. كتابة الاختبارات أولاً يمكن أن تقلل وقت التصحيح بشكل كبير.

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

خامسًا، انتبه جيدًا لتصميم قاعدة البيانات. قد يحتاج Ralph عدة تكرارات قبل التوصل إلى مخطط قوي.


مقارنة الطرق واختيارها

كل طريقة لها خصائصها وتناسب سيناريوهات مختلفة.

حلقة While True هي الأبسط: 5 أسطر فقط للتشغيل، ملائمة للتجارب والنماذج الأولية السريعة. لكنها محدودة ولا تكشف الاكتمال الحقيقي، بل تعتمد فقط على حدود التكرار.

Ralph Wiggum هو التوصية العامة لمعظم السيناريوهات. لديه آلية Stop Hook كاملة، يدعم فحص علامات الاكتمال، وله دعم رسمي ووثائق قوية.

Ralph المُحسّن أفضل لبيئات الإنتاج، مع شروط خروج مزدوجة وحدود معدل وقواطع دوائر ذكية.

المهام الخلفية مفيدة للتنفيذ غير المحظور البسيط: فقط اضغط Ctrl+B. لكنها تنفيذ خلفي فقط، وليست تنسيق حلقات تكرارية.


الخلاصة

الفكرة الأساسية لجعل Claude Code يعمل لفترات طويلة بسيطة: لا تطلب منه "الإنجاز في محاولة واحدة"، بل اطلب منه "الاستمرار في المحاولة حتى الاكتمال الحقيقي".

جميع الطرق تفعل نفس الشيء أساسيًا: أعطِ Claude مهمة، دعه يعمل، تحقق مما إذا كان الاكتمال حقيقيًا، وإذا لم يكن كذلك، استمر في الجولة التالية.

أي طريقة تختارها يعتمد على احتياجاتك.

إذا كنت تريد البساطة والسرعة، استخدم حلقة While True. خمسة أسطر يمكنها العمل، لكن الميزات محدودة.

إذا كنت تريد التوصية العامة، استخدم Ralph Wiggum. دعم رسمي، قدرة كاملة، مناسب لمعظم الحالات.

إذا كان هذا استخدامًا إنتاجيًا، استخدم Ralph المُحسّن. لديه آليات أمان إضافية وهو أكثر موثوقية.

(بالنسبة لتعاون فرق الوكلاء متعددة الوكلاء، راجع القسم التالي: "3.3 فرق الوكلاء: تعاون متعدد الوكلاء".)

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


المراجع

الموارد الرسمية

مشاريع المجتمع

مقالات ودروس

موارد إنجليزية

دروس صينية

دراسات حالة عملية