00:00:00لا يكفي أي نموذج Claude بمفرده. يمتلك Opus القدرة على التفكير ولكنه يستهلك
00:00:04حدودك. Sonnet سريع ولكنه يواجه عائقاً في القرارات الصعبة. والحل ليس في اختيار أحدهما
00:00:10على الآخر، بل في استخدامهما معاً. يقوم Claude code بهذا بالفعل إلى حد ما؛
00:00:14فهو ينسق بين النماذج تلقائياً. لكن Anthropic أصدرت للتو شيئاً
00:00:18لا يوفر الرموز فحسب، بل يجعل النماذج الصغيرة قادرة تقريباً مثل النماذج الكبيرة.
00:00:23عند البناء باستخدام Claude، ربما لاحظت هذا: عندما تعطي Opus مهمة
00:00:28ويحدد أنها لا تتطلب جهداً كبيراً، فإنه يحولها إلى Sonnet أو Haiku و
00:00:32يفوض المهام للنماذج الأصغر لإدارة استخدام الرموز بشكل صحيح. لكن هناك مشكلة
00:00:37في هذا النهج. كما ذكرنا في فيديونا السابق، كانت Anthropic تخفض حدود المعدل
00:00:42لذا فخلال ساعات الذروة، تمتلئ نافذة الـ 5 ساعات بشكل أسرع. وعلاوة على ذلك، يستهلك Opus الكثير
00:00:47من الرموز حتى في المهام البسيطة، مما يعني أن استخدام Opus يجعل حد السياق يمتلئ أسرع.
00:00:52قررت Anthropic تغيير القواعد وطرحت شيئاً يسمى
00:00:55استراتيجية المستشار (Advisor strategy). وتعتمد هذه الاستراتيجية على إعطاء دور المنفذ لنموذج
00:01:00Sonnet واستخدام Opus كمستشار فقط، يتم الرجوع إليه عندما يحتاج المنفذ لذلك حقاً.
00:01:05هناك وكيلان مشاركان. المنفذ هو وكيلك الرئيسي الذي يعمل على Sonnet ويتولى
00:01:10جميع استدعاءات الأدوات وتغييرات الكود والمخرجات للمستخدم. أما المستشار فيعمل على Opus و
00:01:15مهمته الوحيدة هي توجيه المنفذ عندما يتعثر. المستشار لا يكتب الكود أو يجري تغييرات أبداً.
00:01:20عندما جربت Anthropic هذا النهج، وجدوا أنه تفوق على Sonnet بمفرده في
00:01:25اختبار SWE bench. ووجدوا أن هذا المزيج تفوق على Sonnet وحده من حيث الأداء والتكلفة.
00:01:31وتكلفته أقل بكثير من تشغيل Opus كوكيل رئيسي لأن استدعاء Opus يتم فقط
00:01:36عندما يهم الأمر حقاً، وليس في كل تكرار بسيط. قد تعتقد أن لدينا بالفعل
00:01:40الكثير من أطر العمل لبناء التطبيقات وهي أفضل وجاهزة، فلماذا نكترث بهذا الإعداد؟
00:01:45السبب هو أن معظم أطر العمل الحالية لم تُبنَ مع مراعاة التكلفة وكفاءة الرموز.
00:01:50رغم أنها تنجز المهمة، إلا أنها تقصر عندما يتعلق الأمر بجعل Claude يعمل لفترة أطول
00:01:54وبكفاءة أعلى لأن تركيزها الأساسي هو بناء التطبيق بدلاً من التحسين
00:01:59لاستخدام الرموز. بهذا الإعداد، يمكنك بناء تطبيق يعمل باستخدام نموذج أضعف، مما يجعل
00:02:04العملية برمتها أكثر كفاءة في استهلاك الرموز. وهذا يرتبط بمشكلة الحدود التي ذكرناها
00:02:09سابقاً. لقد صنعنا فيديو بالفعل عن حدود Claude ونصحنا بالتبديل لنموذج أصغر
00:02:13ليستمر لفترة أطول. إليكم الرابط: يستهلك Sonnet رموزاً أقل بكثير ويتطلب جهداً أقل
00:02:19من Opus لأداء نفس المهمة. Opus نموذج كبير جداً وقوي لذا يستهلك الكثير من
00:02:24الرموز حتى للمهام البسيطة. بينما يستطيع Sonnet التعامل مع الكثير من تلك المهام بكفاءة أكبر. لذا
00:02:30فإن استخدام Opus فقط لسد فجوة الأداء في القرارات الصعبة هو مكمن التأثير الحقيقي.
00:02:35أنت تستدعي تلك القوة فقط عندما تحتاجها فعلاً، وليس لكل مهمة. وهذا يجعل
00:02:40الاستخدام العام أكثر كفاءة في الرموز ويتيح لك إنجاز المزيد ضمن نفس الحدود. نحن نشارك
00:02:45كل ما نجده حول بناء المنتجات بالذكاء الاصطناعي في هذه القناة، لذا إذا أردت المزيد من الفيديوهات
00:02:50اشترك وتابع فيديوهاتنا القادمة. أردنا اختبار كيف ينجح هذا فعلياً على
00:02:55تطبيق تم بناؤه مسبقاً باستخدام Sonnet. لاستخدام الاستراتيجية داخل Claude code، قمنا بضبط
00:03:00أمر المستشار بوضع Opus 4.6 كنموذج مستشار. وكان وكيلنا الرئيسي هو المنفذ الذي
00:03:05ضبطته مسبقاً على Sonnet بما أنني بنيت التطبيق باستخدامه. كان من المفترض أن يحتوي التطبيق على مزامنة فورية،
00:03:10وبينما كانت مزامنة نقل وتغيير حجم العناصر تعمل تماماً، لم تكن عمليات الحذف تُزامن إطلاقاً. حاولنا
00:03:16تصحيح هذا عدة مرات باستخدام Sonnet بمفرده لكن المشكلة استمرت مهما
00:03:20حاول إصلاحها. لذا بعد تفعيل Opus كمستشار، أعطينا Claude أمراً
00:03:25يصف المشكلة، ولأن Sonnet كان قد فشل عدة مرات، فبدلاً من المحاولة
00:03:30مرة أخرى بمفرده، قرر استدعاء المستشار هذه المرة. قام المستشار بمراجعة
00:03:34المحادثة حتى الآن لتقييم الموقف. وقدم التغييرات الدقيقة المطلوبة، محدداً
00:03:40مكان تعطل منطق المزامنة وما يجب إعادة هيكلته بدقة. أخذ نموذج المنفذ
00:03:45تلك النصيحة وطبق تلك الإصلاحات مباشرة دون أي أخذ ورد إضافي. اختبرنا ذلك
00:03:50عبر أجهزة متعددة للتأكد من المزامنة ووجدنا أن المشكلة قد حُلت. كلا الطرفين
00:03:55يعكسان عمليات الحذف بشكل صحيح كما هو مقصود، حتى لو اختار المستخدم عنصراً في طرف
00:04:00وكان الطرف الآخر يُحذف، وهو ما لم يكن يحدث سابقاً. لو حاولنا إصلاح هذا باستخدام Sonnet
00:04:05وحده، لاستغرق الأمر جولات أكثر من التوجيه لأن Sonnet بطبيعته
00:04:09نموذج أضعف وغير قادر بما يكفي للتعامل مع المنطق المعقد بمفرده. ومن ناحية أخرى، استخدام Opus وحده
00:04:15كان سيستهلك رموزاً أكثر بكثير وربما لم يكن بهذه السرعة. استخدام Sonnet مع Opus
00:04:20كمستشار جعل العملية أكثر كفاءة بكثير. إجمالاً، ساعدت هذه الاستراتيجية في تصحيح مشكلات المزامنة
00:04:25بسرعة أكبر من ذي قبل. ولكن قبل أن نمضي قدماً، كلمة من راعينا Juni من JetBrains.
00:04:30إذا كنت مطوراً، فأنت تعرف معاناة التبديل بين الطرفية (Terminal) وبيئة التطوير (IDE) وخطوط أنابيب CI
00:04:36فقط لإنجاز المهام. معظم وكلاء الأكواد يحصرونك في بيئة واحدة أو نموذج لغوي واحد.
00:04:41Juni CLI مختلف. إنه وكيل أكواد مستقل عن النماذج يعمل في كل مكان: في
00:04:47طرفيتك، وبيئتك، وGitHub، وخطوط CI/CD، وحتى مدير المهام. وكيل واحد لكل شيء. فوضه
00:04:54للقيام بعمل حقيقي: كتابة الاختبارات، بناء الخلفية، إعادة الهيكلة، وأتمتة مراجعات الكود في كل التزام.
00:04:59حالياً تدير JetBrains برنامج وصول مبكر مجاني يتضمن 50 دولاراً من رصيد Gemini لاختبار
00:05:04الوكيل بالإضافة لدعم مفتاحك الخاص لتستخدم أي نموذج تفضله. وصول كامل لكل الميزات، ووصول مبكر
00:05:10للميزات الجديدة ودعم مباشر من فريق التطوير الذي يشكل المنتج. الأمر ببساطة أفضل مع Juni.
00:05:15انقر على الرابط في التعليق المثبت للانضمام مجاناً. الآن، أردنا اختبار ما إذا كان Sonnet يستشير
00:05:20المستشار فعلاً في تغييرات واجهة المستخدم الكبيرة. كان لدينا تطبيق مبني مسبقاً وأردنا
00:05:25تحويل واجهته إلى مكتبة مختلفة. وعلاوة على ذلك، أردنا إجراء عدة تغييرات في الواجهة
00:05:31دفعة واحدة، وهو ما لا يُنصح به عادة، لكننا أردنا رؤية أداء النموذج الصغير بالتنسيق
00:05:36مع الكبير في مهمة ضخمة. قام أولاً بالوصول للواجهة الحالية باستخدام Playwright MCP.
00:05:41بمجرد فهم التخطيط، وبدلاً من القفز مباشرة لتغيير الكود، استشار المستشار
00:05:46لتحديد أفضل نهج لأن التغيير كان جذرياً وقد يتسبب في تعطل التطبيق إذا
00:05:50عولج بشكل خاطئ. أفاد المستشار أن المكتبة التي اخترناها كمكتبة جديدة والمكتبة
00:05:55المستخدمة بالفعل في المشروع لديهما مشكلات في الإصدارات. لذا قبل بدء أي عمل في الواجهة، احتاج Claude
00:06:00لحل هذه المشكلات أولاً. تعامل Sonnet معها، ونفذ عدة أوامر للتأكد من تطبيق التبعيات
00:06:04بشكل صحيح، ثم فحص حالة الواجهة عبر Playwright للتأكد من أن التطبيق
00:06:09ما زال يعمل دون مشكلات في جانب العميل. بمجرد ترتيب التبعيات، بدأ في إجراء
00:06:14التغييرات كما اقترح المستشار، حيث عمل على كل مكون واحداً تلو الآخر، وأعاد
00:06:18تصميم التطبيق ككل بفعالية. كانت الواجهة التي أنشأها أكثر تفاعلية وبدت أكثر
00:06:23إتقاناً من ذي قبل. لا تزال بها بعض المشكلات، لكن التحسن العام كان واضحاً. ولكن هنا
00:06:27ظهرت الحدود. استغرقت العملية برمتها حوالي 31 دقيقة. ولو كان Opus بمفرده
00:06:32لأنجز ذلك أسرع بكثير لأنه أفضل في تنسيق المهام عبر تحديد ما يمكن تشغيله
00:06:37بشكل متوازٍ وتنفيذه في نفس الوقت. أما Sonnet، كونه نموذجاً أصغر، فقد تعامل مع كل شيء بالتتابع
00:06:43دون تقسيم العمل إلى وكلاء فرعيين متوازيين. بالنسبة لتطبيق لم يكن بتلك التعقيد،
00:06:48فإن 31 دقيقة مدة أطول مما ينبغي. كما أنه يتعامل مع التغييرات الصغيرة بنفسه دون
00:06:53إشراك المستشار، وهو السلوك الصحيح للتعديلات الطفيفة. لكن للتغييرات واسعة النطاق عبر
00:06:58تطبيق كامل كهذا، فمن الأفضل استخدام Opus مباشرة لأن ذلك سيوفر لك الكثير
00:07:03من الوقت والجهد. الآن، أردنا اختبار ما إذا كان سينفذ ميزة جديدة تماماً على
00:07:08قاعدة أكواد حالية بشكل صحيح. كان لدينا تطبيق مبني بالفعل وأردنا إضافة صفحة أخرى
00:07:13بميزة مختلفة. أعطيناه أمراً يصف ما نريده، وتوقعنا تماماً هذه المرة
00:07:17أن يستخدم المستشار لأنها لم تكن مهمة بسيطة، لكنه مضى قدماً ونفذ
00:07:22التغييرات بالكامل بمفرده دون استشارة المستشار إطلاقاً. تعامل مع الأمر كله كعمل
00:07:27روتيني، وهو ما لم يكن كذلك نظراً لنطاق الميزة. عندما اختبرنا
00:07:31التطبيق، وجدنا مشكلات متعددة. فإذا عدلنا شيئاً وضغطنا زر التشغيل، كانت التغييرات
00:07:37مثل تحديثات العناوين أو تعديلات الألوان تنعكس أيضاً في مكونات خارج نافذة المعاينة،
00:07:41وهو ما لا ينبغي أن يحدث. وعلاوة على ذلك، أردناه أن يزامن مباشرة بدلاً من مطالبتنا بالضغط على
00:07:46زر التشغيل بعد كل تغيير. لذا وجهناه مرة أخرى وأخبرناه باستخدام المستشار لإصلاح
00:07:51هذه المشكلات. وبناءً على طلبنا، استدعى أولاً وكيل المستشار. نظر المستشار في
00:07:56التنفيذ وحدد السبب الفعلي لكلتا المشكلتين، وكان ذلك
00:08:00الاختيار الخاطئ للمكون. وحدد ما يجب تغييره ولماذا أدى النهج الأصلي لتلك
00:08:06المشكلات في المقام الأول. أخذ المنفذ تلك التوجيهات وطبقها عبر التطبيق. وعندما
00:08:10اختبرناه مرة أخرى، عمل البث (streaming) بشكل صحيح. وانعكست جميع التغييرات فورياً أثناء التحرير دون
00:08:16الحاجة للضغط على زر التشغيل بعد كل تعديل. كما حُلت مشكلة تداخل التغييرات
00:08:20بين المكونات وتحدث كل شيء بشكل صحيح ضمن الحدود المطلوبة. لذا، هناك أوقات
00:08:25يعمل فيها تماماً كما هو مقصود، لكن في أوقات أخرى يفترض المنفذ أن المهمة صغيرة بما يكفي
00:08:30ويقرر عدم استشارة المستشار. في تلك الحالات، غالباً ما تضطر لتنبيهه بنفسك ليتبع
00:08:35سير العمل المنشود. فالنموذج لا يقدر تعقيد المهمة دائماً بنفس طريقتك،
00:08:40وعندما يخطئ التقدير، ينتهي بك الأمر بأخطاء كان المستشار سيكتشفها من البداية. أيضاً
00:08:44إذا كنتم تستمتعون بمحتوانا، يرجى الضغط على زر الإعجاب (hype) لأنه يساعدنا على إنشاء المزيد
00:08:49من هذا المحتوى والوصول لعدد أكبر من الناس. مع وجود حالة موزعة في الوقت الفعلي،
00:08:54ظل هذا النهج يتطلب جولات متعددة من التوجيه قبل أن يعمل كل شيء بشكل صحيح.
00:08:58ساعدت الاستراتيجية، ولكن لها سقف يجب أن تفهمه قبل الالتزام بها في مشروعك.
00:09:02بالنسبة للتطبيقات البسيطة إلى متوسطة الحجم، يمكن لاستراتيجية المستشار أن توفر عليك عدة جولات
00:09:07من الأخذ والرد التي كنت ستقضيها في محاولة دفع Sonnet لتجاوز حدوده بمفرده.
00:09:11إذا كان ما تبنيه يتطلب تفكيراً عميقاً أحياناً ولكن تنفيذه مباشر في الغالب،
00:09:16فهذا هيكل جيد حقاً له. يمكنك بناء المزيد ضمن حدود الرموز الخاصة بك
00:09:20دون الحاجة لمراقبة النموذج في كل قرار أو العودة إلى Opus طوال الجلسة.
00:09:25أما للتطبيقات المعقدة ذات التبعيات المتصلة الكثيرة أو نقاط الفشل المتعددة، فمن الأفضل
00:09:30استخدام Opus مباشرة كوكيل رئيسي. فحتى عندما يتبع Sonnet توجيهات المستشار بشكل صحيح،
00:09:36لا يزال بإمكانه اختيار مسار تنفيذ خاطئ لأنه لا يمتلك عمق التفكير
00:09:40لتقييم نهج متعددة في وقت واحد ووزن العواقب اللاحقة. يساعد المستشار في سد
00:09:45تلك الفجوة، لكنه لا يسدها بالكامل. وفي تلك الحالات، قد يكلفك الأخذ والرد وقتاً أكثر
00:09:50مما كان سيكلفه تشغيل Opus منذ البداية. لذا، هذه الاستراتيجية مفيدة عندما تعمل ضمن
00:09:54حدود ضيقة للرموز ولا يتطلب التطبيق تفكيراً بمستوى Opus في كل خطوة. إذا
00:09:58كان كلا الشرطين صحيحين لما تبنيه، فالأمر يستحق الإعداد. وهذا يوصلنا إلى
00:10:03نهاية هذا الفيديو. إذا كنت ترغب في دعم القناة ومساعدتنا في الاستمرار في صنع فيديوهات كهذه،
00:10:08يمكنك القيام بذلك عبر زر شكراً (super thanks) أدناه. كما هو دائماً، شكراً للمشاهدة وسأراكم
00:10:12في الفيديو القادم.