أفضل الممارسات: جمع العادات البسيطة في منهجية عمل متكاملة
📚 دليل السلسلة: الدرس السابق 48 المشروع التطبيقي الكامل أخذك في رحلة عملية لربط كل المهارات والميزات التي تعلمتها لبناء مشروع كامل من الصفر. هذا الدرس يرتفع بنا لمستوى جديد — حيث لا نطرح ميزات تقنية جديدة، بل نعلمك "كيفية الاستخدام الفعال للأداة". فبينما يعمل Claude Code بسلاسة مطلقة مع بعض المطورين، يواجه آخرون صعوبات متكررة في إنجاز المهام، ويكمن الفارق في تبني أفضل الممارسات التي صاغتها الوثائق وتجارب المطورين. وسنقوم بجمعها في قواعد عملية جاهزة للتطبيق، مع توفير لوحات مقارنة للممارسات السليمة والخاطئة.
"هذا التوجيه (prompt) يفتقر للتفاصيل تماماً."
تخيل مطوراً مبتدئاً مع الأداة، يكتب في صندوق المدخلات "أصلح خطأ تسجيل الدخول" ويضغط على زر الإرسال، وينتظر ليقوم Claude بتعديل ملفات متعددة وإنتاج أكواد مختلفة تماماً عما يريده، ليتذمر متسائلاً: "ألم تكن جملتي واضحة؟"
ولكن لو قمت بتوجيه هذه الجملة لـ متدرب جديد انضم اليوم للفريق ولا يعرف شيئاً عن مشروعك، فهل يستطيع إصلاح الخطأ؟ أي شاشة لتسجيل الدخول؟ وما هو الخطأ بالتحديد؟ وفي أي ملف برمجي؟ وكيف نتحقق من سلامة الإصلاح؟ — لم تذكر له أي تفصيل من ذلك. لنعد كتابة التوجيه بصياغة سليمة: "يشتكي المستخدمون من فشل تسجيل الدخول بعد انتهاء جلسة العمل (session timeout)، ابدأ بفحص كود تحديث الـ token في مجلد src/auth/ واكتب اختباراً لإعادة إنتاج المشكلة أولاً ثم أصلحه". بمثل هذا التوجيه، ينجح Claude في إتمام المهمة من المحاولة الأولى.
وبالمصطلحات البسيطة، لا يكمن سر نجاح Claude Code في الأداة نفسها، بل في كيفية تواصلك وتوجيهك لها. فالأداة تملك قدرات استثنائية، ولكنها لا تقرأ أفكارك. وسنلخص اليوم أفضل الممارسات الفنية المعتمدة وتجارب المطورين في قواعد عملية يمكنك تبنيها وتطبيقها اليوم.
بعد قراءة هذا الدرس، ستحصل على:
- القيد التقني الأهم الذي يحكم كل الممارسات (سياق المحادثة هو أثمن أصولك)، وبفهمه تتضح لك كل القواعد الأخرى
- خمسة قواعد أساسية: توفير أدوات التحقق، الاستكشاف قبل البناء، صياغة التوجيهات بدقة، اختصار قواعد CLAUDE.md، والتصحيح الفوري للمسار
- لوحات مقارنة لـ "❌ ممارسات خاطئة مقابل ✅ ممارسات سليمة" لتحسين كتابة توجيهاتك فوراً
- دليل لتحديد القاعدة المناسبة لكل سيناريو عمل، مع تجربة عملية للمقارنة والتحقق بنفسك
01 القيد الأساسي: مساحة سياق المحادثة هي أثمن أصولك
ترتبط كل أفضل الممارسات بقيد تقني أساسي واحد، توضحه الوثائق الرسمية في البداية وسنقله لك حرفياً:
تعتمد معظم أفضل الممارسات على قيد تقني أساسي: وهو سرعة امتلاء مساحة سياق المحادثة (context window) لـ Claude، وتراجع مستوى الذكاء والاستنتاج مع تزايد هذا الامتلاء.
تضم مساحة سياق المحادثة (التي تمثل ذاكرة العمل اللحظية لـ Claude) كل تفاصيل جلستك الحالية — كل رسالة أرسلتها، وكل ملف قرأه، ومخرجات كل أمر تم تشغيله. والمشكلة أن هذه المساحة تمتلىء بسرعة كبيرة: فجلسة فحص أخطاء متوسطة، أو مطالبته بقراءة ملفات المشروع، كفيلة باستهلاك عشرات الآلاف من التوكنز (وقد شرحنا التوكنز وسياق المحادثة في الدرس 19).
وبمجرد امتلاء هذه المساحة، يقل تركيز وذكاء Claude — فينسى شروطك السابقة، ويقع في أخطاء بدائية وبسيطة.
تشبيه: تفويض متدرب جديد للعمل ولكن ذاكرته تقتصر على سبورة بيضاء محدودة المساحة. هذا المتدرب ذكي جداً وسريع الحركة، ولكنه يواجه مشكلة: فذاكرته هي سبورة بيضاء محددة المقاس، وكل توجيه تقوله له، وكل ورقة يقرأها، وكل نتيجة أمر يفحصها، يجب أن تكتب على هذه السبورة. وبمجرد امتلاء السبورة بالكتابة، يبدأ في النسيان وتداخل الأمور — فالتنبيه الذي قلته له صباحاً بـ "ضرورة تشغيل الاختبارات قبل حفظ التعديلات" يمسح من السبورة ليحل محله تفاصيل فحص الأكواد ظهراً، لينسى تشغيل الاختبارات عصراً.
وسنكرر هذا التشبيه كثيراً في هذا الدرس — لأن جوهر القواعد التالية ينصب على كيفية مساعدة هذا المتدرب في "حفظ وتوفير مساحة سبورته البيضاء":
- نوفر له طرقاً ذاتية للتحقق، لتجنب التدخل البشري المتكرر (مما يوفر وقتك ويمنع تراكم التنبيهات على السبورة)؛
- نطلب منه الاستكشاف أولاً قبل كتابة الكود، لتجنب ملء السبورة بتعديلات خاطئة ناتجة عن افتراضات غير صحيحة؛
- نصيغ التوجيهات بدقة ووضوح من المرة الأولى، لتفادي جولات الأسئلة المتكررة التي تستهلك المساحة؛
- نختصر قواعد 便签 (المذكرات الثابتة) المكتوبة له، لئلا تبدأ السبورة وهي ممتلئة بنصوص غير ضرورية؛
- نقوم بتصحيح مساره فور انحرافه، لتفادي امتلاء السبورة بمحاولات تصحيح خاطئة.
تذكر هذا القيد الأساسي دائماً، لتكتشف أن القواعد الخمسة الأولى تسعى لهدف واحد — وهو "توفير مساحة السبورة للمتدرب الذكي". وبمجرد إتقان قيادة المتدرب الواحد، تأتي القاعدة السادسة المتمثلة في: الاستعانة بمتدربين متعددين بالتوازي.
💡 خلاصة القول في جملة واحدة: تمتلئ مساحة سياق المحادثة بسرعة ويتراجع ذكاء Claude عند امتلائها، ولذلك تمثل أثمن أصولك التي يجب حمايتها؛ وتهدف كل القواعد لتوفير مساحة الذاكرة المؤقتة للوكيل ليعمل بأعلى ذكاء ممكن.
02 القاعدة الأولى: توفير أدوات تحقق ذاتية للوكيل
الخلاصة أولاً، وتمثل هذه القاعدة الأهم على الإطلاق:
وفر لـ Claude وسيلة للتحقق الذاتي من عمله — مثل اختبارات، أو عمليات بناء، أو لقطات شاشة للمقارنة. ويمثل هذا الفارق بين "المحادثة التي تضطر لمراقبتها طوال الوقت" و "المحادثة التي تتركها وتذهب لإنجاز مهام أخرى".
ولماذا تعتبر هذه القاعدة حاسمة؟ تجيب الوثائق الرسمية عن ذلك بدقة:
يتوقف Claude عن العمل بمجرد ظهور مؤشرات تفيد بانتهاء المهمة. وعند غياب وسائل التحقق التلقائية، يمثل "ظهور النص بشكل مكتمل" الإشارة الوحيدة له للتوقف، لتتحول أنت بنفسك لصمام التحقق وتستهلك وقتك.
بالمصطلحات البسيطة: إذا لم توفر له طريقة للتحقق، فستضطر للقيام بالتحقق والمراجعة بنفسك — ومع كل خطأ يقع فيه، يجب أن تكتشفه بعينك وتوجهه للتصحيح. لتتحول من دور "الموجه للمشروع" لدور "المراجع والمصحح للأخطاء" طوال الوقت. ولكن بمجرد تزويده بأمر يخرج نتيجة صريحة بـ "نجاح / فشل"، تكتمل دائرة العمل تلقائياً: يكتب الكود، يشغل أداة التحقق، يقرأ النتيجة، ويصحح الأكواد بنفسه عند الفشل حتى ينجح التحقق.
تشبيه: تسليم أعمال التشطيب لعمال البناء بالاعتماد على قائمة استلام. عند استئجار عمال لتشطيب المنزل، تخشى مغادرتهم بالاعتماد على "شعورهم بأن العمل اكتمل" — لتكتشف لاحقاً عيوباً في التوصيلات الكهربائية أو تركيب البلاط لم ينتبهوا لها، وتضطر للتدخل والتصحيح. ولكن لو سلمتهم في البداية قائمة استلام محددة بأدوات فحص (مثل "فحص كل مقبس بجهاز الفحص وتأكيد الإضاءة، وقياس استواء البلاط بالميزان")، فسيقومون بالفحص الذاتي وإصلاح العيوب قبل تسليم العمل لك. وتمثل "أدوات التحقق التلقائية" قائمة الاستلام هذه لـ Claude.
ما هي الأدوات التي يمكن استخدامها للتحقق؟ توفر الوثائق قائمة من الأدوات التي ترجع نتائج واضحة يستطيع Claude قراءتها وفهمها:
- مجموعات فحص الاختبارات (Test suites) (الخيار الأكثر استخداماً، حيث توضح نجاح أو فشل الفحوصات مباشرة)
- أكواد الخروج لعمليات البناء (Build exit codes) (تؤكد نجاح أو فشل البناء والترجمة للأكواد)
- أدوات فحص جودة الأكواد (Linters) (تتحقق من الالتزام بالمعايير الفنية وتناسق الأكواد)
- سيناريوهات مقارنة المخرجات مع نتائج مرجعية ثابتة
- لقطات شاشة للمتصفح لمقارنتها بالتصاميم المعتمدة (وهو ما شرحناه في الدرس 17 لمطابقة واجهات UI)
وكيف نكتب ذلك داخل التوجيه prompt؟ ننصحك بحفظ واستخدام لوحة المقارنة التالية المأخوذة من الوثائق:
| سيناريو العمل | ❌ غياب أداة التحقق | ✅ توفير أداة التحقق |
|---|---|---|
| كتابة دالة برمجية | "اكتب دالة للتحقق من سلامة البريد الإلكتروني" | "اكتب دالة validateEmail؛ وتأكد من الحالات التالية: القبول لـ user@example.com والرفض لـ invalid و user@.com. وبعد الانتهاء شغّل الاختبارات البرمجية للتأكد" |
| تعديل واجهة UI | "حسن مظهر لوحة التحكم لتصبح أجمل" | "[أرفق لقطة شاشة] عدل الواجهة لتتطابق مع التصميم. وبعد التعديل خذ لقطة شاشة وقارنها بالتصميم البرمجي واعرض الفروق ثم أصلحها" |
| إصلاح أخطاء البناء | "فشلت عملية بناء الكود" | "تفشل عملية البناء مع الخطأ التالي: [أرفق نص الخطأ]. أصلح الخلل و تأكد من نجاح عملية البناء الفعلي. وعالج السبب الأساسي للخطأ وتجنب كتم التحذيرات" |
هل لاحظت الفارق بين العمودين؟ في العمود الأيسر، يتوقف Claude بمجرد "شعوره" بانتهاء المهمة؛ بينما ينتهي كل توجيه في العمود الأيمن بـ أداة فحص آلية يشغلها بنفسه ويقرأ نتيجتها.
وتتفاوت قوة وسائل التحقق بحسب الأهمية ودقة العمل، وتتلخص في ثلاثة مستويات:
| مستوى الإلزام | كيفية التهيئة | السيناريو الأنسب |
|---|---|---|
| داخل التوجيه اللحظي | كتابة جملة "شغل الاختبارات وتأكد من نجاحها" في نهاية التوجيه مباشرة | للمهام اليومية المعتادة والبسيطة (الخيار الأسهل) |
| طوال محادثة العمل | تحديد الهدف عبر أداة /goal ليقوم بإعادة الفحص تلقائياً في كل جولة | لضمان بقاء الوكيل ملتزماً بهدف عام دون الانحراف عنه |
| صمامات أمان صارمة | صياغة خطاف Stop hook يمنع إنهاء المهمة عند فشل الفحص | لأتمتة العمليات دون مراقبة بشرية (الدرس 33) |
ويكفي استخدام المستوى الأول للمبتدئين — إضافة جملة "وبعد الانتهاء شغل الاختبارات للتأكد" في نهاية التوجيه prompt لتلاحظ الفارق الفوري. وتترك المستويات الأخرى لأتمتة العمليات المتقدمة.
ونؤكد على التنبيه الرسمي الصارم بـ "معالجة السبب الأساسي للخطأ وتجنب كتم التحذيرات" — ويتطابق هذا مع القاعدة البرمجية الذهبية: تجنب تجميد أو إخفاء رسائل الخطأ لمجرد تمرير عملية البناء. فمن الأخطاء الشائعة مطالبة Claude بـ "تجاوز خطأ النوع المكتوب"، ليقوم بتحويل نوع المتغير لـ any في لغة TypeScript، لتختفي رسالة التحذير ظاهرياً وتدفن المشكلة الحقيقية في عمق الكود البرمجي. والممارسة السليمة هي كتابة "أصلح الخلل من جذوره وتجنب كتم التحذيرات" في التوجيه دائماً.
ونضيف ممارسة ذكية أخرى: مطالبة Claude بعرض أدلة النجاح الفعلية وتجنب الاكتفاء بالوعود الشفهية.
وجه Claude دائماً لعرض أدلة النجاح الملموسة بدلاً من الاكتفاء بعبارة "تم بنجاح": مثل عرض مخرجات الاختبارات، أو سجل الأوامر التي تم تشغيلها ونتائجها، أو لقطة شاشة للواجهة بعد التعديل.
فقراءة تقرير الاختبارات المعروض في نافذة المحادثة أسرع بكثير من تشغيله يدوياً للتأكد — ويمثل هذا الخيار الضمانة الوحيدة لموثوقية العمل في السيناريوهات الآلية التي تعمل دون وجودك.
💡 خلاصة القول في جملة واحدة: تزويد Claude بأداة تحقق آلية (اختبارات / بناء / لقطات شاشة) يتيح له الفحص الذاتي وتصحيح أخطائه تلقائياً؛ واحرص على إنهاء توجيهاتك بجملة "شغّل الاختبارات وتأكد من النجاح" لتتحول من دور المراجع لدور الموجه الفعلي للمشروع.
03 القاعدة الثانية: الاستكشاف أولاً، ثم التخطيط، والبدء في البناء أخيراً
تعالج القاعدة الثانية مشكلة "انحراف وتخريب الأكواد البرمجية".
يؤدي دفع Claude للبدء الفوري في كتابة الأكواد لإنتاج حلول خاطئة لمشاكل لم تكن مقصودة في الأساس. واحرص على الفصل التام بين مرحلتي "الاستكشاف وصياغة الخطة" و "الكتابة البرمجية الفعلية".
وتقترح الوثائق الرسمية دورة عمل تتكون من أربع خطوات متتالية، سنوضحها بتشبيه المتدرب المذكور سابقاً لتسهيل الفهم:
يوضح هذا الرسم دورة التطوير المعتمدة: مرحلتان للتفكير والدراسة على اليسار، ومرحلتان للكتابة والحفظ على اليمين، ويمثل الخط الرأسي الفاصل (الخروج من وضع Plan Mode) صمام الانتقال من "التفكير" إلى "التنفيذ".
ولماذا يجب الفصل بين مرحلتي الاستكشاف والبناء؟ تفكر في الأمر — لن تطلب من المتدرب الجديد تعديل كود وحدة برمجية حساسة دون أن يتصفح المجلدات ويقرأ الأكواد أولاً. بل ستطلب منه أولاً قراءة الكود، وطرح الأسئلة، وفهم طريقة الترابط (وهذا هو الاستكشاف)، ثم شرح خطة التعديل المقترحة (وهذا هو التخطيط)، لتبدأ مرحلة الكتابة الفعلية بعد موافقتك. ويعمل Claude بنفس الطريقة، ويوفر وضع Plan Mode (وضع التخطيط، وهو وضع مخصص للقراءة والتحليل دون تعديل الملفات، وشرحناه بالتفصيل في الدرس 35) البيئة المناسبة لهذه الدراسة.
وفي مرحلة الاستكشاف، استعن بوضع Plan Mode لتوجيه الأسئلة كالتالي (توافقاً مع الأمثلة الرسمية):
读一下 src/auth 目录，搞清楚我们怎么处理 session 和登录。
顺便看看 secret 这类环境变量是怎么管的。ليقوم بالقراءة والتحليل دون المساس بالملفات ويعرض لك النتائج. وبعدها اطلب منه صياغة الخطة الفنية:
我想加 Google OAuth。哪些文件要改？session 流程是怎样的？给我一份计划。وإذا لاحظت خطأ في الخطة المعروضة، فاضغط على الاختصار Ctrl+G لفتح الخطة وتعديلها يدوياً لتصحيح المسار قبل البدء. وعند الاطمئنان للخطة، اخرج من وضع Plan Mode واطلب منه البدء في الكتابة الفعلية — وتذكر توفير أداة التحقق كما أوضحنا في القاعدة الأولى.
ولكن تنبه الوثائق الرسمية بوضوح: لا تبالغ في استخدام وضع Plan Mode للمهام البسيطة، لتفادي إضاعة الوقت وتكلفة التوكنز.
للمهام واضحة المعالم وصغيرة الحجم (مثل تصحيح خطأ إملائي، إضافة سطر سجل أخطاء، أو إعادة تسمية متغير)، اطلب من Claude البدء الفوري في التنفيذ دون تخطيط مسبق.
وتوفر الوثائق قاعدة ذهبية بسيطة للموازنة واختيار القرار المناسب يومياً:
إذا كنت تملك القدرة على صياغة التعديل (diff) المتوقع في جملة واحدة صريحة، فتجاوز مرحلة التخطيط وابدأ بالعمل مباشرة.
فتصحيح كلمة، أو إضافة سطر طباعة، أو تبديل اسم متغير — هي مهام واضحة تحدد مخرجاتها بجملة واحدة، ومطالبته بالتخطيط لها هو تعقيد غير مبرر. وبالعكس، إذا كان مسار الحل غير واضح، أو يتطلب تعديل عدة ملفات متداخلة، أو تتعامل مع كود برمجى لم تقرأه سابقاً — فالفصل والاستكشاف أولاً هو الخيار الصحيح والآمن. ونقترح قاعدة فاصلة: قراءة وحدة برمجية جديدة، أو توقع تعديل أكثر من ثلاثة ملفات برمجية متداخلة يتطلب تفعيل وضع Plan Mode أولاً؛ وتجاوز التخطيط فيما عدا ذلك.
💡 خلاصة القول في جملة واحدة: عند تشابك الأكواد أو تعديل ملفات متعددة، استخدم وضع Plan Mode للاستكشاف وصياغة الخطة أولاً ثم ابدأ بالبناء؛ وتجاوز التخطيط للمهام البسيطة التي تصوغ مخرجاتها بجملة واحدة؛ فالقاعدة الذهبية هي "جملة واحدة للـ diff تعني العمل المباشر".
04 القاعدة الثالثة: صياغة التوجيهات بدقة وتجنب الجمل العائمة
ترتبط هذه القاعدة بقصة المبرمج المبتدئ المذكورة في البداية. وتتلخص في قاعدة واحدة:
كلما كانت تعليماتك وتوجيهاتك دقيقة ومحددة، تراجعت الحاجة لطلب التعديل والتصحيح اللاحق. فرغم قدرة Claude العالية على استنتاج السياق، إلا أنه يعجز عن قراءة أفكارك.
وتساعدك ممارسات: تحديد أسماء الملفات، وصياغة القيود الفنية، والإشارة لأمثلة سابقة في رفع جودة ووضوح التوجيه prompt بشكل ملحوظ. وسنفصل في لوحة المقارنة التالية المأخوذة من الوثائق (وقد شرحنا مبادئ صياغة التوجيهات في الدرس 15، ونركز هنا على مفهوم "الدقة والتحديد"):
| أسلوب التوجيه | ❌ توجيه عائم وغير محدد | ✅ توجيه دقيق ومحدد |
|---|---|---|
| تحديد النطاق والقيود (الملف، الحالات الخاصة، والأسلوب) | "اكتب اختبارات لملف foo.py" | "اكتب اختبارات لملف foo.py؛ وتأكد من تغطية حالة خروج المستخدم (logout)، وتجنب استخدام المكونات الوهمية (mock) تماماً" |
| توجيه مصادر المعلومات (قصر البحث وتسهيله) | "لماذا تبدو الواجهة البرمجية لـ ExecutionFactory غريبة؟" | "راجع سجل تاريخ git لملف ExecutionFactory، ولخص مراحل تطور الواجهة البرمجية لتصل لشكلها الحالي" |
| محاكاة الأنماط السابقة (محاكاة كود المستودع) | "أضف مكون التقويم للمشروع" | "راجع طريقة بناء المكونات الحالية في المشروع، ويمثل ملف HotDogWidget.php نموذجاً ممتازاً. وبناءً على هذا النمط اكتب مكون التقويم ليتيح اختيار الأشهر والسنوات وتجنب استدعاء مكتبات خارجية" |
| وصف الأعراض والأهداف (تحديد ملامح الحل) | "أصلح عطل تسجيل الدخول" | "يشتكي المستخدمون من فشل تسجيل الدخول بعد انتهاء جلسة العمل. تفحص كود التوثيق في src/auth/ وخصوصاً كود تحديث الـ token. واكتب اختباراً لإعادة إنتاج المشكلة أولاً ثم أصلحه" |
تأمل تفاصيل العمود الأيسر لتكتشف إضافة قيود فنية واضحة ومحددة بعد صياغة المهمة الأساسية — مثل كتابة أسماء الملفات بدقة، وتحديد حالات الفحص، والإشارة لملف مرجعي للمحاكاة، وصياغة ملامح نجاح الحل. وهي تفاصيل تحمي الوكيل من التشتت وتوفر مساحة ذاكرته.
وننصح بالاهتمام بممارسة "محاكاة الأنماط السابقة". فكثيراً ما يقع المطور في فخ مطالبة Claude بـ "إضافة ميزة تصدير البيانات لصيغة CSV"، ليقوم بكتابة كود صحيح تقنياً ولكنه يعتمد على أسلوب ومكتبات تختلف تماماً عن الأسلوب المتبع في بقية ملفات المشروع، بل وقد يستدعي حزمة خارجية لم تكن مستخدمة، مما يضطر لإعادة الهيكلة وتوحيد الأسلوب يدوياً. وتُحل المشكلة بكتابة جملة بسيطة في التوجيه: "راجع ملف XXX.ts لرؤية أسلوب التصدير المتبع، واكتب الكود الجديد محاكياً لنفس النمط ودون استخدام مكتبات خارجية". وبكتابة هذه الجملة، يلتزم بكتابة كود متناسق تماماً مع بقية المستودع البرمجي ويوفر عليك عناء المراجعة والتعديل. فـ الإشارة لمثال سليم في المستودع أفضل بكثير من كتابة عشر أسطر تصف فيها الأسلوب المفضل لديك.
ولكن تشير الوثائق الرسمية لحالة خاصة ومفيدة للتوجيهات العائمة:
يمثل التوجيه العائم خياراً ممتازاً في مراحل الاستكشاف والبحث الأولية عندما ترغب في تلقي مقترحات وأفكار متنوعة لتوجيه مسار عملك لاحقاً.
فطرح سؤال مثل "كيف تقترح تحسين هذا الملف البرمجي؟" يفتح الباب لتلقي أفكار وملاحظات برمجية ذكية قد تغيب عن ذهنك تماماً. ولذلك اعتمد على "الدقة والتحديد" كخيار افتراضي لعملك، واستخدم "الأسلوب العائم" للاستكشاف والعصف الذهني الأولي فقط.
تزويد الوكيل بالمعلومات والبيانات الكافية للعمل
لا تقتصر الدقة على الكلمات المكتوبة فقط، بل تشمل توفير الملفات والبيانات اللازمة للعمل البرمجي. وتوفر الوثائق عدة طرق لتمرير البيانات (شرحناها بالتفصيل في الدرس 17)، ونلخصها في هذه اللوحة السريعة:
- استخدام رمز
@للإشارة للملفات، بدلاً من كتابة مسار الملف نصياً. وتسهل هذه الطريقة اختيار الملف وقراءته مباشرة من الوكيل قبل الإجابة. - إرفاق الصور لقطات الشاشة: لقطات شاشة الأخطاء، أو لقطات التصاميم الفنية، انسخها والصقها أو اسحبها لداخل نافذة المحادثة مباشرة (فزيارة الطبيب تتطلب إرفاق صور الأشعة لتسهيل الفحص ولا يكتفي الطبيب بوصفك الشفهي للألم).
- إرفاق روابط المواقع والتوثيق (URLs): روابط التوثيق الفني للمكتبات أو واجهات API. ويمكنك إضافة نطاقات المواقع لقائمة المسموحات الآمنة عبر
/permissionsلتفادي رسائل طلب الإذن. - تمرير البيانات عبر الأنابيب (Pipelines): تشغيل أمر مثل
cat error.log | claudeلتمرير سجل الأخطاء مباشرة لبيئة العمل. - توجيه الوكيل لجلب البيانات بنفسه: مطالبته بـ "شغل أوامر bash أو خوادم MCP لجلب السياق والبيانات اللازمة للملف الحالي"، ليتولى هو إنجاز العمل.
💡 خلاصة القول في جملة واحدة: التزم بكتابة توجيهات دقيقة ومحددة تماثل ما توجهه لمهندس زميل في العمل — حدد أسماء الملفات، وافرض القيود الفنية، وأشر لأمثلة سابقة للمحاكاة، وحدد ملامح النجاح؛ ووفر البيانات اللازمة عبر
@والصور والروابط؛ واستخدم التوجيهات العائمة للعصف الذهني الأولي فقط.
05 القاعدة الرابعة: اختصار وثيقة CLAUDE.md والتركيز على القواعد الاستثنائية
تمثل مراجعة قواعد وصياغة وثيقة CLAUDE.md ركيزة أساسية لأفضل الممارسات. وقد شرحنا قواعد صياغتها ومسار حفظها في الدرس 18، وسنركز في هذا القسم على قاعدة هامة جداً: الاختصار والتركيز أهم بكثير من الشمول والتفصيل.
تذكر وظيفة وثيقة CLAUDE.md دائماً — فهي أول ورقة يقرأها Claude تلقائياً مع بدء كل محادثة جديدة، وتضم المعلومات الثابتة التي يصعب استنتاجها من الكود (أوامر البناء، أساليب الفحص، وقواعد سير عمل git). ويمكنك الاستعانة بأمر /init لبناء المسودة الأولى للوثيقة (الدرس 12).
تشبيه: ورقة التنبيهات المتروكة لزميلك المناوب. قبل مغادرة العمل، تترك لزميلك ورقة تنبيهات صغيرة تكتب فيها "سيتوقف الخادم تلقائياً عند منتصف الليل لإجراء الصيانة فلا تقلق" و "يرجى تقديم طلبات العميل A أولاً" — بضعة تنبيهات هامة ومحددة يقرأها ويحفظها في ثوانٍ. ولكن لو قمت بنسخ دليل الصيانة الكامل للشركة ولصقته في الورقة وتغطية الحائط بها، فستكون النتيجة تجاهله للورقة بالكامل لضخامتها، وتضيع التنبيهات الهامة التي أردت إيصالها. وتمثل وثيقة CLAUDE.md ورقة التنبيهات هذه: وقيمتها تكمن في قصرها لتُقرأ بالكامل، وليست في ضخامتها.
وهذا ليس تخميناً، بل تحذير رسمي صارم تؤكد عليه الوثائق:
حافظ على الاختصار والتركيز. ومع كل سطر تكتبه، اسأل نفسك: "هل يؤدي حذف هذا السطر لوقوع Claude في خطأ برمجى؟" وإذا كانت الإجابة لا فاحذفه فوراً. فالملفات الضخمة والمكتظة لـ CLAUDE.md تشتت تركيز Claude وتجعله يتجاهل توجيهاتك المباشرة في المحادثة!
ويتكرر الخطأ في صياغة الوثيقة بأسلوبين خاطئين. الأول: كتابة تفاصيل تاريخية وفلسفية حول هندسة بناء المشروع ونية التصميم لـ "تسهيل فهم الوكيل للخلفية الفنية"، لتصل الوثيقة لمئة سطر مكتظة بالتفاصيل. وتضيع القواعد الفنية الهامة (مثل "تجنب تعديل ملفات تهجير قاعدة البيانات") وسط هذا الوصف التاريخي — بالرغم من قدرة الوكيل على فهم الخلفية الفنية بمجرد قراءة ملفات الكود البرمجي الفعلي دون حاجة لوصفها يدوياً. والأسلوب الآخر: حشر قواعد تفصيلية تخص كتابة نوعية معينة من الواجهات البرمجية وتستخدم نادراً داخل وثيقة CLAUDE.md، مما يعادل مطالبته بحفظ وثيقة غير مرتبطة بعمله اليومي وتستهلك مساحة الذاكرة بلا طائل. والتصرف السليم لهاتين الحالتين يتوافق مع التوجيه الرسمي — حذف الوصف التاريخي بالكامل (سيفهمه بقراءة الكود)، ونقل القواعد المتخصصة النادرة لملف مهارة Skill مستقل (الدرس 26)؛ وبتقليص حجم وثيقة CLAUDE.md وتركيزها، يرتفع التزام Claude بالقواعد المكتوبة بشكل ملحوظ.
ولفرز القواعد وتحديد ما يجدر كتابته أو حذفه، التزم بجدول المراجعة المعتمد من الوثائق:
| ✅ قواعد يجدر كتابتها وحفظها | ❌ تفاصيل يجب تجنبها وحذفها |
|---|---|
| أوامر bash والتشغيل التي يصعب استنتاجها | التفاصيل التي تتضح بمجرد قراءة الكود البرمجي للمستودع |
| أساليب وقواعد كتابة الكود التي تختلف عن الأسلوب المعتاد | القواعد والاتفاقيات القياسية للغات البرمجة (يفهمها تلقائياً) |
| أوامر تشغيل الاختبارات وأدوات الفحص المفضلة | وثائق واجهات API التفصيلية (واستبدلها بإرفاق الروابط) |
| سير عمل المستودع (طريقة تسمية الفروع وطلبات السحب) | البيانات السريعة والتفاصيل التقنية المتغيرة باستمرار |
| القرارات الهندسية والهيكلية الخاصة بالمستودع | الشروحات الطويلة والدروس التعليمية للأدوات |
| المتغيرات البيئية وشروط تشغيل بيئة التطوير المحلية | الجمل العامة غير المفيدة مثل "اكتب كوداً نظيفاً ومنظماً" |
| الحالات الخاصة والتصرفات غير المعتادة لبعض الملفات | وصف هيكل المستودع ووظيفة كل مجلد بالتفصيل |
ويتميز العمود الأيسر بقاعدة عامة: كل ما يستطيع Claude فهمه بمفرده، أو البيانات سريعة التغير، أو العبارات العامة التي لا تقدم توجيهاً فنياً محدداً — يجب مسحها وتطهير الوثيقة منها.
وتوفر الوثائق ممارستين متقدمتين لتهيئة الوثيقة:
- لتأكيد أهمية وضرورة الالتزام بقاعدة معينة، استخدم كلمات تأكيد مثل
IMPORTANTأوYOU MUST(وستلاحظ استخدام كلمة IMPORTANT لتأكيد الشروط في ملف CLAUDE.md الخاص بمشروعنا الحالي). - تدعم وثيقة CLAUDE.md استدعاء وربط ملفات خارجية باستخدام صيغة
@Path، مثل كتابةGit workflow: @docs/git-instructions.mdلتفصيل الخطوات في ملف خارجي والحفاظ على اختصار وثيقة CLAUDE.md الرئيسية.
ونختم بـ طريقة التشخيص العكسي الفعالة والمقترحة من الوثائق: إذا لاحظت تكرار تجاهل Claude لقاعدة معينة بالرغم من كتابتها، فاعلم أن ملف CLAUDE.md ضخم جداً ويحتوي على حشو يشتت تركيزه؛ وإذا سألك عن تفصيل مكتوب بالفعل، فاعلم أن صياغة القاعدة غير واضحة وتحتاج لإعادة صياغة. تعامل مع ملف CLAUDE.md كوداً برمجياً يحتاج للتنظيف والتقليص والتحديث المستمر لتضمن فاعليته.
💡 خلاصة القول في جملة واحدة: تعتمد قوة وثيقة CLAUDE.md على اختصارها وتركيزها وليس ضخامتها — وتجنب كتابة ما يستطيع فهمه بمفرده، وانقل التفاصيل المتخصصة لملفات المهارات Skills، واكتفِ بالقواعد الاستثنائية لتبقيها قصيرة ومقروءة بالكامل.
06 القاعدة الخامسة: التدخل الفوري لتصحيح المسار وتجنب الاستمرار في سياق خاطئ
ترتبط القاعدة الخامسة بكيفية إدارة وتوجيه جلسة المحادثة الحالية. وتتلخص في قاعدة أساسية:
بمجرد ملاحظة انحراف Claude أو تبنيه لمسار خاطئ، سارع بإيقافه وتصحيح مساره فوراً وتجنب تركه يستمر في العمل الخاطئ. فالجلسات مرنة وتتيح لك العودة للخلف — فاستغل هذه الميزة.
تتحقق أفضل نتائج التطوير عبر التقييم الفوري والتغذية الراجعة المستمرة. فبالرغم من قدرة Claude على إنجاز المهام من المحاولة الأولى أحياناً، إلا أن التدخل السريع لتعديل مساره يوفر عليك الوقت والتوكنز مقارنة بتركه يكمل البناء الخاطئ ثم هدمه وإعادة البناء مجدداً. وتوفر الأداة مجموعة من وسائل التدخل الفوري:
| الهدف من التدخل | كيفية تنفيذه تقنياً | أسلوب الاستخدام العملي |
|---|---|---|
| إيقاف التشغيل الفوري | ضغط مفتاح Esc لمرة واحدة | عند ملاحظة قراءته لملف خاطئ أو البدء في كتابة أوامر غير مقصودة، لإيقافه وحفظ السياق |
| العودة والتراجع للوراء | ضغط Esc مرتين متتاليتين أو كتابة أمر /rewind | عند تخريب الكود أو تداخل التعديلات، للعودة لآخر نقطة برمجية سليمة ومجربة (الدرس 37) |
| التراجع عن التعديل الأخير | كتابة توجيه "تراجع عن التعديل الأخير" | أسرع بكثير من تصحيح الأسطر وإعادتها يدوياً |
| تصفية وإعادة تهيئة الجلسة | كتابة أمر /clear في المحادثة | عند انتهاء مهمة برمجية والرغبة في البدء في مهمة جديدة مستقلة لتطهير السياق |
وننبه لـ القاعدة الفنية الصارمة التي يتفق عليها خبراء الأداة وتؤكد عليها الوثائق بوضوح:
إذا قمت بتوجيه وتصحيح مسار Claude لأكثر من مرتين متتاليتين دون جدوى لنفس المشكلة، فاعلم أن سياق المحادثة قد تلوث تماماً بمحاولات الحل الخاطئة المتراكمة. وشغّل أمر
/clearلتصفية السياق، وابدأ محادثة جديدة نظيفة مع صياغة توجيه دقيق يضم الدروس الفنية التي تعلمتها من المحاولات السابقة.
بمعنى آخر: إذا فشلت المحاولة الثالثة للتصحيح، فتجنب خوض المحاولة الرابعة في نفس المحادثة. فذاكرة المحادثة (السبورة البيضاء) امتلأت بعبارات "هذا الحل لم ينجح، وجربنا الأسلوب الآخر ولم ينجح"، مما يشتت تركيز Claude ويجعله يكرر الأخطاء. والتصرف الصحيح والذكي هو كتابة /clear للبدء من جديد — مع كتابة توجيه جديد يوضح القيود التي كشفتها المحاولات السابقة (مثل "تجنب استخدام الأسلوب X، واحرص على معالجة المشكلة من الزاوية Y").
إن البدء في محادثة نظيفة بتوجيه دقيق ومهيأ، أفضل بكثير من الاستمرار في محادثة طويلة مكتظة بمحاولات التصحيح المتعارضة.
وقد عانيت شخصياً قبل تبني هذه القاعدة. ففي إحدى جولات فحص خطأ في إدارة حالة البرنامج، استمريت في توجيهه وتصحيحه لخمس مرات متتالية في نفس الجلسة، لتتعارض التعديلات وتتشابك الأكواد بشكل غريب عجزت عن فهمه بنفسي. لتُحل المشكلة بمجرد كتابة أمر /rewind للعودة لنقطة البداية وتشغيل /clear لتصفية الجلسة، وصياغة توجيه جديد يحدد المشكلة بدقة — لينجح Claude في إصلاح الخطأ في جولتين فقط، وتذهب ساعات المحاولات السابقة هباءً. ومنذ ذلك اليوم، التزمت بهذه القاعدة الصارمة: إذا تطلب التصحيح أكثر من ثلاث محاولات متتالية، تصفى المحادثة /clear ونبدأ من جديد.
ممارستان إضافيتان لحفظ ونظافة سياق المحادثة
ونضيف ممارستين رسميتين لحفظ مساحة ذاكرة المحادثة نظيفة (وتتوافق مع إدارة السياق في الدرس 19):
- تفويض المهام الاستكشافية للوكلاء subagents: توجيهه بـ "استعن بـ subagent لفحص وتفحص الملف X". ليقوم بالبحث والقراءة داخل سياق منفصل وخاص به، ويعود للمحادثة الرئيسية بالخلاصة فقط، لتبقى مساحة سياق محادثتك الرئيسية نظيفة (الدرس 23 بالتفصيل). وتؤكد الوثائق: "نظراً لكون سياق المحادثة هو القيد التقني الأهم لك، يبرز تفويض الوكلاء subagents كأقوى أداة لتخطي هذا القيد".
- تسمية ومتابعة المحادثات: استخدام معامل
claude --continueللمتابعة السريعة لآخر جلسة، أوclaude --resumeلاختيار جلسة معينة من القائمة. وقم بتسمية جلساتك بأسماء معبرة (مثلoauth-migration)، وتعامل مع المحادثات كأنها فروع git مستقلة لتسهيل العودة والمتابعة عند الحاجة.
💡 خلاصة القول في جملة واحدة: سارع بإيقاف العمل عبر
Escأو التراجع بـ/rewindفور انحراف الوكيل؛ وإذا تجاوزت محاولات التصحيح ثلاث مرات متتالية، فشغل أمر/clearلتصفية الجلسة والبدء من جديد بتوجيه منظم؛ وتجنب تلويث السياق بمحاولات الحل الخاطئة المتراكمة.
07 القاعدة السادسة: إتقان عمل الوكيل الفردي أولاً، ثم التوسع في العمل الجماعي والتوازي
تقتصر القواعد الخمس السابقة على سيناريو "مطور واحد يتعامل مع وكيل واحد في محادثة واحدة". ولكن بمجرد إتقان قيادة الوكيل الفردي، توفر المنصة أدوات للتوسع والتوازي تضاعف الإنتاجية عدة مرات. وقد شرحنا تفاصيل تشغيل هذه المهام في الدرس 41 (المهام المتوازية) والدرس 44 (GitHub Actions)، وسنشير لملامحها الأساسية هنا.
احرص على إتقان قيادة الوكيل الواحد أولاً قبل التفكير في التوازي. فالترتيب هام جداً — فالعجز عن قيادة وكيل واحد يعني مضاعفة الفوضى والأخطاء لخمس مرات عند تشغيل خمسة وكلاء معاً.
وتتوزع خيارات التوسع والعمل الجماعي كالتالي:
تشغيل محادثات متعددة بالتوازي: تقسيم المهام المستقلة وتشغيل محادثة مستقلة لكل منها. وتتمثل أفضل طريقة لعزل التعديلات ومنع تعارض الملفات في استخدام بيئات عمل git المستقلة (worktree)، أو إدارة الجلسات بصرياً عبر تطبيق سطح المكتب أو نسخة الويب.
توزيع الأدوار بين كاتب ومراجع (Writer / Reviewer): وهي ممارسة فنية ممتازة ننصح بتبنيها. حيث تخصص محادثة A لكتابة الأكواد، وتفتح محادثة B نظيفة ومستقلة لتتولى مراجعة وتقييم الأكواد التي كتبتها المحادثة A. ويكمن سر الميزة في — خلو ذاكرة المحادثة B من افتراضات كاتب الكود، مما يمنعها من الانحياز للأكواد المكتوبة ويجعلها تكشف العيوب وال边界 بنشاط ودقة تفوق التقييم الذاتي. وتوضح الوثائق ذلك:
ترفع المحادثة النظيفة من جودة مراجعة الأكواد، لخلوها من الانحياز للأكواد التي تمت كتابتها للتو في سياق المحادثة المجاورة.
تشغيل الأوامر والسيناريوهات البرمجية غير التفاعلية: استخدام أمر
claude -p "التوجيه"لتلقي المخرجات مباشرة دون فتح جلسة تفاعلية، ويمثل هذا الخيار مدخل ربط Claude ببيئات البناء المستمر CI، أو خطافات pre-commit، أو نصوص الأتمتة البرمجية. واستخدم خيار--output-format jsonلتلقي مخرجات منظمة قابلة للفرز البرمجي، وخيار--verboseلتفصيل سجل العمليات. فعند الرغبة في تحديث ملفات متعددة، يمكنك تشغيل حلقة تكرارية برمجية تمرر كل ملف لأمرclaude -pمع تحديد الأسلوب والحدود الفنية للأدوات عبر--allowedToolsلضمان حماية وسلامة العمليات التلقائية.إجراء مراجعة نهائية فاحصة: كلما طالت أتمتة العمليات التلقائية دون وجودك، تزايدت أهمية مطالبة وكيل فرعي subagent نظيف ومستقل بفحص ومراجعة الفروق (diff) النهائية قبل تسليم العمل. ويوفر أمر مراجعة الأكواد المدمج
/code-reviewهذه الوظيفة تلقائياً بمجرد استدعائه.
ولكن نبهت الوثائق الرسمية لخطر المبالغة في التدقيق لقطاع المراجعة الفاحصة:
يميل مراجع الأكواد الموجه للبحث عن العيوب إلى تسجيل تنبيهات وملاحظات حتى لو كان الكود البرمجي سليماً ومطابقاً للمعايير... ومحاولة ملاحقة وتعديل كل ملاحظة تجميلية يوقعك في فخ المبالغة الفنية والهندسة الزائدة (over-engineering).
بمعنى آخر: مطالبة النموذج بالبحث عن العيوب يجعله يخترع ويبحث عن ملاحظات تجميلية حتى لو كانت الأكواد ممتازة. فتجنب تعديل كل ملاحظة هامشية، لئلا تنتهي بتعقيد الأكواد وإضافة شروط حماية لا نفع حقيقي منها — ووجه مراجع الأكواد للتركيز على الأخطاء المنطقية وال边界 المؤثرة فقط.
💡 خلاصة القول في جملة واحدة: أتقن إدارة الوكيل الفردي أولاً ثم توجه للتوازي — عبر تشغيل محادثات متعددة بالتوازي (مع عزلها ببيئات worktree)، وتوزيع الأدوار بين كاتب ومراجع (Writer/Reviewer) لفحص الأكواد بحيادية، واستدعاء الأتمتة البرمجية عبر
claude -p؛ واكتفِ بإصلاح الملاحظات المؤثرة في تقرير المراجعة وتجنب الهدر البرمجي.
08 ممارسات عملية لرفع كفاءة التواصل والتوجيه
تمثل القواعد الست السابقة هيكل العمل الأساسي، ونضيف في هذا القسم مجموعة من العادات والمهارات العملية التي ترفع كفاءة تواصلك اليومي مع Claude وتسهل الفهم.
أولاً: محاورته كمهندس خبير وزميل في العمل. عند التعامل مع مستودع برمجي جديد وغير مألوف، تجنب قضاء الساعات في قراءة السطور بمفردك، بل وجه له الأسئلة الفنية المباشرة التي قد توجهها لمهندس خبير انضم للمشروع قبلك — وتؤكد الوثائق الرسمية: "وجه لـ Claude نفس الأسئلة الفنية التي قد توجهها لمهندس برمجيات خبير":
日志是怎么工作的？
我要怎么新建一个 API 端点？
foo.rs 第 134 行那个 async move 是干嘛的？
为啥这段代码第 333 行调 foo() 而不是 bar()？دون الحاجة لكتابة توجيهات معقدة أو جمل تمهيدية، اسأل مباشرة. ويمثل هذا الأسلوب أسرع وسيلة للانخراط وفهم تفاصيل المشاريع البرمجية الجديدة مقارنة بانتظار قراءة التوثيق الفني بالكامل.
ثانياً: مطالبته بـ "إجراء مقابلة فنية" للمشاريع الكبيرة. وهي ممارسة ذكية توفر عليك الكثير من الوقت — فقبل البدء بالبناء البرمجي، اطلب من Claude تفصيل الأسئلة ومحاورتك لكشف الحدود والخيارات الفنية:
我想做 [اكتب وصفاً موجزاً للمشروع]. 用 AskUserQuestion 工具详细采访我.
问技术实现、UI/UX、边界情况、顾虑和权衡。别问显而易见的，
专挑我可能没想到的硬骨头问。聊透了，把完整的 spec 写到 SPEC.md。ليقوم بطرح أسئلة ذكية حول هندسة البناء، والحالات الخاصة، والموازنات الفنية. وتنتهي المقابلة بصياغة وثيقة المواصفات الفنية SPEC.md، لتفتح محادثة جديدة نظيفة وتوجهه لبناء المشروع بالاعتماد على هذه الوثيقة المحددة. وتوضح الوثائق: "أن الوقت المقضي في صياغة وتدقيق وثيقة المواصفات الفنية SPEC يوفر أضعاف وقت مراقبة وتعديل البناء الخاطئ لاحقاً". وننصح بتبني هذا الأسلوب للمشاريع المتوسطة والكبيرة.
ثالثاً: مطالبته بعرض أدلة النجاح، وتجنب الاكتفاء بوعوده. تتكامل هذه الممارسة مع القاعدة الأولى وتوفر حماية ممتازة — فكلما أخبرك بـ "تم الإصلاح بنجاح" أو "الكود يعمل الآن"، وجه له السؤال الفوري: "شغل الفحص والتحقق الفعلي، وأرفق مخرجات التشغيل هنا للتأكد". وتحويل "التصريحات الشفهية" إلى "أدلة ملموسة" هو الضمان الأقوى لكشف الأخطاء البرمجية الخفية وال边界 المهملة.
💡 خلاصة القول في جملة واحدة: في المشاريع غير المألوفة وجه الأسئلة الفنية المباشرة لـ Claude كأنه مهندس خبير؛ وللمشاريع الكبيرة اطلب منه إجراء مقابلة معك عبر أداة
AskUserQuestionلصياغة SPEC.md أولاً؛ وتجنب تصريحاته الشفهية بانتهاء العمل وطالبه دائماً بإرفاق مخرجات الاختبارات والتحقق كدليل للنجاح.
09 العمل: تجربة مقارنة عملية لكشف نفع "التوجيه الدقيق والتحقق"
القراءة النظرية للقواعد لا تغني عن التجربة العملية. سنقوم الآن بتشغيل تجربة مقارنة مصغرة تستغرق خمس دقائق، لتشهد بنفسك فارق مخرجات التوجيه الدقيق والتحقق العملي على جهازك الفعلي، ودون حاجة لمشاريع سابقة.
الهدف: بناء نفس الميزة البرمجية بتوجيه عائم أولاً، وتكرارها بتوجيه دقيق مع أداة تحقق ثانياً، لمقارنة دقة مخرجات Claude وسهولة الاستلام.
الخطوة الأولى: إنشاء مجلد تجريبي وتشغيل Claude
mkdir cc-best-practice-demo && cd cc-best-practice-demo && claudeالخطوة الثانية: تشغيل التجربة الأولى بتوجيه عائم (مماثل لأسلوب المبتدئين)
اكتب التوجيه التالي في المحادثة:
写个判断密码强不强的函数المتوقع: ينشأ كود برمجى لدالة التحقق، ولكن قواعد ومعايير قوة الكلمة يحددها Claude من ذاكرته وبشكل عشوائي — فقد يكتفي بفحص طول الكلمة، أو يفرض قيوداً معقدة لم تطلبها؛ والأهم هو غياب أي اختبارات برمجية للتحقق، مما يضطر قراءة الكود للتأكد من سلامة المعايير الفعالة. احتفظ بهذه النسخة لمقارنتها.
الخطوة الثالثة: تصفية الجلسة وتشغيل التجربة الثانية بتوجيه دقيق مع أداة تحقق
اكتب أمر التصفية أولاً:
/clearوبعد تصفية الجلسة، أعد كتابة نفس المتطلب مع تطبيق القاعدة الأولى والثالثة (الدقة والتحقق التلقائي):
写一个 isStrongPassword(pwd) 函数，放到 password.js。
规则：长度 >= 8、至少 1 个大写字母、至少 1 个数字，三条全满足才算强。
示例用例：'Abc12345' 为 true，'abc12345' 为 false（没大写），'Abcdefgh' 为 false（没数字）。
写完用这些用例跑一遍验证，把测试输出贴给我。المتوقع: ستشهد ثلاثة فروق جوهرية في النسخة الثانية مقارنة بالأولى —
- قواعد التحقق المطبقة في الكود تتطابق تماماً وبدقة مع شروطك الثلاثة دون عشوائية أو زيادة؛
- يقوم Claude بتشغيل الحالات التجريبية الثلاثة المحددة فعلياً على جهازك، ويعرض نتائج التشغيل بوضوح مثل
✓ Abc12345 → true؛ - يمكنك استلام والاطمئنان لسلامة الكود بمجرد مراجعة سجل التشغيل المعروض، ودون حاجة لقراءة سطور الكود البرمجي للتخمين.
الخطوة الرابعة: مقارنة الفروق وتثبيت الفهم
تأمل فارق النتائج وسهولة الاستلام بين النسختين: في التجربة الأولى تحولت لدور مراجع الأكواد وتبحث عن العيوب؛ وفي التجربة الثانية تولى Claude البناء والتحقق وعرض لك أدلة النجاح لتسلم العمل آمناً. وهذا الفارق يلخص جوهر أفضل الممارسات — فإضافة بضعة كلمات محددة تصف القيود والتحقق يختصر عليك جولات التعديل وال返工 اللاحقة.
💡 خلاصة القول في جملة واحدة: يضعك التوجيه العائم في دور المراجع للأخطاء بينما يتيح التوجيه الدقيق المزود بأدوات التحقق للوكيل إنجاز المهمة وتسليمها مجربة وموثوقة تلقائياً؛ وتجربتك للمقارنة العملية بنفسك تثبت نفع وأهمية تبني أفضل الممارسات في عملك اليومي.
10 خلاصة
لم نطرح في هذا الدرس ميزات تقنية جديدة لـ Claude Code، بل ركزنا على توضيح أفضل ممارسات وقواعد العمل الذكي لرفع جودة وموثوقية مخرجاتك البرمجية وتوفير وقتك.
ونلخص القواعد الستة الأساسية وعلاقتها بقيد سياق المحادثة (السبورة البيضاء) في جدول المراجعة التالي:
| العائق الفعلي الذي تواجهه | القاعدة البرمجية المناسبة | الإجراء التقني والعملي للحل |
|---|---|---|
| "أقضي وقتاً طويلاً في مراجعة وتصحيح الأكواد بنفسي" | توفير أدوات تحقق ذاتية | إنهاء التوجيه بـ "وبعد الانتهاء شغل الاختبارات / البناء وتأكد من نجاحها" |
| "يكتب الوكيل حلولاً معقدة وخاطئة لمشاكل لم أقصدها" | الاستكشاف قبل البناء | تفعيل وضع Plan Mode للمشاريع المتشابكة، وتجاوز التخطيط للمهام البسيطة |
| "يفشل الوكيل في فهم الأهداف ويعدل ملفات غير مقصودة" | صياغة توجيهات دقيقة ومحددة | تحديد أسماء الملفات، وصياغة القيود، والإشارة لأمثلة سابقة للمحاكاة، وإرفاق الصور والروابط |
| "يتجاهل الوكيل القواعد المكتوبة ويسأل عن تنبيهات واضحة" | اختصار قواعد CLAUDE.md | مراجعة وتقليص الوثيقة وحذف الحشو، ونقل التفاصيل المتخصصة لملفات المهارات Skills |
| "تتعارض التعديلات وتتشابك الأكواد وتتكرر الأخطاء" | التدخل الفوري وتصحيح المسار | التراجع السريع عبر /rewind؛ وإذا تجاوزت المحاولات ثلاث جولات فصف الجلسة بـ /clear وابدأ من جديد |
| "أريد زيادة سرعة العمل ومواكبة ميزات التوازي" | التوسع والتوازي الذكي | إتقان عمل الوكيل الفردي أولاً، ثم تشغيل محادثات متوازية وتوزيع أدوار المراجعة (Writer/Reviewer) |
ويجب أن تكون قادراً الآن على: إدراك أهمية حماية مساحة سياق المحادثة لـ Claude، وتطبيق قواعد العمل الأساسية لرفع كفاءتك (توفير أدوات التحقق التلقائية، الاستكشاف والتخطيط الفني أولاً، صياغة التوجيهات الدقيقة وتجنب الجمل العائمة، تقليص وثيقة CLAUDE.md والتركيز على الاستثناءات، التدخل الفوري لتصحيح المسار وتصفية الجلسات المتأثرة بالأخطاء)، واستخدام خيارات التوازي والعمل الجماعي بأمان، ومحاورة Claude كمهندس خبير وتفويض المقابلات الفنية وصياغة SPEC.md، وتطبيق المقارنة العملية للتوجيه والتحقق بنفسك. وبتبني وتطبيق هذه المنهجية، يتحول تفاعلك مع Claude Code من محاولات عشوائية متكررة إلى سير عمل منظم يحقق أعلى إنتاجية وأمان.
إتقانك لأفضل الممارسات يمثل الفارق بين كتابة الأكواد مع مساعد يطرح أسئلة متكررة، والعمل مع وكيل ذكي ينجز ويسلم المهام مجربة وتلقائية بالكامل.
الدرس القادم 50 "Antipatterns أخطاء وممارسات خاطئة شائعة" — ركزنا في هذا الدرس على توضيح "ما يجب عليك فعله فِعلاً لرفع الجودة"؛ الدرس القادم يسير في الاتجاه المعاكس لتوضيح "الأفعال والممارسات الخاطئة التي يجب عليك تجنبها تماماً". حيث نفتح وثيقة الأخطاء الشائعة (مثل تضخم المحادثات، التكرار اليدوي للتصحيح، تضخم قواعد CLAUDE.md، الثقة المطلقة دون فحص، والبحث اللانهائي دون خطة)، ونفكك تفاصيل كل خطأ برمجى مع عرض سيناريوهات حقيقية من بيئة العمل وتقديم الحل التقني المناسب لكل منها. فكر في الأمر: ما هو الخطأ أو الفخ الأبرز الذي وقعت فيه خلال تجربتك السابقة مع Claude Code؟ قراءة الدرس القادم ستمنحك إجابة واضحة وتوافقاً كبيراً مع تجربتك اليومية.