البدء العملي: خذ متطلبات حقيقية، من البداية وحتى التسليم

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

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

انحرف الاتجاه، وتم تعديل ثلاثة ملفات إضافية بالخطأ، وقيل إن الخطأ تم إصلاحه ولكنه استمر في الانهيار... في النهاية، الوقت المستغرق في التنظيف كان أكثر من القيام بالعمل بنفسك.

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

ببساطة، هذه هي الفجوة بين "تعلم كل حركة" و"القدرة على ربط الحركات معاً في تدفق واحد". لقد تدربت على توجيه عجلة القيادة، والنظر في المرآة الخلفية، والضغط على الفرامل، ولكن في المرة الأولى التي تقود فيها بمفردك على الطريق، يجب عليك ربط هذه الحركات بالترتيب الصحيح لكي يُطلق عليك أنك تعرف كيف تقود. هذا الدرس لا يعلمك أي ميزات جديدة، بل يفعل شيئاً واحداً فقط — يأخذك لتربط الأجزاء التي تعرفها بالفعل لتصنع مساراً عملياً ناجحاً لأول مرة.

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

بعد قراءة هذا الدرس، ستحصل على:

• مسار عملي قياسي يتكون من "البدء ← الاستكشاف ← التخطيط ← العمل ← التحقق ← التسليم"، وما يجب كتابته ورؤيته في كل خطوة
• مهمة حقيقية صغيرة يمكنك نسخها وتطبيقها (إضافة --top N إلى سيناريو عد الكلمات، وإصلاح الانهيار عند غياب المعاملات)، مع الأوامر الكاملة والمخرجات المتوقعة
• لماذا تعتبر قاعدة "دعه يستكشف أولاً، ثم دعه يعمل" هي أهم ذاكرة عضلية يجب أن يطورها المبتدئون
• كيف تستخدم plan mode (راجع الدرس 20 بالتفصيل) لجعله يقدم الخطة أولاً قبل كتابة الكود، وكيف تراجع الـ diff الذي يقدمه لك
• جدول مقارنة بين "كيف يسير المحترف vs كيف يسير المبتدئ" لتوضيح أكثر مصائد الترتيب شيوعاً

---

01 نظرة عامة أولاً: تدفق عملي من ست خطوات

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

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

هذه الخطوات الست ليست من اختراعي، بل هي ترتيب عملي ناتج عن دمج وثيقتي البدء السريع (quickstart) وسير العمل المشترك (common workflows) الرسميتين. تلك العبارة الرسمية تعبر عن الموضوع بدقة:

قبل إجراء التغييرات، دع Claude يفهم كودك.

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

💡 خلاصة القول في جملة واحدة: الهيكل العظمي لأي مهمة عملية هو دائماً الخطوات الست "البدء ← الاستكشاف ← التخطيط ← العمل ← التحقق ← التسليم"، حيث يتم تسليم العصا بدقة مثل سباق التتابع؛ والخطوة الأكثر شيوعاً التي يسقطها المبتدئون هي "البدء في العمل مباشرة دون استكشاف".

---

02 التحضير: إنشاء مشروع صغير للتدريب

لكي تتمكن من التشغيل والمتابعة خطوة بخطوة، لن نلمس أي مشروع حقيقي كبير، بل سنقضي دقيقتين لإنشاء ساحة تدريب صغيرة جداً. تحتوي فقط على نص برمجى Python واحد وملف نصي واحد، ولا تعتمد على أي مكتبات خارجية، ويمكن تشغيلها طالما يتوفر python3 (يأتي مدمجاً في Mac / Linux؛ وفي Windows يكفي تثبيت Python).

الخطوة الأولى: إنشاء المجلد والدخول إليه ووضع الملفين

قم بتشغيل الأوامر التالية في الطرفية (هذه الخطوة هي تحضير يدوي بحت، لم نستخدم Claude Code بعد):

mkdir wordcount-demo && cd wordcount-demo

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

import sys
from collections import Counter

def count_words(path):
    with open(path) as f:
        text = f.read()
    words = text.lower().split()
    return Counter(words)

def main():
    path = sys.argv[1]
    counts = count_words(path)
    for word, n in counts.items():
        print(f"{word}: {n}")

if __name__ == "__main__":
    main()

ثم أنشئ ملفاً آخر باسم sample.txt كبيانات اختبار:

the quick brown fox the lazy dog the fox

الخطوة الثانية: التشغيل يدوياً للتأكد من أنه يعمل

python3 wordcount.py sample.txt

المخرجات المتوقعة (قد يختلف الترتيب قليلاً، لكن الأرقام يجب أن تكون متطابقة):

the: 3
quick: 1
brown: 1
fox: 2
lazy: 1
dog: 1

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

