حلقة ShadCN هي أفضل حل لواجهة المستخدم المعطلة

AAI LABS
컴퓨터/소프트웨어창업/스타트업AI/미래기술

Transcript

00:00:00معظمكم يعرف بالفعل shad cn كواحدة من أكثر مكتبات واجهات المستخدم استخدامًا، ولكن استخدام وكيل ذكاء اصطناعي للبناء بها قد يكون مشكلة.
00:00:08إذا كنت تبني صفحات هبوط بسيطة فلن تواجه مشكلة كبيرة، لكن إذا كنت تبني تطبيقًا جديدًا أو تقوم بتنفيذ ميزة جديدة فإن الأمور تتعطل وتعطل أجزاء أخرى من التطبيق أيضًا.
00:00:18لكن هذا ليس جديدًا، فهذه المشكلة تم حلها بالفعل وهذه هي الطريقة التي يبني بها المهندسون التطبيقات الآن.
00:00:24وكلاء الذكاء الاصطناعي دائمًا يختبرون الكود الذي يكتبونه، لكن هؤلاء الوكلاء يصبحون غير موثوقين مع السياقات الكبيرة.
00:00:31لذلك نحتاج إلى طريقة لضمان أن الوكلاء يكملون العمل الموكل إليهم.
00:00:35هنا يأتي مفهوم الحلقات الوكيلة، وأنثروبيك تحل هذا باستخدام حلقة ralph.
00:00:40لحل مشكلة واجهة المستخدم الخاصة بي، حاولت تنفيذ حلقة ralph وفي البداية فشلت تمامًا، لكنني اكتشفت بسرعة أن الفشل لم يكن بسبب حلقة ralph بل بسبب العملية التي نفذتها معها.
00:00:50ralph في الواقع هو إضافة جديدة تم إصدارها من قبل أنثروبيك أنفسهم، لكن هذه لم تكن من أفكارهم الأصلية.
00:00:56إنها مبنية على تقنية من شخص آخر وأنثروبيك قاموا بتنفيذها وجعلها مفتوحة المصدر.
00:01:01ralph هو في الأساس حلقة، وإذا كنت تعرف عن خطافات claud code فهي تستخدم خطافات التوقف التي تعمل عندما يتوقف claud عن إخراج الإجابة.
00:01:09بمجرد أن يتوقف، يتم تغذية وكيل الذكاء الاصطناعي بملف المطالبة الأولي مرة أخرى وهذا يسمح له بتحسين عمله بشكل تكراري.
00:01:16الآن السؤال المهم هو: متى يخرج فعليًا من الحلقة؟ هناك شيء يسمى وعد الإكمال والذي يمكن أن يكون أي كلمة تدخلها.
00:01:23عندما يشعر claud أن مهمته قد اكتملت، يخرج هذا الوعد بنفسه.
00:01:26على سبيل المثال، في هذه الحالة الوعد هو كلمة complete.
00:01:30إذا كان الوعد موجودًا في المطالبة المُرجعة، فإن الحلقة لا تعمل مرة أخرى.
00:01:34لذلك حتى يُخرج claud الوعد، فإنه لا يتوقف.
00:01:37هذا يضمن أن claud لا ينسحب متى يريد.
00:01:39بعد تثبيت الإضافة، سيكون لديك ثلاثة أوامر: أمر حلقة ralph وأمر إلغاء وأمر مساعدة.
00:01:44في أمر الحلقة تحتاج إلى توفير المطالبة التي يتم تغذيتها للوكيل مرارًا وتكرارًا.
00:01:49في بعض الأحيان قد يحصل على مهمة مستحيلة لا يستطيع حلها وقد يعلق في حلقة لا نهائية، لذلك تحديد عدد التكرارات الأقصى هو ممارسة جيدة حقًا.
00:01:57سأترك رابط المستودع أدناه لأن لديهم بعض الممارسات الجيدة للمطالبات التي يمكنك تقديمها لحلقة ralph، لكن في هذا الفيديو سأناقش فقط تلك المتعلقة بسير عمل واجهة المستخدم الذي سأعرضه لكم.
00:02:08لنفترض أننا نريد تنفيذ ميزتين في هذا التطبيق.
00:02:11واحدة هي لوحة الأوامر حيث نضيف قائمة للبحث في تطبيقنا وتنفيذ أوامر أخرى.
00:02:15للتأكد من أن هذه الميزة الجديدة لا تعطل أجزاء أخرى من التطبيق، يجب أن تبدأ بالاختبارات.
00:02:21هذا يسمى التطوير الموجه بالاختبار.
00:02:23إذا لم تكن على دراية بهذا، يمكنك أن تطلب من claud code إعداد هيكل TDD لك حيث ينشئ مجلد اختبار من البداية للنهاية ومجلد لقطات الشاشة للتحقق من مشاكل واجهة المستخدم والاختبار المقابل أيضًا.
00:02:35الميزة الأخرى التي سننفذها هي عرض اللوحة في قاعدة البيانات مشابهًا لما يسمح لنا notion بفعله مع قواعد بياناتهم.
00:02:41إذا كنت قد فهمت الفكرة، فإن التطوير الموجه بالاختبار هو نهج حيث يتم كتابة الاختبارات قبل تنفيذ الكود، لكن هذا يعني أن الاختبارات الأولية ستفشل دائمًا.
00:02:51لذلك إذا كنت أنفذ ميزة لوحة الأوامر، فلن أبدأ فقط في كتابة الكود لها، بل سأكتب أولاً اختبارات مفصلة لها.
00:02:57ثم نكتب الحد الأدنى من الكود المطلوب لاجتياز تلك الاختبارات.
00:03:01بمجرد الانتهاء من ذلك، نعيد الهيكلة ونضيف المزيد من الوظائف ومع كل إضافة نتأكد من أن الاختبارات لا تزال تنجح.
00:03:08شيء مثير آخر هو أن هذه الاختبارات آلية ويمكن استيراد playwright واستخدامه للتحقق البصري.
00:03:13إذا كنت تعتقد أننا نستخدم playwright mcp للتحقق من هذا بشكل مستقل من خلال المتصفح، فأنت مخطئ.
00:03:19مع TDD لكل سلوك وظيفي يمكنك التقاط لقطات شاشة.
00:03:21على سبيل المثال، إذا كان السلوك الوظيفي هو إضافة بطاقة، فإن لقطة الشاشة ستظهر بطاقة مضافة إلى اللوحة.
00:03:28لذا الآن كل ما على وكيل الذكاء الاصطناعي فعله هو النظر إلى تلك اللقطات والتأكد من عدم وجود مشاكل في الطريقة التي تم بها تنفيذ مكونات shad cn.
00:03:36ملفات الاختبار هذه تضمن أنه كلما تمت إضافة شيء جديد أو أثناء بناء ميزة، يتم تلبية جميع متطلباتنا السلوكية.
00:03:43لكن في حالتنا نريد استخدام لقطات الشاشة فقط للتحقق من واجهة المستخدم.
00:03:47لكن إذا كان لدينا بالفعل TDD، لماذا نحتاج إلى حلقة ralph؟ كما ذكرت بالفعل، مع المهام الأكبر ونوافذ السياق التي تصبح ممتلئة تقريبًا، فإن هذه النماذج تتوقف فجأة عن مهامها وتتطلب تدخلاً بشريًا مستمرًا.
00:03:59لذلك يمكنني كتابة اختبارات مسبقًا لأي نوع من الوظائف التي أريدها، ثم استخدام الحلقة لتعليمها بما يجب القيام به ويمكنها العمل بشكل مستقل.
00:04:08بإخبارها بسير العمل الذي يجب اتباعه ثم إعطائها الشرط لمتى يمكنها إخراج الوعد، فإنها تكمل المهمة وتخرج من الحلقة، والتي في هذه الحالة عندما تجتاز جميع الاختبارات الـ25 الفريدة.
00:04:19لذلك باستخدام أمر slash ralph أعطيته مطالبة لكي يبني بشكل تكراري ميزة لوحة الأوامر.
00:04:24في المطالبة كنا في الأساس نخبره بتنفيذ الميزة مع بعض المتطلبات الأساسية التي ليست مهمة حقًا لأن المتطلبات موجودة في الاختبارات أيضًا، لكننا حددنا سير العمل بالكامل.
00:04:34في سير العمل هذا كان من المفترض أن يبدأ بتشغيل الاختبارات.
00:04:37يعرف أن الاختبارات ستفشل وبعد ذلك يحتاج إلى تنفيذ المكونات لجعلها تنجح.
00:04:42هذا هو الهدف الكامل.
00:04:43الآن إذا كانت هذه مهمة أوسع بكثير، فإن الاحتمالات هي أنه عندما تمتلئ نافذة السياق أو يتشوش claud، سينسحب تلقائيًا.
00:04:50لن يخرج أبدًا وعد الإكمال وبما أنه لا يخرج الوعد، ستُغذى المطالبة مرة أخرى وسيتعين عليه البدء من جديد مما يعني أنه سيستمر في العمل عليه بشكل تكراري.
00:04:59لكن بما أن هذه كانت مهمة أصغر، فقد تمكن فعليًا من تنفيذ كل شيء دفعة واحدة وكتابة جميع المكونات وجعل جميع الاختبارات تنجح.
00:05:07الآن بعد نجاح الاختبارات، يخبره سير العمل بمراجعة جميع لقطات الشاشة للوحة الأوامر.
00:05:12هذه لقطات شاشة مأخوذة في مراحل مختلفة للتأكد من أن واجهة المستخدم، سواء كانت shad cn أو أي مكتبة مكونات أخرى تستخدمها، تم تنفيذها بشكل صحيح وأنه لا توجد أي مشاكل بسيطة.
00:05:22بعد ذلك يجب أن يشغل الاختبارات مرة أخرى ويتأكد من أنها لا تزال تنجح بعد تغييرات واجهة المستخدم.
00:05:28نظرًا لأن جميع الاختبارات كانت ناجحة وتمت مراجعة لقطات الشاشة، فقد أخرج وعد الإكمال.
00:05:33هنا توقفت الحلقة ولم تستمر مرة أخرى.
00:05:35لكن كانت هناك مشكلة كبيرة حقًا في هذا والتي لم ألاحظها في ميزة لوحة الأوامر لأنه كانت هناك فرص قليلة جدًا لأخطاء واجهة المستخدم.
00:05:43ومع ذلك، عندما انتقلت إلى تنفيذ عرض اللوحة، أدركت أن هناك خطأ كبيرًا في النظام.
00:05:48بدأت بتنفيذ اللوحة بنفس المطالبة.
00:05:50كانت المتطلبات مختلفة بالطبع لكن سير العمل كان نفسه إلى حد كبير.
00:05:54الآن كنت نوعًا ما متفاجئًا عندما أكمل جميع المتطلبات دفعة واحدة.
00:05:58لا تفهموني خطأ، كان فعليًا يتأكد من أن جميع الاختبارات تنجح، لكن بينما كان يفعل ذلك كانت هناك حالات كان فيها عدد الاختبارات الناجحة ينخفض فعليًا لأنه بتغيير شيء ما كان يعطل شيئًا آخر وهذا هو السبب في أن TDD مهم حقًا بسبب هذا الاختبار المتكرر والتأكد من أن كل شيء يعمل.
00:06:15لكن المشكلة الرئيسية كانت أنه بعد أن تحقق من أنه انتهى وذهبت للتحقق من واجهة المستخدم، كانت معظم الأشياء منفذة بشكل صحيح لكنه فاته تمامًا بعض أخطاء واجهة المستخدم مثل هذا.
00:06:25تحققت أيضًا من لقطات الشاشة وكانت الأخطاء تظهر في تلك اللقطات أيضًا.
00:06:30لذلك سألته وحللنا ما الذي حدث خطأ فعليًا.
00:06:32المشكلة الحقيقية كانت فشل العملية، خاصة فيما يتعلق بإصلاح واجهة المستخدم.
00:06:37ما حدث هو أنه اجتاز جميع الاختبارات لأنه كان من المفترض أن يشغل ملفات الاختبار مرارًا وتكرارًا، لكن لم يكن هناك اختبار محدد لواجهة المستخدم غير لقطات الشاشة.
00:06:46نظر إلى بعضها بشكل سريع وحتى تجاهل بعض أخطاء واجهة المستخدم التي رآها.
00:06:51بعض الملفات تم تجاهلها تمامًا.
00:06:52لذلك المشكلة الرئيسية كانت أنه أخرج بيان الوعد مبكرًا ولم يتحقق مما إذا كانت واجهة المستخدم مُصلحة فعليًا.
00:06:59مررنا بجلسة عصف ذهني كاملة حول كيفية إصلاح هذا وحتى أعطيت أفضل ممارسات كتابة المطالبات من المستودع لـ clod code، لكن في النهاية توصلنا إلى بعض القواعد المحددة وتغيير في العملية من شأنه أن يضمن أن واجهة المستخدم دائمًا صحيحة.
00:07:13الآن هذا لم يكن له علاقة بالاختبارات لأنها ستعمل دائمًا.
00:07:16المطالبة التي استخدمناها للوحة الأوامر مفيدة حقًا عندما تكون الميزة أو التنفيذ كبيرًا جدًا حيث لا يهلوس clod بأنه أكمل المهمة ولكن بسبب نافذة سياق ممتلئة أو تعقيد المهمة ينسحب فجأة.
00:07:27الآن clod code مستقل بالفعل حقًا، لا شك في ذلك، لكن لا تزال هناك مشاكل مثل هذه نحتاج إلى إصلاحها.
00:07:33لذلك غيرنا عددًا من الأشياء في المطالبة الرئيسية.
00:07:36الأول كان بروتوكول التحقق من لقطة الشاشة.
00:07:39أضفنا بادئة بسيطة لكل صورة أخبرت clod ما إذا كان قد قرأ لقطة الشاشة أم لا.
00:07:44لكن عندما نفذت هذا لأول مرة، لم يقرأ كل الصور.
00:07:46كان يقرأ بعضها ويكتب verified في الأعلى وكما كان من قبل، كان ينسحب مبكرًا.
00:07:51لذلك لحل هذا شجعناه على التفكير بطريقة مختلفة.
00:07:54أخبرناه أنه بعد إعادة تسمية جميع لقطات الشاشة، لا يجب أن يخرج الوعد بعد، مما يعني أنه لا يجب أن يعتبر المهمة مكتملة ويجب أن يسمح للتكرار التالي بتأكيد الإكمال.
00:08:04لذلك يجب تشغيل حلقتين على الأقل.
00:08:06ما يحدث في التحقق التالي هو أن clod يتحقق من أن جميع الملفات لديها بادئة verified.
00:08:11بالطبع هذا يعني أننا اضطررنا لتغيير الاختبارات وفصل التحقق من الصور عن الاختبارات الوظيفية.
00:08:16التكرار التالي يتأكد من أن جميع الصور لديها نتائج محققة وإذا فات clod أي شيء فإنه ينظر إليها مرة أخرى ويصلح المخرجات.
00:08:23مع هذا التغيير، الأخطاء الصغيرة في واجهة المستخدم التي كنا نواجهها تم إصلاحها أخيرًا وتمكن من تنفيذ كل هذه الميزات بشكل صحيح.
00:08:31لذلك عندما دخل الحلقة التالية، شغل الاختبارات مرة أخرى.
00:08:35بما أنه وجد بعض الأخطاء، أصلحها ولأن جميع الملفات كانت تحتوي على كلمة verified فيها، شغل اختبارًا نهائيًا.
00:08:41هذه المرة أكمل مهمته في حلقتين وتمكن من إصلاح جميع أخطاء واجهة المستخدم الرئيسية في التطبيق.
00:08:47دعونا نتحدث عن أوتوماتا الآن.
00:08:49بعد تعليم الملايين من الناس كيفية البناء باستخدام الذكاء الاصطناعي، بدأنا في تنفيذ سير العمل هذا بأنفسنا.
00:08:55اكتشفنا أنه يمكننا بناء منتجات أفضل بشكل أسرع من أي وقت مضى.
00:08:59نحن نساعد في إحياء أفكارك سواء كانت تطبيقات أو مواقع ويب.
00:09:02ربما شاهدت مقاطع الفيديو الخاصة بنا وأنت تفكر
00:09:05"لدي فكرة رائعة لكن ليس لدي فريق تقني لبنائها"
00:09:08.
00:09:08هذا بالضبط هو المكان الذي ندخل فيه.
00:09:11فكر فينا كطيار مساعد تقني لك.
00:09:12نطبق نفس سير العمل الذي علمناه للملايين مباشرة على مشروعك، محولين المفاهيم إلى حلول عملية حقيقية دون صداع التوظيف أو إدارة فريق تطوير.
00:09:21هل أنت مستعد لتسريع فكرتك إلى واقع؟ تواصل معنا على hello@automata.dev.
00:09:25إذا كنت ترغب في دعم القناة ومساعدتنا في الاستمرار في صنع مقاطع فيديو مثل هذه، يمكنك القيام بذلك باستخدام زر الشكر الفائق أدناه.
00:09:33كما هو الحال دائمًا، شكرًا لك على المشاهدة وسأراك في المرة القادمة.

