BREAKING MY APP TO FIX IT
تحب تدعم البث؟ عضوية «داعم» على يوتيوب بـ 60 جنيه في الشهر: شارات، إيموجي، وأسئلتك بجاوبها الأول في البث. اشترك كداعم
الخلاصة
يتابع البث انتقال تطوير تطبيق مساعد ذكاء اصطناعي داخل Shopify من البناء إلى المراجعة والتصحيح وصقل UI/UX. يطوّر لقمان مركز قيادة يفصل اختبارات الواجهة والتجربة والخلفية عن مهام الإصلاح، ويسجّل النتائج ويعيد الاختبار خطوة بخطوة، مع توزيع العمل بين Codex وClaude ووكلاء آخرين بحسب طبيعة المهمة. تشمل التجارب العملية ترحيل الواجهة إلى Polaris، ومراجعة الصفحة الرئيسية وبطاقة التقرير، وتشخيص أعطال المصنّف والتوجيه وأزرار المحادثة والصور والعداد اللحظي وفهم التواريخ النسبية؛ وقد تأكد إصلاح بعض الحالات، بينما بقيت مشكلات أخرى مفتوحة مثل بطء التطبيق وبعض تدفقات المحادثة وفشل تحليل الرؤية. كما تناقش الجلسة أسئلة الجمهور حول اختيار النماذج وأدوات البرمجة، وبناء تطبيقات صوتية، وتشغيل النماذج محلياً أو سحابياً، مع التأكيد أن المقارنات المعروضة انطباعية وليست معايير حاسمة. وعلى مستوى المنتج، يعرض لقمان رأيه في ضرورة اختبار الطلب واقتصاديات الوحدة والتسعير وتكلفة اكتساب العميل قبل التوسع، مع الإقرار بأن التحقق المسبق ليس المسار الوحيد وأن اختلاف العملات والقدرة الشرائية قد يزيد صعوبة الاستدامة في بعض الأسواق العربية.
105 لحظة من البث
- 3:09:30
بناء command center من مواصفات Markdown
ردًا على سؤال عن صعوبة بناء command center، أوضح المتحدث أن وجود خريطة واضحة وملف Markdown مفصل قد يتيح لوكيل برمجي مثل Codex تنفيذ قدر كبير من العمل. كما ذكر خطة مستقبلية لشرح البناء من الصفر ومشاركة الملف.
- 3:12:28
تشخيص أخطاء تدفق المحادثة وإعادة الاختبار
يتتبع المتحدث عدة مشكلات في تجربة المحادثة، منها مطالبة تأكيد تسبب التردد، وزر يعرض رسالة المستخدم بدل إرسال الطلب داخليًا، وتوقف التدفق من جهة الخادم. يناقش إصلاح المشكلة داخل الجلسة نفسها أو في جلسة منفصلة، ثم يعيد الاختبار ويؤكد أهمية عزل كل مشكلة وتحليلها بمفردها.
- 3:15:33
اقتصاديات الاشتراكات في الأسواق العربية
يرى المتحدث أن بعض المستخدمين في أسواق مثل مصر والجزائر أقل اعتيادًا على الدفع الشهري، وأن القدرة الشرائية قد تجعل تسعير الاشتراكات صعبًا. ويؤكد أن الفرص موجودة، لكن تحقيق unit economics وربحية مناسبة يحتاج إلى حساب دقيق؛ وهذا طرح منسوب إليه لا حكم عام نهائي.
- 3:18:16
الفرق بين منصة خدمات محلية ومنتج SaaS
يوضح المتحدث أن تطبيق النقل الذي يكيّف نموذجًا قائمًا مع البنية المحلية ينتمي إلى نموذج أعمال مختلف عن شركة SaaS. فرغم أن كليهما تطبيق برمجي، تعتمد منصة النقل على تشغيل سوق وخدمات ميدانية، لذلك لا يصح تقييمها بمنطق منتج البرمجيات كخدمة وحده.
- 3:23:14
تقييم فكرة تطبيق لحجز مواعيد الحلاقة
يناقش سؤالًا عن تطبيق يتيح للحلاقين إنشاء صفحات لمحالهم والظهور على الخريطة مع حجز العملاء للمواعيد. اعتبر الفكرة جيدة ومشابهة جزئيًا لمنصة خدمات محلية، لكنه أوصى بحساب المصروفات وunit economics والتحقق من وجود هامش ربح قبل التنفيذ.
- 3:25:19
مجتمع لتبادل ملاحظات المشاريع والخبرات
يصف المتحدث هدف مجتمع دردشة يستطيع فيه الأعضاء مشاركة مشاريعهم، وطلب آراء الآخرين، وتبادل الخبرات المكتسبة من العمل العملي.
- 3:28:05
تشخيص أزرار إجراءات عامة لا تناسب نتيجة المحادثة
لاحظ لقمان أن الرد الخاص بتقييم اكتمال بيانات كتالوج المنتجات ينتهي دائماً بالأزرار العامة نفسها، ومنها إعادة كتابة الأوصاف، رغم أنها لا ترتبط بالطلب. اعتبر أن المشكلة أعمق في التوجيه والتحقق وسلوك الأزرار، وأوقف محاولة الإصلاح في الجلسة الحالية طالباً إعداد تسليم إلى جلسة أخرى؛ ولم يثبت هذا المقطع نجاح الإصلاح.
- 3:29:59
فصل مراجعة اختبارات الضغط عن تنفيذ الإصلاحات
يراجع لقمان سير العمل ويستنتج أن جلسة المراجعة حُمّلت بمهام كثيرة لأنها كانت تراجع المشكلات وتحاول إصلاحها في الوقت نفسه. ويوضح أن قسم Command Center مخصص لاختبار ضغط الواجهة وتجربة الاستخدام والخلفية، بينما ينبغي أن تنتقل الاختبارات الفاشلة والأخطاء إلى مسار التنفيذ المعتاد، مع تدقيق واضح يفصل مهام الاختبار عن مهام الإصلاح.
- 3:33:34
فصل جلسات المراجعة عن تنفيذ الإصلاحات
أُعيد تصور قسم المراجعة ليقتصر على الاختبار وتسجيل النجاح أو الفشل. تُجمع المشكلات المكتشفة في قسم مستقل للإصلاحات، ثم تُحوّل إلى مهام على لوحة المهام؛ وبعد تنفيذها يعود العمل إلى جلسة المراجعة لإعادة الاختبار. أظهر التحقق من الواجهة أن قسم الإصلاحات المتوقع لم يكن ظاهرًا بعد، ما استدعى توضيح المتطلب مجددًا.
- 3:41:03
تتبّع تعطل المصنّف وإعادة اختباره
أظهر اختبار المصنّف درجة ثقة صفرية، ثم وُصف بأنه يتعطل بالكامل ويعيد المحادثة إلى مسار احتياطي، رغم عدم ظهور أخطاء في سجل طرفية الخادم. بعد متابعة التصحيح وإعادة التجربة ظهرت نتيجة تصنيف 0.95، وقال المتحدث إن المشكلة أُصلحت، من دون تحديد سبب جذري واضح في هذه الصفحات.
- 3:49:02
ملاحظة خلل مؤجل في فتح محادثة جديدة
أثناء الاختبار، لاحظ المتحدث أن النظام كان يُفترض أن يفتح محادثة جديدة لكنه لم يفعل، وعدّه خللًا منفصلًا ثم أجّل التعامل معه للتركيز على التصحيح الجاري.
- 3:50:34
فصل اختبارات الاستكشاف عن مهام الإصلاح
أُعيد تنظيم مركز الأوامر لأن مرحلة التصحيح أصبحت معقدة: الاختبار يعني التفاعل مع التطبيق والتحقق من تجربة الاستخدام أو الواجهة أو الخلفية، بينما تتحول المشكلة المكتشفة إلى مهمة إصلاح مستقلة. طُلب استخدام عدة وكلاء لمراجعة البطاقات ونقل مهام الإصلاح من قسم المراجعة إلى قسم مخصص لها، مع تأكيد فهم التصنيف قبل البدء.
- 3:53:07
تحديث عن تقدم التطوير وموعد الإطلاق المستهدف
قال المتحدث إن كل بث يُظهر تقدماً ومشكلات وإنجازات جديدة، وإن هدف الإطلاق تغيّر آنذاك من 17 أبريل إلى 20 أبريل، مع دخول العمل مرحلة تصحيح أصعب.
- 3:55:04
التحقق من ميزة مع ملاحظة بطء تجربة الاستخدام
جرى تشغيل ميزة موصوفة في النص باسم «plan enrichment» وبدت عاملة، لكن بطء الروبوت ظل ملاحظة واضحة مرتبطة بتجربة الاستخدام.
- 3:56:36
تتبّع انهيار لم يُنتج أي رد
أظهرت السجلات أن خطوة تحليل بدأت ثم انهارت من دون أن تُرجع رداً، ما وفّر نقطة بداية واضحة لتتبّع العطل.
- 4:00:48
فصل الإصلاحات عن الاختبارات داخل سير التصحيح
صُمّم قسم ومعلَم مخصّصان لمراجعة الواجهة وتجربة المستخدم وتصحيح الأخطاء، مع زر ينقل الإصلاح المقترح إلى لوحة المهام. ويوضح النقاش أن فصل مهام الإصلاح عن الاختبارات يقلل التشوش عندما تكشف عملية التصحيح مشكلات إضافية، مع الاستعانة بسجلات الخادم لمتابعة حالات الفشل والمهلات الزمنية.
- 4:13:19
التعامل مع فشل تحليل الرؤية
فشل تحليل الرؤية، فاستمر المسار من دون دفعة الرؤية مع الاشتباه في وجود مشكلة في واجهة Vision API. لا توضح المقاطع سبب العطل أو نتيجة إصلاحه.
- 4:14:41
إثراء مهام الإصلاح قبل تنفيذها
يناقش تصميم إثراء لمهام الإصلاح عبر تزويد الوكيل بمعلومات إضافية أو system prompt، مع الإشارة إلى أن المنتجات التي لا تحتوي على صور قد تحتاج إلى مسار مختلف. استُخدمت مشكلة في تاريخ شهري مثالًا على إدخال مهمة إلى لوحة Debug & Review، من دون إثبات إصلاحها هنا.
- 4:16:15
استبدال تأكيدات النص بأزرار
اقتراح تحويل عبارات الموافقة مثل go ahead وyes وconfirm إلى أزرار واضحة، مع إبقاء إمكانية أن يكتب المشغّل أو التاجر الموافقة نصيًا.
- 4:16:44
مسار التنفيذ والمراجعة مع إرشادات اختبار
يقترح مسارًا تنتقل فيه المهمة إلى حالة قيد التنفيذ، ثم إلى المراجعة للتحقق منها. المطلوب من الوكيل ألا يكتفي بإكمال المهمة، بل يشرح أيضًا كيفية اختبارها ومشاهدة النتائج خطوة بخطوة، مع طرح إضافة ملاحظات كجزء محتمل من التصميم.
عندك سؤال عن حاجة في البث ده؟
اسأل في الجروب