• ميزة غائبة: أريد فقط رؤية "الكلمات الأكثر تكراراً (أول N كلمات)"، حالياً يقوم بطباعة كل شيء دفعة واحدة.
• خطأ مخفي (bug): جرب تشغيل python3 wordcount.py مباشرة دون تمرير اسم الملف، وسيقوم بانهيار البرنامج وعرض IndexError في وجهك، بدلاً من تنبيهك بشكل لائق بـ "يجب تمرير ملف".

الخطوة الثالثة: ضمه إلى git (هذه الخطوة مهمة جداً، لا تتخطاها)

git init && git add . && git commit -m "init: 一个简陋的数词脚本"

المتوقع: ظهور سطر في النهاية يؤكد التزام التغييرات مثل 2 files changed (تم تسجيل ملفي wordcount.py و sample.txt). رؤية هذا يعني أنه أصبح لديك "نقطة انطلاق" نظيفة، ومهما قام Claude بتعديل الكود لاحقاً، يمكنك التراجع إلى هنا بضغطة زر واحدة.

لماذا نقوم بـ git commit دائماً قبل البدء بالعمل؟ لأنها أقوى بطاقة تراجع تملكها. شرح الدرس 37 أن نقاط الفحص (checkpoint) يمكنها التراجع عن تعديلات Claude، ولكن نقاط الفحص و git نظامان مختلفان يعمل كل منهما في منطقة (وقد فصلنا ذلك في الدرس 37). التزام git النظيف قبل البدء هو الأساس الذي يتيح لك "العودة إلى نقطة البداية مهما كانت الفوضى التي أحدثتها لاحقاً" — السماح له بإجراء تعديلات كبيرة دون التزام، ثم الرغبة في التراجع دون وجود أساس نظيف للمقارنة هو خسارة شائعة جداً، لذا التزم أولاً دون تردد ثم ابدأ العمل.

💡 خلاصة القول في جملة واحدة: ساحة التدريب تحتوي على كود برمجى بسيط + ملف نصي، ويمكن تشغيله بوجود python3؛ لقد تم ترك "ميزة غائبة" و"خطأ مخفي" عمداً؛ قم بعمل git commit أولاً قبل بدء العمل لتضمن لنفسك أقوى وسيلة للتراجع.

---

03 البدء: التشغيل من مجلد المشروع، وكتابة ملف CLAUDE.md مصغر أولاً

البيئة جاهزة، لنبدأ بالخطوة الأولى — البدء. تقابل هذه الخطوة الدرس 02 (التشغيل)، الدرس 07 (التشغيل الناجح الأول)，والدرسين 12 / 18 (ملف CLAUDE.md).

الخطوة الأولى: تشغيل Claude Code في المجلد الرئيسي للمشروع

يجب عليك كتابة claude داخل المجلد wordcount-demo وليس في أي مكان آخر. يعتبر Claude Code مجلد التشغيل بمثابة بيئة العمل الافتراضية له — إذا وقفت في المكان الخاطئ، فسيقوم بقراءة ملفات مشاريع أخرى.

claude

المتوقع: رؤية شاشة الترحيب الخاصة بـ Claude Code، ويظهر في الأسفل أن المجلد الحالي هو wordcount-demo. هذه هي نقطة البداية التي تم شرحها في الدرس 07.

الخطوة الثانية: إعطاؤه ملف CLAUDE.md "قابل للاستخدام كحد أدنى" أولاً

لقد شدد الدرس 18 مراراً على جملة: ملف CLAUDE.md الأكثر عديمة الفائدة هو الذي يحتوي على 300 سطر ولم يستمع Claude إلى أي منها. لذلك لا تطمع في الكثير في مشاريع التدريب، يكفي كتابة 3 إلى 5 أسطر توضح القواعد الأكثر أهمية. بالنسبة لكودنا الصغير هذا، القواعد هي اثنتان فقط: ما الذي نستخدمه للتشغيل، وكيف نتحقق بعد التعديل. اطلب منه كتابته مباشرة في المحادثة (يمكنك كتابته يدوياً، لكن دعه يكتبه لتوفير الجهد):

帮我在项目根目录建一个 CLAUDE.md，写清两条：
1. 这是个纯标准库的 Python 命令行小工具，不要引入任何第三方依赖
2. 每次改完代码，用 python3 wordcount.py sample.txt 跑一遍验证不报错

المتوقع: سيقوم Claude بعرض المحتوى الذي ينوي كتابته أولاً، ثم يطلب الإذن لكتابة الملف (آلية الأذونات المشروحة في الدرس 20 — حيث يسألك دائماً قبل تعديل الملفات). بعد الموافقة، سيظهر ملف CLAUDE.md في المجلد الرئيسي للمشروع، بمحتوى يشبه هذا تقريباً:

# wordcount-demo

