Building AI Apps Live from Cairo 🔴
تحب تدعم البث؟ عضوية «داعم» على يوتيوب بـ 60 جنيه في الشهر: شارات، إيموجي، وأسئلتك بجاوبها الأول في البث. اشترك كداعم
الخلاصة
تركّز الجلسة على تطوير مركز بث يعمل بأقل تدخل يدوي وربطه بـYouTube لعرض حالة البث والمواعيد والبثوث المجدولة تلقائيًا، مع جدول ثابت احتياطي. شمل العمل إعداد YouTube Data API ومتغيرات Cloudflare، وتشخيص قيود المفتاح وملف غير مضمّن عطّل النشر، ثم تصميم بطاقات منفصلة للحالة المباشرة وغير المباشرة، وقوائم تشغيل، وعارض فيديوهات قابل للتمرير؛ بينما بقيت بعض أولويات عدم الاتصال، وتنظيم بثوث النهار والليل، وخطأ تحديث محلي دون حسم كامل. ورجّح النقاش مبدئيًا توجيه المشاهد إلى YouTube بدل تضمين المشغّل، خصوصًا لتحسين تجربة الهاتف والحفاظ على التفاعل. كما تناول مقارنة شخصية وتجريبية بين Cursor وAntigravity وWarp، وتقسيم المهام بين Codex وClaude، والعمل المتوازي ونقل السياق بين الوكلاء، وضبط أذونات وكيل البرمجة مع معاملة حذف الملفات والدفع إلى GitHub بوصفهما عمليتين حساستين، إلى جانب انتقادات لعزل الطرفية ومسار لقطات الشاشة دون مقارنة منهجية نهائية. وعُرض تصور لمركز قيادة يجمع خريطة زمنية للمشروع وعُقد المهام الفرعية ووكلاء متخصصين وتتبع محاولات التنفيذ، مع تجميع البرومبت تلقائيًا من سياق المشروع وملفات التعليمات. وفي أعمال صفحة الهبوط، نوقشت إضافة أقسام للترويج لمجتمع Telegram، وتبسيط منطقة جمع البريد، وإعادة هيكلة قسم «ما الذي أبنيه؟» انطلاقًا من احتياجات الجمهور مع عدة بدائل لبنية المعلومات لم يُحسم أحدها. وخلص نقاش التصميم إلى أن المراجع البصرية والمواصفات الدقيقة للمسافات والحركة والمراجعة المتكررة أهم من أوصاف عامة مثل «فاخر»، وأن الإضافات المدفوعة تكون أجدى عندما تختصر تعقيدًا هندسيًا حقيقيًا. وشملت تجربة منفصلة تصميم عدّاد بصري بأسلوب متتبع الأهداف، وتسليمات JSON منظّمة بين الوكلاء، واقتراح ربط المتصفح عبر Playwright MCP؛ لكن المقاطع لا تؤكد اكتمال الربط أو التنفيذ. وامتدت الأسئلة إلى استراتيجية SEO وقياس الزيارات في مصر والمنطقة، وفجوة التسويق والتوزيع لدى صُنّاع منتجات الذكاء الاصطناعي، والمفاضلة العامة بين B2B وB2C SaaS، من دون نتائج بحث أو اختبارات نهائية موثقة.
53 لحظة من البث
- 1:14:56
ثلاثة أنماط لواجهة البث والإعادات
شملت الخيارات بطاقة بصورة مصغرة تنقل إلى YouTube أثناء البث، أو تضمين الفيديو مع شريط بارز يدعو للمشاهدة على YouTube للحصول على الدردشة والتجربة الكاملة، مع اقتراح معاملة الإعادات بصورة مختلفة. رُجّح مؤقتًا خيار التحويل إلى YouTube لأنه يحافظ على التفاعل ووقت المشاهدة ويعمل ببساطة على الهاتف، رغم أنه يخرج الزائر من الموقع.
- 1:16:32
الاحتكاك في أدوات البرمجة ودراسة الانتقال إلى Cursor
عبّر المتحدث عن انزعاجه من قيود العزل في أداة البرمجة الحالية، وقال إنه قد يقلل استخدامها وينتقل إلى Cursor، الذي وصفه بأنه أشهر وأكثر رسوخًا في المجال. لم تُعرض مقارنة عملية أو اختبار منهجي بين الأداتين.
- 1:17:38
بطاقات بث مختلفة للحالة المباشرة وغير المباشرة
استقر التصور على استخدام صورة مصغرة قابلة للنقر عند البث وصورة ثابتة مختلفة عند عدم البث، مع صقل الشكل وإضافة إشارة واضحة للحالة. وذُكر أن YouTube API يوفّر أثناء البث بيانات مثل العنوان ومعرّف الفيديو والصورة المصغرة، بينما تعذرت معاينة الحالة غير المباشرة خلال البث الجاري.
- 1:22:18
ربط صورة البث في الموقع بـ YouTube بدل تضمين المشغّل
تجربة واجهة تعرض صورة مصغرة للبث بإطار أخضر عند الاتصال، ثم تنقل المشاهد إلى YouTube عند النقر. فُضّل هذا المسار على تضمين البث داخل الموقع بسبب صعوبة تقديم تجربة جيدة للاشتراك والإعجاب والدردشة، خصوصًا على الهاتف، مع تصور لحالة منفصلة باللون الذهبي ومعلومات الجدول عند عدم الاتصال.
- 1:24:36
تحديث حالة البث والجدول تلقائيًا عبر YouTube API
نوقش جعل مدة البث وعدد المشاهدين وحالة شريط البطل بيانات ديناميكية. يعتمد التصور على جدول ثابت احتياطي، مع استعلام دوري من الموقع إلى YouTube API؛ فإذا وُجد بث مجدول أو قائم، تُستخدم بياناته مثل العنوان والوقت ومعرّف الفيديو وعدد المشاهدين ووقت البدء بدل النص الثابت. تفاصيل ترتيب جميع حالات عدم الاتصال لم تكتمل بوضوح في النص.
- 1:28:15
جدولة عدة بثوث على يوتيوب مسبقًا
نقاش حول جدولة عدة بثوث مسبقًا، ومتى يُفترض أن تصل إشعارات المشتركين، وكيف تظهر البثوث المرتقبة مرتبة على صفحة القناة. خلص النقاش إلى أن الجدولة المجمعة عملية مناسبة، مع وصول الإشعارات قرب موعد كل بث بدلًا من إرسالها كلها وقت الجدولة.
- 1:31:33
تصميم حالة عدم وجود بث مرتقب
إعادة تصور الحالة الاحتياطية للموقع بعد اعتماد الجدولة المسبقة: لا تظهر إلا عند عدم وجود بثوث مرتقبة فعلًا، وتتحول إلى رسالة عودة قريبة مع دعوة واضحة للانتقال إلى القناة. ذُكر أيضًا أن مشاهدة البث داخل الموقع قد تقدم تجربة أضعف، خصوصًا على الهاتف.
- 1:34:14
ربط قسم البثوث في الموقع بيوتيوب
عمل عملي لإزالة بطاقات الجدول الثابتة وعرض البثوث المجدولة مسبقًا على الموقع. ظهر أثناء التحديث خطأ بناء متعلق بوحدة مفقودة، ثم عُرضت واجهة بحالات مثل المزامنة مع يوتيوب والبث المباشر، ووُصف الجزء بأنه مكتمل.
- 1:43:56
تنظيم بثوث النهار والليل في أقسام منفصلة
مراجعة لواجهة البث الديناميكية واقتراح تمييز بثوث النهار الرئيسية عن بثوث الليل داخل الموقع، بالاستفادة من قائمتي تشغيل منفصلتين على يوتيوب. ينتهي المقطع أثناء البحث عن إعدادات قوائم التشغيل، لذلك لم يُحسم شكل التنفيذ.
- 1:48:50
دمج قوائم تشغيل YouTube في الموقع
اقتُرح عرض قائمتَي البث في بطاقتين، مع جلب الفيديوهات الموجودة داخل كل قائمة وإظهارها في عارض قابل للنقر ينقل الزائر إلى الفيديو المحدد على YouTube. كانت إحدى القائمتين فارغة وقت المناقشة.
- 1:52:33
مراجعة بيانات قوائم التشغيل وخطأ التحديث المحلي
أظهرت المراجعة بيانات حقيقية وبطاقات فيديو بصور مصغّرة، بينما ظهرت القائمة الفارغة كما كان متوقعًا. بعد تحديث localhost ظهر خطأ مرتبط بوحدات webpack، ولا توثّق المقاطع حلّه.
- 1:54:28
تصميم عارض فيديوهات قابل للتمرير وحالة القائمة الفارغة
طُلب أن يدعم عارض قائمة البث التمرير حتى عدد محدد من الفيديوهات، وأن ينتهي ببطاقة «عرض الكل» تقود إلى القائمة الكاملة بدل رابط نصي فقط. كما نوقش إخفاء قسم البث الليلي وهو فارغ وإظهاره تلقائيًا بعد إضافة أول فيديو.
- 2:01:39
تشخيص السحب للتمرير في واجهة Carousel
فُحصت الواجهة محليًا بعد تعذّر تمرير الـcarousel وغياب السحب، ثم أُعيدت المحاولة والتحديث إلى أن أصبح سلوك السحب للتمرير مقبولًا مؤقتًا، مع طلب ضمان وجوده في نسخة أخرى من الواجهة.
- 2:06:24
نقل سياق التصميم بين نماذج الذكاء الاصطناعي
يشرح النقاش طلب hand-off prompt من نموذج لنقل فهم تصميم محدد وسياقه التقني إلى نموذج يعمل في طرفية أخرى. يتيح ذلك الحصول على رأي أو تنفيذ بديل دون إعادة شرح المشروع كاملًا، ثم متابعة المهمتين بالتوازي.
- 2:08:40
إعادة هيكلة قسم المشروعات بما يناسب الجمهور
يحلّل النقاش قسم «ما الذي أبنيه؟» في صفحة هبوط ويسأل أولًا ما الذي يحتاج الجمهور إلى فهمه ولماذا قد يهتم. طُرح إبراز أداة مركزية قابلة للاستخدام بدل مخطط معماري معقد، مع مقارنة ثلاثة اتجاهات تنظيمية: تبسيط التسلسل داخل قسم واحد، تقسيم المحتوى إلى قسمين، أو إنشاء قسم واحد بمستويين مختلفي الغرض. لم يُحسم الخيار في هذه الصفحات، وطُلب hand-off prompt لاستكشاف الاتجاه الثالث.
- 2:19:42
لماذا تنتج وكلاء الذكاء الاصطناعي واجهات عامة؟
يتساءل المتحدث عما إذا كانت المهارات والإضافات هي ما ينقص سير عمل تصميم صفحات الهبوط. ويعرض رد الوكيل تشخيصاً مختلفاً: الفجوة الأهم هي المراجع البصرية، لأن نظام التصميم القائم على النص وحده يدفع الوكلاء نحو مظهر عام ومتكرر.
- 2:25:37
تأثير عزل الطرفية على سير عمل التصميم بالصور
يناقش المتحدث تحديثاً مؤرخاً في 26 فبراير 2026 أضاف عزل الطرفية في Antigravity IDE. وبرأيه، تعرقل القيود نسخ المحتوى وإرسال لقطات الشاشة إلى أدوات أو مساحات عمل خارجية، مع أن اللقطات تساعد الوكلاء على تحليل التأثيرات البصرية وإعادة تنفيذها.
- 2:27:05
مقارنة بيئات البرمجة الوكيلة ومعاينة الموقع داخل المحرر
مقارنة بين تشغيل أعمال متعددة بالتوازي وبين بيئة تضع الموقع داخل المحرر لعرض التحديثات الحية. ناقش المتحدث فائدة المعاينة المدمجة، إلى جانب مخاوف محتملة مثل عزل الطرفية، باعتبارها عوامل عملية عند اختيار بيئة العمل.
- 2:27:29
كيف تنقل الذوق البصري إلى وكيل برمجي
تحتاج الواجهة المصقولة إلى أكثر من وصف بنية المكونات: صور مرجعية، ونظام واضح للمسافات، ومواصفات للحركات الدقيقة ومنحنيات التيسير، ومكوّن نموذجي مكتمل، وقائمة تدقيق بصرية. الفكرة المطروحة هي أن الوكلاء يتبعون التعليمات الدقيقة جيداً، لكن أوصافاً مثل «فاخر» لا تحدد وحدها التفاصيل البصرية المطلوبة.
- 2:31:13
حدود تقليد المؤثرات المتحركة بالوكلاء
طُرح سؤال حول قدرة الوكيل على فحص واجهة متحركة وإعادة تنفيذها. الإجابة المتداولة قالت إن الوكيل يستطيع غالباً بناء حركات CSS وتسلسلات مرتبطة بالتمرير ومؤثرات تفاعلية، لكن جلب البنية لا يكشف التجربة الحركية كاملة، كما أن الوصول إلى نتيجة مصقولة يتطلب من الإنسان أن يراجع المخرجات ويعطي ملاحظات رقمية ومتكررة حول التوقيت والتيسير والأقنعة وغيرها.
عندك سؤال عن حاجة في البث ده؟
اسأل في الجروب