00:00:00يعلم الجميع أنك بحاجة إلى إطار عمل للتعامل مع وكلاء البرمجة، ولكن ليس لدى الكثيرين
00:00:04إطار بسيط وخاص بهم حقاً، وبإمكانهم تطويره بمرور الوقت. والآن، هناك
00:00:09الكثير من أطر العمل المبالغ في تعقيدها على GitHub. كل هذه الأنظمة متعددة الوكلاء التي
00:00:15يبتكرها الناس، أنا أحترم عملهم، ولكن في كثير من الأحيان تحتاج فقط إلى شيء
00:00:19بسيط للغاية ينجز المهمة لك. لأنني أعلم أن لديك أفكاراً جيدة
00:00:24تريد بناءها، ولا تريد قضاء وقت في إنشاء سير عمل البرمجة بالوكلاء أكثر مما
00:00:29تقضيه في البرمجة الفعلية، وهذا ما سأقدمه لك الآن. هذا هو إطار عملي البسيط للغاية
00:00:35الذي أستخدمه في كل مرة أبدأ فيها مشروعاً جديداً مع وكيل البرمجة الخاص بي. الآن، تطوير
00:00:40المشاريع القائمة (Brownfield)، أي العمل على كود موجود مسبقاً، يختلف قليلاً. وهذا موضوع لفيديو آخر. أما هنا،
00:00:45فنحن نركز على تطوير المشاريع الجديدة (Greenfield). نريد إطار عمل بسيطاً لنبدأ
00:00:50بأسرع ما يمكن في بناء أي شيء جديد، وكل ما سأغطيه هنا هو مبادئ عالمية.
00:00:56ستنطبق هذه المبادئ بغض النظر عن وكيل البرمجة الذي تستخدمه. لذا، هناك جزأين
00:01:00لهذا الفيديو، وسأقوم بعملية بناء مباشرة أمامكم بينما أشرح كل شيء
00:01:05لجعل الأمر ملموساً تماماً. وما لدي الآن في قاعدة الكود الخاصة بي هو لا شيء تقريباً
00:01:11سوى طبقة الذكاء الاصطناعي. هناك بضعة أوامر ومهارات استحضرتها. هذا ما أستخدمه كـ
00:01:16نقطة انطلاق لكل مشاريعي. سنقوم بإنشاء شيء من الصفر،
00:01:21ولذا نحتاج للبدء بالتخطيط الأولي، وإنشاء ما يسمى بـ PRD. وهذا هو
00:01:27النطاق الأولي للعمل الذي يجب علينا القيام به لإنشاء الحد الأدنى من المنتج القابل للتطبيق (MVP). وهناك
00:01:32الكثير مما يدخل هنا، كإعداد طبقة الذكاء الاصطناعي الأولية قبل البدء في أي برمجة فعلية.
00:01:37ثم نأخذ مستند PRD ونقسمه إلى مراحل عمل، وسننجزه
00:01:43باستخدام حلقات PIV. سأتحدث عما يعنيه ذلك، وسنرى مثالاً عليه، وبعد ذلك
00:01:47بينما أمضي في هذا التنفيذ الكامل، سأغطي القواعد الذهبية الأربع التي نريد
00:01:52اتباعها طوال الوقت. وهذه القواعد الذهبية ستتناسب بشكل طبيعي مع
00:01:57إنشاء مستند PRD، وطبقة الذكاء الاصطناعي، والقيام بحلقة PIV. على سبيل المثال، إدارة السياق.
00:02:03السياق هو أثمن مورد لديك عند العمل مع مساعدي البرمجة بالذكاء الاصطناعي. سيكون ذلك
00:02:08موضوعاً رئيسياً. أيضاً إنشاء الأوامر والمهارات لكل شيء وعقلية تطوير النظام،
00:02:14لأن ما نسعى إليه هنا في نظامنا هو إنشاء شيء موثوق
00:02:18وقابل للتكرار. لذا سأتحدث عن ذلك بينما أشرح كل شيء. أحاول فقط استعراض بعض
00:02:23المواضيع الأساسية التي ستراها. سيكون فيديو مليئاً بالقيمة. وسوف
00:02:28نبدأ هنا بتخطيطنا الأولي، لإنشاء ما أحب تسميته بـ "طبقة الذكاء الاصطناعي". سأشرح
00:02:34ماهيتها وسنبنيها معاً الآن. طبقة الذكاء الاصطناعي هي كل الأصول في قاعدة الكود
00:02:39التي أنشأتها لتكون بمثابة سياق لوكيل البرمجة الخاص بك. مثل مستند PRD: ماذا سنبني؟
00:02:45قواعدك العامة: كيف سنبنيه؟ الأوامر: ليكون لدينا سير عمل قابل لإعادة الاستخدام
00:02:50لوكلاء البرمجة. سنركز على الأمر الأساسي أولاً، ثم الوكلاء الفرعيين، لنتمكن من التفويض
00:02:55للقيام بالأبحاث. وبشكل عام، كيف أتعامل مع طبقة الذكاء الاصطناعي الخاصة بي، ولدي هذا المورد لك،
00:03:01هو أن لدي مجموعة عامة من الأوامر التي سأجلبها لأي مشروع جديد. والهدف
00:03:07من هذا هو أنه مع نمو قاعدة الكود وبدء بنائها، سأقوم أيضاً بتطوير أوامري لجعلها
00:03:13أكثر قوة لحالة الاستخدام المحددة، بجعلها أكثر تخصيصاً لكودي. وهذا
00:03:18هو ما أوصيك به عموماً. لذا استخدم هذا كنقطة انطلاق إذا أردت. سأترك
00:03:23رابطاً لمستودع GitHub في الوصف. الهدف من الحفاظ على بساطته هو أنه يمكنك
00:03:27أخذه لنفسك وتطويره بسهولة لحالة استخدامك وطريقة عملك المفضلة. لهذا السبب
00:03:33أوصي بشيء كهذا على حساب أطر العمل الأكثر تعقيداً مثل Beemad أو GitHub spec kit.
00:03:38إنها قوية جداً حقاً، ولكن من الصعب جعلها خاصة بك تماماً. أريدك أن تكون قادراً
00:03:42على جعل هذا خاصاً بك. الآن سأريكم كيف يبدو إنشاء مستند PRD كامل. تحديد
00:03:48القواعد الأولية لقاعدة الكود الخاصة بنا. سنقوم حتى بتخصيص أمرنا الأول قليلاً. ثم
00:03:52سأتحدث عن الوكلاء الفرعيين خلال العملية. وأعلم أننا نقوم بالكثير من التخطيط قبل كتابة أي
00:03:57كود فعلي عبر حلقات PIV، ولكن من المهم القيام بذلك. التخطيط المسبق
00:04:03قد يبدو كأننا نأخذ الأمور ببطء شديد، ولكن إذا أنشأنا خطة جيدة حقاً، كأن يكون لدينا
00:04:07قواعد جيدة ومستند PRD جيد، فهذا يعني أن كل تطويرنا اللاحق سيكون أسرع بكثير
00:04:13وأكثر موثوقية. لنبدأ بمستند PRD. يطلق عليه الكثيرون اسم "المواصفات" (spec). مرة أخرى، إنه مجرد
00:04:18النطاق الكامل للعمل لبناء النسخة الأولية من تطبيقنا. وبعد هذه
00:04:24النقطة، عندما نصل لأساس جيد، ينتقل الأمر أكثر إلى تطوير المشاريع القائمة. وهذا هو
00:04:28الفيديو القادم الذي أحضره لكم. لذا ابقوا متابعين. وما سأفعله هنا مع Claude code،
00:04:34لدي مشروع فارغ تماماً هنا باستثناء طبقة الذكاء الاصطناعي، هو أنني سأجري محادثة عفوية
00:04:40في البداية. سأخبره فقط عن فكرتي، وربما بعض الأفكار التي لدي حول التقنيات المستخدمة
00:04:45والهيكلية. تبدأ بشكل غير منظم تماماً، مما يسهل أيضاً البدء.
00:04:50ثم تصل في النهاية إلى النقطة التي تستخدم فيها محادثتك كسياق لإنشاء
00:04:55مستند PRD منظم. ولدي أمر سيساعدنا في إنجاز المهمة. سأغطي ذلك بمجرد
00:05:01وصولنا إلى هناك، ولكن أولاً لنبدأ بفكرتنا. وما أريد بناءه كمجرد
00:05:06مثال ممتع لهذا الفيديو هو شيء يشبه Linktree، بل هو نسخة تستضيفها بنفسك
00:05:12حيث يمكنك إعداد صفحة الهبوط الخاصة بك التي تحتوي على مجموعة من الروابط التي يمكنك تنظيمها.
00:05:16ولديك تحليلات مثل نسبة النقر إلى الظهور على روابطك المختلفة. أريد بناء شيء
00:05:20كهذا. إنه مثال جيد الآن لأنه ليس بسيطاً لدرجة أنك تستطيع
00:05:24برمجته بالحدس والارتجال بسهولة مع الميزات الرائعة التي يمكننا إضافتها، وفي نفس الوقت
00:05:29لن يكون معقداً للغاية بحيث لا نكاد ننجز شيئاً بنهاية هذا الفيديو.
00:05:33لذا سأستخدم أداة تحويل الكلام إلى نص لإنجاز المهمة هنا. أوصي بشدة باستخدام
00:05:39شيء مثل Aqua voice. هذا ما أستخدمه. هناك الكثير من الخيارات الجيدة والمجانية ومفتوحة المصدر
00:05:43أيضاً. Whisper flow و epicenter whispering هي أدوات رائعة متوفرة لدينا، لكنني أحب استخدام الكلام
00:05:48إلى نص لأنني أعدك، لن أتمكن أبداً من طباعة 226 كلمة في الدقيقة. لذا
00:05:54سأستخدم أداة كهذه فقط لإعطاء تفريغ ذهني كبير في البداية لما أريد بناءه. وسيكون هذا
00:05:59عفوياً جداً، لكنني سأقوم بتفريغ ذهني مباشر أمامكم الآن، وانتبهوا لما سأطلبه
00:06:03من Claude code أن يفعله لي، لأن هذا لا يقل أهمية عن الأفكار التي
00:06:09أشاركها. سأشرح قليلاً عن ذلك لاحقاً أيضاً. وبالمناسبة، يمكنك القيام بهذا
00:06:13الأمر بالكامل مع أي مساعد برمجة بالذكاء الاصطناعي. إليكم ما سأقوله: أريد بناء أداة لإنشاء صفحة روابط لوسائل التواصل.
00:06:20شيء يشبه Linktree حيث يمكن للمستخدمين إنشاء حساب. ويمكنهم إنشاء
00:06:24صفحة الهبوط الخاصة بهم حيث يحددون الروابط. ويمكنهم تغيير الترتيب. أريدهم أن يتمكنوا من
00:06:29رؤية التحليلات حتى يتمكنوا من عرض نسب النقر على روابطهم أيضاً. ويمكنهم تخصيص
00:06:33المظهر. وبالنسبة لمجموعة التقنيات، أفكر في شيء مثل Next JS، وأود استخدام Neon
00:06:37لقاعدة بياناتي و Neon Authentication. لذا، قم بالتأكيد بتشغيل وكيل فرعي لإجراء بعض الأبحاث
00:06:43حول ذلك. وبالنسبة للهيكلية، لست متشدداً بشأنها. بالتأكيد أريد توصياتك
00:06:48بشأنها. وكيف سنتعامل مع السمات وبناء الروابط وكل ذلك. وأريدك
00:06:55أيضاً أن تطلق وكيلاً لإجراء مجموعة من الأبحاث على الويب حول أفضل الممارسات
00:07:00لإنشاء تطبيقات من نوع Linktree. ثم ما أريدك فعله بعد ذلك هو العودة إليّ
00:07:04بمجموعة من الأسئلة حتى نكون على نفس الصفحة حتى في التفاصيل الصغيرة لما
00:07:10سنبنيه هنا. حسناً، جيد جداً. سأرسل ذلك وسيقوم بنسخه
00:07:14في بضع ثوانٍ هنا. ها قد انتهى، وانطلقنا في العمل. وأهم
00:07:20شيء فعلته هناك كان في النهاية عندما طلبت منه أن يسألني مجموعة من الأسئلة
00:07:25بعد إجراء أبحاثه. هذا أمر مهم جداً لتوضيحه هنا. هدفك الأول
00:07:32لأي نوع من التخطيط مع وكلاء البرمجة هو تقليل عدد الافتراضات التي يقوم بها
00:07:37وكيل البرمجة. لأنه في النهاية، عندما يرتكب وكيل البرمجة خطأً في قاعدة الكود الخاصة بك، فإن نصف
00:07:42الوقت لا يكون السبب هو أن الكود سيئ، بل لأنكما لم تكونا متوافقين على ما يجب
00:07:48بناؤه بالضبط. القول المأثور الشائع هو أن سطراً واحداً من الكود السيئ هو مجرد سطر واحد من الكود السيئ. لكن
00:07:54سطراً واحداً في خطة سيئة قد يؤدي لمئات الأسطر من الكود السيئ. أما سطر واحد سيئ في مستند PRD، فقد يعني ألف
00:08:02سطر من الكود السيئ بسبب عدم التوافق. ولذا، قمت بالكثير من التجارب
00:08:08على طرق لتقليل الافتراضات بمرور الوقت. وجعل وكيل البرمجة يقوم فعلياً
00:08:13بإعطائي سيلاً من الأسئلة قد نجح معي بشكل مذهل للغاية. لأنه خاصة مع
00:08:17Claude Code وأداة "سؤال المستخدم" (ask user question)، حيث يمكنه تقديم خيارات متعددة أو كتابة إجابتك الخاصة.
00:08:23سنرى ذلك في ثانية، إنه قوي جداً. إنهم يقومون بعمل رائع في التفكير في جميع الحالات
00:08:28الاستثنائية والتفاصيل الصغيرة التي ربما لا نفكر فيها حتى. من الصعب علينا مجرد التفكير
00:08:33بأنفسنا في الافتراضات التي قد يضعها وكيل البرمجة. لذا فهو قوي جداً. والشيء
00:08:38الآخر الذي فعلته، كما ترون هنا، هو أن لدينا وكلاء فرعيين مختلفين
00:08:42يعملون في الأبحاث. أحب استخدام الوكلاء الفرعيين لأي نوع من التخطيط، أو إنشاء مستند PRD،
00:08:48أو حتى لعملية التخطيط لحلقات PIV التي سنتحدث عنها بعد قليل. ومع
00:08:53Claude Code، لست مضطراً فعلياً لإنشاء وكلاء فرعيين خاصين بي لأن لدينا وكلاء
00:08:59الاستكشاف والبحث الفرعيين مدمجين مباشرة في الأداة. بالنسبة لوكلاء البرمجة الآخرين، قد تضطر
00:09:04لبناء وكلائك الخاصين، ولهذا السبب أردت الإشارة إلى ذلك هنا. ولكن تقريباً كل وكيل برمجة
00:09:08جيد هذه الأيام يدعم فكرة الوكلاء الفرعيين. وأنا أحب استخدامهم للأبحاث. والسبب
00:09:14في ذلك هو عزل السياق. مرة أخرى، أحد المواضيع الرئيسية هنا هو أننا نريد حقاً حماية
00:09:20سياق وكيل البرمجة الرئيسي لدينا. والسبب في أن البحث هو حالة استخدام جيدة للوكلاء الفرعيين
00:09:26تحديداً هو أنهم عندما يستكشفون، فإنهم ينظرون في كل شيء. يقومون بمجموعة من
00:09:32عمليات استكشاف قاعدة الكود أو أبحاث الويب. إنهم يحملون عشرات، بل مئات الآلاف من
00:09:36الرموز (tokens) لعملهم. لكن في الحقيقة، كل ما يهمنا هو نتائجهم، والملخص في النهاية
00:09:41الذي يعيدونه إلى سياقنا الرئيسي. وبذلك يمكننا الحفاظ على سياقنا الرئيسي نظيفاً. لا أوصي
00:09:46باستخدام الوكلاء الفرعيين للتنفيذ لأنه مع التنفيذ، عادة ما نهتم بكل
00:09:51سياق الملفات التي كنا نقوم بتحريرها وإنشائها. وإلا فسيؤدي ذلك للكثير من الهلوسة
00:09:57بناءً على خبرتي. وهذا هو السبب أيضاً في أن Claude Code ليس لديه أي وكلاء مدمجين للتنفيذ.
00:10:01إنه مخصص للبحث فقط. وهذا بالضبط ما نراه هنا. ولذا سأترك
00:10:06كل شيء يكتمل ثم سأعود بمجرد أن تتوفر لديه الأسئلة لنا. حسناً، لقد انتهى
00:10:12كل بحث الوكلاء الفرعيين ولدينا الآن المجموعة الأولية من الأسئلة للإجابة عليها. وبينما أمضي
00:10:17في هذا، أعتقد أنكم ستقدرون ذلك بقدر ما أفعل لأننا نوضح الكثير
00:10:22من الأمور. كل سؤال نجيب عليه هنا يزيل افتراضاً من وكيل
00:10:26البرمجة. ولأنه اختيار من متعدد وعادة ما يكون أحد الخيارات التي يقدمها هنا جيداً، يمكننا
00:10:31إنجاز هذا بسرعة كبيرة. لذا يمكننا أن نكون واثقين تماماً عند الانتقال للتنفيذ بأن
00:10:36لدينا كل التفاصيل محكمة. فمثلاً، كيف يجب أن تعمل بنية رابط الصفحة العامة؟
00:10:41في الواقع يعجبني الخيار الأول هنا، ثم ننتقل للتالي. كم عدد الصفحات التي
00:10:46يجب أن يكون كل مستخدم قادراً على إنشائها؟ لنجعلها صفحة واحدة لكل مستخدم. أعني، بعض هذه الإجابات
00:10:50ستكون بمجرد المضي مع الخيارات الافتراضية هنا، ولكن هناك حالات كثيرة حيث
00:10:54يسيء فهم شيء ما بشكل جوهري وهنا يمكنني كتابة إجابتي الخاصة للتوضيح. لا
00:10:59أعرف ما إذا كنت سأصادف مثالاً هنا، ولكن ما سأفعله هو أنني سأقوم فقط
00:11:03بالإجابة على جميع أسئلته، وأعود بمجرد انتهائي من ذلك. لا تحتاجون حقاً لرؤيتي أجيب على كل
00:11:07سؤال هنا لأنه قد يطرح ما يصل إلى 20 أو 25 سؤالاً. أي أنه سيأخذ هذا الأمر إلى أبعد مدى.
00:11:14ومرة أخرى، عليك أن تكون صبوراً قليلاً مع هذا، لكن كل سؤال تجيب عليه قد
00:11:19يوفر عليك مئات الأسطر من الكود السيئ. في الواقع هذا مثال جيد حيث أريد
00:11:24توضيح شيء مختلف تماماً عما اقترحه هنا. إنه يقول أن هذه هي الدفعة
00:11:30الثانية من الأسئلة التي طرحها Claude عليّ، بالمناسبة. هل يجب أن يحتوي محرر الروابط على إطار هاتف
00:11:35للمعاينة الحية؟ مثل Lovable أو Bolt.new، حيث ترى ما تنشئه وبجانبه
00:11:39أداة البناء على الجانب الأيسر أم يجب أن يكون المحرر مدمجاً في السطر؟ وأنا أريد في الواقع الحصول
00:11:44على كلا الخيارين هنا. لذا يمكنني الدردشة حول هذا الأمر. وسوف يطرح علي الأسئلة الأخرى
00:11:49بعد ذلك، ولكن الآن يمكننا إجراء محادثة صغيرة لهذا الأمر تحديداً. ولذا
00:11:53سأقول هنا، أريد أن يكون لدي محرر مدمج (inline)، ولكن أريد خيار التمكن من رؤية
00:11:58المعاينة أيضاً. لذا في الأساس أريد الحصول على ثلاثة أزرار، واحد أرى فيه المحرر فقط، وواحد
00:12:03أرى فيه كليهما، وواحد أرى فيه المعاينة فقط. أرسل ذلك ثم سيعود
00:12:08ويطرح علي المزيد من الأسئلة وسأواصل العملية فقط. ها نحن ذا. لقد انتهى Claude من طرح
00:12:13مجموعة من الأسئلة عليّ، ربما أكثر مما أحتاج، ولكن يمكنك حقاً تعديل هذا حسبما
00:12:18تريد. والآن حان الوقت لإنشاء مستند PRD الخاص بنا لأنه كما ترون من ملخص المواصفات النهائي،
00:12:23لديه حقاً فهم واضح لما سنبنيه بالضبط،
00:12:28حتى المكان الذي سأقوم بنشره فيه. سأنشر هذا على Vercel بعد بنائه.
00:12:31هذا رائع. أشعر أنه لم يعد يفترض الكثير من الأشياء. لذا ما سأفعله الآن
00:12:36هو تشغيل أمر "create PRD". سأضعه فقط في .claud/prd.md. يمكنك حقاً وضع هذا
00:12:43في أي مكان تريده. يمكنك حتى تسميته بأي اسم تريده. وأنا أستخدم الأمر الذي
00:12:47ذكرته سابقاً لأن بالعودة إلى قواعدنا الذهبية الأربع، إحدى القواعد الكبيرة هنا
00:12:53هي "حول كل شيء إلى أوامر" (commandify). إذا قمت بشيء أكثر من مرتين، وأنا بالتأكيد بدأت
00:12:59أكثر من بضعة مشاريع، فيجب عليك تحويله إلى أمر. ويُعرف أيضاً بالمهارة (skill)
00:13:03لأن Claude code قام مؤخراً بدمج الأوامر مع المهارات، ولكن لا يزال يعجبني التمييز بأن
00:13:10الأوامر هي أشياء تستدعيها بنفسك مثل slash commit. أما المهارات، فهي عندما يقرر الوكيل
00:13:15قراءة السياق، مثل فهم كيفية القيام بشيء جديد. ولذا فأنا أقوم بإنشاء أمر
00:13:20هنا لأنني أقرر، حسناً، في هذه النقطة من المحادثة، أريد تشغيل هذا الأمر لـ
00:13:27إخراج مستند PRD منظم. كجزء من هذا الأمر، أعطيه الهيكل الدقيق،
00:13:32وجميع الأقسام المختلفة التي أريدها في مستند PRD. بهذه الطريقة أجعل عمليتي بالكامل قابلة للتكرار،
00:13:38صحيح؟ جزء كبير من هذا النظام الذي أريكم إياه هنا هو أنه يمكنك إنشاء شيء يعمل
00:13:42من أجلك ومن ثم يمكنك القيام به مراراً وتكراراً لميزات جديدة وقواعد كود جديدة.
00:13:48لذا سأكتب slash create PRD. سأطلقه وسأعود بمجرد أن نحصل على
00:13:53مستند PRD النهائي الخاص بنا. حسناً، لقد تم الآن إنشاء مستند PRD وهو شامل للغاية، ولكن هذا جيد
00:14:00لأننا لن نرسل هذا إلى وكيل البرمجة الخاص بنا ليقوم بتنفيذه مباشرة. بل
00:14:04سنقوم ببناء الأشياء في مراحل موصوفة في مستند PRD الخاص بنا. لن أقوم بالكثير من
00:14:09التحقق أمام الكاميرا الآن، فهذا بالتأكيد لا يستحق وقتكم، ولكني أريد أن أقول أنه من
00:14:14المهم قراءة هذا والتأكد من أنك متوافق حقاً على كل شيء. وإلا
00:14:18سيؤدي ذلك إلى الكثير من الكود السيئ في المستقبل. وأول شيء أريد الإشارة إليه
00:14:22بسرعة هنا هو أن لدينا نطاق المنتج القابل للتطبيق (MVP)، وفي هذا يمكننا رؤية كل أسئلتنا وهي تتجسد
00:14:29في مستند PRD الخاص بنا. وهذا مهم لأن المحادثة التي أجريناها للتو كانت مجرد
00:14:34سياق غير منظم لتغذي مستند PRD. مستند PRD هو الشيء الوحيد الذي سيبقى. لذا نحتاج للتأكد
00:14:40من أن المحادثة بأكملها التي أجريناها مع وكيلنا قد وضعت هنا حقاً. لدينا
00:14:44ما هو خارج النطاق (out of scope)، وهو أمر لا يقل أهمية عما لا نريد بناءه الآن. لدينا كامل
00:14:49هيكل الدليل (directory structure). لذا فهو يفهم بالفعل بشكل عام ما الذي سيدخل في قاعدة الكود الخاصة بنا،
00:14:53وهو أمر جيد لأننا أنشأنا بالفعل مجموعة تقنياتنا وهيكليتنا. والشيء المهم
00:14:58في هذا هو أن لدينا مراحل عملنا. ومن هذا المنطلق، عندما نستخدم أمرنا الأساسي
00:15:04الذي سنتحدث عنه بعد قليل، نكون قادرين على تحديد ما قمنا ببنائه بالفعل
00:15:09في قاعدة الكود الخاصة بنا؟ وما الذي يجب علينا بناؤه تالياً بناءً على مستند PRD؟ سيكون هذا أحد
00:15:13قطع السياق المهمة في بداية كل محادثة بينما نبني الـ MVP الخاص بنا. وبالمناسبة،
00:15:19هذا هو القسم نفسه حيث أضع المراحل. كل واحدة من هذه ستكون تنفيذاً دقيقاً،
00:15:24إحدى حلقات PIV الخاصة بنا. فنقوم ببناء الأساس ونبني إدارة الروابط.
00:15:29ثم نقوم بالمظهر وسنخطط لكل واحدة من هذه بشكل فردي. لذا نحن لا نحاول
00:15:33أن نجعل وكيل البرمجة يقوم بالكثير من الأشياء دفعة واحدة. حسناً. لقد أنشأنا للتو مستند PRD وهذا حقاً
00:15:38هو الشيء الأهم. لقد اقتربنا من البدء في أول تنفيذ لنا. الشيء التالي الذي
00:15:43علينا إعداده هو قواعدنا. وسيكون هذا أساسياً جداً في البداية لأن قواعدنا
00:15:48ستتطور بالتأكيد بشكل أكبر بينما نقوم بتطوير قاعدة الكود الفعلية الخاصة بنا. ولذا أنا أستخدم
00:15:53Claude code. أنا أشير فقط إلى .agents و agents.md لأن هذا هو المعيار
00:15:58العالمي لتسمية القواعد العامة. والشيء المهم هنا هو أن القيود
00:16:04والاصطلاحات التي نريد أن يتبعها وكيل البرمجة الخاص بنا دائماً، توضع في ملف القواعد العامة.
00:16:10وهذه أشياء مثل أوامر تشغيل تطبيقنا، واستراتيجية الاختبار لدينا، واستراتيجية
00:16:16تسجيل البيانات (logging). بغض النظر عما نبنيه، نريد دائماً أن يرى وكيل البرمجة هذا. ولذا نريد
00:16:20إنشاء هذا الآن، على الأقل نسخة أولية لتبدأنا. والمكون
00:16:25الآخر الذي لدي هنا هو مجلد المراجع (reference folder). يمكنك أيضاً استخدام مهارات Claude code لهذا الغرض بالمناسبة،
00:16:30ولكن هذا أكثر عالمية لأننا في كثير من الأحيان نملك سياقاً آخر نريد للوكيل أن
00:16:35يضعه في اعتباره، ولكن فقط عندما نعمل على أجزاء محددة من تطبيقنا، مثل دليل
00:16:40لبناء مكونات الواجهة الأمامية إذا كنا نعمل على الواجهة الأمامية. والسبب في أننا لا نريد
00:16:44مجرد وضع كل هذا في agents.md هو أن هذا الملف يتم تحميله في سياق وكيل البرمجة
00:16:49في كل محادثة. وتذكر أن السياق ثمين. لذا نريد إبقاء هذا الملف مختصراً للغاية
00:16:55ثم نوجهه فقط إلى كل من هذه الملفات. حيث يمكننا إخبار وكيل البرمجة، إذا كنت تعمل
00:17:00على الواجهة الأمامية، فيمكنك قراءة هذا الملف. أو إذا كنت تبني نقاط نهاية API جديدة، فيمكنك
00:17:04لذا، فهذا يعني ببساطة الكشف التدريجي. لدينا طبقات مختلفة من السياق
00:17:09التي يمكن للعميل اكتشافها بمرور الوقت لضمان تحميل ما يحتاجه فعلياً فقط
00:17:14بناءً على المهمة الحالية التي بين يديه. وبالنسبة لهذه المهمة، لدي أمر آخر. ومرة أخرى، قمت بتحويل
00:17:20كل شيء إلى أوامر، فمثلما لدي قالب أحبه لوثائق متطلبات المنتج (PRDs)، لدي قالب أحبه
00:17:25لإنشاء قواعدي العامة. أولاً، سنستكشف ما لدينا بالفعل في قاعدة الكود.
00:17:30لأنني صممت هذا ليعمل مع قواعد الكود الحالية والجديدة على حد سواء. وفي الواقع، كل ما
00:17:35سيستكشفه هنا هو وثيقة متطلبات المنتج. سيعرف ما هي مجموعتنا التقنية، وما هي
00:17:38بنيتنا البرمجية، وسيجري بعض البحث عبر الويب عن استراتيجيات الاختبار والتسجيل، ثم يجمع كل ذلك
00:17:43مع توجيهاتي لإنشاء قواعدي العامة. ولدي الهيكل الدقيق هنا.
00:17:50لذا سيعتمد الأمر على هذا القالب الذي لدي. سأعرضه لكم بسرعة أيضاً،
00:17:55لأن هذا هو القالب الذي أحب استخدامه لجميع قواعدي العامة. ويمكنكم رؤية
00:17:59أن كل شيء هنا يهمنا حقاً بغض النظر عن أي شيء. مثل، حسناً، ها هي مجموعتنا التقنية،
00:18:04والأوامر لتشغيل واختبار الأشياء، وهيكل مشروعنا. لذا فهو يحتوي أساساً على فهرس
00:18:08لقاعدة الكود الخاصة بنا، وبنيتنا، وأنماط الكود، مثل اتفاقيات التسمية، واستراتيجيات
00:18:13الاختبار والتحقق. إنه بسيط جداً بشكل عام، لكننا سننشئه أولاً،
00:18:17ثم سأعطيكم بضعة أمثلة على الوثائق المرجعية مثل سياقنا الثانوي المتاح عند الطلب.
00:18:22لذا سأذهب إلى Claude هنا، وفي نفس المحادثة التي أنشأت فيها وثيقة متطلبات المنتج،
00:18:27سأقوم ببساطة بكتابة أمر إنشاء القواعد (create rules) لأنه يمكنني استخدام كل هذه المحادثة كفهرس
00:18:33للمساعدة. سيعرف على الفور، حسناً، ها هي وثيقة متطلبات المنتج، وها هي مجموعتنا التقنية وما إلى ذلك.
00:18:38حسناً، انتهى أمر إنشاء القواعد، ولدينا الآن قواعدنا العامة. لقد قمت
00:18:43بفتحها بالفعل. الأمر قياسي جداً هنا. لدينا مجموعتنا التقنية، والأوامر،
00:18:47مثل استخدامنا لـ Drizzle ORM لقاعدة بياناتنا على سبيل المثال، وهيكل المشروع، والبنية،
00:18:52وأنماط الكود. من أجل الاختصار، لا أقوم حقاً بتخصيص الأشياء هنا أو تطبيق
00:18:57أفكاري الخاصة على هذا كثيراً، ولكن بناءً على مدى مهارتك التقنية، فهذا هو وقتك للتأكد
00:19:03من أن القيود والاتفاقيات وأنماط الكود متوافقة تماماً مع الطريقة التي تريد بها
00:19:07إنشاء قواعد الكود الخاصة بك. لذا يمكنك قضاء الكثير من الوقت في هذا إذا أردت. أنا فقط لا أفعل ذلك
00:19:12لأنني أركز على الأفكار عالية المستوى معكم هنا. ولقد جعلته أيضاً يجري بعض الأبحاث
00:19:16عبر الويب حول أفضل الممارسات لإنشاء أشياء مثل مكونات الواجهة الأمامية ونقاط نهاية واجهة برمجة التطبيقات.
00:19:21وبناءً على ذلك، قمت بإنشاء بعض السياقات المتاحة عند الطلب أيضاً. ومرة أخرى،
00:19:24يمكن أن تكون هذه مهارات كود لـ Claude إذا رغبت في ذلك. لذا إذا عدنا إلى القواعد العامة
00:19:29وانتقلنا للأسفل إلى قسم السياق المتاح عند الطلب، فها هو ذا. عند العمل على مكونات الواجهة الأمامية،
00:19:34اقرأ هذا الملف. وعند العمل على مسارات واجهة برمجة التطبيقات، اقرأ هذا الملف. لذا فإن ملف clod.md هو الشيء الوحيد الذي يتم تحميله
00:19:40مسبقاً، لكنه سيقرر بعد ذلك جلب هذه الملفات عندما يحتاج إليها. ومن خلال خبرتي، فإنه
00:19:45جيد جداً في الرجوع إلى هذا، خاصة إذا كانت قواعدنا العامة موجزة، كما ينبغي أن تكون. فمثلاً
00:19:50ليس لدينا هنا حتى 240 سطراً، بل 233 سطراً فقط لقواعدنا العامة. ثم لدينا ملفات api.md
00:19:58و components.md. هذه الملفات أكبر بكثير لأننا عندما نكون بصدد العمل على المهمة وتكون محددة جداً
00:20:03لهذا الغرض، فلا بأس بجلب الكثير من المعلومات لضمان حصول عميل البرمجة الخاص بنا على توجيه جيد.
00:20:08لذا، وبالعودة إلى مخططنا هنا، فإن القواعد هي الطريقة التي نريد بها بناء الأشياء.
00:20:14ووثيقة متطلبات المنتج هي ما سنقوم ببنائه بالضبط. ومع وضع هذين الأمرين في الاعتبار،
00:20:19فإن آخر شيء أريد التحدث عنه هنا هو الأوامر، وتحديداً أمر التهيئة (prime).
00:20:23ثم سننتقل إلى بناء خطة مرحلتنا الأولى وإنشاء الكود. في هذه المرحلة،
00:20:29لدينا طبقة الذكاء الاصطناعي الأولية. لدينا وثيقة متطلبات المنتج، وقواعدنا، وتلك الأوامر العامة التي جلبتها
00:20:34والتي يمكنك استخدامها لنفسك بحرية. ونحن ننتقل الآن إلى التنفيذ. ولكن
00:20:39إليكم الأمر. في بداية كل محادثة جديدة مع مساعد برمجة بالذكاء الاصطناعي،
00:20:44نحتاج منه أن يواكب قاعدة الكود. ماذا نبني؟ وماذا يأتي بعد ذلك؟
00:20:50هنا يأتي دور أمر التهيئة (prime). وهذا أمر سنقوم بتشغيله (prime/) في بداية كل
00:20:56جلسة جديدة. إنها عملية موجهة له لاستكشاف قاعدة الكود الخاصة بنا والوصول إلى النقطة
00:21:02التي يمتلك فيها النموذج العقلي، ويكون مستعداً لتنفيذ الميزة التالية. وهكذا
00:21:06سنجعله يقرأ الوثائق ويستكشف الهيكل. ويمكنه استخدام عملاء فرعيين للقيام بكل هذا أيضاً.
00:21:11والتحقق من سجل git، لأن هذا شيء آخر سأتحدث عنه أكثر بعد قليل أيضاً،
00:21:15وهو استخدام سجل git كذاكرة طويلة المدى لنا. لكي يتمكن من رؤية كيفية تطور قاعدة الكود بمرور الوقت،
00:21:21لأن ذلك سيساعده في اتخاذ القرارات بشأن ما سيبنيه تالياً. وبعد هذا الأمر،
00:21:26سيخرج لنا فهمه لقاعدة الكود. لكي نتمكن من التحقق من أنه يدرك
00:21:31ما يحدث في قاعدة الكود الخاصة بنا، ونتمكن من المضي قدماً في بناء الشيء التالي. ولن نخوض
00:21:36في تفاصيل أمر التهيئة كثيراً هنا، لكننا نقوم ببعض العمليات باستخدام git للاستفادة
00:21:40من السجل التاريخي. ثم نقرأ الملفات الأساسية ونحدد أي شيء
00:21:45نحتاج إلى إيلاء اهتمام خاص له، مثل نقاط الإدخال الرئيسية لتطبيقنا على سبيل المثال. ثم
00:21:49هذا التقرير الناتج هو كيف يمكننا التحقق من فهمه. ويمكننا تطوير هذا بمرور الوقت
00:21:55لجعله مخصصاً لمشروعنا. فقط لأعطيكم مثالاً صغيراً جداً هنا، بالنسبة لقراءة الوثائق
00:22:01الأساسية، يمكنني أن أقول: اقرأ عمليات هجرة drizzle حتى تفهم مخطط قاعدة البيانات،
00:22:08أليس كذلك؟ حتى أنه استخدم الإكمال التلقائي هناك. لقد عرف بالضبط ما كنت أصبو إليه. وهكذا بينما
00:22:12تبني فهمك الخاص حول ما هي الأشياء الأساسية التي أريد من عميل البرمجة الخاص بي الاهتمام بها
00:22:16في قاعدة الكود هذه، مثل ربما الوثائق الأخرى التي لدينا في المجلد المرجعي،
00:22:20على سبيل المثال، يمكننا إضافة ذلك هنا. والآن ما سأفعله هو الذهاب إلى Claude، لكنني سأبدأ
00:22:25محادثة جديدة تماماً، لأننا الآن سندخل في أول حلقة PIV لنا. وسأشرح
00:22:30حلقة PIV كاملة بعد قليل هنا، ولكن شاهدوا هذا. سأقوم فقط بتشغيل Prime. وستكون
00:22:34تلك بداية محادثتي قبل القيام بأي شيء أريد استكشافه. وفي هذه الحالة،
00:22:39سيدرك أن هذا مشروع جديد تماماً. دعني أتحقق من وثيقة متطلبات المنتج. وسوف
00:22:44يوصي بشيء مثل: لنقم بالمرحلة الأولى أولاً. لننشئ الأساس لمشروعنا.
00:22:49لقد اكتملت تهيئة Prime الخاصة بنا. إليكم نظرة عامة على المشروع، صفحة بناء الروابط في النبذة الشخصية. الحالة الحالية،
00:22:54هو مستودع فارغ يحتوي فقط على الوثائق. لقد قمت بعمل بناء تجريبي في وقت سابق، ولهذا السبب يقول
00:22:59هذا، لكنني مسحت كل شيء في الوقت الحالي. ثم استخرج المرحلة الأولى، وهي الأساس،
00:23:04من وثيقة متطلبات المنتج الخاصة بنا. وهذا هو ما يوصي ببنائه.
00:23:10وهذا هو بالضبط ما أصبو إليه هنا. أريده أن يختار المراحل واحدة تلو الأخرى من وثيقة متطلبات المنتج. ليكون لدينا
00:23:14تنفيذات دقيقة لحلقات PIV الخاصة بنا، وبالحديث عن حلقات PIV، سوف ندخل في هذا الآن.
00:23:20لذا فإن PIV هي اختصار لـ (التخطيط، التنفيذ، التحقق). نحن نأخذ عملاً مركزاً، عادة ما يكون مرحلة من وثيقة متطلبات المنتج،
00:23:29ونقوم بتشغيلها عبر هذه العملية برمتها. لذا ننشئ خطة منظمة. وهذا هو الجزء
00:23:34هنا حول ما سنعالجه. وهذه العملية في الواقع مشابهة جداً
00:23:38لإنشاء وثيقة متطلبات المنتج. ثم ننتقل إلى التنفيذ. وهدفنا هنا هو تفويض كل البرمجة
00:23:44إلى عميل البرمجة. ثم نقوم بالتحقق بعد ذلك. وسأشرح بسرعة كيف
00:23:50تبدو هذه العملية. ثم سنمر بها عملياً. أولاً وقبل كل شيء، عندما نكون في
00:23:55مرحلة التخطيط، لدينا مستويان من التخطيط، لدينا تخطيط المشروع عالي المستوى. وهذا هو ما
00:24:00قمنا به بالفعل عند إنشاء وثيقة متطلبات المنتج وقواعدنا. والآن لدينا التخطيط الخاص بالمهمة. فكما
00:24:07ذكرت للتو، هما متشابهان جداً. إنشاء خطة منظمة يشبه إلى حد كبير إنشاء
00:24:13وثيقة متطلبات منتج منظمة. والفرق الرئيسي هو أن الخطة المنظمة تركز فقط وبشكل كبير على
00:24:19ميزة فردية وجميع المهام التي تأتي معها. لذا فنحن ننتقل الآن إلى
00:24:24الكود. لسنا في مستوى عالٍ من العمومية، لكننا لا نزال سنبدأ بمحادثة
00:24:30غير منظمة للغاية. أحب أن أسميها “تخطيط الحالة العامة”، حيث سنستكشف الأفكار العامة فقط.
00:24:35ما هي البنية البرمجية لما نبنيه بالتحديد، مع إطلاق عملاء فرعيين لتحليل قاعدة الكود
00:24:40والتوثيق، ثم مجرد اكتشاف ما هي المهام المحددة التي نحتاج
00:24:44لإنجازها لهذه الميزة؟ لذا نجري هذه المحادثة وسأريكم مثالاً عليها.
00:24:50ثم نحول ذلك إلى وثيقة منظمة، تماماً كما فعلنا مع وثيقة متطلبات المنتج. والهدف هنا هو
00:24:56إنشاء خطة هجوم مفصلة لمساعد البرمجة بالذكاء الاصطناعي بناءً على محادثتنا. فالمحادثة
00:25:02هي جزء من سياقنا، ولكن لدينا هنا أقسام محددة جداً أريد إنشاءها
00:25:09في الخطة المنظمة. الهدف ومعايير النجاح لهذه الميزة، وأي وثائق
00:25:13نريد الرجوع إليها والتي ربما وجدها أحد العملاء الفرعيين، وقائمة مهامنا، والتي يمكن أن تكون
00:25:18محددة لدرجة الملفات الفردية التي نريد إنشاءها وتحديثها. ومن المحتمل أن يكون الجزء الأكثر
00:25:23أهمية في هذه الخطة بأكملها هو استراتيجية التحقق. وهذا يشبه نوعاً ما
00:25:27التطوير القائم على الاختبار حيث نريد أن نكون محددين للغاية في كيفية التحقق من الميزة
00:25:33حتى قبل كتابة سطر واحد من الكود. وهذا يجبرنا نحن وعميل البرمجة على حد سواء على أن نكون
00:25:38محددين جداً بشأن معايير النجاح. وهكذا ننشئ خطتنا المنظمة ونحن
00:25:45جزء كبير من هذا، ولكننا بعد ذلك نفوض كل البرمجة للعميل نفسه. هذا ليس
00:25:51مجرد برمجة عشوائية. السبب الوحيد الذي سيجعلني أثق في العميل مع التحقق هو لأنني
00:25:56أحيط التنفيذ بالتخطيط والتحقق اللذين أشارك فيهما بشكل كبير كجزء من
00:26:01العملية. لذا سنجعل عميل البرمجة يتحقق من عمله من خلال اختبار الوحدات،
00:26:06واختبار التكامل، والاختبار الشامل من البداية للنهاية. وسنرى ذلك أيضاً. ولكن بعد ذلك سأقوم
00:26:11بمراجعة الكود الخاصة بي واختبار التطبيق يدوياً. وسأقوم برفعه بنفسي. وسأمر عبر
00:26:16التطبيق تماماً كأي مستخدم للتأكد من أن كل شيء يعمل جيداً قبل أن أقوم بعملية
00:26:20التثبيت (commit) وإرساله إلى الإنتاج أو بيئة الاختبار أو أي شيء آخر. الشيء المهم هنا هو أنه
00:26:26بين التخطيط والتنفيذ، سأقوم بإعادة ضبط السياق. هذه واحدة من
00:26:32القواعد الذهبية. السياق ثمين جداً. ولذلك أجريت محادثة طويلة ومفصلة لاكتشاف
00:26:38هذه الميزة التي سنقوم بتنفيذها. ثم الخطة المنظمة التي أنشأتها هنا، أريدها
00:26:44أن تكون كل السياق الذي يحتاجه عميل البرمجة لإنجاز المهمة بحيث يمكنني الحصول على محادثة
00:26:50جديدة حيث تكون الخطة هي الشيء الوحيد الذي أرسله لأنها تحتوي على جميع الوثائق
00:26:55للرجوع إليها. وبها قائمة المهام كاملة. لذا نحن نعرف ما يجب علينا فعله. ونعرف كيف نتحقق. وبهذه
00:27:00الطريقة يمكننا فقط قطع الأمور والانتقال إلى التنفيذ للحفاظ على التركيز الشديد، أليس كذلك؟ نحن
00:27:06لا نريد وجود الكثير من السياق الذي يثقل كاهل المحادثة عندما نبدأ في كتابة
00:27:12الكود الفعلي. حسناً. مع ذلك، دعونا الآن ندخل في أول حلقة PIV لنا. وسيكون هذا
00:27:16أبسط بكثير مما تعتقد لأننا حقاً سنحصد ثمار كل التخطيط
00:27:22الذي قمنا به مسبقاً. نحن على وفاق مع عميل البرمجة الخاص بنا. ونحن واثقون من أنه يفهم
00:27:27ما نريد بناءه. ولذلك لا يوجد حتى هذا القدر الكبير من التخطيط الذي سيتعين علينا القيام به لكل من
00:27:31هذه المراحل، على الأقل في البداية. وبالعودة إلى هنا، لقد انتهينا من التهيئة. ونحن
00:27:36على وفاق مع عميل البرمجة. وقد أعطيته مطالبات بسيطة جداً هنا. مثل، نعم، المرحلة الأولى
00:27:40تبدو جيدة. فقط أكد لي بالضبط كل ما سنقوم ببنائه. الآن، عادةً في حلقات
00:27:44PIV بعد الحلقة الأولى، يكون الأمر أكثر تفصيلاً. مثل لنلقي نظرة على قاعدة الكود لمعرفة كيف
00:27:49سنقوم ببناء هذا بالضبط. ولكن هنا، الأمر بسيط جداً. لذا هذا يبدو جيداً. والآن
00:27:53تذكروا، حولوا كل شيء إلى أوامر. أريد تحويل هذه المحادثة وفكرة المرحلة الأولى هذه إلى
00:27:59خطة منظمة مع قائمة مهام وتحقق. لذا لدي أمر آخر لذلك. يسمى
00:28:04ببساطة “خطة الميزة” (plan feature/). ها هو ذا. سأرسل هذا والآن أمر خطة الميزة،
00:28:10تماماً مثل إنشاء وثيقة متطلبات المنتج، يحتوي على فكرة الخطة المنظمة مدمجة فيه. سأريكم
00:28:17هذا الأمر أيضاً. إذن، خطة الميزة، لنفتح هذا. إنه يقبل وسيطاً اختيارياً حيث يمكنني
00:28:23تحديد ما أريد بناءه. في هذه الحالة، أنا فقط أستخدم سجل المحادثة. لذا فقد عرف بالفعل،
00:28:28لكننا نمر بعملية مرحلية هنا. لذا فهم الميزة من خلال الغوص في قاعدة الكود، وهو
00:28:33مرة أخرى، أكثر قابلية للتطبيق في حلقات PIV المستقبلية، لكنه يقوم بالكثير من البحث، ويجلب الوثائق
00:28:38ذات الصلة، لضمان حصولنا على مجموعة غنية من السياقات قبل الدخول في التنفيذ. ثم
00:28:44ما تنظرون إليه هنا، هذا هو القالب. لذا نريد وصف بيان المشكلة،
00:28:49وأي سياق أو مرجع. لدينا خطة التنفيذ مع قائمة المهام هنا. وبالطبع
00:28:55لدينا استراتيجية الاختبار. نريد تحديد عملية التحقق مسبقاً. وبعد أن ننشئ
00:29:00هذه الخطة، بالطبع، سنقوم بالتحقق منها. سنتأكد من أننا محددون جداً،
00:29:05خطوة بخطوة، إليك بالضبط كيف نريد منك التحقق من التطبيق. وأنا أستخدم بالفعل
00:29:11مهارة Vercel agent browser CLI، والتي قمت بعمل فيديو عنها وسأضع رابطه هنا. لذا
00:29:17سنقوم ببناء أتمتة كاملة للمتصفح. سيقوم العميل بتشغيل الواجهة الخلفية والأمامية
00:29:21وتشغيل عمليات هجرة قاعدة البيانات، والمضي قدماً في بناء شجرة الروابط الخاصة به وجعل
00:29:26كل شيء يعمل تماماً كما سيستخدم المستخدم التطبيق. هذا مثير جداً،
00:29:31ولكن التحقق سيكون مفصلاً للغاية هنا لكي نكون واثقين جداً في التنفيذ
00:29:36بحلول الوقت الذي تعود فيه السيطرة إلينا، لا نزال نقوم بالتحقق بأنفسنا، ولكن الأمر سيكون
00:29:42أقل جهداً بكثير. حسناً. لقد تم إنشاء خطتنا الآن. دعونا نلقي نظرة. لقد قمت
00:29:47ببعض التحقق خلف الكواليس. سأريكم ذلك بعد قليل. عادةً ستقوم بالتكرار والمراجعة بشكل جيد
00:29:52لأنك تريد التأكد من أن فهمه للمرحلة الأولى متوافق مع ما لديك في
00:29:56وثيقة متطلبات المنتج، وما تريد بناءه حقاً، لذا مر عبر جميع الأقسام. أشجعكم على القيام بذلك. إذن
00:30:01ها هي خطة التنفيذ الخاصة بنا مع قائمة المهام. إنها مفصلة للغاية، وهذا جيد. نريد أن نكون
00:30:05محددين الآن بما أننا نركز بشدة على ميزة واحدة. لدينا التحقق الخاص بنا مع هرم التحقق
00:30:10بالكامل، كما أحب أن أسميه. مثل التحقق من الأنواع والتنسيق واختبار الوحدات. وبعد ذلك
00:30:15نحن محددون جداً للاختبار الشامل، وجميع رحلات المستخدم التي نريد أن يمر العميل بها.
00:30:20لكي نكون واثقين في التنفيذ عندما يعود إلينا. وهذا شيء
00:30:24لم يفعله جيداً في البداية. ولذلك قمت بمطالبة متابعة هنا فقط لأعطيكم
00:30:29مثالاً سريعاً على كيفية تكرار وتحسين الخطة قبل إرسالها للتنفيذ.
00:30:34وهناك جوهرة صغيرة أخرى، أعدكم بأننا سندخل في التنفيذ بعد ثانية،
00:30:38لكن هذا مهم حقاً. بشكل عام، عملاء البرمجة ليسوا الأفضل في التعامل مع متغيرات
00:30:43البيئة. فهم يقعون في أخطاء. وإذا لم تكن متغيرات البيئة معدة قبل التنفيذ،
00:30:48فسيؤدي ذلك فقط إلى إجراء مجموعة من الاختبارات الوهمية ويقول إن كل شيء قد تم التحقق منه بينما ليس كذلك في الواقع،
00:30:53وهذا أمر محبط حقاً. ولذلك عادةً ما أحب القيام به بالتوازي مع التخطيط
00:30:57هو أننا سننشئ ملف .env.example وسأجعله ينظر هنا. لكي يعرف جميع متغيرات
00:31:03البيئة التي قمت بضبطها، ثم سأقوم بإعداد متغيرات البيئة الخاصة بي أيضاً. وبالطبع
00:31:09لن أعرض هذا الملف لأنه يحتوي على أسراري لعنوان URL لقاعدة البيانات وأشياء من هذا القبيل. ولكن
00:31:13لأنني قمت بإعداد ذلك بالفعل، يمكننا الآن الانطلاق في التنفيذ بالكامل وليس
00:31:19مجرد كتابة الكود، بل يمكنه تشغيل هجرة قاعدة البيانات، وبدء الواجهة الخلفية والأمامية،
00:31:23واستخدام Vercel agent browser CLI لاختبار كل شيء. ولا يضطر للتوقف من أجلي
00:31:29لأقوم بضبط متغيرات البيئة الخاصة بي. وهكذا قمت بإعداد المسرح بشكل مثالي الآن وبالانتقال إلى
00:31:34التنفيذ وأنا سعيد جداً بهذه الخطة. الآن، تذكروا إعادة ضبط السياق لأن السياق
00:31:40ثمين. أنا الآن في نافذة سياق جديدة تماماً حيث سأستخدم أمر التنفيذ الخاص بي والوسيط
00:31:45الوحيد هو الخطة التي أوجهه إليها. هذا هو كل ما يحتاجه لسياقه الآن. وما
00:31:51سأفعله هو أنني سأتوقف مؤقتاً وأعود بمجرد انتهائه من الأمر بالكامل. وفي الحقيقة نحن
00:31:56نفوض كل البرمجة للعميل الآن، ونحصد ثمار كل الجهد الذي بذلناه في التخطيط.
00:32:01كل حلقة PIV فردية عند هذه النقطة ستكون سريعة جداً الآن بسبب العمل الذي بذلناه في
00:32:06هذا. حسناً، لقد اكتمل تنفيذنا. يمكننا أن نرى من لقطات الشاشة أنه أجرى اختباراً
00:32:11كاملاً من البداية للنهاية. لذا يمكنك أن تكون واثقاً جداً في التنفيذ لأن العميل قد تكفل
00:32:16بالفعل بكل شيء هنا، ولكن لا يزال من المهم بالنسبة لنا إجراء عمليات التحقق البشرية. يمكننا
00:32:21حقاً التأكد من أننا نثق ولكن نتحقق. وبالنسبة لمراجعة الكود، فهذا يدخل في
00:32:26تفاصيل دقيقة جداً. لذا لن أفعل ذلك الآن، ولكن إذا كنت أكثر مهارة من الناحية التقنية، فمن
00:32:30المهم بالتأكيد أن تفعل ذلك. ولكن ما سأفعله هو اختبار التطبيق مباشرة معكم.
00:32:35الشيء الوحيد الذي فعلته خلف الكواليس هو أنني أنشأت حساباً بالفعل للتأكد من أن عملية
00:32:39المصادقة الأساسية تعمل، لكنني لم أفعل أي شيء هنا بعد. وانظروا إلى هذا. هذا
00:32:43رائع جداً. إنه يبدو جميلاً حقاً بالفعل. لذا يمكنني ضبط اسم العرض الخاص بي. يمكنني كتابة نبذة مثل
00:32:49باني ذكاء اصطناعي رائع. حسناً، يمكنني ضبط رابط صورتي الشخصية. لقد قمت برفع صورة على Imgur. حسناً،
00:32:55هذا يبدو جميلاً جداً أيضاً. يمكنني إضافة بعض الروابط مثل، حسناً، سأضيف يوتيوب. ثم هذا هو
00:32:59رابط [youtube.com/@colemedine](https://www.google.com/search?q=https://youtube.com/%40colemedine). حسناً، يبدو رائعاً. أضف رابطاً آخر. سأضيف لينكد إن. ليس
00:33:08لدي رابط لينكد إن الخاص بي الآن. لذا سأضع فقط linkedin.com. لا يهمني حقاً. حسناً،
00:33:11جميل. ودعوني أضيف واحداً آخر فقط. سأضيف إكس. حسناً، لنضع فقط x.com. رائع جداً. ويمكنني
00:33:18سحب هذه الروابط لإعادة ترتيبها. يتم عكس ذلك تلقائياً هنا. يمكنني عرض المحرر فقط ثم
00:33:24تعديل المعاينة. السمة لا تبدو في أفضل حالاتها الآن. كأنها بيضاء فقط، لكنني أعتقد أن
00:33:28ذلك يأتي في مرحلة لاحقة على أي حال، لأننا الآن نقوم فقط ببناء الأساس. لذا فالكثير من
00:33:32هذا ليس مثالياً بعد، ولكنه لا يزال يبدو جيداً للغاية كنقطة بداية. ومن ثم
00:33:37يمكنني النقر على حفظ. و، حسناً، نعم، لنقم بتحميل نقاط نهاية واجهة برمجة التطبيقات. هذا يعمل على المضيف المحلي.
00:33:42ها هو ذا. تم حفظ التغييرات بنجاح. لذا يمكنني إجراء تحديث وسيظل كل شيء
00:33:46موجوداً هناك. حسناً. هذا مذهل. إذن هذا يبدو جيداً حقاً. والآن ما أريد التحدث عنه
00:33:51بما أننا وصلنا إلى بناء أساس جيد هو رسالة التثبيت (commit) بسرعة كبيرة هنا.
00:33:57ولذلك لدي أمر آخر يسمى commit/، وهذا الأمر أساسي جداً. يمكنك
00:34:01جعل هذا أكثر تفصيلاً إذا أردت، ولكن في الأساس تريد فقط تقديم تعليمات للعميل حول
00:34:06كيفية إنشاء رسالة git، لأننا سنستخدم ذلك كذاكرة طويلة المدى لنا. وبالعودة
00:34:11بالعودة إلى المخطط هنا، هذه إحدى القواعد الذهبية. سجل التعديلات (commit history) هو ذاكرتك طويلة المدى.
00:34:17لذا، فنحن نقوم بتوحيد رسائلنا، ولهذا السبب نستخدم الأمر "slash commit"
00:34:22لجعل هذا قابلاً لإعادة الاستخدام، وعندها يستطيع الوكيل، أثناء عملية التهيئة، النظر في سجل الـ git لمعرفة
00:34:28تاريخ ما بنيناه مؤخراً، مما سيوجه الخطوات التالية وربما الأنماط التي
00:34:32نريده أن يتبعها. وهذه هي قوة رسالة التعديل هذه هنا. لذا سأقوم بكتابة "slash commit"،
00:34:38ورغم أنه يمكنني تنفيذ "git commit" بنفسي، فالأمر سهل للغاية، لكن هذا يضمن
00:34:43أن تكون الرسالة دائماً من نفس النوع لضمان الاستمرارية. في هذه الحالة، لا يوجد شيء لاعتماده
00:34:48لأنني قمت بتشغيل هذا خلف الكواليس أيضاً، ولكن من المهم الاهتمام بذلك بعد كل
00:34:53عملية تنفيذ. الآن، هناك أمر آخر غاية في الأهمية يجب تغطيته بعد أن وضعنا
00:34:58الأساس لمشروعنا، وهو إعداد إطار عمل لاختبار التراجع (regression testing).
00:35:04نريد التأكد من أننا بينما نمضي في حلقات التطوير المستقبلية، أي تكرار هذه العملية مراراً
00:35:09لكل الميزات التي نريد بناءها، نحتاج للتأكد من أن الأشياء القديمة لا تتعطل. وسوف
00:35:14أغطي هذا بمزيد من التفصيل في فيديو آخر، حيث سأعرض كل الاستراتيجيات التي لدي لتنفيذ
00:35:19هذا النوع من بيئة الاختبار بنفسك، لأنك تذهب ببساطة إلى الوكيل وتقول: "حسناً، ما
00:35:25لدينا الآن رائع، لكن يمكنني أيضاً الدخول إلى Aqua voice هنا والقول: أريدك أن تدرج لي كل
00:35:31اختبارات (End-to-End) التي أجريتها ووضعها في أمر خاص لي. حتى أتمكن من تشغيله لاحقاً بعد
00:35:36بناء ميزات أخرى للتأكد من أن كل ما بنيناه سابقاً لا يزال
00:35:41يعمل بشكل صحيح، أليس كذلك؟ شيء من هذا القبيل. مرة أخرى، لن أخوض في التفاصيل العميقة لهذا
00:35:46الآن. فإعداد بيئة اختبار يستغرق وقتاً، ولكن هذه هي الطريقة التي تضمن بها
00:35:50استقرار تطبيقك بينما تستمر في البناء فوقه. وهذا يتطلب
00:35:55الكثير من العمل لإنشاءه وصيانته لأن عليك تحديثه باستمرار. لذا، هناك أيضاً
00:36:00حلول متوفرة تتولى هذا الأمر نيابة عنك، وهي قوية جداً. وأحد هذه
00:36:05التطبيقات هو QA tech. لديهم وكلاء اختبار بالذكاء الاصطناعي يتطورون ويتكيفون مع كود مشروعك.
00:36:11لذا فبينما تضيف المزيد من الميزات، يضيفون هم المزيد من حالات الاختبار للتأكد من أن
00:36:16تطبيقك يعمل بشكل جيد مع استمرارك في تطويره. وسأريك
00:36:22مثالاً على ذلك بسرعة. البدء به سهل للغاية. تذهب إلى QA tech، لديهم
00:36:26فئة مجانية لتبدأ وتجربه. سأنشئ مشروعاً هنا، وبعد ذلك عليك فقط
00:36:30لصق الرابط الذي تريد اختباره. لقد أخذت هذا التطبيق بما أنني قمت بالفعل برفع التعديلات
00:36:35ودفعتها إلى GitHub. وقمت بنشره في دقيقة واحدة فقط على Vercel. وهو أسهل مكان لاستضافة
00:36:40مواقعك مجاناً، خاصة عندما تبني باستخدام Next.js. لذا سأذهب إلى مشروعي هنا
00:36:45وأقوم بلصق هذا الرابط. سيستغرق الأمر بعض الوقت لإنشاء مشروعك وتحليل
00:36:50الكود الخاص بك. وما يمكننا فعله هو القول: "أريد إعداد اختبار جيد لموقعي. ساعدني في إنشاء
00:36:55أول ثلاث إلى خمس حالات اختبار". وهذا يشبه، كما تعلمون، Bolt.new أو Lovable،
00:36:59أو يمكنك فقط إعطاء أمر لأي شيء تريده لإعداد مجموعة الاختبارات
00:37:04لمشروعك. ولكن هذا ما يوصون به للبدء. سأقوم بإرسال هذا الآن.
00:37:08إنه أمر رائع لأنه سيقوم بفحص موقعك، والزحف فيه فعلياً، دون
00:37:12أن تضطر لإدارة البنية التحتية على الإطلاق. فهو يحلل موقعك ويستخرج حالات الاختبار.
00:37:16سأعود بمجرد انتهائه من ذلك. أثناء التنفيذ، أردت فقط أن أريكم بسرعة
00:37:21أنه قام بالزحف في موقعي في غضون دقيقتين فقط. ومن الأمور المهمة جداً
00:37:25أننا نحتاج لطريقة لتسجيل الدخول إلى موقعنا. نريد أن تتمكن الأتمتة من فعل ذلك.
00:37:29لذا لديهم طريقة لإدخال اسم المستخدم وكلمة المرور، وسيقومون بتخزينهما
00:37:34بطريقة آمنة. لقد أنشأت حساباً تجريبياً هنا. سأقوم بحفظه. ومن ثم
00:37:38سيستخدم ذلك للدخول إلى الموقع، والتعمق فيه وفهم كل رحلات المستخدم التي
00:37:43نريد اختبارها هنا. وها قد انتهى. لقد قام بإنشاء مجموعة من حالات الاختبار لنا، ويمكننا
00:37:48حتى النقر على كل واحدة منها. ونرى المسار الدقيق الذي سلكه. والآن
00:37:53لدينا كل هذه الاختبارات معدة. ووكلاء الاختبار بالذكاء الاصطناعي في QA tech سيطورون
00:37:59حالات الاختبار هذه بمرور الوقت للتأكد من استمرار تغطية كل شيء في الكود. ومع بنائنا
00:38:04للمزيد والمزيد من الميزات، يصبح الأمر رائعاً جداً. ومرة أخرى، يمكننا بناء نظام الأوامر الخاص بنا
00:38:09للقيام بشيء كهذا. لكنني أقدر حقاً وجود منصة تتولى كل هذا
00:38:14نيابة عني. وهناك وكلاء يعملون في الخلفية يمكنني الدردشة معهم حتى للعمل على
00:38:19الاختبار هنا والتأكد من أنني أجري اختبار تراجع لكل شيء حقاً. وعندها كلما
00:38:24حدث خلل ما، يمكنني المجيء إلى هنا والقول: حسناً، هناك ثغرة في التطبيق الآن،
00:38:28قم بإنشاء اختبار يفشل حالياً. دعني أعالج المشكلة. وبعد ذلك يجب أن
00:38:33ينجح الاختبار. وهذا يأخذنا إلى آخر قاعدة ذهبية لدي هنا، وهي عقلية تطوير النظام.
00:38:40لذا فكلما واجهنا ثغرة في الكود، من المهم ألا نكتفي بإصلاح الثغرة فحسب،
00:38:46بل نفكر فيما يمكننا إصلاحه في طبقة الذكاء الاصطناعي لدينا. حتى لا يتكرر ذلك مرة أخرى. فربما نحتاج
00:38:51أن نكون أكثر تحديداً بشأن دليل التنسيق والقواعد، أو إنشاء سياق جديد عند الطلب لذلك.
00:38:57ربما نحتاج لمزيد من اختبارات (End-to-End) الموضحة في أوامرنا، وسير العمل لدينا،
00:39:02أو أي شيء يلزم لضمان عدم مواجهة هذه المشكلة مجدداً. وبعد ذلك يمكننا أيضاً
00:39:06فعل ما أريتكم إياه في QA tech أو نظامنا الخاص، حيث نضيف اختباراً للتأكد من أننا
00:39:12لن نواجه تلك المشكلة مرة أخرى في الكود. وقوة هذا الأمر، رغم أنه
00:39:16يستغرق وقتاً، هي أننا نجعل وكيل البرمجة أكثر موثوقية وقابلية للتكرار بمرور الوقت، ونطوره
00:39:21جنباً إلى جنب مع الكود الخاص بنا. وبذلك نقوم بثلاثة أشياء بالتوازي. فبينما نقوم ببناء
00:39:26الكود، نحن نطور قاعدة الاختبار، والكود، وطبقة الذكاء الاصطناعي. وهذا التأثير
00:39:32يتضاعف بمرور الوقت. وبالعودة إلى Cloud Code هنا، سأعطيكم مثالاً بسيطاً
00:39:37على ذلك. أحد الأشياء التي فعلتها للتطوير خلف الكواليس هو العمل على تصميم الموقع.
00:39:43لأنك إذا عدت لبداية الفيديو، ستجد أنني نسيت نوعاً ما التحدث عن
00:39:47التنسيق، وكيف أردت أن يبدو الموقع بالضبط. لذا قام Cloud Code بوضع
00:39:51افتراضاته الخاصة. ولم يبدُ الموقع في أفضل حال. لذا كان عليّ العمل على ذلك.
00:39:56وأحد الأشياء التي يمكنني فعلها هنا هو القول: "في البداية، لم يعجبني التنسيق الذي نفذته للواجهة الأمامية.
00:40:01من الواضح أنه ليس لدينا ما يكفي في طبقة الذكاء الاصطناعي من قواعد وسياق عند الطلب
00:40:06لدليل التنسيق. لذا أريدك أن تقوم ببعض التفكير التحليلي (meta reasoning) هنا. لا تغير أي شيء، بل ساعدني
00:40:10في التفكير الآن، ما الذي يمكننا تغييره في قواعدنا أو سياقنا عند الطلب، أو شيء يمكننا
00:40:15إضافته أو تحديثه حتى نحصل على أنماط تصميم أكثر اتساقاً سنقوم ببنائها بينما
00:40:20نستمر في تطوير التحليلات والأشياء الأخرى، والصفحات الأخرى في هذا التطبيق".
00:40:25والشيء المهم الذي أفعله هنا هو إخباره ألا يغير أي شيء بعد،
00:40:29لأنني عادة ما أريد سيطرة أكبر بكثير على تغيير طبقة الذكاء الاصطناعي، على عكس
00:40:34الكود الذي أريد تفويض أكبر قدر ممكن منه للوكيل. لذا أجعله يحلل معي،
00:40:39لكنني أفضل عادةً إجراء هذه التغييرات الصغيرة والمركزة جداً بنفسي. ويمكنك أن ترى هنا
00:40:44أنه يوصي بإنشاء ملف style.md في مجلد المراجع (reference). ليكون الجزء الثالث من السياق عند الطلب
00:40:50بالنسبة لنا. وأعتقد أن هذا سيتماشى مع components.md. هذا الأخير يشبه: "هكذا
00:40:54يجب أن نرتب الأشياء". أما styles.md فهو: "هكذا تعمل الأمور. هكذا يجب أن نعمل
00:40:58مع Tailwind CSS وربما Shad CN، على سبيل المثال". لن أخوض في كامل
00:41:03عملية التنفيذ وتصحيح كل شيء، بل أحاول فقط إعطاءكم مثالاً جيداً هنا
00:41:06على أنه عندما نواجه أي شيء به ثغرات في الكود أو لا يتماشى تماماً معنا،
00:41:11مثلما حدث هنا، فهي دائماً فرصة لنا لتطوير طبقة الذكاء الاصطناعي. وبذلك نصبح
00:41:16أكثر انسجاماً مع وكيل البرمجة الخاص بنا لهذا المشروع المحدد، مع استمرارنا في بنائه.
00:41:20وهذا يا صديقي هو الجزء الأكثر تأثيراً في العملية بأكملها، وقد ادخرت الأفضل
00:41:26للنهاية. هذا كل شيء. إنها حقاً عملية بسيطة جداً للحصول على نتائج موثوقة وقابلة للتكرار
00:41:32مع وكلاء البرمجة عند بدء مشاريع جديدة، لأنه الآن بعد
00:41:35تطوير النظام، نعود مرة أخرى إلى البداية ونمر بمزيد من حلقات PIV مستخدمين
00:41:40نفس العملية تماماً لبناء كل المراحل في وثيقة متطلبات المنتج (PRD)، وإضافة أي ميزات أخرى، وأي شيء
00:41:45يلزم للوصول إلى المنتج الأدنى القابل للتطبيق (MVP). وبعد ذلك سينقلنا هذا إلى تطوير المشاريع القائمة (Brownfield)
00:41:49في أحد الفيديوهات القادمة التي سأقوم بنشرها على قناتي. فإذا كان كل هذا
00:41:54يبدو جيداً بالنسبة لك وتريد التعمق أكثر مع مكتبة مواردي الكاملة من الأوامر والقواعد، وتريد
00:41:59أن ترى كيف يبدو تطوير النظام حقاً وتتعمق في ذلك. فبالتأكيد ألقِ نظرة على
00:42:04دورة البرمجة باستخدام الوكلاء التي أقدمها في مجتمع Dynamics. سأترك رابطاً لها في
00:42:08الوصف وفي التعليق المثبت. وهذا كل ما لدي لكم الآن. فإذا
00:42:13أعجبكم هذا الفيديو، وكنتم تتطلعون للمزيد حول البرمجة بالوكلاء وفيديو
00:42:17تطوير المشاريع القائمة، سأقدر حقاً الإعجاب والاشتراك. ومع ذلك، سأراكم في
00:42:22الفيديو القادم.