المشروع التطبيقي الكامل: من الصفر وحتى النشر، ربط المهارات في مسار موحد
📚 دليل السلسلة: الدرس السابق [47 Voice وضع التحدث الصوتي] علمك كيفية استبدال "كتابة الأوامر" بـ "نطق المتطلبات شفهياً"، لتريح أصابعك وتسرع العمل. هذا الدرس يمثل مشروع التخرج للسلسلة بالكامل — حيث لا نطرح ميزات تقنية جديدة، بل نأخذ مشروعاً حقيقياً يفوق حجم تدريب الدرس 39 ويتطلب الربط بين عدة محادثات، لنفعل معاً ميزات CLAUDE.md، وإدارة الأذونات، وخوادم MCP، والوكلاء الفرعيين subagents، ونقاط التراجع، وسير عمل git في نفس الوقت، لنمر بالدورة الكاملة للتطوير من مجلد فارغ وحتى تسليم المنتج.
إذا قمنا بجرد وتصفح المشاريع التي ساهم فيها Claude Code بنجاح، فسنخرج بنتيجة واضحة: أن المشاريع التي شعر فيها المطورون بـ "القيمة الحقيقية للأداة" لم تكن مهام بسيطة من قبيل "تعديل سطر واحد بطلب واحد"، بل كانت مشاريع متوسطة الحجم تمتد عبر عدة محادثات وتستدعي عدة ميزات وتكاملات.
بالمصطلحات العملية — عند بناء أداة داخلية للفريق من الصفر، قد تفتح 4 محادثات متتالية وتستغرق ساعتين ونصف من العمل، وتستعين بـ MCP لقراءة وثائق أداة خارجية، وترسل وكيلاً فرعياً subagent لإجراء فحص أمني، وتنقذ الأكواد من الضياع بعد خطأ هيكلي بالاعتماد على نقاط التراجع. وعند مراجعة سجل التزامات git في النهاية، تجده منظماً في 7 التزامات (commits) واضحة وتفصيلية. في تلك اللحظة تحديداً ستشعر بأن المهارات التي تعلمتها في السلسلة ليست مجرد قطع منفصلة، بل أجزاء مترابطة تصنع فارقاً حقيقياً.
وهذا هو الجسر الفاصل بين "التعرف على كل ميزة بشكل منفصل" و "القدرة على جمعها لإنجاز عمل حقيقي". لقد مررنا في الدرس 39 بتجربة مصغرة — محادثة واحدة، ملف برمجي واحد، وعمل محلي بالكامل. أما في هذا الدرس فسنقوم بتوسيع رقعة العمل: حيث يصبح المشروع أكثر تعقيداً، ونربط العمل بين عدة محادثات، ونتصل بالعالم الخارجي، ونفوض المهام للوكلاء الفرعيين، ونتراجع بمرونة عند حدوث أخطاء. فالدروس السبعة والأربعين السابقة علمتك العزف على الأدوات بشكل منفرد، وجاء هذا الدرس لتلعب دور المايسترو وتقود الفرقة الموسيقية بالكامل لإنتاج معزوفة متكاملة.
تشبيه: قيادة أوركسترا متكاملة لعزف مقطوعة موسيقية. لقد تدربت على عزف الكمان والنحاسيات والإيقاع — وكل آلة تتقنها بشكل منفصل. ولكن "إتقان كل آلة على حدة" يختلف تماماً عن "قيادتهم معاً لإنتاج معزوفة متناسقة": فيجب أن تعرف متى يدخل كل قسم، ومن يقود ومن يتبع، وكيف يتناسق الإيقاع. وفي هذا الدرس، ستلعب دور المايسترو — لتكون مكونات CLAUDE.md، وإدارة الأذونات، و MCP، والوكلاء الفرعيين subagents، ونقاط التراجع، و git هي الأقسام الموسيقية التي نقودها بالترتيب المناسب لإتمام العمل.
بعد قراءة هذا الدرس، ستحصل على:
- مخطط متكامل لـ "دورة التطوير لمشروع متوسط من الصفر وحتى التسليم"، لتدرك موضع ونفع كل ميزة تعلمتها في السلسلة
- مهارة تمرير وتكامل العمل عبر عدة محادثات متتالية: كيفية استخدام معامل
--resumeووثائق SPEC ونقاط التراجع لتقسيم مهمة معقدة على عدة محادثات أو أيام عمل بأمان - تفاصيل كل مرحلة عملية: "ماذا تكتب، وماذا تلاحظ، وأين قد تتعطل" مع الأوامر والمخرجات المتوقعة
- كود برمجي لمشروع حقيقي يمكنك تطبيقه (أداة سطر أوامر لإدارة المهام تملك حفظاً محلياً واختبارات ووثائق)، يربط بين CLAUDE.md ← الأذونات ← MCP ← subagent ← نقاط التراجع ← git
- جدول مقارنة بين "مشاريع التدريب البسيطة ومشاريع العمل الحقيقية" لتفادي الفخاخ التي تسبب تعطل المشاريع الكبيرة
01 نظرة شاملة: أين تتدخل كل ميزة في مشروع متوسط الحجم
قبل البدء بالعمل البرمجي، دعنا نستعرض مخطط العمل الكامل. فبناء مشروع متوسط من الصفر وحتى التسليم يحافظ على نفس المراحل الأساسية، ولكن كل مرحلة تصبح أكثر ثقلاً وتتطلب استدعاء أدوات جديدة.
يوضح هذا المخطط مراحل التطوير لـ "مشروع متوسط الحجم" في حلقة تكرارية: تبدأ الخطوات بالتوالي، ويمثل الخط المتقطع العودة الحيوية — فالمشاريع الحقيقية لا تكتمل في محادثة واحدة، وبعد التحقق من جزء نعود لمرحلة التخطيط لفتح محادثة جديدة وتطوير الجزء التالي. وبذلك تختلف عن المسار المستقيم للمشاريع البسيطة في الدرس 39.
ويبرز فارقان أساسيان للمشاريع متوسطة الحجم عن المشاريع البسيطة، احفظهما جيداً:
- العمل يمتد عبر عدة محادثات متتالية. فعند امتلاء سياق المحادثة بالملفات والبيانات (وقد أوضحنا في الدرس 19 أن امتلاء السياق يجعل الذكاء الاصطناعي بطيئاً وعرضة للأخطاء)، يجب عليك إغلاق المحادثة وفتح محادثة جديدة نظيفة لمتابعة العمل. وتعتبر مهارة نقل العمل بأمان للمحادثة التالية مهارة أساسية للمطور.
- استدعاء تكاملات جديدة. لا تحتاج المشاريع البسيطة لربط MCP أو تفويض وكلاء subagents، بينما تعتبر هذه الأدوات ركيزة أساسية للمشاريع المتوسطة — لقراءة الوثائق الخارجية، أو عزل العمليات التجريبية، أو الاستعانة بنماذج متخصصة للفحص.
وتلخص العبارة الرسمية المنهجية الأفضل للعمل:
بمجرد صياغة مسار عمل ناجح مع Claude، ضاعف مخرجاتك بالاعتماد على المحادثات المتوازية، والتشغيل غير التفاعلي، وتفويض المهام التكراري.
بمعنى آخر: عند استقرارك على أسلوب عمل فعال، قم بنسخه لتشغيل عدة محادثات متوازية، وتشغيل الأتمتة الجماعية، وتفويض المهام للوكلاء المساعدين لإنجاز العمل بالتزامن — بدلاً من بناء كل شيء يدوياً في كل مرة. وهذا ما سنطبقه عملياً في هذا الدرس.
وسنشير في بداية كل قسم إلى الدروس السابقة المرتبطة به لتربط المهارات معاً. وبعد تثبيت المخطط في ذهنك، نبدأ باستدعاء كل قسم في موقعه المناسب.
💡 خلاصة القول في جملة واحدة: يتكون هيكل المشاريع المتوسطة من خطوات "立项 ← التخطيط ← الاتصال الخارجي ← تفويض المهام ← التراجع ← التسليم"، وتتميز عن المهام البسيطة بـ تكامل العمل عبر عدة محادثات، واستدعاء ميزات متقدمة مثل MCP و الوكلاء subagents؛ وتمثل الحلقة التكرارية طبيعة المشاريع الحقيقية.
02 立项 (التأسيس): إنشاء المشروع وصياغة CLAUDE.md وضبط الأذونات
الخطوة الأولى — التأسيس. وترتبط بالدرسين 12 و 18 (CLAUDE.md)، والدرس 20 (الأذونات). في المهام البسيطة، نكتفي بكتابة بضعة سطور في CLAUDE.md، أما في المشاريع المتوسطة، فيجب تأسيس "قواعد المشروع" و "حدود الأذونات" معاً في البداية، لكونها الأساس الذي تسير عليه كل المحادثات اللاحقة.
المشروع الذي سنقوم ببنائه اليوم: أداة سطر أوامر لإدارة المهام (todo-cli) — تتيح إضافة المهام، واستعراضها، وتحديد المكتمل منها، وحفظ البيانات محلياً في ملف JSON، مع كتابة اختبارات برمجية وملف README توضيحي. وهو أضخم من مشروع الدرس 39: فهو يتكون من عدة ملفات، ويحفظ البيانات، ويحتوي على اختبارات، ويمتد عبر عدة محادثات، ولكنه يقتصر على مكتبات Python القياسية لتسهيل التشغيل للجميع.
الخطوة الأولى: إنشاء مجلد المشروع وربطه بـ git
mkdir todo-cli && cd todo-cli && git initلماذا يعتبر ربط git أول خطوة نقوم بها؟ لأنه صمام الأمان الأساسي لاستعادة الأكواد عند حدوث أخطاء. فميزة نقاط التراجع (الدرس 37) تتراجع عن تعديلات Claude للملفات، ولكنها تختلف عن git وتغطي نطاقاً مختلفاً. ووجود التزام (commit) نظيف وأولى يمثل نقطة العودة الآمنة التي تلجأ إليها عند تعطل الأكواد البرمجية بالكامل — وقد أكدنا على هذه القاعدة في الدرس 39 وتزداد أهميتها للمشاريع الكبيرة.
الخطوة الثانية: تشغيل Claude في مجلد المشروع، وصياغة ملف CLAUDE.md
claudeبعد الدخول للمحادثة، اطلب منه صياغة قواعد CLAUDE.md (وننصح في المشاريع المتوسطة بتحديد القواعد الأساسية يدوياً بدلاً من تشغيل أمر /init الذي يمسح مجلدات فارغة، لعدم وجود أكواد برمجية بعد):
帮我在项目根目录建一个 CLAUDE.md，写清这几条：
1. 这是个纯 Python 标准库的命令行工具，不要引入任何第三方依赖
2. 数据持久化到项目根的 todos.json，所有读写都走这一个文件
3. 每加一个功能都要配 unittest 测试，改完跑 python3 -m unittest 验证
4. 提交信息用中文，前缀用 feat: / fix: / docs:المتوقع: يعرض لك Claude محتويات الملف المقترح ويطلب موافقتك لكتابة الملف (بموجب نظام الأذونات في الدرس 20). وبعد الموافقة، ينشأ ملف CLAUDE.md مقيداً بهذه الشروط الأربعة. وتذكر — أنه لا يتجاوز عشرة أسطر. ونعيد التذكير بالقاعدة الذهبية للوثائق الرسمية:
حافظ على الاختصار. ومع كل سطر تكتبه، اسأل نفسك: "هل يؤدي حذف هذا السطر لوقوع Claude في خطأ برمجى؟" وإذا كانت الإجابة لا فاحذفه فوراً.
فهذه الشروط الأربعة يصعب على Claude تخمينها بمفرده وسيتكرر استخدامها، ولذلك نحتفظ بها. ومع بدء المحادثات الثلاث أو الأربع اللاحقة، سيقوم Claude بقراءة هذه القواعد تلقائياً، دون أن تحتاج لإعادة إخبارك له في كل مرة بـ "تجنب المكتبات الخارجية وتشغيل الاختبارات".
الخطوة الثالثة: تهيئة حدود الأذونات — وهي خطوة أساسية للمشاريع المتوسطة
في المهام البسيطة، يمكنك الموافقة على الأذونات خطوة بخطوة. ولكن عند العمل على مشروع متوسط يتكون من عدة محادثات ويعدل عشرات الملفات، تنبه الوثائق الرسمية لخطر الموافقة الروتينية: "بعد الموافقة العاشرة المتتالية، لن تدقق في السطور، بل ستضغط على زر الموافقة تلقائياً." ولذلك يجب ضبط حدود الأذونات في البداية. وتتوزع الخيارات بحسب السيناريو كالتالي:
| الأسلوب | كيفية استخدامه | السيناريو الأنسب |
|---|---|---|
| قائمة المسموحات (Allowlist) | استخدام /permissions لإضافة الأوامر الآمنة والموثوقة (مثل python3 -m unittest أو git status) | الأوامر الروتينية التي يتكرر تشغيلها لتفادي إزعاج التنبيهات |
| وضع التخطيط (Plan mode) | التبديل بالاختصار Shift+Tab أو تشغيل الأداة عبر claude --permission-mode plan | للتحقق ومراجعة خطة العمل قبل تعديل الملفات |
| الوضع التلقائي (Auto mode) | التشغيل عبر claude --permission-mode auto لمطالبة الموافقة للعمليات الخطيرة فقط | عند الوثوق بمسار العمل العام ورغبتك في تقليل التدخل البشري |
والتوزيع العملي المقترح لمشروع todo-cli هو: إضافة الأوامر الروتينية مثل python3 -m unittest و git diff و git status لقائمة المسموحات عبر لوحة /permissions؛ والتبديل لوضع plan mode عبر Shift+Tab عند تعديل الأكواد البرمجية لمراجعة خطة التعديل أولاً. وبتأسيس هذه الحدود، ستتخلص من معظم رسائل التنبيه الروتينية اللاحقة — فعدم تهيئة هذه الحدود يجعلك تضغط على زر الموافقة لأكثر من عشرين مرة لمجرد تشغيل الاختبارات، مما يسبب الملل ويؤدي لإغلاق نظام الحماية بالكامل (وهو الخطر الحقيقي).
⚠️ الأذونات المفتوحة سلاح ذو حدين — فالوضع التلقائي والقبول التلقائي يوفران الوقت، ولكنهما يفقدانك القدرة على المراجعة اللحظية للعمليات. وقد شرحنا هذه الموازنة في الدرسين 20 و 21: فكلما منحت حرية أكبر للوكيل، وجب عليك التدقيق في المخرجات والاعتماد على نقاط التراجع لحماية الملفات.
💡 خلاصة القول في جملة واحدة: تتلخص خطوة التأسيس لمشروع متوسط في — ربط git init لضمان التراجع + صياغة ملف CLAUDE.md مختصر يحدد القواعد + وتهيئة حدود الأذونات عبر قائمة المسموحات وأوضاع التشغيل؛ وتهيئة الأذونات هي الفارق الأهم عن المهام البسيطة ويجدر قضاء دقيقتين لضبطها في البداية.
03 التخطيط: صياغة وثيقة SPEC أولاً، وتوزيع العمل على عدة محادثات
بعد تأسيس القواعد، ننتقل للخطوة الثانية — التخطيط. وترتبط بالدرس 16 (الاستكشاف والتحليل)، والدرس 20 (وضع plan mode)، والدرس 19 (إدارة السياق). ويكمن الفارق الأكبر بين المشاريع المتوسطة والبسيطة في هذه المرحلة: فالمهمة البسيطة تبدأ بالعمل الفوري بمجرد توجيه جملة واحدة، بينما يتطلب المشروع المتوسط صياغة "وثيقة المواصفات الفنية (SPEC)" أولاً وتوزيع المهام على محادثات متتالية.
لماذا يجب صياغة وثيقة SPEC للمشاريع المتوسطة؟ لأنه مع تزايد الميزات وتعدد الملفات، يؤدي العمل بالاعتماد على الأفكار الشفهية غير المرتبة للوقوع في أخطاء هيكلية وتعارض البيانات، مما يضطر لإعادة العمل البرمجي بالكامل. وتوفر الوثائق الرسمية طريقة عملية لصياغتها: وهي مطالبة Claude بإجراء مقابلة معك للوقوف على التفاصيل الفنية.
الخطوة الأولى: مطالبته بإجراء مقابلة وصياغة وثيقة SPEC
بدل وضع التشغيل لوضع plan mode (عبر Shift+Tab)، ووجه له هذا التوجيه:
我想做一个命令行任务清单工具 todo-cli，数据存本地 JSON。
用 AskUserQuestion 工具详细采访我：技术实现、命令行接口怎么设计、
边界情况（比如空清单、重复任务、文件损坏）、有哪些权衡。
别问显而易见的，挖那些我可能没想到的硬骨头。
问完把完整规格写进 SPEC.md。المتوقع: يوجه لك Claude أسئلة فنية دقيقة ومتتالية — مثل "هل تحمل المهام أولويات معينة؟"، "هل نقوم بإنشاء ملف todos.json تلقائياً عند غيابه أم نخرج خطأ؟"، "هل تحديد المكتمل يقوم بحذف المهمة أم إبقائها مع إضافة علامة اكتمال؟" وهي تفاصيل هامة قد تهملها في البداية. وبعد الإجابة، يصيغ وثيقة SPEC.md موضحاً بها الواجهات البرمجية، وصيغ البيانات، والحالات الخاصة، ومعايير القبول. وتعرف الوثائق وثيقة المواصفات الجيدة:
تتصف وثيقة المواصفات الجيدة بالشمول الذاتي: حيث تحدد الملفات والواجهات البرمجية المعنية، وتفرز المهام الخارجة عن نطاق العمل الحالي، وتنتهي بخطوات التحقق والاختبار الفعلي للبرنامج.
فعند بناء الأداة مثلاً، يسألك عن تفصيل هام: "إذا تطابقت كلمات مهمتين تماماً، فهل نعتبرهما مهمة مكررة ونمنع الإضافة، أم نقبلهما معاً؟" وسؤال مثل هذا يوجهك لاتخاذ قرار هيكلي هام في البداية. وقضاء عشر دقائق في هذه المقابلة يوفر عليك ساعات من تعديل وهدم الأكواد لاحقاً — وهي صفقة رابحة جداً للمطور.
الخطوة الثانية: تقسيم المهمة الكبيرة لمحادثات فردية
بعد صياغة وثيقة المواصفات الفنية SPEC، تجنب محاولة بناء المشروع بالكامل في محادثة واحدة. فتعدد الملفات وكثرة الأكواد يملأ سياق المحادثة بسرعة ويجعل الوكيل مشتتاً وبطيئاً. والمسار الصحيح هو تقسيم المهام وتخصيص محادثة مستقلة لكل جزء:
المحادثة 1: بناء الهيكل الأساسي — ملفات المشروع، وحفظ وقراءة ملف todos.json، ودالة add مع اختباراتها
المحادثة 2: بناء دالتي list و done مع كتابة اختباراتهما
المحادثة 3: التعامل مع الحالات الخاصة (الملفات التالفة، القوائم الفارغة) وكتابة الاختبارات الشاملة
المحادثة 4: كتابة وثائق README وفحص البرنامج بالكامل والتسليم النهائيالخطوة الثالثة: كيفية نقل وتكامل العمل بين المحادثات بأمان
هذه هي المهارة الفنية الأهم للمشاريع المتوسطة. عند انتهاء محادثة وبدء المحادثة التالية، كيف ننقل تفاصيل العمل بأمان؟ نعتمد على آليتين:
- أمر
/clearللإغلاق، ومعامل--resumeللمتابعة. عند انتهاء جزء والرغبة في البدء في جزء آخر مستقل، اكتب/clearلتصفية السياق (وتنصح الوثائق الرسمية بتكرار تصفية السياق/clearعند الانتقال بين مهام غير مرتبطة)؛ وإذا كنت تريد متابعة العمل على نفس الجزء السابق، فشغل الأداة مع معاملclaude --resumeلاختيار الجلسة السابقة ومتابعتها. - استخدام ملف SPEC.md كوثيقة للتسليم. في بداية كل محادثة جديدة، اطلب من Claude قراءة ملف
SPEC.mdوسجلgit logأولاً، ليربط سياق العمل البرمجي مع ما تم إنجازه في ثوانٍ معدودة — ولهذا السبب نقوم بحفظ المواصفات في ملف SPEC الفعلي بدلاً من تركها في نافذة المحادثة: فالنصوص في المحادثة تمسح بانتهاء الجلسة، بينما تبقى الملفات محفوظة.
إليك جملة عملية يمكنك نسخها وتوجيهها لـ Claude في بداية كل محادثة جديدة لمتابعة العمل:
先读 SPEC.md 和 git log 看我们做到哪了，别改任何代码，
告诉我下一块该做什么、有没有遗留的坑。والتكاسل عن مطالبة Claude بقراءة SPEC في بداية المحادثة الثانية يؤدي لفخ تباين البيانات — حيث قد يفترض سياقاً جديداً ويعدل أسماء حقول ملف JSON لتعارض البيانات التي تم حفظها في المحادثة الأولى، مما يسبب ضياع الوقت. ولذلك التزم بهذه القاعدة: توجيه المحادثة الجديدة دائماً لقراءة SPEC و git log أولاً، ليتولى هو ربط التفاصيل بدقة تفوق تذكيرك الشفهي له.
وتشير الوثائق الرسمية لميزة حفظ المحادثات:
يحفظ Claude Code تفاصيل المحادثات محلياً، وبموجب ذلك لن تحتاج لإعادة شرح السياق للوكيل عند امتداد المهمة عبر عدة جلسات عمل.
وتعني هذه الميزة بقاء سجلات المحادثات السابقة محفوظة — ولكن تذكر أن إعادة تحميل المحادثات الطويلة بالكامل يستهلك سياق العمل ويجعل الوكيل بطيئاً (الخطأ المشروح في الدرس 19). ولذلك يمثل ملف SPEC نقطة مرجعية أفضل بكثير: ملف واحد مختصر يقرأه الوكيل في ثوانٍ معدودة ليربط السياق، دون استهلاك مساحة السياق في قراءة سجلات قديمة.
💡 خلاصة القول في جملة واحدة: يتكون التخطيط للمشاريع المتوسطة من — مطالبة Claude بإجراء مقابلة معك لكتابة ملف SPEC.md الفني، ثم تقسيم المهمة الكبيرة لمحادثات مستقلة؛ واستخدام أمر
/clearللإغلاق ومعامل--resumeللمتابعة، مع جعل ملف SPEC وثيقة تسليم العمل — فالرسائل تمسح وتبقى الملفات.
04 الاتصال الخارجي: استدعاء خوادم MCP لجلب ما يعجز Claude عن الوصول إليه
بعد بدء العمل على الهيكل الأساسي، ستواجه الخطوة الثالثة — الاتصال الخارجي. وترتبط بالدرس 22 (خوادم MCP). لا تحتاج المشاريع المحلية البسيطة لهذه الميزة، ولكنها تصبح ركيزة أساسية للمشاريع المتوسطة: فستحتاج بالتأكيد لقراءة وثائق أداة خارجية، أو تصفح قاعدة بيانات، أو فتح طلب سحب.
متى يجب عليك استدعاء خوادم MCP؟ تضع الوثائق الرسمية علامة بسيطة وعملية لذلك:
بمجرد أن تجد نفسك تقوم بنسخ ولصق البيانات يدوياً من أداة خارجية لتضعها في نافذة المحادثة لـ Claude، فاعلم أن هذا هو وقت ربط وتوصيل خادم MCP المناسب.
فأثناء بناء todo-cli مثلاً، قد تحتار في الصياغة الصحيحة لإحدى دوال فحص الاختبارات في مكتبة unittest، وتذهب تلقائياً لتصفح المتصفح والبحث عنها ثم نسخها ولصقها لـ Claude — وتعتبر هذه الحركة هي الإشارة لاستدعاء MCP. وبدلاً من النقل اليدوي، دع Claude يتصفح ويجلب المعلومة بنفسه.
تشبيه: ربط كابل الشبكة بجهاز حاسوب يقتصر على البيانات المحلية. فدون كابل الشبكة، يقتصر عمل الحاسوب على الملفات المخزنة محلياً، ولجلب بيانات خارجية تضطر لنقلها عبر ذاكرة فلاش يدوياً في كل مرة. وربط كابل الشبكة يمنحه الوصول المباشر وجلب الملفات تلقائياً. ويعتبر Claude بمثابة هذا الحاسوب المعزول — حيث يقتصر وصوله الافتراضي على ملفات وأوامر جهازك المحلي؛ ويمثل خادم MCP كابل الشبكة، وبمجرد ربطه، يستطيع Claude جلب ما يعجز عن الوصول إليه بمفرده تلقائياً. ويختلف عمل الأداة بحسب الخدمة المرتبطة بها: تصفح وثائق، فحص قاعدة بيانات، أو تكامل مع منصة GitHub.
وسنقوم بربط خادم MCP الرسمي المخصص لقراءة الوثائق كمثال للتدريب. وهو خادم مجاني تدار خدماته سحابياً ولا يتطلب تسجيلاً أو تهيئة معقدة، ويمثل أفضل خيار لبدء التجربة بأمان.
الخطوة الأولى: إضافة خادم MCP (تكتب في طرفية جهازك، وليس داخل محادثة claude):
claude mcp add --transport http claude-code-docs https://code.claude.com/docs/mcpتنبيه: يعتبر هذا الخادم خدمة سحابية خارجية، وتتطلب إضافته توفر اتصال بالإنترنت؛ وإذا واجهت مشكلة في ربطه، فاستخدم شبكة تدعم الوصول للمواقع المحجوبة وجرب مجدداً.
المتوقع: تظهر رسالة تأكيد في الطرفية تفيد بالإضافة بالشكل التالي: Added HTTP MCP server claude-code-docs ....
الخطوة الثانية: التحقق من حالة الاتصال
claude mcp listالمتوقع: يظهر الخادم المسمى claude-code-docs في القائمة وبجانبه علامة الاتصال ✓ Connected. رؤية العلامة الخضراء تعني نجاح الاتصال المباشر بالخادم؛ وإذا ظهرت علامة الفشل ✗ Failed to connect فتأكد من جودة اتصال الشبكة وجرب مجدداً.
الخطوة الثالثة: توجيه Claude للبحث بالاستعانة بالخادم المضاف (تكتب داخل المحادثة)
用 claude-code-docs server 查一下 Claude Code 的 subagent 是怎么定义的，
配置文件放哪、有哪些字段。المتوقع: يتوقف Claude في المرة الأولى لطلب موافقتك على استدعاء الخادم المضاف (بموجب أذونات تشغيل الأدوات لأول مرة الموضحة في الدرس 22) — فوافق عليه. ليقوم بالبحث وجلب تفاصيل وكلاء subagent وعرضها لك، وستلاحظ ظهور وسم اسم الخادم claude-code-docs بجانب أداة البحث في سجل العمليات. وظهور هذا الوسم يؤكد جلب البيانات من ملفات التوثيق الرسمية الفعلية للخدمة، وليس تخميناً أو اختلاقاً من ذاكرة النموذج.
ولا تقتصر استخدامات خوادم MCP للمشاريع المتوسطة على قراءة الوثائق فقط. وتتعدد السيناريوهات لتشمل تكاملات عملية هامة:
| ما تريد الوصول إليه | خادم MCP المناسب | طبيعة العمليات التي ينجزها Claude |
|---|---|---|
| إدارة المشكلات وطلبات السحب | GitHub MCP | "اقرأ تفاصيل المشكلة رقم 12 ونفذ المتطلبات الفنية، ثم افتح طلب سحب PR للتعديل" |
| مراجعة وتصفح قواعد البيانات | PostgreSQL MCP (أو غيرها) | "احسب عدد المهام المضافة لهذا الشهر من جدول قاعدة البيانات" (واحرص على استخدام حسابات قراءة فقط للمشاريع الفعلية) |
| قراءة تفاصيل التصاميم الفنية | Figma MCP | "أعد تنسيق وعرض ألوان الطرفية لتتطابق مع هذا التصميم المعتمد" |
ونعيد التذكير بالتحذير الأمني الصارم قبل إضافة أي خادم MCP (الدرسين 21 و 22):
تأكد من موثوقية وأمان خادم MCP قبل ربطه ومشاركته مع المستودع. فالخوادم التي تجلب محتويات خارجية قد تعرضك لمخاطر حقن التوجيهات الخبيثة (prompt injection).
فخوادم MCP هي برمجيات يطورها طرف ثالث، ولا تقوم شركة Anthropic بفحصها أو تدقيقها بالنيابة عنك. ولذلك اعتمد على الخوادم المعتمدة والرسمية، واستخدم حسابات ذات صلاحيات قراءة فقط لقواعد البيانات لضمان حماية أصولك. وتذكر تنبيه الوثائق: تستهلك خوادم MCP المرتبطة جزءاً من مساحة سياق المحادثة، ولذلك قم بحذف خادم التوثيق التجريبي بعد انتهاء حاجتك منه عبر تشغيل أمر claude mcp remove claude-code-docs لتوفير مساحة السياق.
💡 خلاصة القول في جملة واحدة: يتطلب المشروع متوسط الحجم استدعاء خوادم MCP — وعند تكرار نسخ ولصق البيانات يدوياً من الأدوات الخارجية، سارع بربط خادم MCP المناسب؛ واعتمد على الخادم الرسمي لقراءة الوثائق في البداية لتجربته بأمان، واستخدم خوادم GitHub وقواعد البيانات للمشاريع الفعلية مع الالتزام بقواعد الحماية وحذف الخوادم غير المستخدمة.
05 تفويض المهام: استدعاء وكلاء subagents للمهام الجانبية، والاستعانة بنموذج جديد للفحص
مع تزايد ملفات وأكواد المشروع، نصل للخطوة الرابعة — تفويض المهام. وترتبط بالدرس 23 (الوكلاء الفرعيون subagents)، والدرس 29 (فرق العمل الذكية agent teams). لا تظهر أهمية هذه الميزة للمشاريع البسيطة، بينما تمثل ركيزة أساسية للمشاريع المتوسطة لحماية سياق المحادثة من الامتلاء، وضمان جودة وموثوقية الأكواد البرمجية.
استدعاء الوكلاء subagents للمهام الجانبية لحفظ مساحة السياق للمحادثة الرئيسية
مع بلوغ المحادثة الثالثة لمشروع todo-cli، تتعدد الملفات وتتداخل الأكواد، وتود معرفة "مواضع ودوال قراءة وحفظ ملف todos.json بالتحديد". تجنب مطالبته بقراءة وفحص كل ملفات المشروع داخل المحادثة الرئيسية — لأن قراءة الملفات بالكامل تملأ سياق المحادثة بالرموز البرمجية، وتضيق المساحة المتاحة للمهام البرمجية الفورية (الخلل المشروح في الدرس 19). والأسلوب الصحيح هو تفويض وكيل فرعي subagent لهذه المهمة الجانبية:
派一个 subagent 去摸清 todos.json 的所有读写都发生在哪些函数里，
只把「哪些文件、哪些函数、各自干啥」的清单报给我，别贴文件全文。المتوقع: يذهب الوكيل الفرعي subagent للعمل داخل سياق محادثة منفصل وخاص به، ليتصفح ويقرأ الملفات، ويعود للمحادثة الرئيسية بتقرير ملخص وموجز للمواضع المطلوبة فقط. وتوضح الوثائق الرسمية هذه الميزة:
يمثل السياق (context) القيد التقني الأهم لك، ويمثل الوكلاء الفرعيون subagents أقوى أداة لتخطي هذا القيد... حيث يعملون في سياقات مستقلة ويعودون بالملخصات دون استهلاك سياق محادثتك الرئيسية.
تشبيه: تفويض متدرب بالذهاب لغرفة الأرشيف لجلب البيانات. تطلب منه تحديد مواضع معينة، ولا تطلب منه جلب دواليب الأوراق بالكامل لمكتبك وتكديسها أمامه. فالوكيل الفرعي subagent هو هذا المتدرب — يبحث ويفحص داخل غرفة الأرشيف (السياق المستقل)، ويعود لك بورقة ملخصة، لتظل مساحة مكتبك (السياق الرئيسي) نظيفة ومنظمة.
الاستعانة بنموذج جديد لفحص الأكواد — "منع الكاتب من تقييم نفسه"
بعد اكتمال كتابة الأكواد، تجنب مطالبة نفس سياق Claude الذي كتب الأكواد بمراجعتها — لأنه سيميل للثقة بأكواد كتبها بنفسه وتغيب عنه الأخطاء المنطقية الخفية. والممارسة الأساسية لضمان جودة الأكواد في المشاريع المتوسطة هي فتح سياق محادثة جديد ومستقل تماماً ليتولى الفحص والمراجعة. وتوضح الوثائق الرسمية المبدأ:
عند تشغيل مراجع الأكواد داخل سياق subagent مستقل ونظيف، يقتصر اطلاعه على الفروق (diff) والمعايير المحددة له فقط، دون التأثر بمسارات التفكير والافتراضات التي رافقت كتابة الأكواد، مما يجعله يقيم جودة الأكواد بحيادية تامة.
والطريقة الأسرع لتنفيذ ذلك هي تشغيل أمر مراجعة الأكواد المدمج /code-review، ليقوم بفتح وكيل فرعي مستقل يفحص الفروق الحالية ويعود بالتقرير:
/code-reviewأو يمكنك كتابة توجيه مخصص تحدد فيه وثيقة المواصفات الفنية SPEC كمرجع لمراجعة الأكواد:
用 subagent 对照 SPEC.md 审一遍刚才的改动：每条要求是否实现、
列出的边界情况有没有测试、有没有动到范围外的代码。
只报影响正确性的问题，别报风格偏好。وأثناء بناء todo-cli، نجح وكيل المراجعة الفرعي subagent في كشف خطأ برمجي خفي أغفلته المحادثة الرئيسية: حيث افترضت المحادثة الرئيسية معالجة تلف ملف todos.json بمجرد التحقق من غيابه، وأغفلت حالة وجود الملف مع احتوائه على نصوص تالفة لا تتوافق مع صيغة JSON. وهذا هو نفع "الاستعانة بنموذج جديد ونظيف" — فمراجعته تخلو من افتراض "أن الكود المكتوب سليم". وتنبه الوثائق لقصر الملاحظات على الأخطاء المؤثرة:
وجه مراجع الأكواد للتركيز على الأخطاء المنطقية وتطابق المتطلبات الفنية الفعالة فقط، وتجاوز الملاحظات المتعلقة بالتفضيلات الشخصية للأكواد.
تنبيه تجريبي: تمثل ميزة فرق العمل الذكية (Agent teams الموضحة في الدرس 29) التطوير التلقائي لهذه المرحلة، وهي ميزة تجريبية قد تتغير. وتتيح للمحادثات التنسيق والعمل المشترك بناءً على قائمة مهام موحدة — كأن تتولى محادثة كتابة الأكواد وتتولى أخرى المراجعة المستمرة. ويكفي المطور حالياً استخدام ميزة تفويض وكيل فرعي للفحص يدوياً؛ وعند تضخم المشاريع، يمكنك تفعيل ميزة فرق العمل لمتابعة التطوير.
💡 خلاصة القول في جملة واحدة: يوفر تفويض المهام ميزتين أساسيتين للمشاريع المتوسطة — تفويض الوكلاء subagents للمهام الجانبية (للبحث وقراءة الملفات في سياق مستقل دون ملء المحادثة الرئيسية)؛ و الاستعانة بنموذج جديد للفحص (عبر أمر
/code-reviewلتقييم الأكواد بحيادية تامة ومنع الكاتب من تقييم نفسه)؛ وتفعيل فرق العمل الذكية للمشاريع الضخمة لاحقاً.
06 التراجع (المرونة): التراجع النظيف عند حدوث أخطاء، وتجنب التعديل على كود تالف
مع زيادة الملفات وتداخل العمل، تصبح أخطاء تعديل الأكواد أمراً متكرراً، ويتولى القسم الخامس معالجة هذه الأخطاء — التراجع. ويرتبط بالدرس 37 (نقاط التراجع). لا تظهر القيمة الكبيرة لهذه الميزة في المشاريع البسيطة، بينما تمثل ركيزة أمان هامة للمشاريع المتوسطة: فكلما تشابكت الأكواد وتعددت الملفات، صعب تتبع الأخطاء البرمجية ومراجعتها بالعين المجردة مقارنة بالمهام البسيطة.
وننبه لأشهر الأخطاء الشائعة للمبتدئين: مطالبة Claude بإصلاح وتعديل أكواد برمجية تعرضت للتلف والتخريب بالفعل.
تجنب تكرار هذا السلوك تماماً. فمحاولة ترقيع كود تعرض للتلف والتخريب تجعل Claude يكتب تعديلات عشوائية ومتعارضة، لأن التعديل الجديد يبنى على سياق خاطئ وتالف، لتتفاقم المشكلة ويزداد تعقيد الأكواد. والتصرف الصحيح والوحيد: هو التراجع النظيف للوراء والعودة لآخر نقطة برمجية سليمة ومجربة، ثم صياغة التوجيه بشكل أوضح وإعادة المحاولة. ويتوزع التراجع بين درجتين أساسيتين:
| درجة التراجع | الأداة المستخدمة | نقطة العودة | السيناريو الأنسب |
|---|---|---|---|
| التراجع الخفيف (تعديلات الجلسة) | نقاط التراجع عبر أمر /rewind أو ضغط زر Esc مرتين متتاليتين | آخر تعديل أجراه Claude على الملفات في المحادثة الحالية | عند حدوث أخطاء بسيطة في بضعة أسطر ونرغب في التراجع السريع عنها |
| التراجع القوي (تاريخ git) | أوامر git مثل git restore . (لمسح التعديلات الحالية) أو git reset --hard <SHA> (للعودة لالتزام سابق) | آخر التزام (commit) سليم ومجرب قمت بحفظه | عند تلف مسار التطوير بالكامل ورغبتنا في البدء مجدداً من نقطة ثابتة |
ويعتبر التراجع الخفيف هو الأكثر استخداماً: حيث تفتح لوحة التراجع عبر أمر /rewind وتحدد التراجع عن تعديل الملفات، أو التراجع عن رسائل المحادثة، أو التراجع عنهما معاً. ونعيد التذكير بالقيد الهام لنقاط التراجع البرمجية: تقتصر نقاط التراجع على تتبع تعديلات Claude لملفات المحادثة الحالية فقط، ولا تتتبع تعديلات أوامر bash الخارجية، ولا تعتبر بديلاً لنظام git المعتمد.
ولهذا السبب يجب الالتزام بالتزام التعديلات (commit) بشكل دوري في git. فنقاط التراجع تخدمك داخل جلسة المحادثة الحالية فقط؛ بينما يمتد المشروع المتوسط لعدة محادثات متتالية وتتخلله اختبارات وتعديلات خارجية — وهي جوانب لا ترصدها نقاط التراجع ولا يحفظها إلا نظام git. فأثناء بناء todo-cli، قد تطلب منه إعادة هيكلة دالة حفظ البيانات ويقوم بتعديل ملفات متعددة وتخريب دوال أخرى سليمة لتتعطل الاختبارات. وبفضل الالتزام الدوري المسبق، تكتتب أمر git reset --hard وتعود لنقطة الأمان السليمة في ثوانٍ معدودة — فلو اعتمدت على نقاط التراجع وحدها، لعجزت عن تصفية التعديلات المتداخلة عبر المحادثات المختلفة.
وبعد التراجع للوراء، تجنب إعادة إرسال التوجيه القديم بنفس صياغته. بل تفكر في مسببات تعطل الأكواد — وغالباً ما يكون السبب هو غياب الشروط والقيود الواضحة في توجيهك (الدرس 15). وصغ التوجيه الجديد مع إضافة شروط واضحة مثل "أعد هيكلة دالتي الحفظ والقراءة فقط، وتجنب لمس أو تعديل دالة add تماماً"، لتسير عملية البناء بنجاح في المحاولة الثانية. فالتراجع ليس تراجعاً للخلف، بل خطوة ذكية لتفادي الهدر.
💡 خلاصة القول في جملة واحدة: تعطل الأكواد وتلفها في المشاريع الكبيرة أمر طبيعي — والتصرف الصحيح هو التراجع النظيف فوراً وتجنب الترقيع فوق أكواد تالفة؛ واعتمد على
/rewindللتراجع الخفيف، وعلى أوامر git للتراجع القوي والعودة لنقاط الأمان؛ ونظراً لأن نقاط التراجع لا تراقب إلا تعديلات المحادثة الحالية وليست بديلاً لـ git، فاحرص على التزام التعديلات (commits) بشكل دوري لحفظ عملك.
07 العمل: بناء مشروع todo-cli من الصفر وحتى التسليم في خطوات عملية
الحديث النظري لا يغني عن التطبيق الفعلي. سنقوم الآن بتطبيق عملي متكامل لبناء مشروع وإنجاز مرحلتين أساسيتين (تأسيس الهيكل وبناء دالتي add و list) وربط كل المهارات معاً. وتقتصر الخطوات على مكتبات Python القياسية، وتتطلب توفر بيئة تشغيل python3 فقط (مدمجة في macOS و Linux، ويتم تثبيتها في Windows).
الخطوة الأولى: التأسيس والربط بـ git (تطبيقا للقسم 02)
mkdir todo-cli && cd todo-cli && git init && claudeبعد تشغيل محادثة Claude، اطلب منه صياغة قواعد CLAUDE.md:
帮我在项目根目录建一个 CLAUDE.md：纯 Python 标准库别引第三方依赖；数据存项目根的 todos.json；
每个功能配 unittest，改完跑 python3 -m unittest 验证；提交信息用中文带 feat:/fix: 前缀。المتوقع: يعرض لك مقترح القواعد ويطلب موافقتك، وينشأ ملف CLAUDE.md مختصر. وبعدها أضف أمر تشغيل الاختبارات لقائمة المسموحات: اكتب أمر /permissions في المحادثة، وأضف الأمر Bash(python3 -m unittest*) لقائمة المسموحات الآمنة. المتوقع: ظهور الأمر المسموح به في اللوحة تأكيداً للإضافة.
الخطوة الثانية: التخطيط البرمجي (تطبيقا للقسم 03)
بدل وضع التشغيل لوضع plan mode (عبر Shift+Tab)، واطلب منه وضع خطة البناء دون تعديل الملفات بعد:
我要做 todo-cli：todo.py 提供 add「文字」加任务、list 列出所有任务（带编号和完成状态），
数据存 todos.json。先告诉我文件结构和你打算怎么实现，等我说「开始」再动手。المتوقع: يعرض لك خطة فنية واضحة — تقترح إنشاء ملف todo.py الذي يضم دوال القراءة والحفظ واستخدام مكتبة argparse لإدارة الأوامر، وإنشاء ملف فحص الاختبارات test_todo.py. ويتوقف Claude بانتظار موافقتك لبدء العمل.
الخطوة الثالثة: البناء ومراقبة التعديلات (تطبيقا لنظام الأذونات في الدرس 02)
اكتب له الموافقة والبدء:
方案可以，开始吧。先实现 add 和 list，再写对应的 unittest。المتوقع: يبدأ Claude بإنشاء ملفات todo.py و test_todo.py بالتوالي، ويعرض لك الفروق (diff) والتعديلات المقترحة خطوة بخطوة لموافقتك. وراقب ثلاثة جوانب في التعديلات المعروضة: ① اقتصار العمل على دالتي add و list؛ ② الالتزام بالمكتبات القياسية لـ Python دون الاستعانة بمكتبات خارجية (التزاماً بـ CLAUDE.md)؛ ③ تجنب تعديلات جانبية غير مطلوبة. ووافق على التعديلات عند الاطمئنان.
الخطوة الرابعة: التحقق والاختبار الفعلي للبرنامج (تأكيداً للقاعدة الذهبية للتحقق)
شغّل الاختبارات البرمجية أولاً (ولكون الأمر مضافاً لقائمة المسموحات، فسيتم تشغيله مباشرة دون تنبيه):
python3 -m unittestالمتوقع للمخرجات (ظهور كلمة OK في النهاية يؤكد سلامة الاختبارات):
...
----------------------------------------------------------------------
Ran 3 tests in 0.00s
OKثم شغّل البرنامج يدوياً وأضف مهاماً لتأكيد مخرجات البرنامج الفعلية:
python3 todo.py add "写第48篇教程"
python3 todo.py add "跑通动手环节"
python3 todo.py listالمتوقع للمخرجات (يظهر رقم المهمة وحالة اكتمالها الفارغة بحسب تنفيذ الكود البرمجي):
[1] [ ] 写第48篇教程
[2] [ ] 跑通动手环节فرؤية كلمة OK للاختبارات وظهور المهام المضافة مع أمر list تثبت سلامة وجودة العمل البرمجي بالكامل. فتصريحات الوكيل بسلامة الأكواد تظل فرضية شفهية، والتحقق والتشغيل الفعلي هو الحقيقة المؤكدة — وقد شددنا على هذه القاعدة في الدرس 39 وتتأكد أهميتها للمشاريع الكبيرة.
الخطوة الخامسة: الاستعانة بنموذج جديد للفحص (تطبيقا للقسم 05)
/code-reviewالمتوقع: يفتح سياق وكيل فرعي مستقل لمراجعة التعديلات الجارية، ويعود بتقرير فحص (مثل التنبيه بغياب معالجة تلف ملف JSON). وقم بإصلاح الأخطاء المؤثرة على سلامة تشغيل البرنامج أولاً، وتجاوز الملاحظات التجميلية.
الخطوة السادسة: الالتزام وحفظ التعديلات في git (تطبيقا للدرس 06 وسير عمل git)
اطلب منه استعراض التعديلات وكتابة التزام منظم:
我改了哪些文件？给个改动概览。然后用一句话描述这次改动、提交它。المتوقع: يشغل أمر git status و git diff لاستعراض الملفات المعدلة، ويصيغ رسالة التزام مناسبة باللغة العربية (مثل feat: 实现 todo-cli 的 add 和 list 命令)، ويطلب موافقتك لتشغيل أمر git commit — وهي بوابة الأمان للأذونات لحماية تاريخ git الخاص بك. ووافق لتثبيت الالتزام.
الخطوة السابعة: التحكم الصارم في أمر دفع التعديلات push
بهذا نصل لنهاية مرحلة التطوير بنجاح. ونضع قاعدة أمنية صارمة لا تقبل التساهل:
نسمح للوكيل بصياغة وحفظ الالتزامات المحلية (commit) بالنيابة عنا، ولكن عملية دفع التعديلات للخادم البعيد (git push) يجب أن تتم بيدك وبشكل يدوي تماماً.
فقبل دفع التعديلات لمستودعات العمل على GitHub، يجب أن تراجع الأكواد وتتأكد منها بنفسك وتكتب أمر الدفع بنفسك — وهذا ما شرحناه بالتفصيل في الدرس 43 "سير عمل Git". فصياغة التزام محلي آمنة؛ أما دفع التعديلات للخارج فهو مسؤوليتك البشرية الحصرية.
وبتشغيل هذه الخطوات السبع، تكون قد مررت بالدورة الكاملة للتطوير لمشروع حقيقي "التأسيس ← التخطيط ← البناء ← التحقق الفعلي ← الفحص بالوكيل الفرعي ← الحفظ في git ← حماية الدفع الخارجي" بنفسك. وتتبع نفس هذه الحلقة التكرارية لتطوير دالة done وإضافة معالجات الحالات الخاصة لاحقاً لإتمام مشروع todo-cli بالكامل — فنفس الدورة والخطوات تتكرر في كل مرحلة.
💡 خلاصة القول في جملة واحدة: يتكون التطبيق العملي من سبع خطوات متتالية — تأسيس وقواعد CLAUDE.md والأذونات ← صياغة الخطة في وضع plan mode ← البناء ومراقبة الفروق ← تشغيل الاختبارات والتحقق الفعلي ← الفحص عبر
/code-reviewالحيادي ← مراجعة وتثبيت الالتزام في git؛ وتذكر الخط الأحمر: تسمح بالالتزام المحلي (commit) يدوياً، وتتولى أنت كتابة دفع التعديلات (push) للخارج بنفسك.
08 جدول المقارنة: مشاريع التدريب البسيطة مقابل مشاريع العمل الحقيقية
تختلف تجربة تشغيل Claude لمشاريع التدريب البسيطة تماماً عن إدارته للمشاريع الحقيقية متوسطة وكبيرة الحجم — ويكمن الفارق في المشكلات التي لا تظهر إلا مع تضخم حجم العمل. وسنلخص الفروق في هذا الجدول لتتجنب المعوقات:
| وجه المقارنة | ❌ أسلوب مشاريع التدريب البسيطة | ✅ أسلوب مشاريع العمل الحقيقية |
|---|---|---|
| قواعد المشروع | كتابة بضعة أسطر في CLAUDE.md وتجاوز الأذونات | تأسيس قواعد المشروع ومحددات الأذونات معاً في البداية لحماية المحادثات اللاحقة |
| التخطيط الفني | البدء بالعمل الفوري بمجرد توجيه جملة واحدة | مطالبة Claude بإجراء مقابلة وصياغة ملف SPEC.md الفني أولاً |
| إدارة المحادثات | محادثة واحدة ممتدة حتى يمتلئ السياق بالبيانات | تقسيم المهام لمحادثات مستقلة وتصفيتها بـ /clear والمتابعة بـ --resume والاعتماد على SPEC كوثيقة تسليم |
| البيانات الخارجية | نسخ ولصق البيانات يدوياً من المصادر الخارجية | ربط خادم MCP المناسب (مع الالتزام بالحسابات الآمنة وحذف الخوادم بعد انتهاء الحاجة) |
| جودة الكود | مطالبة كاتب الكود بمراجعته وتقييمه بنفسه | تفويض وكيل فرعي مستقل عبر /code-review لإجراء فحص حيادي للأكواد |
| التعامل مع الأخطاء | الترقيع والتعديل فوق أكواد تالفة ومخربة بالفعل | التراجع النظيف فوراً للوراء بالاعتماد على نقاط التراجع /rewind أو تاريخ git |
| التسليم والرفع | إهمال الالتزامات وكتابة التزامات عشوائية | مراجعة الملفات المعدلة وصياغة التزام منظم في git، وتتولى أنت كتابة أمر push بنفسك |
والخلاصة الفنية لجدول المقارنة: الخطوات البرمجية التي تتجاوزها وتوفر وقتها في مشاريع التدريب البسيطة، تمثل ركائز أساسية تضمن سلامة وسرعة مشاريع العمل الحقيقية — لأن غيابها في المشاريع الكبيرة يسبب تعطل العمل وتضاعف أوقات返工 لاحقاً. فالمبتدئ ينقل أساليب العمل البسيطة للمشاريع الكبيرة ويقع في فخاخ تداخل سياق المحادثات وترقيع الأكواد التالفة وإهمال الاختبارات والموافقة الروتينية على التعديلات، ليستهلك ساعات طويلة في تصحيح أخطاء كان بالإمكان تفاديها بتهيئة سليمة. فاحفظ هذا المبدأ: تزايد حجم المشروع يطالبك بصرامة والتزام أكبر بمسارات العمل السليمة — فالقواعد والخطوات ليست قيوداً تعيق حركتك، بل دعامات تقودك لبناء مشاريع ضخمة وناجحة بأمان.
وقد يتساءل البعض: "ألا تؤدي هذه الخطوات الصارمة لإبطاء سرعة التطوير؟" والواقع العملي يثبت العكس تماماً — فهذه الخطوات تمنحك الثقة لتفويض مهام أكبر للوكيل والابتعاد لتناوله الغداء دون قلق. فالسرعة الحقيقية هي سرعة إنجاز المشروع دون الاضطرار لهدم وإعادة بناء الأكواد البرمجية.
💡 خلاصة القول في جملة واحدة: تكمن الفروق بين مشاريع التدريب والمشاريع الحقيقية في قوة وصرامة الالتزام بالخطوات الأساسية؛ فالقواعد، والتخطيط بملف SPEC، وتقسيم المحادثات، وربط خوادم MCP، والمراجعة بالنماذج المستقلة، والتراجع النظيف، وحماية دفع الأكواد — هي خطوات لا غنى عنها لنجاح المشاريع الكبيرة وتفادي تعطل العمل لاحقاً.
09 خلاصة
يمثل هذا الدرس مشروع التخرج العملي للسلسلة — حيث قمنا بجمع وتوظيف المهارات والأدوات التي تعلمتها في الدروس السبعة والأربعين السابقة لقيادة وبناء مشروع برمجي متوسط الحجم من الصفر وحتى التسليم.
ونلخص هيكل ومراحل العمل التي مررنا بها في جدول المراجعة التالي:
| مرحلة العمل | طبيعة المهام المنجزة | الأدوات والدروس المرتبطة | الفائدة التقنية والعملية للمرحلة |
|---|---|---|---|
| التأسيس (立项) | إنشاء مجلد المشروع وكتابة القواعد وتحديد الأذونات | 12 / 18 / 20 | توفير الجهد وحماية الملفات ومنع رسائل الموافقة الروتينية اللاحقة |
| التخطيط (规划) | إجراء مقابلة المواصفات الفنية وصياغة وثيقة SPEC.md | 16 / 19 / 20 | تحديد ملامح المشروع فَنياً وتوزيع المهام على عدة محادثات متتالية بأمان |
| تكامل الشبكة | ربط خوادم MCP لقراءة التوثيق الفني للخدمات | 22 | تمكين Claude من جلب واستخدام بيانات خارجية يعجز عن الوصول إليها بمفرده |
| تفويض المهام | استدعاء وكيل فرعي subagent للبحث، ونموذج مستقل للفحص | 23 / 29 | حماية سياق المحادثة الرئيسية من التكدس، وفحص جودة الأكواد بحيادية |
| التراجع والوقاية | التراجع عن التعديلات التالفة للعودة لنقاط الأمان السليمة | 37 | تفادي تخريب الأكواد البرمجية بالترقيع العشوائي، والالتزام الدوري بالـ commits |
| التسليم والرفع | التحقق الفعلي للاختبارات وصياغة التزامات git والدفع بيدك | 43 / 44 | ضمان جودة البرنامج المخرجة فِعلياً، وحصر أذونات التعديل الخارجي بيدك |
ويجب أن تكون قادراً الآن على: قيادة وبناء مشروع برمجي متوسط الحجم من مجلد فارغ وحتى تسليمه النهائي، وصياغة قواعد CLAUDE.md وتهيئة حدود الأذونات في البداية، ومطالبة Claude بصياغة وثيقة SPEC الفنية وتقسيم مهام المشروع على محادثات متتالية بأمان باستخدام معاملات الجلسة، وربط واستخدام خوادم MCP لجلب البيانات الخارجية وتفويض وكلاء subagents للبحث ومراجعة جودة الأكواد بحيادية، والتراجع السليم عن التعديلات التالفة لحفظ سلامة الأكواد، وإجراء التحقق الفعلي للاختبارات وصياغة التزامات git ودفع التعديلات يدوياً. وبتطبيقك لهذه الدورة الكاملة للتطوير، تكتمل خبرتك العملية وتتحول من التعرف على الميزات البرمجية المنفصلة إلى القدرة على قيادتها معاً لبناء منتجات برمجية متكاملة بنجاح.
بإنهاء هذا المشروع التطبيقي بنجاح، تكون قد اجتزت المرحلة العملية الأهم — وتتحول مهاراتك من العزف الفردي لقيادة الأوركسترا البرمجية الذكية بالكامل.
الدرس القادم 49 "أفضل الممارسات البرمجية" — قمنا في هذا الدرس بتوضيح "كيفية العمل والربط الفعلي للمشروع"؛ الدرس القادم يأخذنا لطبقة أعلى: وهي كيفية ترقية ورفع كفاءة هذا العمل المنجز. حيث نجمع لك خلاصة التجارب والنصائح الفنية وتجارب المطورين في لوحة نصائح سريعة ومباشرة يمكنك الرجوع إليها دائماً. فكر في الأمر: لماذا يستطيع مطور إنجاز المشروع بأربعة توجيهات واضحة وسريعة، بينما يستغرق مطور آخر خمس محاولات وتعديلات مكررة لإنجاز نفس العمل؟ تكمن الإجابة في تفاصيل الممارسات الفنية البسيطة والذكية، وسنعمل في الدرس القادم على فرزها وتوضيحها بالتفصيل لمساعدتك في رفع كفاءتك وسرعتك لأقصى درجة.