أداة سطر أوامر صغيرة لعد تردد الكلمات في النصوص.

## القيود التقنية
- مكتبة Python القياسية فقط، **لا تقم بإدخال أي اعتماديات خارجية**.

## التحقق
- بعد كل تعديل على الكود، قم بالتشغيل للتأكد من عدم وجود أخطاء: `python3 wordcount.py sample.txt`

قصير، ولكنه ثبت أهم قاعدتين. لا تستصغر بساطته — ما يمكن إدارته بثلاثة إلى خمسة أسطر لا داعي لكتابته في ثلاثين سطراً.

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

لماذا نكتب CLAUDE.md في بداية العمل؟ لأنه يمثل "القواعد العامة" لجميع خطوات تسليم العصا التالية. عندما تطلب منه إضافة ميزة لاحقاً، سيتذكر تلقائياً "عدم إدخال مكتبات خارجية"؛ وبعد التعديل سيتذكر تلقائياً "التشغيل للتحقق" — أنت تقوله مرة واحدة ويظل فعالاً طوال الوقت دون الحاجة لتكراره في كل أمر. هذه هي القيمة الحقيقية لملف CLAUDE.md: تحويل "الكلام الذي يجب التوصية به في كل مرة" إلى خلفية يتم تحميلها تلقائياً في كل محادثة.

💡 خلاصة القول في جملة واحدة: البدء = الوقوف في المجلد الصحيح وكتابة claude + كتابة ملف CLAUDE.md مصغر لتثبيت القواعد الأساسية؛ في المشاريع الصغيرة، تحديد القواعد يدوياً أدق وأقصر من استخدام /init لفرز المشروع بالكامل.

---

04 الاستكشاف: دعه "يفهم" أولاً، ولا تتعجل في جعله "يعمل"

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

الخلاصة أولاً: الجملة الأولى عند استلام المهمة ليست "عدل لي"، بل "افهم أولاً".

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

先别改任何代码。给我讲讲 @wordcount.py 现在是怎么工作的，
入口在哪、有没有什么明显的问题或者容易崩的地方？

لاحظ تفصيلين مهمين:

• العبارة في البداية "لا تعدل أي كود أولاً"، هي لرسم خط أحمر له — هذه المرحلة مخصصة للنظر فقط، ولا يُسمح فيها بالتعديل. كما أوضح الدرس 15، عندما توضح الحدود، فإنه لن يتخطاها.
• استخدام @wordcount.py هو لتضمين محتوى الملف مباشرة في المحادثة باستخدام الإشارة @ (والتي تم ذكرها في الدرسين 16 و 17)، مما يغنيه عن البحث عنه بنفسه.

المتوقع: سيقرأ Claude الملف ويقدم لك شرحاً — سيقول تقريباً: هذا كود برمجى يستخدم Counter لعد الكلمات، والمدخل هو main()، وهو يأخذ مسار الملف من sys.argv[1]، ثم سيشير على الأرجح من تلقاء نفسه إلى الثغرة: إذا لم يتم تمرير اسم الملف، فسينهار البرنامج بسبب تجاوز حدود sys.argv[1].

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

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

先给我这个代码库的整体结构 and 它是干嘛的（先别改任何代码）

处理用户登录的逻辑在哪几个文件？它们怎么配合的？

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

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

تستهلك قراءة الملفات في مرحلة الاستكشاف مساحة من السياق (كما شرح الدرس 19 أن امتلاء مساحة العمل يجعله بطيئاً). عندما تكون المهمة كبيرة وتتطلب تصفح الكثير من الملفات، يمكنك جعله يرسل subagent للاستكشاف (الدرس 23) — حيث يتصفح الوكيل الفرعي الملفات في نافذته الخاصة ويرسل الاستنتاجات فقط، فلا تمتلئ محادثتك الرئيسية بمحتويات الملفات الكثيرة. هذا غير ضروري للمهام الصغيرة، ولكن يكفي معرفة هذا الطريق.

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

---

05 التخطيط: دعه يطرح الخطة أولاً، واقبلها قبل كتابة الكود

بعد الاستكشاف، فهم الوضع الحالي وعرف ما تريد القيام به. ولكن لا تزال هناك خطوة ناقصة — دعه يعرض "كيف ينوي التعديل" لتراها أولاً، وابدأ بالعمل بعد موافقتك. تقابل هذه الخطوة plan mode (وضع التخطيط) المذكور في الدرس 20.

لماذا لا نتركه يعدل مباشرة؟ لأن "الخطة التي يفهمها" قد لا تكون "الخطة التي تريدها". السماح له بشرح خطته أولاً هو أرخص تأمين يمنع "انحراف الاتجاه تماماً والاستمرار في التعديل حتى النهاية".

الطريقة الأولى: اطلب منه صراحة تقديم الخطة أولاً ودون تعديل