Key Takeaway

دمج حلقة RALPH مع التطوير الموجه بالاختبار وبروتوكول التحقق من لقطات الشاشة يحل مشكلة تعطل واجهة المستخدم عند بناء تطبيقات ShadCN باستخدام وكلاء الذكاء الاصطناعي.

Highlights

استخدام ShadCN مع وكلاء الذكاء الاصطناعي يواجه مشكلة تعطل واجهة المستخدم عند بناء تطبيقات معقدة

حلقة RALPH من Anthropic تحل مشكلة توقف الوكلاء عن العمل مع السياقات الكبيرة من خلال التغذية المتكررة للمطالبات

التطوير الموجه بالاختبار (TDD) يضمن عدم تعطل الميزات الجديدة لأجزاء أخرى من التطبيق

استخدام Playwright لالتقاط لقطات شاشة آلية يساعد في التحقق البصري من تنفيذ مكونات ShadCN

بروتوكول التحقق من لقطات الشاشة بإضافة بادئة 'verified' يمنع خروج الوكيل المبكر من الحلقة

النظام يتطلب حلقتين على الأقل: الأولى لإعادة تسمية الصور والثانية للتحقق من اكتمال التنفيذ

فصل التحقق من الصور عن الاختبارات الوظيفية أساسي لضمان صحة واجهة المستخدم

