BREAKING MY APP TO FIX IT
تحب تدعم البث؟ عضوية «داعم» على يوتيوب بـ 60 جنيه في الشهر: شارات، إيموجي، وأسئلتك بجاوبها الأول في البث. اشترك كداعم
الخلاصة
يتابع البث انتقال تطوير تطبيق مساعد ذكاء اصطناعي داخل Shopify من البناء إلى المراجعة والتصحيح وصقل UI/UX. يطوّر لقمان مركز قيادة يفصل اختبارات الواجهة والتجربة والخلفية عن مهام الإصلاح، ويسجّل النتائج ويعيد الاختبار خطوة بخطوة، مع توزيع العمل بين Codex وClaude ووكلاء آخرين بحسب طبيعة المهمة. تشمل التجارب العملية ترحيل الواجهة إلى Polaris، ومراجعة الصفحة الرئيسية وبطاقة التقرير، وتشخيص أعطال المصنّف والتوجيه وأزرار المحادثة والصور والعداد اللحظي وفهم التواريخ النسبية؛ وقد تأكد إصلاح بعض الحالات، بينما بقيت مشكلات أخرى مفتوحة مثل بطء التطبيق وبعض تدفقات المحادثة وفشل تحليل الرؤية. كما تناقش الجلسة أسئلة الجمهور حول اختيار النماذج وأدوات البرمجة، وبناء تطبيقات صوتية، وتشغيل النماذج محلياً أو سحابياً، مع التأكيد أن المقارنات المعروضة انطباعية وليست معايير حاسمة. وعلى مستوى المنتج، يعرض لقمان رأيه في ضرورة اختبار الطلب واقتصاديات الوحدة والتسعير وتكلفة اكتساب العميل قبل التوسع، مع الإقرار بأن التحقق المسبق ليس المسار الوحيد وأن اختلاف العملات والقدرة الشرائية قد يزيد صعوبة الاستدامة في بعض الأسواق العربية.
105 لحظة من البث
- 4:18:06
إثراء مهام الإصلاح بالسياق وخطوات التحقق
اقتُرح أن تحمل كل مهمة تُنقل من المراجعة ملاحظات جاهزة عن مصدرها ومسارها ومستوى الأمان، مع متطلبات البناء وفحص الأنواع وlint وتعليمات عملية خطوة بخطوة ليختبرها المشغّل. ونوقش استخدام prompt خفيف لكل مهمة بدلاً من مرحلة إعداد كاملة يشترك فيها وكيلا بحث واستكشاف، مع الإقرار بفقدان بعض الإثراء عند التبسيط.
- 4:29:49
اختبار سير عمل الإصلاح تدريجياً
اختير إصلاح صغير متعلق بعرض تاريخ غير صحيح لتجربة النظام الجديد، مع تفضيل البدء تدريجياً بدلاً من تشغيل عدد كبير من الوكلاء. وأشير إلى أن التصحيح قد يكون أخف من البناء، مع بقاء بعض مهام التصحيح محتاجة إلى بناء فعلي.
- 4:31:11
استكشاف نماذج بديلة للوكلاء
أفاد أحد الحضور بأن نموذجاً غير محدد بوضوح يعمل جيداً وبأداء قريب من نموذج آخر، ما شجّع المتحدث على التفكير في إعداد وتجربة نماذج بديلة لاحقاً. كان ذلك انطباعاً من الحضور وخطة مستقبلية، لا نتيجة اختبار موثقة في المقطع.
- 4:31:51
الفصل بين الإصلاحات وعمليات التحقق
طُلب نقل مهمة إلى قسم الإصلاحات، مع توضيح أن اختبارات التدفقات الخلفية والجديدة هي عمليات تحقق وليست إصلاحات. خلط النوعين قد يربك لوحة المهام وسير العمل.
- 4:32:38
موازنة جودة التصحيح مع كفاءة استخدام الرموز
يناقش نهجًا خفيفًا للمطالبات في الخلفية يهدف إلى الحفاظ على جودة التصحيح مع تقليل استهلاك الرموز، مع اقتراح تجربته تدريجيًا قبل الاعتماد عليه.
- 4:36:04
النماذج المجانية: تشغيل محلي أم نقاط نهاية سحابية؟
يستكشف الفرق بين تنزيل النماذج وتشغيلها محليًا وبين استخدامها عبر نقاط نهاية سحابية مجانية، بما يشمل متطلبات العتاد وطلب رابط للتأكد مما إذا كان الوصول السحابي المجاني متاحًا.
- 4:38:02
فصل التحقق عن مهام الإصلاح في سير عمل التصحيح
يعيد تنظيم سير العمل بحيث تبقى عناصر التحقق في قسمها، بينما يؤدي فشل التحقق إلى إنشاء مهمة تُنقل إلى قسم الإصلاحات. ثم تُراجع عناصر واجهة المستخدم وتجربة الاستخدام والخلفية سطرًا بسطر للتأكد من تصنيفها الصحيح قبل تجربة التدفق.
- 4:44:16
اختبار سير العمل بخطأ في تفسير «الشهر الماضي»
يُختار خطأ صغير لاختبار سير العمل: استعلام محادثة عن «الشهر الماضي» فسّر الفترة على أنها ديسمبر 2024 بدلًا من مارس 2026. يوضح المثال أهمية معالجة التواريخ النسبية وفق السياق الزمني الصحيح.
- 4:47:00
التحقيق في الإصلاحات عند بدء المهمة
جرى التحقق مما إذا كان موجّه النظام البسيط يعمل كما ينبغي. يوضح الرد أن تحليل جميع الإصلاحات مسبقاً قد يهدر الرموز على مهام لن تُنفذ قريباً، لذلك يحدث التحقيق عند اختيار إصلاح محدد وبدء العمل عليه.
- 4:49:27
مسار إصلاح يتبعه استعراض تصحيح تفاعلي
بدأت مهمة تصحيح مباشرة من دون خطوة إعداد منفصلة. التوقع هو أن ينفذ النظام الإصلاح أولاً، ثم ينقل المهمة إلى الاستعراض ليمر المستخدم معه في التصحيح خطوة بخطوة قبل اعتبارها منجزة؛ مع الإشارة إلى أن تكرار ذلك عبر مهام كثيرة سيكون ثقيلاً.
- 4:52:02
إصلاح فهم التواريخ النسبية والتحقق منه
عُزي خطأ التاريخ إلى غياب التاريخ الحالي وقت التشغيل عن موجّه النظام، وكان الإصلاح المقترح حقنه في الموجّه. جرى التحقق باستعلامات عن الشهر الحالي وشهرين سابقاً، وأعطى الاختبار الشهر التاريخي المتوقع ضمن سياق أبريل 2026.
- 4:52:51
زمن تحميل تطبيق Shopify كمشكلة مستقلة
أشار المتحدث إلى أن بطء التحميل يمثل مشكلة منفصلة تحتاج إلى معالجة، وذكر أن Shopify يرفض التطبيقات التي يتجاوز تحميلها خمس ثوانٍ.
- 4:54:20
اختبار النموذج نفسه المستخدم في المنتج
رداً على اقتراح استخدام نقاط نهاية مجانية، أوضح المتحدث أنه يفضّل تصحيح التطبيق بالنماذج نفسها المزمع استخدامها في المنتج؛ لأن استبدال النموذج، حتى مع إعدادات متشابهة، يعني اختبار سلوك مختلف.
- 4:56:19
توزيع الميزانية بين أولويات المشروع
يشجع المتحدث على ضبط الإنفاق عبر تحديد ميزانية مسبقاً وتوزيعها بوضوح بين أولويات مثل الإعلانات وتصحيح الأخطاء، بدلاً من تجنب كل إنفاق دون خطة.
- 4:57:17
مزامنة المهمة المنجزة داخل لوحة الإصلاحات
بعد اكتمال مهمة إصلاح، ينبغي شطب المهمة المطابقة تلقائياً داخل قسم الإصلاحات في ملف الاستعراض، بحيث تتسق حالة المهمة بين قسم المنجز ومسار المراجعة.
- 4:59:14
منع حدود الاستخدام من تعطيل الاختبار
أُجّل بحث الإجراءات التي ينبغي احتسابها ضمن الفوترة، وعُدّل حد المهام المجانية مؤقتاً أثناء مرحلة ما قبل الإرسال حتى لا يوقف اختبار التطبيق، مع نية إعادة ضبطه لاحقاً.
- 5:00:56
استراتيجيات الربحية والتعادل في البداية
يناقش المتحدث معياراً عاماً هو أن تتجاوز إيرادات المشروع مصروفاته، مع الإشارة إلى استراتيجية بديلة تقبل التعادل في البداية لاكتساب مزيد من العملاء ثم ترفع الأسعار لاحقاً سعياً إلى الربح.
- 5:01:57
بدء تصحيح مهمتين بالتوازي
بعد نجاح تجربة مهمة منفردة، اختيرت مشكلتان تاليتان—عرض صور المنتجات في المحادثة وعداد المهام بعد إعادة كتابة الوصف—وبدأتا معاً لاختبار قدرة سير العمل على معالجة أكثر من مهمة.
- 5:02:54
التحقق من إصلاحات الأخطاء خطوة بخطوة
يناقش أسلوباً حذراً لمراجعة مهام التصحيح واحدة تلو الأخرى، حيث لا تُعد المهمة مكتملة إلا بعد فتح المحادثة وطرح سؤال محدد والتحقق من الإجابة المتوقعة. تشمل الأمثلة عدّاداً في الواجهة لم يتحدث إلا بعد إعادة تحميل الصفحة، وصورةً مشوهة قليلاً أثناء عرض صفحة منتج.
- 5:08:25
إعادة تشغيل خادم التطوير وفحص المخرجات
أثناء فحص سير العمل، يعيد تشغيل خادم تطوير Shopify ليرى إن كانت العملية ينقصها شيء، ثم يلاحظ بعد بدء الخادم أن ملف المخرجات ما يزال فارغاً. المقتطف لا يوضح سبب المشكلة أو حلها النهائي.
عندك سؤال عن حاجة في البث ده؟
اسأل في الجروب