Building AI Apps Live from Cairo 🔴
تحب تدعم البث؟ عضوية «داعم» على يوتيوب بـ 60 جنيه في الشهر: شارات، إيموجي، وأسئلتك بجاوبها الأول في البث. اشترك كداعم
الخلاصة
يركّز البث على تطوير مركز أوامر يربط خريطة المشاريع ولوحة المهام والموجّهات بجلسات وكلاء البرمجة. نوقشت مفاضلات تشغيل الوكلاء داخل Electron مقابل مسار هجين يرسل موجّهات منظّمة إلى Warp أو Cursor، مع إبقاء المشغّل قادرًا على المتابعة والتدخل ومزامنة حالة المهام. شملت التجارب توليد الموجّهات، فتح جلسات Warp، اللصق الآلي، واختبار جلسات Claude Code التفاعلية؛ لكن الاختبارات كشفت مشكلات في نقل الموجّه، وحالات إنجاز مضللة، وحدودًا في أتمتة تبويبات Warp، لذلك لم يثبت اكتمال التدفق النهائي. كما تناول البث استخدام لقطات الشاشة وDOM وPlaywright لإعادة بناء عناصر واجهة، والبحث عن مراجع تصميمية، وتوزيع النماذج بحسب أدوار الوكلاء، مع بقاء بعض الاتصالات والتعيينات والنتائج البصرية غير محسومة. وظهرت أيضًا مناقشات مفيدة عن أتمتة المحتوى وSEO، والتحقق من قيمة الأدوات قبل بيعها أو دفع اشتراكها، وتشخيص نفاد حصة YouTube API، وأهمية خريطة المشاريع لمقاومة التشتت، والتعلم العلني وتقديم مزيد من المحتوى التقني بالعربية.
43 لحظة من البث
- 1:28:22
مقارنة تشغيل Warp بالتنفيذ الكامل داخل Electron
قورنت طريقتان: إطلاق الجلسات في Warp، وهو نموذج أولي أخف وأسرع لكنه يفرض التنقل بين التطبيقات والتتبع اليدوي ولا يمنح التطبيق تحكماً موثوقاً في الأعطال؛ وتشغيل الوكلاء كعمليات فرعية داخل Electron، وهو أعقد لكنه يتيح ربط المهام بالعمليات، اكتشاف حالتها، التقاط النتائج، فصل المهام المتزامنة وربط مراحل خط العمل تلقائياً. تقديرات الجهد والجدوى الواردة كانت تقديرات نقاشية وليست نتائج اختبار.
- 1:30:57
ملاءمة مكوّن طرفية يعمل داخل المتصفح
مناقشة قصيرة لمكوّن طرفية مبني للويب وTypeScript، مع توضيح أنه مكوّن لواجهات وتجارب سطر الأوامر داخل المتصفح، وليس تطبيقاً مستقلاً قابلاً للتنزيل، ولذلك قد لا يطابق احتياج مركز قيادة أوسع.
- 1:31:26
مركز قيادة يربط المهام والموجّهات وجلسات الوكلاء
تصور لمركز قيادة يحتوي المشروع ومهامه وموجّهات النظام، ويربط عدة وكلاء لتنفيذ المهام آلياً. يناقش التصميم تجميع الموجّه، تشغيل جلسات سحابية، إعادة النتائج إلى المركز، وحفظ سجل المحاولات لكل مهمة بدلاً من نسخ الموجّهات يدوياً إلى أداة خارجية.
- 1:33:54
مفاضلات تشغيل وكلاء CLI بصورة غير تفاعلية
تقييم لتشغيل دورة الوكلاء داخل Electron دون تدخل تفاعلي. تشمل القيود عدم القدرة على الإجابة عن أسئلة التوضيح أو مطالبات الصلاحيات أثناء التشغيل، والحاجة إلى عارض مخرجات مخصص، وإدارة العمليات والذاكرة والعمليات المتروكة، ومنع تعارض الكتابة عند تعديل وكلاء متعددين للملفات نفسها. يظل النهج جذاباً مع موجّهات جيدة، لكن صلاحيات التنفيذ تبقى مصدر القلق الأساسي.
- 1:35:39
طلب سير عمل عملي قبل بناء محرك تنفيذ
يبحث النقاش في الحاجة إلى محرك خلفي قادر على تشغيل CLI، مع تحفظ على استثمار عدة أيام في بناء شيء قد لا يُستخدم. وينتهي بطلب شرح كامل لسير العمل المقترح ومثال حي باستخدام مهمة حالية، قبل الالتزام بالتنفيذ.
- 1:38:05
تصور خط أنابيب وكلاء كامل داخل Command Center
استعراض خيار يشغّل مراحل Explorer ثم Planner ثم Builder من بطاقة المهمة، مع بث المخرجات وحفظ ناتج كل مرحلة وتمريره إلى التالية. رغم جاذبية الفكرة، اعتُبر تنفيذ الجلسات وإدارتها بالكامل داخل Command Center معقدًا وربما مبالغًا فيه، لذلك وُضع الخيار جانبًا مؤقتًا.
- 1:44:48
تكامل هجين بين لوحة المهام وWarp أو Cursor
يقترح الخيار الأبسط أن تولّد لوحة المهام prompt دقيقًا يتضمن سياق المهمة وتعليمات الإبلاغ، ثم ترسله أو تنسخه إلى Warp أو Cursor بدل استضافة جلسة الوكيل داخل التطبيق. يستطيع المستخدم متابعة الجلسة والتدخل فيها، بينما يُطلب من الوكيل تحديث متتبع الحالة؛ لكن موثوقية ذلك تعتمد على اتباعه للتعليمات، لذا طُرحت مهلة للكشف عن غياب التحديثات.
- 1:50:10
اعتماد مسار Warp ووضع مواصفة التنفيذ
نوقش API كبديل مرن لكنه غير مجدٍ من ناحية التكلفة لهذا الاستخدام، مع بقاء عدم يقين حول أتمتة Warp الخاصة. استقر التصور على فتح جلسة داخل نافذة Warp القائمة، تشغيل المهمة من prompt مولّد، ثم إعادة النتيجة وحالة الإنجاز إلى swim lane في Command Center مع إبقاء الجلسة متاحة للتفاعل إذا لم تكتمل المهمة. بعد ذلك طُلب إنشاء ملف Markdown يصف الحل وخطوات تنفيذه، مع اعتبار بروتوكول الإبلاغ جوهر الحد الأدنى للتشغيل؛ وتوقفت الصفحات عند سؤال هل تُنفذ الخطوات الأولى معًا أم بالتتابع، دون إثبات اكتمال البناء.
- 1:56:15
مقاومة التشتّت بخريطة واضحة للمشاريع
يناقش المتحدث سهولة الانجراف من فكرة برمجية إلى أخرى من دون الوصول إلى التسويق أو تحقيق الدخل، ويوضح أن خريطة للمشاريع، يصفها بأنها swim lane، كانت ضرورية له للحفاظ على التركيز.
- 1:57:39
بناء مسار آلي لتشغيل المهام واختباره
يجمع المتحدث عدة تغييرات في ميزة واحدة يُفترض أن تولّد موجهاً محدداً، وتفتح جلسة Warp تلقائياً، ثم تشغّل المهمة. بعد اكتمال البناء أعاد تشغيل بيئة التطوير وطلب إنشاء بطاقة مؤقتة ثم ظهرت بطاقة لاختبار التكامل، لكنه وصفها بأنها نقلة نوعية فقط إذا عملت؛ ولا تؤكد اللقطات النصية نجاح الاختبار النهائي.
- 2:04:14
اختبار تشغيل مهمة آليًا داخل Warp
تم إعداد بطاقة اختبار بوضع الوكيل ومسار Explorer وتجاوز للـ prompt، ثم تجربة زري «Run in Warp». فتح المشغّل تطبيق Warp، لكنه لم يبدأ جلسة جديدة بالمحتوى المطلوب، ما قاد إلى فحص آلية الإرسال واحتمال تعارضها مع جلسة نشطة.
- 2:11:54
استخدام اللصق كحل عملي لإرسال المهمة
كشف الاختبار عن طلب صلاحية للتحكم في أحداث النظام، ثم جُرّبت آلية تفتح علامة التبويب المطلوبة وتستخدم Command‑V ثم Enter لإرسال الأمر. اعتُبر هذا تنازلًا بسيطًا مقابل مسار أكثر موثوقية، وطُلب تحديث المشغّل وفقًا له.
- 2:17:27
إعادة اختبار التدفق وكشف حالة إنجاز مضللة
أُعيد اختبار التدفق المحدّث الذي يكتب الـ prompt إلى ملف مؤقت ويفتح علامة تبويب Warp في مجلد المشروع، مع مراجعة حذف الملفات المؤقتة تلقائيًا. رغم ظهور بطاقة الاختبار كمكتملة وورود تقرير بأن التدفق نجح، لم يرَ المقدم بدء جلسة Claude، فطلب تشخيص المشكلة وإعادة البطاقة إلى قائمة المهام لإجراء اختبار جديد. الهدف المعلن هو أن يبدأ «Run in Warp» جلسة فعلية تلقائيًا.
- 2:23:03
تشخيص تعطل نقل الـ prompt تلقائيًا إلى جلسة Warp جديدة
بعد ملاحظة احتمال نسيان توليد الـ prompt، أُعيد إنشاء المعاينة وتجربة أمر التشغيل في Warp. كان المتوقع فتح جلسة جديدة ونقل الـ prompt إليها تلقائيًا، لكن اللصق ثم الضغط على Enter لم يؤديا إلى التشغيل. بدأ فحص المشكلة مع فرضية غير مؤكدة بأن تبويب Warp الجديد لم يكن جاهزًا لاستقبال الإدخال أو أن اللصق وصل إلى موضع غير صحيح؛ ولم تعرض هذه الصفحة سببًا مؤكدًا أو حلًا ناجحًا.
- 2:28:37
من أمر أحادي إلى جلسة Claude Code تفاعلية
اتضح أن وضع الطباعة ينفّذ مطالبة واحدة بصورة غير تفاعلية ولا يفتح جلسة قابلة للحوار. نوقش تعديل التشغيل بحيث تُرسل المطالبة المجمّعة كأول رسالة في جلسة Claude Code كاملة تبقى مفتوحة لمطالبات المتابعة.
- 2:33:33
حدود أتمتة تبويبات Warp وبدائلها العملية
نجح تشغيل المهام في تبويبات جديدة، لكن المطلوب كان إضافة طرفية إلى تبويب المشروع النشط لتجنب كثرة التبويبات. وفقاً للمناقشة وقت التسجيل، لم تكن إجراءات Warp المتاحة توفر تقسيم اللوحة أو إضافة طرفية برمجياً إلى تبويب حالي؛ لذلك طُرحت بدائل مثل نسخ الأمر ثم تقسيم اللوحة يدوياً، أو إبقاء كل مهمة في تبويب مستقل، مع إمكانية استئناف الجلسة عبر التبويبات.
- 2:41:11
مراجعة تعيين النماذج لأنواع الوكلاء
بعد أن شغّلت تجربة نموذج Sonnet تلقائياً، جرت مراجعة خريطة تعيين النماذج للوكلاء، مع التساؤل عن سبب إسناد Sonnet إلى المخطط والباني بدلاً من نموذج Opus المطلوب. المقتطف يحدد وجود تعيين غير متوقع، ولا يوثق حله.
- 2:43:06
إدارة مهام متوازية داخل مركز أوامر
يناقش تصوراً تفتح فيه كل مهمة في تبويب أو جلسة منفصلة، مع مراجعة النتائج وتشغيل أدوات متجاورة والعمل على عدة تحسينات بالتوازي. ويقترح تمييز المهام بالألوان لتسهيل متابعتها وتسليمها داخل مركز الأوامر.
- 2:44:19
توزيع النماذج بحسب أدوار الوكلاء
يقترح استخدام أفضل نموذج متاح لدور البناء، مع إعداد خريطة تربط أدواراً مثل المخطط والمستكشف بنماذج مختلفة؛ ويذكر Opus للمخطط وSonnet للمستكشف بوصفهما اختيارات تصميمية.
- 2:47:27
تشغيل مطالبة من الواجهة عبر Warp ومركز الأوامر
يشرح تدفقاً تجريبياً يولّد فيه وضع خط الأنابيب المطالبات، ثم يختار المستخدم وكيلاً مثل Explorer ويشغّل المطالبة عبر زر «Run in Warp» المقترح تحويله إلى «Run in Command Center». الهدف هو فتح جلسة طرفية مرتبطة داخل مركز الأوامر، مع بقاء بعض تفاصيل السلوك غير محسومة في الشرح.
عندك سؤال عن حاجة في البث ده؟
اسأل في الجروب