Timeline

المشكلة الأساسية مع ShadCN ووكلاء الذكاء الاصطناعي

يقدم المتحدث المشكلة الرئيسية التي يواجهها المطورون عند استخدام وكلاء الذكاء الاصطناعي لبناء تطبيقات بمكتبة ShadCN. بينما تعمل الأمور بشكل جيد مع صفحات الهبوط البسيطة، فإن بناء تطبيقات جديدة أو تنفيذ ميزات جديدة يؤدي إلى تعطل الأشياء وتعطيل أجزاء أخرى من التطبيق. يشير إلى أن هذه المشكلة ليست جديدة وأن هناك حلاً متاحاً بالفعل يستخدمه المهندسون حالياً. هذا يمهد الطريق لاستكشاف الحل من خلال حلقات الوكلاء والتطوير الموجه بالاختبار.

مفهوم حلقة RALPH وآلية عملها

يشرح المتحدث مفهوم حلقات الوكلاء وكيف تحل Anthropic هذا باستخدام حلقة RALPH. الوكلاء يصبحون غير موثوقين مع السياقات الكبيرة، لذا تضمن RALPH إكمال المهام الموكلة. الحلقة تعمل بشكل مشابه لخطافات التوقف في Claude Code، حيث يتم تغذية وكيل الذكاء الاصطناعي بملف المطالبة الأولي مرة أخرى بعد التوقف، مما يسمح له بتحسين عمله بشكل تكراري. يتم الخروج من الحلقة عندما يخرج Claude وعد الإكمال (completion promise)، وهي كلمة محددة مثل 'complete' تشير إلى اكتمال المهمة. هذا النظام يضمن أن Claude لا ينسحب متى يريد ويستمر في العمل حتى إنجاز المهمة فعلياً.