أبسط الطرق هي تقييده بجملة واحدة:

我想给这个脚本加一个 --top N 参数，只显示最高频的前 N 个词；
顺手把不传文件名就崩溃的问题也修了。
先告诉我你打算怎么改、动哪几个地方，等我说「开始」你再动手。

المتوقع: سيعود إليك بخطة مثل — استخدام argparse بدلاً من sys.argv المكتوبة يدوياً، وإضافة خيار --top، واستخدام Counter.most_common(N) للحصول على أول N كلمات، وعند عدم تمرير اسم الملف يقوم argparse تلقائياً بعرض تنبيه لطيف بدلاً من الانهيار. سيتوقف هنا منتظراً قرارك، ولن يقوم بتعديل الملفات تلقائياً.

الطريقة الثانية: استخدام plan mode بشكل رسمي

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

claude --permission-mode plan

أو اضغط على Shift+Tab في المحادثة للتبديل الدائري إلى plan mode. وتحديد موقع هذا الوضع واضح جداً في الوثائق الرسمية:

يقرأ Claude الملفات ويقترح خطة، ولكنه لا يقوم بأي تعديلات حتى توافق عليها.

الفرق بين هاتين الطريقتين يظهر بوضوح في هذا الجدول:

الأسلوب	كيف تقيده	درجة الإلزام	مناسب لـ
طلب تقديم الخطة بجملة واحدة	يعتمد على كتابتك لـ "لا تعدل أولاً" في التوجيه	قيد مرن (سيستمع لك عادة، لكنه غير مغلق تماماً)	التعديلات الصغيرة، وتحت نظرك
plan mode	يمنع تعديل الكود المصدري على مستوى وضع التشغيل (أوامر shell لا تزال تعمل)	قيد صارم (لا يمكن تعديل سطر واحد من الكود قبل الموافقة)	التعديلات الكبيرة، عدم الاطمئنان، الرغبة في مراجعة الخطة بدقة

عادة مفيدة: بالنسبة للتعديلات الصغيرة مثل --top، تكفي الطريقة الأولى بجملة واحدة؛ ولكن في أي تعديل يتضمن ملفات متعددة أو تشعر بعدم اليقين تجاهه، استخدم Shift+Tab للتبديل إلى plan mode دون تردد — دع النظام يغلق الباب بالنيابة عنك لمنع التعديل دون موافقة، فهو أسهل من المراقبة. عند إجراء تعديل كبير على مشروع غير مألوف، وإذا نسيت التبديل إلى plan mode بسبب الرغبة في السرعة، فقد يقوم بتعديل أربعة ملفات دفعة واحدة وباتجاه مختلف تماماً عما كنت تفكر فيه، والوقت المستغرق للتراجع سيكون كافياً لقراءة الخطة ثلاث مرات. لذا إذا كنت غير متأكد، استخدم التخطيط (plan).

💡 خلاصة القول في جملة واحدة: قبل البدء بالعمل، دعه يقدم الخطة أولاً، واقبلها ثم ابدأ بالتعديل؛ في التعديلات الصغيرة تكفي جملة "لا تعمل أولاً"، وفي التعديلات الكبيرة أو غير الموثوقة استخدم Shift+Tab للتبديل إلى plan mode لإغلاق إمكانية تعديل الكود قبل الموافقة بشكل صارم.

---

06 العمل + المراجعة: دعه يعدل، ولكن راجع كل diff بنفسك

بعد الموافقة على الخطة، ننتقل للخطوة الرابعة (وهي في الواقع خطوتان متتاليتان: العمل والمراجعة) — دعه يعدل، وفي نفس الوقت تابع كل تعديل بنفسك. تقابل هذه الخطوة تأكيد الأذونات في الدرس 20.

الخطوة الأولى: إعطاؤه الضوء الأخضر

方案可以，开始改吧。

المتوقع: يبدأ Claude بتعديل wordcount.py. الآن يأتي الجزء المهم — مع كل تعديل يجريه، سيعرض الـ diff (مقارنة التعديل: الأسطر المحذوفة والأسطر المضافة) أمامك ويطلب موافقتك (إلا إذا قمت بتفعيل وضع "قبول الكل"، وهو ما أنصح المبتدئين بشدة بعدم فعله). لقد شرح الدرس 20 آلية الأذونات هذه، وهذه الخطوة هي اللحظة الحقيقية لتطبيقها.

الخطوة الثانية: اقرأ الـ diff بجدية، ولا تضغط Enter دون وعي

هذا هو المكان الذي يسهل فيه على المبتدئين التراخي — تمرير الـ diff دون قراءته والضغط على y طوال الطريق. قاعدتي الصارمة هي: ألقِ نظرة على كل تعديل على الأقل لتتأكد من "هل يقوم بالتعديل في المكان الذي طلبته منه". التعديل الذي يجب أن تراه في هذه المهمة يبدو هكذا تقريباً:

