🧠 كيف يعمل فريق أنثروبيك مع Claude Code؟ دليل مبسط لأسرار التطوير بالذكاء الاصطناعي
تخيل أنك تشرف على مطور ذكي جداً — لكنه يحتاج منك أن تشرح له ما تريد بدقة. معظمنا يظن أن المشكلة في الذكاء الاصطناعي نفسه، لكن الحقيقة أن المشكلة في طريقة تواصلنا معه. في هذا المقال، سنأخذك في رحلة شيقة لفهم كيف يستخدم فريق أنثروبيك (Anthropic — الشركة التي تصنع Claude) أداة Claude Code (أداة برمجة بالذكاء الاصطناعي) بطريقة احترافية.
📍 فهرس المحتويات
🔑 المفاهيم الأساسية التي عليك فهمها أولاً
Claude Code: أداة برمجة تعمل بالذكاء الاصطناعي — سبق أن شرحنا كيف يعمل ذاكرة وحلم Claude بشكل أعمق — تسمح لك بكتابة الأكواد البرمجية وتعديلها وتصحيحها عبر التحدث مع الذكاء الاصطناعي بدلاً من كتابة كل سطر بنفسك.
Agent (وكيل ذكي): برنامج ذكي يمكنه تنفيذ مهام معقدة بشكل مستقل — يمكنك قراءة الدليل الشامل للأنظمة الوكيلة الذكية لمزيد من التفاصيل — مثل مساعد شخصي لكن للبرمجة.
Spec (المواصفات): وثيقة تصف بالتفصيل ماذا تريد بناءه — مثل رسم معماري قبل بناء المنزل.
Verification (التحقق): عملية التأكد من أن البرنامج يعمل كما يجب — مثل تجربة المصعد بعد تركيبه للتأكد من أنه آمن.
🎯 المشكلة الكبرى: لماذا تفشل معظم محاولات البرمجة بالذكاء الاصطناعي؟
تخيل أنك تدخل مطبخاً وتطلب من الطباخ “اطبخ شيئاً لذيذاً”. سينتج لك شيئاً عشوائياً، أليس كذلك؟ هذا بالضبط ما يفعله معظم المبرمجين مع Claude Code عندما يكتبون له ببساطة: “حسّن هذا الكود” (Just make it better).
المشكلة ليست في Claude — المشكلة في طريقة صياغة الطلب. كلما أصبحت نماذج الذكاء الاصطناعي أكثر ذكاءً، كلما كان من الأفضل أن تدعها تستخرج منك المعلومات بدلاً من أن تحاول أنت تحديد كل شيء مسبقاً. هذا هو الدرس الأهم من محاضرة “The Bitter Lesson” (الدرس المر) لريتشارد ساتون — أبو تعلّم الآلة — الذي يقول: بدلاً من قضاء وقتك في تقييد النظام وتحديد كل شيء بنفسك، الأفضل أن تصبّ المزيد من البيانات والقدرة الحاسوبية وتترك النظام يتعلم.
💡 تشبيه: الأمر يشبه الذهاب إلى الطبيب. بدلاً من أن تقول “أعطني دواءً”، أنت تصف الأعراض وهو يسألك أسئلة ليكتشف التشخيص الصحيح. بنفس الطريقة، Claude أفضل في استخراج ما تريده منك بالأسئلة التفاعلية مما أنت في تحديده مسبقاً.
🔄 الطريقة المثلى: ثلاث مستويات للعمل مع Claude Code
استناداً إلى خبرة فريق التطوير في أنثروبيك، هناك ثلاث مراحل متدرجة يمكنك اتباعها:
المستوى 1: المقابلة التفاعلية — دع Claude يسألك
بدلاً من كتابة طلب طويل ومفصل، ابدأ بجملة قصيرة تحدد المجال، ثم استخدم أداة “Ask User Question” (اسأل المستخدم) المدمجة في Claude. مثلاً:
طلب جيد: “أريد تطبيقاً لتقسيم الفاتورة بين الأصدقاء. أسألني عن التفاصيل التي تحتاجها.”
النتيجة: Claude سيطرح عليك أسئلة مثل: كم عدد المستخدمين؟ هل هناك عملة محددة؟ هل تريد حساب الضريبة؟ وهكذا…
هذا الأسلوب يضمن أن المواصفات (Spec) شاملة لأن Claude يعرف الأسئلة الصحيحة التي يجب طرحها — وهو أفضل من محاولة تذكر كل التفاصيل بنفسك.
المستوى 2: مواصفات HTML بدلاً من Markdown
تقليدياً، كان المبرمجون يكتبون المواصفات على شكل ملفات Markdown (نصوص بتنسيق بسيط). لكن مشكلة Markdown أنه عندما يطول — أكثر من 200 سطر — يصعب قراءته. تخيل أن تقرأ دليل تعليمات من 30 صفحة بدون أي صور أو ألوان!
الحل؟ استخدام ملفات HTML بدلاً من Markdown. لماذا؟ لأن HTML يمكنه عرض:
- نماذج أولية مرئية (Prototypes) يمكنك التفاعل معها
- أزرار وحقول إدخال — وليس مجرد نصوص
- صور ولقطات شاشة توضح الفكرة
- تصاميم مختلفة يمكن مقارنتها جنباً إلى جنب
🎨 تشبيه: تخيل أن تطلب من مهندس معماري أن يصف لك المنزل الذي سيبنيه عبر رسالة نصية فقط. صعب جداً! لكن لو أعطاك نموذجاً ثلاثي الأبعاد يمكنك التجول فيه — ستفهم كل شيء بثوانٍ. HTML هو ذلك النموذج الثلاثي الأبعاد في عالم البرمجة.
في المحاضرة، طلب المتحدث من Claude مع Opus 4.7 (أحدث نموذج لأنثروبيك مع قدرات بصرية متطورة) توليد 4 تصاميم مختلفة لتطبيق تقسيم الفاتورة — أحدها بأسلوب “Brutalist” وآخر بأسلوب “Tokyo Fintech” — وتمكن من معاينتها جميعاً والنقر عليها واتخاذ القرار.
المستوى 3: التحقق المضمن — Verification-as-Artifact
هذا هو المستوى الأكثر تقدماً والأهم. بدلاً من كتابة اختبارات منفصلة للبرنامج، يقوم Claude بتضمين التحقق داخل القطعة البرمجية نفسها. كيف؟
يستخدم فريق أنثروبيك تقنية ذكية: يجعلون كل مكوّن (Component) في التطبيق ينشر حالته (State) إلى واجهة DOM (هيكل صفحة الويب) بشكل منفصل عن واجهة المستخدم. بهذه الطريقة، يمكن للوكيل الذكي قراءة هذه البيانات مباشرة والتحقق منها دون الحاجة إلى “كشط” (Scraping — استخراج بالقوة) واجهة المستخدم.
| المكوّن | الشرح المبسّط |
|---|---|
| Schema (المخطط) | هيكل البيانات المتوقعة — مثل جدول المحتويات الذي يخبرك بماذا ستحتوي كل خانة |
| Fixtures (البيانات الافتراضية) | عينات جاهزة من البيانات تستخدم للاختبار — مثل تجربة السيارة قبل شرائها |
| Invariants (الثوابت) | خصائص يجب أن تبقى صحيحة دائماً — مثل أن مجموع المهام المنجزة + النشطة = العدد الكلي |
| Probes (المسابر) | اختبارات صغيرة تتأكد من صحة الثوابت — مثل أجهزة الإنذار في المباني |
🔍 تشبيه: تخيل أنك مدير مستودع. بدلاً من أن تفتح كل صندوق بنفسك لتتأكد من محتوياته، يمكنك وضع جهاز مسح ضوئي يقرأ ملصق كل صندوق ويخبرك فوراً إذا كان هناك خطأ. هذه هي فكرة نشر الحالة إلى DOM — الوكيل الذكي يقرأ الحالة مباشرة دون أن يلمس التطبيق نفسه.
🛠️ ثلاث طرق للتحقق: بشري، وكيل، وتلقائي
يقدم فريق أنثروبيك ثلاث طرق للتحقق — مشابهة للمنهجية التي استخدمناها في بناء وكيل SRE للاستجابة للحوادث باستخدام Claude Managed Agents من صحة التطبيق — ولكل طريقة استخدامها المناسب:
| الطريقة | من يستخدمها | متى تستخدم |
|---|---|---|
| لوحة التحكم البشرية (Human Dashboard) | المطور البشري | عند تطوير الميزات وتجربتها يدوياً |
| الوكيل في المتصفح (Agent-First) | Claude عبر Playwright MCP | عند اختبار التطبيق مباشرة من المتصفح — مثل محاكاة نقر المستخدم |
| التشغيل الآلي (Headless CI) | أنظمة التكامل المستمر (مثل GitHub Actions) | قبل نشر التحديثات — تأكد أن كل شيء يعمل تلقائياً |
تخيل أن لديك تطبيق To-Do List (قائمة مهام). في المحاضرة، أظهر المتحدث كيف يمكن إضافة مهمة، وضع علامة اكتمال، وحذفها — وكل حركة تنشر أرقاماً محدثة إلى DOM: “المهام المنجزة: 2″، “المهام النشطة: 3″، “المجموع: 5”. إذا كان المجموع لا يساوي الإنجاز + النشط — يفشل التحقق فوراً!
💡 الدرس العملي: في المحاضرة، قام المتحدث بزرع خطأ متعمد — جعل 3 + 4 = 10 (خطأ في الحساب) — واستخدم Claude لتشخيص المشكلة. عندما يدير Claude التحقق بنفسه عبر Playwright MCP (أداة تتحكم بالمتصفح برمجياً)، يكتشف التناقض فوراً ويخبرك أين المشكلة بالضبط. هذا يختصر ساعات من البحث اليدوي عن الأخطاء!
⚙️ الإعدادات التي يجب أن تعرفها
أثناء المحاضرة، شارك المتحدث بعض الإعدادات التي يستخدمها فريق أنثروبيك يومياً:
- /effort — معامل الجهد: يوصون باستخدام X High أو Max Effort (أقصى جهد). هذا يجعل Claude يفكر أعمق ويعطي نتائج أفضل.
- /fast — الوضع السريع: يستهلك توكنات (Tokens — وحدات المعالجة) أكثر، لكنه ممتاز للتكرار السريع على المواصفات. استخدمه عندما تريد تجربة أفكار متعددة بسرعة.
- Auto Mode — الوضع التلقائي: الأهم على الإطلاق! يسمح لـ Claude بتنفيذ المهام المتعددة دون توقف. إذا لم تستعمله، فأنت تفوّت الكثير.
- Opus 4.7: النموذج الموصى به لهذه المهام لأنه يملك قدرات بصرية متطورة — يمكنه قراءة لقطات الشاشة وفهم التصاميم بشكل أفضل بكثير من Sonnet.
🎬 تسجيل الأدلة: لماذا هذا مهم؟
هل سبق أن أصلحت خطأً في برنامج، ثم بعد أسبوع عاد نفس الخطأ ولا تعرف لماذا؟ فريق أنثروبيك يحل هذه المشكلة عبر تسجيل فيديوهات للتحقق. نعم! كل مرة ينفذ Claude عملية تحقق، يسجل مقطع فيديو يوثق النتائج — نجاح أو فشل — ويخزنه على S3 (خدمة تخزين سحابية).
🎥 تشبيه: الأمر مثل كاميرات المراقبة في البنك. لا أحد يراقبها طوال الوقت، لكن عند حدوث مشكلة — تعود إليها لترى ماذا حدث بالضبط. تسجيلات التحقق هي كاميرات المراقبة لمشاريعك البرمجية.
هذه التسجيلات تسمح لأعضاء الفريق بمشاهدة الأدلة دون الحاجة لتكرار الاختبارات بأنفسهم. كما أنها توثق أن الميزة كانت تعمل بشكل صحيح قبل أي تغيير لاحق.
📋 الخلاصة
ما تعلمناه اليوم يمكن تلخيصه في ثلاث خطوات بسيطة:
- دع Claude يسألك أسئلة بدلاً من أن تكتب مواصفات طويلة — استخدم أداة Ask User Question
- استخدم HTML بدلاً من Markdown للمواصفات — إنها أغنى بالمعلومات وأسهل للفهم والتفاعل
- ضمّن التحقق داخل القطعة البرمجية نفسها — اجعل الوكيل الذكي قادراً على التحقق من عمله دون مساعدتك
هذه ليست مجرد نصائح تقنية — إنها تغيير في طريقة التفكير. الفرق بين مطور يستخدم Claude وبين مطور يتقن Claude هو نفسه الفرق بين من يستخدم الآلة الحاسبة ومن يفهم الرياضيات. الأول ينفذ مهام، والثاني يبدع حلولاً.
🖼️ شرائح الفيديو التوضيحية
فيما يلي الشرائح الرئيسية من العرض التقديمي — اخترناها لتساعدك على الفهم البصري للمفاهيم:
📚 المصادر والمراجع
لضمان الدقة والموثوقية، اعتمدنا في هذا المقال على المصادر التالية:
- المحاضرة الأصلية: Code with Claude: كيف يعمل فريق أنثروبيك مع Claude Code — يوتيوب (قناة Anthropic)
- وثائق Claude Code الرسمية: Anthropic Claude Code Documentation
- مستودع التمارين: CWB UC Workshops على GitHub — يحتوي ثلاث مراحل تدريجية من السهل إلى المتقدم
- The Bitter Lesson: ريتشارد ساتون — الدرس المر (المقال الأصلي)
❓ الأسئلة الشائعة
س: هل استخدام HTML للمواصفات يستهلك توكنات أكثر؟
ج: سؤال ممتاز! قد تستهلك مواصفات HTML توكنات أكثر في كل مرة، لكنها توفر عليك التكرار. إذا كتبت مواصفة HTML غنية، ستقل أخطاء الفهم والتعديلات — مما يقلل العدد الإجمالي للتوكنات على المدى الطويل. الفريق يؤكد: “في المدى البعيد، تتكرر أقل إذا كانت المواصفة جيدة وغنية.”
س: ما الفرق بين الاختبار (Testing) والتحقق (Verification)؟
ج: الاختبار هو التأكد من أن الكود يعمل كما هو مكتوب — مثل فحص المحرك بعد تركيبه. أما التحقق فهو التأكد من أن الكود يحقق ما يريده المستخدم فعلاً — مثل قيادة السيارة والتأكد من أنها مريحة وتناسب احتياجاتك. في هذه الطريقة، التحقق مضمَّن في القطعة البرمجية نفسها وليس منفصلاً عنها.
س: هل ينفع استخدام Sonnet بدلاً من Opus 4.7؟
ج: ينصح المتحدث بعدم استخدام Sonnet لهذه المهام تحديداً. Opus 4.7 يملك نموذج رؤية (Vision Model — قدرة على تحليل الصور) أفضل بكثير، وهذا ضروري للعمل مع التصاميم ولقطات الشاشة. إذا كان ميزانيتك محدودة، جرب الوضع السريع (Fast Mode) مع Opus — قد يكلف أكثر لكن النتائج أفضل.
س: كيف أبدأ بتطبيق هذه الطريقة في مشاريعي؟
ج: أبسط بداية هي تحميل الريبو (Repository — مستودع الكود) الذي أشار إليه المتحدث: CWB UC Workshops على GitHub. يحتوي على ثلاث مراحل متدرجة من السهل إلى المتقدم. ابدأ بالمرحلة الأولى: استخدم أداة Ask User Question في Claude Code لبناء مواصفة تفاعلية.
س: هل هذه الطريقة مناسبة للمشاريع الصغيرة فقط؟
ج: العكس! فريق أنثروبيك نفسه يستخدم هذه الطريقة يومياً في مشاريعهم الكبيرة — ويسجلون جميع تغييرات الواجهة الأمامية بهذه الطريقة. كلما كبر المشروع، زادت أهمية تضمين التحقق في القطعة البرمجية لتجنب الأخطاء المكلفة.
اترك تعليقاً