إعداد حلقة RALPH والتطوير الموجه بالاختبار

بعد تثبيت الإضافة، تتوفر ثلاثة أوامر: حلقة RALPH، إلغاء، ومساعدة. في أمر الحلقة تحتاج إلى توفير المطالبة والحد الأقصى للتكرارات لتجنب الحلقات اللانهائية. المتحدث يركز على سير عمل واجهة المستخدم ويقدم مثالاً بميزتين: لوحة الأوامر وعرض اللوحة في قاعدة البيانات. يؤكد على أهمية البدء بالاختبارات للتأكد من أن الميزات الجديدة لا تعطل أجزاء أخرى من التطبيق، وهذا ما يسمى بالتطوير الموجه بالاختبار (TDD). يمكن لـ Claude Code إعداد هيكل TDD كامل من البداية للنهاية بما في ذلك مجلد الاختبارات ومجلد لقطات الشاشة للتحقق من مشاكل واجهة المستخدم.

شرح منهجية التطوير الموجه بالاختبار والتحقق البصري

يوضح المتحدث أن TDD هو نهج حيث تُكتب الاختبارات قبل تنفيذ الكود، مما يعني أن الاختبارات الأولية ستفشل دائماً. العملية تتضمن كتابة اختبارات مفصلة أولاً، ثم كتابة الحد الأدنى من الكود لاجتياز تلك الاختبارات، ثم إعادة الهيكلة وإضافة المزيد من الوظائف مع التأكد من نجاح الاختبارات. الميزة المثيرة هي أن هذه الاختبارات آلية باستخدام Playwright للتحقق البصري، حيث يتم التقاط لقطات شاشة لكل سلوك وظيفي. على سبيل المثال، إذا كان السلوك هو إضافة بطاقة، ستظهر لقطة الشاشة البطاقة المضافة. وكيل الذكاء الاصطناعي ينظر إلى هذه اللقطات ويتأكد من عدم وجود مشاكل في تنفيذ مكونات ShadCN.