- import sys
+ import argparse

- def main():
-     path = sys.argv[1]
-     counts = count_words(path)
-     for word, n in counts.items():
+ def main():
+     parser = argparse.ArgumentParser(...)
+     parser.add_argument("path", ...)
+     parser.add_argument("--top", type=int, default=None, ...)
+     args = parser.parse_args()
+     counts = count_words(args.path)
+     items = counts.most_common(args.top) if args.top else counts.most_common()
+     for word, n in items:

ألقِ نظرة سريعة للتأكد من ثلاثة أمور: 1. أنه يضيف --top ويعدل طريقة استقبال المعاملات بالفعل (وفقاً للخطة)؛ 2. أنه لم يلمس بالخطأ دالة count_words التي كانت تعمل بشكل صحيح؛ 3. أنه لم يدخل أي مكتبات خارجية سراً (القاعدة التي وضعها CLAUDE.md). إذا كان كل شيء متطابقاً، فوافق.

كيف تقرأ الـ diff بسرعة؟ لا تحتاج لقراءته حرفاً بحرف، بل انتبه لثلاث إشارات فقط: الأسطر الحمراء (-، ما تم حذفه) تأكد أنها لا تحتوي على ما لا تريد حذفه؛ الأسطر الخضراء (+، ما تم إضافته) تأكد أنها خالية من الاعتماديات التي لم تطلبها أو الميزات غير المطلوبة؛ وأن نطاق التعديل لم يتجاوز الأماكن التي حددتها. في هذه المهمة، الأسطر الحمراء المحذوفة هي sys.argv المكتوبة يدوياً، والأسطر الخضراء المضافة هي argparse و --top، والنطاق محصور داخل main() فقط — كل شيء متوقع، وافق باطمئنان.

نصيحة للمبتدئين حول وضع "قبول الكل" (acceptEdits): لا تفعله في مرحلة التدريب. لقد ذكر دليل البدء السريع أنه يمكنك "تفعيل وضع قبول الكل لجلسة العمل" (أي الخاصية acceptEdits المذكورة في الدرس 20). هذا يوفر الجهد، ولكن المقابل هو أنك تتخلى تماماً عن نافذة "الاعتراض أثناء العمل". الطريقة الأكثر أماناً هي تفعيلها في حالتين فقط: الأولى بعد مراجعة الخطة سطراً بسطر في plan mode والاطمئنان إليها؛ والثانية عند إجراء تعديلات تكرارية آلية (مثل تعديل اسم متغير في أماكن متعددة). في أول شهرين، التزم بمراجعة التعديلات مكاناً بمكان يدوياً، لتكتسب مهارة "قراءة الـ diff" قبل أن تفكر في ترك الأمور تسير بحرية.

لماذا لا يمكن الاستغناء عن خطوة المراجعة هذه؟ لأن تعديل الذكاء الاصطناعي للكود ليس عملية ثنائية (صواب أو خطأ)، بل غالباً ما يكون "صحيحاً بشكل عام، ومنحرفاً في التفاصيل" — فقد يعدل بالخطأ أماكن لم تطلب تعديلها، أو يستخدم أسلوب كتابة لا تريده. وتلك الجملة من الدرس 20 تستحق أن نكررها هنا:

يطلب Claude Code الإذن دائماً قبل تعديل الملفات.

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

💡 خلاصة القول في جملة واحدة: في مرحلة العمل دعه يعدل، ولكن راجع الـ diff في كل مكان بنفسك — تأكد من أن "التعديل في المكان الصحيح، ولم يلمس الكود السليم، ولم يخالف CLAUDE.md"؛ هذه الموافقة هي نافذتك الوحيدة لـ الاعتراض أثناء العمل، والضغط العشوائي على Enter يعني ترك فرصة التراجع لـ "ما بعد العمل".

---

07 التحقق: قم بالتشغيل لرؤية النتائج، ولا تصدق قول "لقد أصلحتها"

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

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

الخطوة الأولى: التحقق من الميزة الجديدة (--top)

python3 wordcount.py sample.txt --top 3

المخرجات المتوقعة (مرتبة حسب تكرار الكلمات من الأكثر إلى الأقل، وتظهر أول 3 كلمات فقط):

the: 3
fox: 2
quick: 1

رؤية الكلمات الثلاث الأولى فقط ومرتبة حسب التكرار تعني أن الميزة الجديدة تعمل بنجاح. (ظهرت the 3 مرات، و fox مرتين، والثالث هو أي كلمة تكررت مرة واحدة.)

الخطوة الثانية: التحقق من أن الميزات القديمة لم تخرب (التراجع)

