FIXED 1 BUG. CREATED 3 MORE.
تحب تدعم البث؟ عضوية «داعم» على يوتيوب بـ 60 جنيه في الشهر: شارات، إيموجي، وأسئلتك بجاوبها الأول في البث. اشترك كداعم
الخلاصة
بث عملي واسع لمراجعة تطبيق Shopify قبل الإطلاق، جمع بين صقل واجهة الدردشة وتجربة التاجر وتشخيص الأعطال وتحويل الملاحظات إلى قائمة إصلاحات واختبارات داخل مركز أوامر مخصص. شمل العمل تتبّع أعطال مثل المنتجات بلا صور، واختفاء النص أو المرفقات، وبطء الردود، ومشكلات المحاذاة والأزرار السياقية والتأكيد، مع تأكيد أن نجاح تعديل موضعي لا يكفي وأن المراجعة البشرية والاختبار عبر السيناريوهات الحقيقية يظلان ضروريين. ناقش لقمان أيضًا أتمتة دورة التصحيح عبر وكلاء يقرؤون السجلات ويختبرون المسار الخلفي، وإدارة السياق بالوثائق وملفات الحالة والجلسات الجديدة، مع الحفاظ على بوابات التأكيد وGit كنقطة أمان وتجنب الاستقلالية غير المنضبطة. أجابت المناقشات عن أسئلة الجمهور حول Claude وCodex وOpenCode وOpenRouter والنماذج المحلية وأدوات البرمجة الوكيلة. كان الاستنتاج العملي أن اختيار النموذج يعتمد على المهمة والجودة والتكلفة وفهم المشروع، وأن جداول القياس تحتاج إلى قراءة منهجيتها بدل الاعتماد على ترتيب واحد؛ أما تجارب النماذج المتعددة والتوجيه الأرخص فبقي كثير منها خططًا للاستكشاف لا نتائج مكتملة. وتناول البث كذلك التحقق من أفكار المنتجات بصفحات هبوط، وأهمية التسويق والوصول إلى السوق بدل تكرار البناء، والتدرج من نسخة أولى نافعة إلى التوسع وفق الاستخدام الفعلي. ظهرت أيضًا أعمال تصميم وعصف ذهني بصري، ومناقشات عن SEO وGEO ووصف المنتجات، وبناء مجتمع عربي لتبادل الخبرات. بقيت أسئلة مفتوحة حول سبب بعض حالات البطء والمهل، واتساع سياق المصنّف مقابل تكلفته، وموثوقية الأتمتة، وبعض الإصلاحات وتجارب الأدوات التي لم تُختبر نهائيًا.
155 لحظة من البث
- 1:53:59
إصلاح الخلل واختباره عبر تشخيص تفاعلي متدرج
يوجّه المتحدث المساعد إلى إكمال الإصلاح مع الانتباه لاحتمال إدخال أخطاء جديدة، ثم طلب تعليمات مراجعة واختبار محددة. أثناء الاختبار يفضّل عملية تشخيص خطوة بخطوة، يعيد بعدها نتيجة كل خطوة، ويلاحظ أن المصنّف صار يعيد تصنيفًا ودرجة ثقة متوقعة في الأمثلة الظاهرة.
- 1:54:52
تجنّب مطاردة كل أداة ونموذج جديد
يناقش المتحدث خطر التشتت الناتج عن كثرة الأدوات وتحديثات النماذج والمحتوى الذي يدعو باستمرار إلى الانتقال لشيء جديد. نصيحته هي اختيار ما يعمل، والتركيز على المشروع، وتجربة البدائل على فترات بدل التنقل الدائم بينها.
- 2:00:28
قيود الوصول إلى السجلات في تصحيح الأخطاء المدعوم بالوكيل
يرى المتحدث أن النسخ واللصق المتكرر للنتائج غير عملي. ويناقش أن تكامل Playwright عبر MCP لا يتيح للمساعد الوصول السلس إلى السجلات في السياق الحالي، ويتصور سير عمل أسرع يستطيع فيه وكيل التصحيح التواصل مع مساعد آخر والوصول إلى السجل عند الحاجة؛ وتنتهي الصفحة قبل اكتمال الفكرة، وتظل هوية المساعد الآخر غير واضحة.
- 2:05:57
تتبّع مشكلة انتهاء المهلة في سير عمل الوكيل
مراجعة مشكلة متكررة في سير عمل متعدد الخطوات: بدت إحدى الخطوات ناجحة، ثم ظهر خلل آخر أثناء المتابعة. طُلب من الوكيل شرح سبب انتهاء المهلة وتسجيل المشكلة في قسم المراجعة.
- 2:08:50
فكرة أن يراجع الوكيل أخطاءه وسجلاته بنفسه
اقتراح قيد الاستكشاف لتمكين الوكيل من إضافة الخطأ إلى مخزن المهام وقراءة السجل بنفسه، ثم بدء محادثة جديدة لتجربة تدفق كامل لإثراء المنتجات مع تحديثات أو مؤشر يوضح حالة التنفيذ. لم تؤكد التعليقات نجاح الفكرة أو اكتمالها.
- 2:11:25
إعادة فحص مسار كان يتعطل
راجع مسارًا كان يتعطل سابقًا أثناء تقييم تحسن التطبيق داخل Shopify، وأبدى ملاحظات إيجابية عن تقدمه مقارنة بحالته قبل يومين، من دون شرح تقني كافٍ لتحديد سبب الخطأ أو إثبات إصلاح نهائي.
- 2:14:17
حصر عرض التفكير في خمسة أسطر
اقترح تعديلًا لواجهة أداة التفكير بحيث تعرض خمسة أسطر كحد أقصى، وتستبدل الأسطر الأقدم عند وصول أسطر جديدة، ثم تُسجل الفكرة كمهمة ضمن قسم الإصلاحات في المراجعة.
- 2:16:40
استكشاف أتمتة دورة تصحيح الأخطاء بالوكيل
ناقش إمكانية نقل دورة تصحيح الأخطاء اليدوية إلى وكيل يعمل في الخلفية: يرسل طلبًا إلى الأداة، يراقب سجل المصنّف، يحلل ما يحدث ثم يعيد النتائج. طُرحت الفكرة كسؤال عن الإمكانية فقط، مع توجيه صريح بعدم تنفيذ شيء في تلك اللحظة.
- 2:23:42
تصميم مسار اختبار لتصحيح المحادثة آليًا
اقتُرح مسار اختبار خفيف فوق واجهة المحادثة يتيح للوكيل إرسال طلب بسيط، قراءة الاستجابة المتدفقة ومراقبة سجلات الخادم. كان العائق الأساسي هو جلسة المصادقة، بينما ظل إرسال الطلب يدويًا مع تحليل السجلات حلًا جزئيًا متاحًا.
- 2:31:48
اختبار النموذج الفعلي مع مراعاة القيود التشغيلية
يرى المتحدث أن اختبار سلوك موجّه للمستخدمين يجب أن يستخدم النموذج المزمع إطلاق المنتج به، لأن نموذجًا أرخص قد لا يمثل النتيجة الفعلية. كما يوضح أن أتمتة واجهة Shopify عبر المتصفح تظل مقيدة بالمصادقة، لذلك يفضّل اختبار المسار الخلفي والسجلات حيثما أمكن.
- 2:35:06
تحويل التحقق من الإصلاحات إلى مهمة ذاتية للوكيل
تشير العناوين إلى إضافة المسار التجريبي واستخدامه لإرسال طلب وتلقي رد. بعد ذلك طُلب تحديث التعليمات بحيث يختبر الوكيل الإصلاحات بنفسه، ويراقب السجلات ويحللها ضمن النطاق المتاح، مع طلب مشاركة المشغّل فقط عندما تتطلب المهمة تفاعلًا خارج ذلك النطاق؛ ولم تشمل القدرة الموصوفة لقطات واجهة المستخدم.
- 2:39:48
استكشاف وضع تخطيط ويب ومقارنته بـ Playwright MCP
تصف المقاطع وضعًا غير محدد الهوية يوفّر تحريرًا غنيًا للخطط على الويب وتشغيل عمل سحابي، مع إمكانية تنفيذ الخطة في جلسة ويب أو إعادتها إلى بيئة العمل. طُرح سؤال عن الفرق بينه وبين Playwright MCP، لكن لا تظهر إجابة في هذه الصفحات.
- 2:43:02
التخطيط المتقدم للمهام البرمجية المعقدة
شرح سير عمل مقترحًا تبدأ فيه المهمة المعقدة بخطة تفصيلية قابلة للمراجعة والتعديل قبل تنفيذها، وأبدى اهتمامه بتجربة هذا الأسلوب. كما أشار إلى أداة مساعدة تستطيع إنتاج ملفات SVG وتأثيرات ورسوم متحركة أثناء جلسات العصف الذهني.
- 2:45:32
توجيه وكيل برمجي للتحقيق باستخدام السجلات
وجّه وكيلًا برمجيًا إلى تحليل مشكلة، والتحقق من قدرته على الوصول إلى بيئة المتجر، وقراءة سجل React Router، ثم تحديد موضع المشكلة بدقة. وأوضح أن وصولًا مشابهًا كان قد أُعد في جلسة سابقة، مع الإشارة إلى أن Playwright لم يتمكن من الوصول إلى المتجر؛ ولا تعرض المقاطع نتيجة نهائية للتحقيق.
- 2:47:59
حماس موجز تجاه GPT-5
عبّر عن حماسه تجاه GPT-5 وربط ذلك بانطباعه الإيجابي عن قوة GPT-4.5. وردت مقارنة معيارية قصيرة، لكن اسم المرجع المقارن غير واضح في النص.
- 2:54:38
لماذا يصعب قراءة جداول تقييم نماذج الذكاء الاصطناعي؟
يتفحص المتحدث جدولًا يقارن نماذج الذكاء الاصطناعي من حيث السرعة ومؤشر الذكاء وعدة اختبارات معيارية، ويلاحظ أن لكل اختبار طريقة تسجيل مختلفة؛ لذلك لا يكفي النظر إلى ترتيب واحد لفهم الأداء. ويقر بأن تفسير هذه المقاييس يحتاج وقتًا ومعرفة بتعريف كل اختبار، مع الإشارة إلى أن المقارنة تظل مهمة.
- 3:01:17
وكيل يدير دورة تصحيح الأخطاء بنفسه
بعد الانتهاء من المشكلات الحرجة، يشرح المتحدث أن سير العمل السابق كان يتطلب منه نقل المشكلة والسجلات ونتائج المحادثة يدويًا بين الأنظمة والوكيل. لذلك أعدّ الوكيل ليتصل بواجهة المحادثة الخلفية، يرسل الموجّه إلى المحادثة، يراجع السجلات والنتيجة ثم يتابع التصحيح بنفسه. يتوقع أن يسرّع ذلك العمل كثيرًا، لكنه بدأ بذكر عيب قبل أن ينقطع الشرح.
- 3:03:39
التمييز بين استهلاك الرموز في التصحيح واستدعاءات API للتطبيق
يوضح النقاش أن التصحيح قد يستهلك رموزًا أقل من بناء الميزات، بينما قد تصبح استدعاءات API التي ينفذها التطبيق نفسه أقل قابلية للسيطرة. كما يحذر من أن منح الوكيل حرية تنفيذ كل شيء قد يصلح عطلًا لكنه يسبب أعطالًا أخرى، ولذلك تمت مراجعة بوابة التأكيد وضمانات المعالجة متعددة الخطوات قبل الاختبار اليدوي.
- 3:05:47
استخدام Git كنقطة أمان أثناء عمل الوكيل
يناقش المتحدث مراجعة تغييرات الوكيل واستخدام Git لحفظ نقطة رجوع، مع تجنب تثبيت التغييرات أو دفعها قبل التأكد من أنها النسخة المراد الاحتفاظ بها.
- 3:07:05
إدارة نوافذ السياق عبر التوثيق والذاكرة والجلسات المتوازية
يناقش المتحدث مشكلة نسيان المحادثات الطويلة، ويشرح أن التوثيق القوي والذاكرة وتعليمات النظام تسمح بفتح جلسات جديدة أو متوازية دون الاعتماد على محادثة واحدة ممتدة. ويرى أن استهلاك السياق يختلف بين الأدوات، وأن البنية الجيدة تمكّن الجلسة الجديدة من بدء مهمة بقليل من السياق المباشر.
عندك سؤال عن حاجة في البث ده؟
اسأل في الجروب