دمج RALPH مع TDD وأهمية الحلقة

يجيب المتحدث على السؤال: لماذا نحتاج حلقة RALPH إذا كان لدينا TDD؟ المشكلة هي أنه مع المهام الأكبر ونوافذ السياق الممتلئة، النماذج تتوقف فجأة عن مهامها وتتطلب تدخلاً بشريًا مستمرًا. بكتابة الاختبارات مسبقاً واستخدام الحلقة لتعليم الوكيل بما يجب القيام به، يمكنه العمل بشكل مستقل. بإخبار الوكيل بسير العمل الذي يجب اتباعه وإعطائه الشرط لإخراج الوعد (عندما تجتاز جميع الاختبارات الـ25)، يكمل المهمة ويخرج من الحلقة. استخدم أمر /ralph مع مطالبة تحدد سير العمل الكامل بما في ذلك تشغيل الاختبارات، معرفة أنها ستفشل، ثم تنفيذ المكونات لجعلها تنجح.

نجاح ميزة لوحة الأوامر والعملية التكرارية

في تنفيذ ميزة لوحة الأوامر، كان سير العمل يبدأ بتشغيل الاختبارات التي ستفشل، ثم تنفيذ المكونات لجعلها تنجح. مع المهام الأوسع، عندما تمتلئ نافذة السياق أو يتشوش Claude، سينسحب تلقائياً ولن يخرج وعد الإكمال، مما يؤدي إلى تغذية المطالبة مرة أخرى والبدء من جديد بشكل تكراري. لكن بما أن هذه كانت مهمة أصغر، تمكن من تنفيذ كل شيء دفعة واحدة وجعل جميع الاختبارات تنجح. بعد نجاح الاختبارات، يخبره سير العمل بمراجعة جميع لقطات الشاشة المأخوذة في مراحل مختلفة للتأكد من تنفيذ واجهة المستخدم بشكل صحيح، ثم يشغل الاختبارات مرة أخرى للتأكد من نجاحها بعد تغييرات واجهة المستخدم، ثم يخرج وعد الإكمال.

