SEND HELP (more bugs) 🐜
تحب تدعم البث؟ عضوية «داعم» على يوتيوب بـ 60 جنيه في الشهر: شارات، إيموجي، وأسئلتك بجاوبها الأول في البث. اشترك كداعم
الخلاصة
يتابع البث عملًا عمليًا على تنظيم التطوير عبر مركز أوامر قابل للتخصيص وجلسات Warp المتعددة، مع تصور لتحويل هيكل المركز—مسار العمل، ولوحة المهام، ومركز الوكلاء، والتقويم—إلى مواصفات Markdown قابلة لإعادة الاستخدام. يتركز جزء كبير من المراجعة على Talkstore وContent Ops: حصر حالات الاستخدام، وفحص السجلات والتصنيف، وتتبع أعطال بوابة التأكيد وشرائح الإجراءات وتنسيق الردود، وتحسين إجراءات سريعة مرتبطة بسياق التاجر. ظهرت محاولات أولية لكتابة محتوى وتشغيل إثراء المنتجات، لكنها لم تكتمل بنجاح؛ بقيت أعطال الواجهة، وحالة المنتج بلا صورة، وبطء معالجة الكتالوجات، وسلوك الشرائح بعد التنفيذ مسائل تحتاج إلى تحقق. يناقش لقمان أيضًا تصورًا لوكيل تشخيصي ذاتي الاختبار يعمل عند الطلب، مع مراجعة بشرية، واقتراح وضع التخطيط كضابط محتمل قبل الإصلاحات الجريئة—مع الإقرار بأنه لم يُستخدم في الحالة الموصوفة—والتفكير في إنشاء خطوط أساس للانحدار ومراجعتها، رغم أن بعض تفاصيل الإعداد ظلت غير واضحة. وتبقى المصادقة وربط نتائج الوكلاء وتحديد معيار النجاح تحديات مفتوحة. وتشمل المناقشات الأوسع آراء وتجارب غير حاسمة حول أدوات البرمجة وخطط الاستخدام، وأهمية قيمة المنتج، واختبار الطلب على أفكار SaaS قبل البناء، ثم الانتقال من البرمجة إلى الطرح والتسويق والبيع.
53 لحظة من البث
- 0:36:25
إجراءات سريعة ذكية داخل ردود المساعد التجاري
يناقش ما كان يصفه وقت البث بأنه أصعب جزء في العمل: منطق الردود وتنسيقها. يقترح أن يكتشف المساعد فرص التنفيذ داخل محادثة التاجر ويعرض أزرار إجراءات سريعة مرتبطة بالسياق، مثل تطبيق تحسينات مقترحة على منتجات محددة أو عرض منتجات أخرى تحتاج إلى تحسين. ويرى أن هذه الأزرار تعمل كدعوات إلى الإجراء تضيف قيمة عملية، منتقدًا النسخة السابقة لأنها كانت عامة وغير مترابطة وتفتقر إلى الذكاء السياقي.
- 0:41:28
مراجعة متعددة الجوانب لنطاق Content Ops
طلب فحص نطاق Content Ops المُضاف حديثًا في Talkstore عبر مراجعة الكود وتصحيح الأخطاء والتحقق والأمن، بهدف إعداد تقرير يوضح ما أُنجز وما لا يزال يحتاج إلى عمل. وأوضح أن النطاق لم يُختبر شخصيًا بعد، وأن الاختبار اليدوي سيأتي بعد المراجعة.
- 0:42:13
زر نسخ لتقليل العمل المتكرر
إضافة زر نسخ جعل نقل النص أسهل وقلّل الحاجة إلى النسخ اليدوي المتكرر، مع إشارة إلى فتح التطبيق التالي تلقائيًا؛ اسم التطبيق غير واضح في النص.
- 0:44:15
تصحيح بوابة التأكيد وإعادة التفكير في شرائح الإجراءات
جرى عزل الخلل بين الردود العادية وبوابة التأكيد، مع فحص أنواع شرائح الإجراءات المتاحة. رأى المتحدث أن الشرائح لا ينبغي أن تكون عامة أو عشوائية، بل دعوات واضحة لاتخاذ إجراء بحسب سياق الرسالة. تقرر إصلاح بوابة التأكيد أولًا والتحقق منها لاحقًا، ثم إعادة هيكلة منطق الشرائح الأوسع؛ ولم يُدَّعَ أن الإصلاح نجح بالفعل.
- 0:52:15
وكلاء متخصصون لمراجعة الأخطاء وإصلاحها على مراحل
عُرض استخدام وكيل للتصحيح وآخر للبحث لمراجعة العمل ومحاولة اكتشاف الأخطاء، مع اختيار البدء بالمرحلة الأولى ثم تحديث الخادم واختبار مشغّل ينفذ تدفقًا لإثراء المنتجات. نجح الخادم في التقاط أمر التنفيذ، لكن الاستجابة بدت بطيئة وظل سبب البطء غير محسوم مع وجود عدة احتمالات.
- 0:55:27
انهيار معالجة الكتالوج عند غياب صورة المنتج
وُصف عطل سابق كانت فيه معالجة الكتالوج تنهار عند الوصول إلى منتج بلا صورة، ما يحدد حالة حدّية مرتبطة بغياب البيانات.
- 0:56:00
تجربة وكلاء البرمجة في Antigravity وCursor
ناقش المتحدث تجربته وانطباعه عن Antigravity وCursor. أشار إلى أن عزل الطرفيات في Antigravity قد يؤثر في توجيه لقطات الشاشة إلى الوكيل المقصود، ورأى أن تصميم هذه البيئات يشجع استخدام وكلائها المدمجين. كما عبّر عن تفضيل شخصي لـCursor مع التنبيه إلى كلفته وحدود الاستخدام، وذكر أنه اطّلع على مواد عن تحديث حديث بدل الادعاء بأنه اختبره بنفسه.
- 1:00:32
استغراب ظهور شرائح الواجهة بعد التنفيذ
أثناء فحص النتيجة، عبّر المتحدث عن ارتباكه من ظهور شرائح واجهة في رسالة النتيجة بعد التنفيذ، وحدد ذلك كسلوك غير متوقع يحتاج إلى تتبع.
- 1:01:13
مخاوف بطء المعالجة مع كتالوجات المنتجات الكبيرة
أُثيرت مخاوف من أن سير العمل بطيء، وأن زمن التنفيذ قد يطول لدى تاجر يملك نحو مئة منتج.
- 1:01:52
تصحيح بوابة تأكيد إجراءات التاجر
يُوضَّح أن بوابة التأكيد المطلوبة يجب أن تعرض للتاجر خيارَي المتابعة أو الإلغاء عبر أزرار واضحة، مع إبقاء إمكانية كتابة الموافقة. ورغم وجود مكوّن للمعاينة بأزرار الموافقة والإلغاء، لم يظهر في الواجهة؛ لذلك طُلب التحقق من التنفيذ وتقديم خطوات مراجعة دقيقة.
- 1:05:00
حصر حالات استخدام Content Ops واختبارها تدريجيًا
طُلب أولًا حصر حالات الاستخدام التي توفرها Content Ops للتجار، ثم شرح كيفية إنشاء كل حالة واختبارها واحدة تلو الأخرى. تتضمن الأمثلة الظاهرة تدقيق المحتوى، مخزون المقالات وتفاصيلها، فحص المجموعات، توصيات فجوات المحتوى، إنشاء محتوى، وأوصاف المجموعات، مع التحقق أيضًا من المصنّف وقدرة النظام على معرفة عدد كتل المحتوى.
- 1:11:09
اختبار التدوين وبوابة التأكيد وتحسين واجهة الإجراء
جرى اختبار تدفق يجمع كتابة محتوى للمدونة مع بوابة تأكيد، ثم تقييم تجربة الواجهة. اقترح المتحدث وضع أزرار الموافقة أو الإلغاء داخل رد الوكيل مع إبقاء خيار التأكيد النصي، وجعل معاينة الإجراء أوضح وأكثر احترافية. نجحت محاولة كتابة المدونة مبدئيًا، لكن التدفق تعطل لاحقًا، لذلك لا تُعد النتيجة نجاحًا كاملًا.
- 1:16:49
تمكين الوكيل من فحص السجلات وتشخيص الأخطاء
ناقش المتحدث تدريب الوكيل على استكشاف الأخطاء بصورة أكثر استقلالًا، مع بقاء المراجعة البشرية، عبر بدء محادثة برمجية وفحص المصنفات والسجلات والنص وحالة المحادثة لاكتشاف المشكلات وتسريع العمل. طُلب أولًا التحقق مما إذا كان هذا الأسلوب ممكنًا وكيفية تنفيذه بدقة.
- 1:18:36
تشخيص خلل بوابة التأكيد وانحدار تنسيق الرد
حاول المتحدث تحديد ما إذا كانت المشكلة في إجراء التدوين أم بوابة التأكيد، ثم وصف انحدارًا بصريًا: يظهر الرد أولًا بخلفية بيضاء، وبعد ظهور أزرار الموافقة والتنفيذ والإلغاء يتحول إلى خلفية سوداء ويتشوّه التنسيق. أعجبه ترتيب الأزرار نفسه، لكن تغيّر الرد المتأخر وغير المتسق ظل المشكلة الأساسية.
- 1:21:25
تصميم وكيل ذاتي لاختبار التطبيق وتصحيح أخطائه
نقاش حول بناء وكيل يعمل عند الطلب لاختبار التطبيق وتصحيح أخطائه باستمرار، وربما ينسّق بين وكلاء فرعيين للتصحيح والتحقق. الدافع هو أتمتة متابعة السجلات وتمرير النتائج بين مكونات النظام، مع الإشارة إلى صعوبة التقاط استجابات الوكلاء الفرعيين وربطها برمجيًا.
- 1:25:15
السلوك المتوقع لتدفق النص وشريط الموافقة
تحديد لسلوك واجهة متوقع: يتدفق النص بصورة طبيعية، ثم يظهر شريط الموافقة أسفله من دون تحويل المحتوى.
- 1:25:47
ضوابط الأمان عند تكليف وكلاء البرمجة بإصلاح الأخطاء
ملاحظة عملية مفادها أن الوكيل المثابر قد ينتقل إلى حلول أكثر جرأة عندما يتعذر الإصلاح المباشر، وقد يصلح مشكلة بينما يتسبب في مشكلة أخرى بالخلفية إذا تصرف بلا موافقة. طُرح وضع التخطيط كوسيلة محتملة لمراجعة النهج قبل التنفيذ، مع الإقرار بأنه لم يُستخدم في الحالة الموصوفة.
- 1:28:38
حدود Playwright MCP عند اختبار تدفقات تتطلب تسجيل الدخول
توجد عقبة أمام الاختبار الآلي لأن وصول Playwright MCP يتطلب تسجيل دخول. التقاط لقطات الشاشة يدويًا مقبول، لكن الهدف الأوسع هو اختبار تدفقات تجربة المستخدم وسلوك الخلفية، ما يتطلب قناة موثوقة لتواصل وكيل الاختبار مع النظام الخلفي.
- 1:30:28
تعريف معيار النجاح للوكيل ذاتي الاختبار
يُطرح سؤال غير مكتمل حول شكل نتيجة النجاح وكيف يقيّم الوكيل الاستجابة، مع اقتراح مقارنة النتائج بخط أساس معروف وسليم. بقية معايير التقييم غير واضحة في النص المتاح.
- 1:31:10
إنشاء خطوط أساس لاختبارات الانحدار
ناقش المتحدث اختيار اختبارات بنيوية ودلالية واختبارات انحدار، مع جعل الوكيل ينشئ خطوط الأساس تلقائيًا في البداية ثم مراجعتها لاكتشاف المشكلات. بعض تفاصيل الإعداد غير واضحة في النص.
عندك سؤال عن حاجة في البث ده؟
اسأل في الجروب