هذه هي المقالة الأولى في سلسلة مقالات حول تحديثات إصدار Caffeine V3، ستقدم هذه المقالة الهيكل الجديد للبناء، والمقالة القادمة: كيف يمكن لنظام التصميم في V3 أن يخلق تطبيقات أكثر جاذبية.
إذا واجهت يومًا Caffeine ينسى شكل تطبيقك الأصلي بعد 50 تعديل، فهنا تفسير لماذا حدث ذلك، ولماذا لن يحدث مرة أخرى.
في الإصدار V3، أعادنا بناء طريقة بناء تطبيق Caffeine من الأساس، حيث كان Caffeine سابقًا يعتمد على خط أنابيب متسلسل، يتكون أساسًا من سلسلة من الوكلاء الذين يعملون بالتتابع: تخطيط التطبيق، بناء الخلفية، بناء الواجهة الأمامية، إجراء فحوصات الجودة، النشر، يجب إكمال كل خطوة قبل البدء في الخطوة التالية، وإذا اكتشفنا مشكلة في الخطوة الثانية خلال الخطوة الثالثة، فلن نتمكن من التراجع.
تنجح هذه الطريقة مع التطبيقات البسيطة، لكن مع نمو المشروع (مزيد من الصفحات، ومزيد من الميزات، ومزيد من دورات التكرار) تبدأ العملية بالوصول إلى الاختناق؛ تمتلئ نافذة السياق، وتتجاهل القرارات المبكرة، وتضعف الجودة.
يستبدل V3 العملية التسلسلية القديمة بفريق من الوكلاء المتخصصين الذين يمكنهم العمل بالتوازي وعبر عدة جولات من التكرار، مع تمرير ما يتعلمونه بين كل جولة وأخرى، وكل ذلك يديره منسق نسميه "المنسق". يمكنك التفكير في الأمر بهذه الطريقة: لم تعد بحاجة إلى أن تعتمد على شخص واحد لإنجاز كل شيء، بل أصبحت هناك شركة كاملة تعمل من أجلك.
من وكيل واحد إلى فريق كامل
لا يقرأ Composer الشيفرة ولا يكتبها أبدًا؛ فمهمته هي تقسيم طلبك إلى عدة مهام، وتوزيعها على الخبراء المناسبين، وجمع النتائج، وتحديد الخطوة التالية، بينما ينفذ الخبراء العمل الفعلي:
يقوم أحد وكلاء Discovery بمسح مشروعك حتى يفهم بدقة حالة المشروع الحالية قبل حدوث أي تغيير.
يقوم أخصائي المنتج بتحويل متطلباتك إلى متطلبات منظمة ليسترشد بها الفريق بأكمله.
يقوم وكيل التصميم بإنشاء نظام بصري كامل (علامات الألوان، الخطوط، وإرشادات التخطيط)، وتُتبع جميع قرارات الواجهة الأمامية هذا النظام.
يكتب مهندس الواجهة الأمامية شيفرة React، ويمكن تشغيل عدة قواعد React بالتوازي لاستخدامها في صفحات مختلفة.
يكتب مهندس الواجهة الخلفية شيفرة Motoko لأجهزة الكمبيوتر على الإنترنت.
يقوم مختص ضمان الجودة بمراجعة الشيفرة وتشغيل الاختبارات البصرية.
عندما تطلب من Caffeine بناء شيء ما، يتولى Composer المهمة في الخلفية، وأثناء عملية البناء يمكنك مواصلة المحادثة، أو إضافة سياق، أو تغيير الاتجاه، أو إيقاف البناء بالكامل متى احتجت ذلك.
الموجات: كيف يتناسق الفريق
ينظم Composer العمل على هيئة موجات؛ ففي كل موجة تعمل المهام المستقلة بالتوازي، وبين الموجات تنتقل النتائج بالتتابع.
تسير عملية التطوير النموذجية على النحو التالي:
الموجة الأولى - تقوم مرحلة الاستكشاف بمسح المشروع، ويقوم وكيل المنتج بإنشاء المواصفات.
الموجة الثانية - يخلق فريق التصميم الهوية البصرية، بينما يكتب الواجهة الخلفية عقود API، ويحدث ذلك بالتزامن.
الموجة الثالثة - يستخدم الواجهة الأمامية رموز التصميم وعقود الواجهة الخلفية من الموجة السابقة لبناء بنية التطبيق.
الموجة الرابعة - إذا كان للتطبيق عدة صفحات مستقلة، فسيتم بناؤها بالتوازي (وتتولى كل صفحة وكيل واجهة أمامية منفصل).
الموجة الخامسة - مراجعة الجودة وفقًا للمتطلبات الأصلية، مع إجراء فحص بصري.
النشر.
المهم هو التغيير بين دورات التكرار؛ إذ يعيد كل خبير نتيجة منظمة: ما الذي بناه (حتى يعرف الوكلاء اللاحقون الموارد المتاحة)، وما الذي تعلمه أثناء ذلك، وما المشكلات التي اكتشفها ولم يتمكن من حلها. تنتقل هذه المعلومات باستمرار، بحيث تحمل كل دورة تكرار سياقًا أغنى من السابقة، وتتراكم الدروس المستفادة طوال عملية البناء، مما يجعل النظام أكثر ذكاءً بمرور الوقت.
وقد أتاح هذا ميزتين لم تكن موجودتين في العملية القديمة: التوازي، أي أن المهام المستقلة داخل كل دورة تكرار (التصميم، الواجهة الخلفية، عدة صفحات، إلخ) يمكن أن تعمل في الوقت نفسه، بينما كانت العملية القديمة تنفذ مهمة واحدة فقط في كل مرة، والتكرارية، حيث يمكن لـ Composer تشغيل أي عدد من دورات التكرار حسب الحاجة؛ فإذا اكتشف فريق الواجهة الأمامية ضرورة إجراء تغيير على الواجهة الخلفية، يُعاد إرسال مهندس الواجهة الخلفية لمعالجة ذلك، وإذا اكتشفت مراجعة الجودة مشكلة، تُضاف دورة تكرار أخرى لإصلاحها، بينما كانت العملية القديمة لا تعمل إلا مرة واحدة من البداية إلى النهاية.
ليس كل تغيير يتطلب الفريق بأكمله؛ فإذا كنت تطلب فقط بعض المتطلبات المحددة، مثل تغيير اللون أو تعديل العنوان، فسيتعرف Composer على ذلك ويرسل وكيلًا واحدًا مباشرةً، متجاوزًا عملية التطوير الكاملة، بينما تمر الميزات المعقدة عبر عملية التطوير الكاملة، وتذهب الإصلاحات السريعة عبر المسار السريع.
كل عملية بناء تجلب سياقًا جديدًا تمامًا
تبدأ كل عملية بناء من الصفر؛ وحتى لو كان التغيير مجرد تعديل العنوان، فإن Caffeine يعيد فحص المشروع من البداية قبل إجراء أي تعديل، وهذا مقصود: فالنماذج الذكية تعمل بأفضل أداء عندما لا تتأثر بتراكم الجلسات السابقة.
ما يُحتفظ به فعلًا بين الإصدارات المختلفة هو ملف خفيف لإعدادات التفضيلات وتراكم الخبرة، أي بيانات وصفية حول كيفية استخدام المشروع، لا لقطة من المشروع نفسه؛ فمشروع يضم 50 ملفًا و700 نسخة مسودة يمكن أن يعمل بكفاءة مشروع جديد تمامًا. في الواقع، يقوم Caffeine مع مرور الوقت بتسجيل الأساليب التي تنجح مع مشروعك تحديدًا، لذا يصبح كل بناء أفضل من السابق، وهو عكس ما اعتدت عليه تمامًا.
يمكنك الآن رؤية ما يحدث
في V2، ترسل رسالة فتظهر لك عبارة "جارٍ بناء تطبيقك..." ثم عليك الانتظار فقط. ومع التطبيقات المعقدة، قد يعني ذلك دقائق من الصمت، دون أي طريقة لمعرفة ما يحدث أو ما إذا كان كل شيء يسير على ما يرام.
يعرض V3 عملية البناء في الوقت الفعلي؛ فتسرد قائمة المهام كل عمل يخطط له Composer، وتظهر مؤشرات الحالة عند اكتمال المهام أو فشلها أو تخطيها، بينما يوضح ملخص التقدم ما الذي يعالجه Caffeine حاليًا. وهناك أيضًا زر إيقاف - فإذا أردت تغيير الاتجاه، يمكنك إيقاف البناء مؤقتًا في أي وقت.
تتطابق قائمة التحقق هذه مباشرةً مع مخطط سير التطوير؛ إذ يمكنك رؤية متى تكتمل خطوة التصميم، ومتى يكتمل ترجمة الواجهة الخلفية، ومتى تُبنى الصفحات المتعددة بالتوازي، ومتى تتم مراجعة الجودة. وإذا حدث عطل، يمكنك معرفة أي مهمة فشلت ولماذا.
استعادة أخطاء أذكى
في العملية القديمة لم تكن هناك في النهاية إلا خطوة فحص جودة واحدة - وكانت تتحقق من بنية الشيفرة فقط لمعرفة ما إذا كانت سليمة، لا مما إذا كان التطبيق يعمل فعليًا؛ هل يمكن ترجمة الشيفرة؟ نعم. هل يضيف زر "إضافة إلى السلة" المنتج فعلاً إلى سلة التسوق؟ لم يتحقق أحد من ذلك. أما V3 فيختبر الجانبين معًا: جودة البنية وجودة الوظيفة شيئان مختلفان، وكلاهما مهم.
يمكن لـ V3 اكتشاف المشكلات في الوقت المناسب؛ فشيفرة الواجهة الخلفية تُترجم قبل بدء تطوير الواجهة الأمامية، وتُفحص الأنواع في شيفرة الواجهة الأمامية بعد كل تعديل، ويقوم نظام ضمان الجودة بالتحقق من التطبيق النهائي وفقًا للمتطلبات الأصلية وتقييم كل تطبيق - ناجح أو فاشل - مع توضيح السبب، كما يلتقط لقطات شاشة للتطبيق أثناء التشغيل ويقارنها بالملخص التصميمي - هل النص واضح ومقروء على الخلفية؟ وهل عناصر التفاعل موضوعة في أماكنها الصحيحة؟
عند حدوث عطل، يعيد Composer المحاولة باستخدام المعلومات السياقية: تفاصيل الخطأ، والدروس المستفادة من الفشل، ونافذة سياق جديدة تمامًا، دون الحاجة إلى القلق بشأن الأخطاء المتراكمة.
ينطبق الأمر نفسه على النشر؛ فعندما يفشل النشر تعود الأخطاء إلى Composer، الذي يقرأ رسالة الخطأ ويحاول إصلاحها ثم يعيد محاولة النشر - وغالبًا ما يتم ذلك قبل أن تلاحظ وجود مشكلة أصلًا. وإذا تعذر إكمال عملية البناء فعلًا، فسيتم التخلص منها بطريقة نظيفة بدلًا من تركها في حالة تالفة.
ما الذي لم يتغير
لا تزال طريقة عمل مشروعك كما هي؛ ما زلت بحاجة إلى وصف متطلباتك بلغة واضحة وموجزة، ولا تزال تتلقى مسودة يمكنك معاينتها وتعديلها ونشرها.
ما يتغير هو كل ما يحدث بين إرسال معلوماتك وظهور النتيجة.
المقال التالي في هذه السلسلة: كيف يساهم نظام التصميم وملخص DESIGN.md في V3 في بناء تطبيقات أكثر اتساقًا وجمالًا.
#CaffeineAI #caffeine #vibecoding #AI
محتوى IC الذي يهمك
التقدم التقني | معلومات المشروع | الفعاليات العالمية
تابعوا قناة IC على بينانس وانضموا إلى المفضلة
ابقَ على اطلاع بأحدث الأخبار