اكتشاف المشكلة في ميزة عرض اللوحة

كانت هناك مشكلة كبيرة لم يلاحظها المتحدث في ميزة لوحة الأوامر بسبب قلة فرص أخطاء واجهة المستخدم. عند الانتقال لتنفيذ ميزة عرض اللوحة بنفس المطالبة وسير العمل، كان متفاجئاً عندما أكمل Claude جميع المتطلبات دفعة واحدة. كان يتأكد من نجاح جميع الاختبارات، لكن كانت هناك حالات ينخفض فيها عدد الاختبارات الناجحة لأنه بتغيير شيء ما كان يعطل شيئاً آخر، وهذا يبرز أهمية TDD. المشكلة الرئيسية ظهرت عندما تحقق من واجهة المستخدم بعد أن أعلن الاكتمال: معظم الأشياء كانت منفذة بشكل صحيح لكنه فاته تماماً بعض أخطاء واجهة المستخدم، وكانت هذه الأخطاء تظهر في لقطات الشاشة أيضاً.

تحليل السبب الجذري لفشل العملية

بعد التحليل، اكتشف المتحدث أن المشكلة الحقيقية كانت فشل العملية فيما يتعلق بإصلاح واجهة المستخدم. Claude اجتاز جميع الاختبارات لأنه كان من المفترض أن يشغل ملفات الاختبار مراراً وتكراراً، لكن لم يكن هناك اختبار محدد لواجهة المستخدم غير لقطات الشاشة. نظر إلى بعضها بشكل سريع وتجاهل بعض أخطاء واجهة المستخدم التي رآها، وبعض الملفات تم تجاهلها تماماً. المشكلة الرئيسية كانت أنه أخرج بيان الوعد مبكراً ولم يتحقق مما إذا كانت واجهة المستخدم مُصلحة فعلياً. هذا لم يكن له علاقة بالاختبارات لأنها ستعمل دائماً، بل كانت المشكلة في عملية التحقق من لقطات الشاشة.