بعد إضافة المعامل الجديد، يجب ألا ينهار الاستخدام القديم — فعند عدم تمرير --top يجب طباعة كل شيء كالسابق:

python3 wordcount.py sample.txt

المتوقع: يتطابق مع المخرجات الأصلية المذكورة في القسم 02 (تظهر الكلمات الست كاملة). التطابق يعني عدم حدوث "إصلاح الجديد وتخريب القديم".

الخطوة الثالثة: التحقق من أن الخطأ تم إصلاحه حقاً

هذه هي الخطوة الأكثر أهمية — أعد إحداث الانهيار الذي حدث في البداية، وتأكد من أنه يعرض تنبيهاً لطيفاً بدلاً من الانهيار وعرض تفاصيل الخطأ:

python3 wordcount.py

المتوقع: لا تظهر تفاصيل الخطأ IndexError مجدداً، بل تظهر رسالة استخدام واضحة ولطيفة، تشبه:

usage: wordcount.py [-h] [--top TOP] path
wordcount.py: error: the following arguments are required: path

التحول من "انهيار البرنامج وعرض تفاصيل الخطأ في وجهك" إلى "إخبارك بوضوح بنقص المعامل path" — هو الدليل القاطع على إصلاح الخطأ. بعد اجتياز الخطوات الثلاث، تكون المهمة قد تمت بنجاح بالفعل.

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

给「不传文件名时不崩溃、而是退出码非 0 并打印用法提示」写一个测试，再确认它通过。

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

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

💡 خلاصة القول في جملة واحدة: التحقق = التشغيل بنفسك ثلاث مرات — للميزة الجديدة، للميزات القديمة، وللخطأ؛ قوله "لقد أصلحتها" هو افتراض، وظهور النجاح عند التشغيل هو الحقيقة، ولا يمكن التخلي عن هذه الخطوة.

---

08 التسليم: دعه يكتب رسالة الالتزام، واحفظ النتائج في المستودع

بعد اجتياز الخطوات الثلاث للتحقق بنجاح، نأتي للخطوة الأخيرة — التسليم، لحفظ هذه النتائج بأمان في git. تقابل هذه الخطوة "استخدام Git عبر المحادثة" المذكور في نهاية الدرس 07.

الخطوة الأولى: ألقِ نظرة على ما تم تعديله في النهاية

我改了哪些文件？给我一个改动概览。

المتوقع: يقوم Claude بتشغيل git status / git diff، ويخبرك بأنه تم تعديل wordcount.py فقط، مع إضافة معامل --top وتعديل استقبال المعاملات باستخدام argparse. التأكد مرة أخرى من أن نطاق التعديلات يتطابق مع المتوقع قبل التسليم هو المراجعة الأخيرة قبل الإنهاء.

الخطوة الثانية: دعه ينشئ رسالة الالتزام ويقوم بالالتزام

用一句话描述清楚这次改动，提交它。

المتوقع: سيقوم Claude بعرض رسالة الالتزام (commit message) التي صاغها لتأكيدها أولاً — مثل feat: 给 wordcount 加 --top N 参数并用 argparse 修复缺参崩溃 — ثم يطلب الإذن لتشغيل git commit. هذه هي نفس بوابة الأذونات في الدرس 20: يسألك دائماً قبل تعديل سجل git الخاص بك.

وهنا نوضح حداً مهماً: أمر git commit سيعرض لك ما سيتم التزامه لتأكيده أولاً؛ ولكن أمر git push (الدفع إلى المستودع البعيد) موضوع آخر تماماً. قبل دفع عملك إلى مستودع بعيد مثل GitHub، يجب أن تكون متأكداً وعلى دراية تامة به وتوافق عليه بنفسك — وهو ما سنفصله في الدرس 43 "سير عمل Git"، وهنا تذكر أولاً: يمكنك ترك أمر commit المحلي ليقوم به بالنيابة عنك، واحتفظ بخطوة push البعيدة في يدك.

الخطوة الثالثة: التأكد من نجاح الالتزام

显示我最后 1 次提交。

المتوقع: يقوم بتشغيل git log -1 لتتمكن من رؤية رسالة الالتزام والتعديلات التي تمت للتو. رؤية هذا يعني أن المهمة قد تم تسليمها رسمياً، وإتمام التدفق من البداية وحتى الحفظ بنجاح.

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

💡 خلاصة القول في جملة واحدة: التسليم = رؤية نظرة عامة على التعديلات ← جعل الكود يصيغ رسالة الالتزام ويقوم بـ commit (سيعرضها لتأكيدها أولاً) ← التحقق من الحفظ باستخدام log؛ وتذكر الحدود — يمكنك ترك commit المحلي له، واحتفظ بـ push لنفسك (سنترك هذا للدرس 43).

---

09 ماذا تفعل إذا انحرف التعديل: تراجع بشكل نظيف، ولا تحاول الرقع فوق الفوضى

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

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

التراجع يتكون من مستويين، يعتمد على الخطوة التي وصلت إليها:

مستوى التراجع	ماذا تستخدم	إلى أين تعود	مناسب لـ
المستوى الخفيف: إلغاء التعديل الأخير	نقاط الفحص في الدرس 37، وأمر /rewind	قبل قيام Claude بتعديل هذه الدفعة من الملفات	انحراف التعديل في مكان أو مكانين، وتريد التراجع بمجرد اكتشافه
المستوى الثقيل: العودة لنقطة البداية	نظام git، وأمر git restore . / git reset --hard	التزامك النظيف قبل البدء بالعمل	انحراف الاتجاه بالكامل، وتريد البدء من الصفر مجدداً

المستوى الخفيف هو الأكثر استخداماً: اكتب /rewind في المحادثة، ليعود بالملفات التي عدلها Claude في هذه الجولة إلى الخلف (وقد خصصنا الدرس 37 لشرح حدوده — قدرته على التراجع عن الملفات والمحادثات، ولكن لا تستخدمه كبديل لـ git). المستوى الثقيل هو الأمان الأخير: إذا أصبح الكود غير قابل للتعرف ولم تعد نقاط الفحص قادرة على ترتيبه، فعد إلى التزام البدء المذكور في القسم 02 — ولهذا أصررنا في البداية على "عمل commit قبل البدء"، فذلك الالتزام النظيف هو نقطة البداية التي يمكنك الهروب إليها دائماً.

بعد التراجع، لا تتعجل في تكرار نفس الطلب حرفياً. فكر أولاً لماذا انحرف الأمر هذه المرة — في 90% من الحالات يكون ذلك بسبب قلة الاستكشاف، أو غموض التوجيهات (كما شرح الدرس 15 "التحدث بوضوح"). تجربة عملية: انحراف التعديل في المرة الأولى يعود في 90% من الحالات إلى نقص القيود الأساسية في التوجيه، مثل عدم توضيح "تعديل هذه الدالة فقط، ولا تلمس غيرها". العودة لنقطة البداية وتوضيح التوجيه يجعل المحاولة الثانية تنجح بسهولة غالباً. التراجع ليس فشلاً، بل هو إيقاف للخسارة — وهو أكثر توفيراً بكثير من الترقيع فوق الفوضى.

💡 خلاصة القول في جملة واحدة: ردة الفعل الأولى عند انحراف التعديل هي "التراجع النظيف"، وليس "الترقيع فوق الفوضى"؛ التراجع الخفيف يكون باستخدام /rewind لإلغاء التعديلات، والتراجع الثقيل يكون باستخدام git للعودة لنقطة البداية (وهذا هو الغرض من commit قبل البدء)؛ بعد التراجع، وضح التوجيهات أولاً ثم أعد المحاولة، ولا تكرر الكلام نفسه.

---

10 مقارنة: كيف يسير المحترف vs كيف يسير المبتدئ

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

المرحلة	❌ يقع فيه المبتدئ	✅ كيف يسير المحترف
البدء	تشغيل claude من أي مجلد عشوائي، وعدم كتابة CLAUDE.md	الوقوف في المجلد الصحيح للمشروع، وكتابة ملف CLAUDE.md مصغر من 3-5 أسطر لتثبيت القواعد
الاستكشاف	البدء مباشرة بـ "عدل لي"، وتخطي الفهم	الجملة الأولى دائماً "لا تعدل، افهم أولاً"، ليدع الكود يستكشف الوضع الحالي
التخطيط	جعل الكود يبدأ بالعمل مباشرة، واكتشاف انحراف الاتجاه لاحقاً	جعل الكود يقدم الخطة أولاً، ويبدأ بالعمل بعد الموافقة؛ واستخدام plan mode عند عدم اليقين
العمل	تمرير الـ diff دون قراءته والضغط على y طوال الطريق	مراجعة كل diff سريعاً: هل التعديل صحيح، وهل تجاوز الحدود
التحقق	الاكتفاء بتصديق عبارة "لقد تم التعديل بنجاح"	التشغيل بنفسك ثلاث مرات: للميزة الجديدة، وللقيمة القديمة، وللخطأ
التسليم	ترك التعديل معلقاً، أو التزامه دون مراجعة النطاق	مراجعة نظرة عامة على التعديلات أولاً، ثم جعله يصيغ رسالة الالتزام، والتأكد من الحفظ باستخدام log