الحل: بروتوكول التحقق من لقطات الشاشة المحسّن

بعد جلسة عصف ذهني ومراجعة أفضل ممارسات كتابة المطالبات، توصلوا إلى حل يتضمن قواعد محددة وتغيير في العملية. أضافوا بروتوكول التحقق من لقطة الشاشة باستخدام بادئة بسيطة لكل صورة تخبر Claude ما إذا كان قد قرأها أم لا. في التنفيذ الأول، لم يقرأ كل الصور وكان ينسحب مبكراً. الحل كان تشجيعه على التفكير بطريقة مختلفة: بعد إعادة تسمية جميع لقطات الشاشة، لا يجب أن يخرج الوعد بعد، بل يجب أن يسمح للتكرار التالي بتأكيد الإكمال، مما يعني تشغيل حلقتين على الأقل. في التحقق التالي، يتحقق Claude من أن جميع الملفات لديها بادئة 'verified'. هذا تطلب تغيير الاختبارات وفصل التحقق من الصور عن الاختبارات الوظيفية.

نجاح الحل وإكمال الميزات بشكل صحيح

التكرار التالي يتأكد من أن جميع الصور لديها نتائج محققة، وإذا فات Claude أي شيء فإنه ينظر إليها مرة أخرى ويصلح المخرجات. مع هذا التغيير، الأخطاء الصغيرة في واجهة المستخدم التي كانوا يواجهونها تم إصلاحها أخيراً وتمكن من تنفيذ جميع الميزات بشكل صحيح. عندما دخل الحلقة التالية، شغل الاختبارات مرة أخرى، ووجد بعض الأخطاء فأصلحها. بما أن جميع الملفات كانت تحتوي على كلمة 'verified'، شغل اختباراً نهائياً. هذه المرة أكمل مهمته في حلقتين فقط وتمكن من إصلاح جميع أخطاء واجهة المستخدم الرئيسية في التطبيق.

الترويج لخدمات Automata والخاتمة

يختتم المتحدث بالترويج لشركته Automata التي تطبق سير العمل هذا لبناء منتجات للعملاء. بعد تعليم الملايين كيفية البناء بالذكاء الاصطناعي، اكتشفوا أنهم يمكنهم بناء منتجات أفضل بشكل أسرع من أي وقت مضى. يقدمون خدمات لإحياء الأفكار سواء كانت تطبيقات أو مواقع ويب، ويعملون كطيار مساعد تقني يطبق نفس سير العمل مباشرة على المشاريع، محولين المفاهيم إلى حلول عملية حقيقية دون صداع التوظيف أو إدارة فريق تطوير. يدعو المشاهدين للتواصل على hello@automata.dev، ويشجع على دعم القناة باستخدام زر الشكر الفائق، ويشكر المشاهدين على المتابعة.

Community Posts

View all posts