جوهر هذا الجدول يكمن في جملة واحدة: يقوم المبتدئ بضغط الخطوات الست إلى خطوتين (قول المتطلبات ← الحصول على النتيجة)، بينما يسير المحترف في الخطوات الست بخطوات ثابتة. يبدأ الجميع بالرغبة في اختصار الطرق في البداية، وبعد الوقوع في فخاخ "انحراف الاتجاه + التزام الكود دون تحقق" لعدة مرات، يبدأون في السير في هذه الخطوات الست بسلاسة. وأكثر ما يجب التدرب لجعله غريزة هو الخطوة الأولى والأخيرة — "الاستكشاف أولاً" في البداية و"التحقق بنفسك" في النهاية، فإذا حافظت عليهما، ستقل فرصة حدوث كوارث كبيرة بنسبة تزيد عن النصف.

وهناك سؤال شائع: "ألا يبدو اتباع هذه الخطوات الست في كل مرة أمراً متعباً؟" لا، لأنه كلما صغرت المهمة، أصبحت كل خطوة أسرع — فهذه المهمة التدريبية لا تستغرق أكثر من عشر دقائق لتنفيذ خطواتها الست كاملة. وعلاوة على ذلك، بعد الاعتياد عليها، يمكن دمج الاستكشاف والتخطيط في جملة واحدة ("افهم أولاً كيف يعمل @file ثم أخبرني كيف تنوي تعديل X دون إجراء أي تعديل"). الخطوات هي الهيكل العظمي وليست قيوداً؛ وبمجرد حفظ الهيكل العظمي، يمكنك تسريع الإيقاع بالطريقة التي تروق لك.

💡 خلاصة القول في جملة واحدة: الفارق بين المحترف والمبتدئ يكمن بالكامل في "هل أهمل خطوات تسليم العصا أم لا"؛ وأكثر ما يجب جعله بمثابة غريزة هو الخطوة الأولى والأخيرة — "الاستكشاف أولاً" في البداية و"التحقق بنفسك" في النهاية؛ وكلما صغرت المهمة كانت الخطوات أسرع، فالخطوات الست هي هيكل عظمي وليست قيوداً.

---

11 خلاصة

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

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

# 开工后（先定规矩）
帮我建个 CLAUDE.md：纯标准库别引第三方依赖；改完跑 python3 wordcount.py sample.txt 验证

# 探索（先看懂、别动手）
先别改任何代码。讲讲 @wordcount.py 怎么工作的、有没有容易崩的地方？

# 规划（出方案、等点头）
我想加 --top N 只看高频前 N 个词，顺手修不传文件名就崩溃的问题。先说方案，等我说开始再动手。

# 动手（点头放行，然后逐处审 diff）
方案可以，开始改吧。

# 验证（亲手跑，不信它说的）
（回终端跑：--top 3 / 不带 top / 不带文件名，三条各验一遍）

# 交付（看范围 → 提交 → 确认）
我改了哪些文件？ → 用一句话描述这次改动，提交它。 → 显示我最后 1 次提交。

هل رأيت بوضوح؟ — "العمل الحقيقي" هو هذه الجمل القليلة باللغة الطبيعية، والصعوبة لا تكمن في صياغة العبارات، بل في وضع كل جملة في مكانها الصحيح. لنلخص خطوات هذا المسار معاً:

الخطوة	ماذا تفعل في هذه الخطوة	الدروس السابقة المستعملة	نقطة رئيسية في جملة واحدة
البدء	الوقوف في المجلد الصحيح والتشغيل + كتابة CLAUDE.md مصغر	02 / 07 / 12 / 18	اذكر القواعد الأساسية مرة واحدة، وستظل فعالة طوال الوقت
الاستكشاف	جعل الكود يفهم الكود أولاً دون تعديل	16	الجملة الأولى دائماً "لا تعدل أولاً، افهم أولاً"
التخطيط	جعل الكود يقترح الخطة وتوافق عليها	20 (plan mode)	عند عدم الاطمئنان استخدم Shift+Tab لمنع التعديل دون موافقة
العمل	السماح له بالتعديل ومراجعة الـ diff في كل مكان	20 (تأكيد الأذونات)	المراجعة أثناء العمل أكثر توفيراً من التراجع بعد العمل
التحقق	التشغيل بنفسك للتأكد، ولا تصدق عبارة "تم التعديل"	16 / 37	نجاح التشغيل الفعلي هو الحقيقة الوحيدة
التسليم	مراجعة النطاق ← صياغة رسالة الالتزام ← الحفظ في المستودع	07	يمكنك ترك commit المحلي له، واحتفظ بـ push لنفسك

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

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

---

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

---

قراءات موصى بها

• تكامل JetBrains
• أنماط المخرجات (Output Styles): تغيير "البرنامج" دون تغيير مقدمه
• المهام الأربعة الأكثر شيوعاً: استكشاف مستودع الكود، إصلاح الأخطاء، إعادة الهيكلة، وكتابة الاختبارات