نفس Claude Opus 5.5: لماذا يبني به البعض تطبيقًا ويراه آخرون غبيًا؟

النموذج نفسه، Claude Opus 5.5، يقول عنه بعضهم إنه ينجز عمل أسبوع في نصف يوم، ويقول آخرون إنه يخطئ في سؤالين من كل ثلاثة.

بنيتُ به مؤخرًا تطبيقًا للهاتف اسمه Ruzai (如在): حين تكون بعيدًا عن حاسوبك، تستطيع من هاتفك أن تتابع محادثات مساعد الذكاء الاصطناعي على الحاسوب، وترسل إليه الرسائل، وتوافق على العمليات الحساسة التي يوشك على تنفيذها.

من تصميم المنتج والواجهة والشيفرة، إلى بناء حزم APK لأندرويد ورفع نسخ iOS إلى TestFlight تلقائيًا عبر GitHub Actions، وخادم التحديثات الفورية الذي استضفته بنفسي، ومواد النشر على App Store، كاد كل ذلك يكون من صنع Opus 5.5 داخل Claude Code. وفي الطريق غيّرنا التقنيات المستخدمة مرة، وقيّمنا حلَّين متعددَي المنصات، ورفضتُ الواجهة ثلاث جولات متتالية.

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

أولًا: التقنيات المستخدمة

الجزء	ما استقررنا عليه	ما جربناه أو تخلينا عنه في الطريق
إطار تطبيق الهاتف	React Native 0.88 + Expo SDK 58	uni-app x (تخلينا عنه)، Lynx 4.0 (تخلينا عنه بعد نموذج أولي)
التوجيه والترجمة البرمجية	Expo Router، React Compiler، TypeScript 6	TypeScript 7 (غير متوافق مع typescript-eslint)
الإيماءات والحركة	Reanimated 4.7، Gesture Handler 3.3
البناء والتغليف	GitHub Actions: حزمة APK لأندرويد، ورفع iOS إلى TestFlight
التحديثات الفورية	بروتوكول expo-updates، مستضاف على خادمي الخاص
HarmonyOS	نسخة أصلية بلغة ArkTS، تجتاز البناء في CI
التطوير والتصحيح	Expo Go على جهاز حقيقي، والذكاء الاصطناعي يتحكم في الهاتف مباشرة عبر adb

كل «تخلينا عنه» و«انتقلنا إلى» في هذا الجدول كان خلافًا بين إنسان وذكاء اصطناعي. وسأتناولها واحدًا تلو الآخر.

الفجوة الأولى: إن قلتَ «قبيح» فقط، فلن يملك إلا التخمين ثلاث جولات

حين ظهرت النسخة الأولى من الواجهة، قلتُ: قبيحة جدًا.

في الجولة الأولى غيّر Opus 5.5 الألوان. بحث على الإنترنت عن ثلاث لوحات ألوان ناضجة وأدخلها في النموذج الأولي لأختار بينها:

الخيار	المصدر	اللون الرئيسي
A البيج الدافئ	ألوان Claude الرسمية	برتقالي طيني #c96442، وخلفية بيضاء مائلة إلى البيج #faf9f5
B الأخضر المزرق	رمادي Sage مع أخضر Jade من Radix	#29a383
C النيلي	رمادي Slate مع أزرق Indigo من Radix	#3e63dd

الألوان نفسها كانت منضبطة تمامًا، ومع ذلك بقيتُ أراها قبيحة.

في الجولة الثانية لم يكتفِ بتغيير الألوان، بل أعاد بناء الواجهة كلها على طراز تحديث تطبيق Gemini في 2026: خلفية بيضاء خالصة أو سوداء خالصة، وإزالة كل الحدود، وعبارة ترحيب بخط كبير، وحقل إدخال عائم على شكل كبسولة.

وفي هذه الجولة اكتشف سببًا لم يخطر لي: لقطات الشاشة نفسها كانت تبدو رخيصة. كانت صور المعاينة تُلتقط بمتصفح Chrome دون واجهة على Windows، حيث يُعرض النص الصيني افتراضيًا بخط Microsoft YaHei. وبعد التبديل إلى Source Han Sans (Noto Sans SC)، اقترب المظهر فورًا من خطَّي MiSans وPingFang على الهواتف. جزء من استيائي في الجولتين الأوليين كان في الحقيقة استياءً من خط اللقطات.

في الجولة الثالثة ظننتُ أن المشكلة ربما في ألوان الأيقونة، فقررتُ حذف كل التدرجات اللونية. قدّم ستة تصاميم لأيقونات بلون واحد (خلفية سوداء بخط عريض، خلفية سوداء بخط Song، ختم أحمر قرمزي…)، واستقر الأمر في النهاية على حرف «Z» أبيض على خلفية سوداء خالصة.

بعد ثلاث جولات أدركتُ أنني كنتُ أقدّم أحكامًا فقط، دون أي اتجاه. لو قلتُ من الجملة الأولى: «اجعلها مثل ChatGPT، تتمحور حول المحادثة، بالأبيض والأسود، دون تدرجات»، لاقتربت النسخة الأولى من الشكل النهائي.

الذكاء الاصطناعي لا يملك ذوقًا خاصًا؛ ما يقدّمه لك هو متوسط عدد هائل من التصاميم. إن لم تستطع وصف ما تريد، فأرسل له لقطة شاشة لتطبيق يعجبك، فهي أنفع من عشر مرات تقول فيها «اجعلها أرقى قليلًا».

الفجوة الثانية: ما يُكتب في وثيقة المتطلبات، ينفّذه بحذافيره

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

هذه الطريقة ناجحة جدًا. تغيير أيقونة عميل الحاسوب وربطه بخادم الوساطة الخاص بالهاتف، كلاهما بدأ بوثيقة تسليم كتبها هذا الطرف، فأتمّها الطرف الآخر كما هي.

لكن لها أثرًا جانبيًا: أي قرار يُكتب في الوثيقة، ينفّذه الذكاء الاصطناعي دون أي تفاوض.

ذات مرة غيّرت وثيقة المتطلبات تقنية تطبيق الهاتف إلى uni-app x، فكتب Opus 5.5 بناءً عليها شيفرة uni-app كاملة، ورفعها، وأصلح مشكلاتها، وأدى العمل بإتقان. وبعد أن انتهى فقط أدركتُ أن هذا يربط المنتج بمنصة واحدة هي DCloud، فالإشعارات والبناء والتحديثات الفورية كلها لا تعمل دونها. فهدمتُ كل شيء وبدأتُ من جديد بـ React Native + Expo.

الذكاء الاصطناعي لن يسألك من تلقاء نفسه: «هل ستندم على هذا الاختيار بعد ثلاث سنوات؟». القرارات التي لا رجعة فيها، مثل اختيار التقنيات، يجب أن يحسمها الإنسان.

الفجوة الثالثة: هل تطلب منه الشيفرة أولًا، أم الأسباب أولًا؟

لاحقًا أردتُ تجربة Lynx من ByteDance: شيفرة واحدة تنتج تطبيقَي أندرويد وiOS، وربما HarmonyOS مستقبلًا. بنى Opus 5.5 نموذجًا أوليًا بسرعة، يُبنى ويتصل بالخادم ويعرض المحادثات.

لكن الواجهة عادت قبيحة، ومختلفة تمامًا عن التصميم المعتمد.

هذه المرة لم أطلب منه تعديلها مباشرة، بل قلت: لا تكتب أي شيفرة الآن. لنفهم أولًا لماذا، ثم ضع خطة، ثم اكتب.

جاءت الأسباب التي قدّمها محددة جدًا:

الموضع	نسخة React Native	نموذج Lynx الأولي	السبب
الأيقونات	أيقونات SVG خطية	رموز نصية ☰ ＋ ↑	Lynx لا يعرض SVG افتراضيًا
الشريط الجانبي	ينزلق من اليسار، يشغل 84% من العرض، مع طبقة تعتيم	الصفحة كلها تُستبدل بقائمة	لا توجد مكونات جاهزة للدُّرج والنوافذ المنبثقة
اللوحة السفلية	اختيار الحاسوب، وتفاصيل التأكيد مع لقطة شاشة	غير موجودة	السبب نفسه
الإجمالي	ضُبطت تفصيلًا تفصيلًا وفق النموذج المبدئي	جُمّعت في ساعة لإثبات الجدوى	مكونات React Native لا تعمل في Lynx، ولا يمكن إعادة استخدام إلا المنطق الصرف

يُضاف إلى ذلك تراجعات اكتُشفت أثناء الاختبار: في Lynx 4.1.0 لا تعمل النقرات داخل scroll-view، وفي ReactLynx 0.128 تتعطل النقرات كلها، فلم يبقَ إلا الرجوع إلى 4.0.3 و0.126.

حين وُضعت الأسباب على الطاولة، صار القرار بسيطًا: نستمر مع React Native.

لو قلتُ يومها «حسّن مظهر الواجهة»، لأمضى على الأرجح ساعات في إعادة ضبطها على Lynx، ثم عدنا في النهاية إلى ما كنا عليه. كلما كتب الذكاء الاصطناعي أسرع، ابتعد أكثر في الاتجاه الخاطئ.

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

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

العَرَض	السبب	الحل
لوحة المفاتيح تغطي حقل الإدخال عند ظهورها	بعد تفعيل edge-to-edge لم يعد التخطيط يفسح مكانًا للوحة المفاتيح	تغيير KeyboardAvoidingView إلى padding
النقر لا يستجيب بعد أن تخفت الشاشة	النقرة الأولى تُستهلك في إيقاظ الشاشة	إرسال KEYCODE_WAKEUP قبل الاختبار
إيماءة السحب لليسار لفتح الشريط الجانبي تنتهي لحظة بدئها	ScrollView الأصلي يستولي على اللمس	استبداله بـ ScrollView من Gesture Handler، مع إضافة منطقة استشعار شفافة بعرض 36dp على الحافة اليسرى
فتح محادثة طويلة يتوقف في منتصفها	أثناء العرض على دفعات، كان التمرير التلقائي إلى الأسفل يطلق حدث تمرير أيضًا، فيُفسَّر خطأً على أن «المستخدم مرّر إلى الأعلى»	جعل حالة «هل نحن في الأسفل» لا تتغير إلا بسحب الإصبع
النص المُدخل عبر adb لا يظهر على الشاشة	لوحة مفاتيح WeChat تعترض الإدخال	النقر على أحد الاقتراحات لاعتماده

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

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

الفجوة الخامسة: البيئة التي تراجع فيها النتيجة تحدد ما تراه

قصة خط لقطات الشاشة السابقة كانت في الحقيقة مشكلة مراجعة: إن نظرتَ إلى النتيجة في البيئة الخطأ، ستنفر حتى من الشيء الجيد.

والأمر نفسه في البناء. حزم أندرويد التي ينتجها GitHub Actions كانت تُوقَّع في كل مرة بشهادة تصحيح مختلفة، فلا يمكن تثبيت نسخة جديدة دون إزالة القديمة أولًا. ولم تُحل المشكلة إلا بإضافة ملف debug.keystore ثابت إلى المستودع. ولو لم أثبّت التطبيق مرتين على هاتف حقيقي، لما اكتشفتُ ذلك أصلًا.

أما مواد النشر على App Store فهي تراكم من التفاصيل:

المادة	المقاسات المطلوبة
مادة العنوان	5244 × 2950 أو 3840 × 1646
مادة نتائج البحث	5244 × 2950 أو 3840 × 2560 أو 1920 × 1280
لقطات شاشة iPhone مقاس 6.3 بوصة	1206 × 2622 أو 2622 × 1206

أصاب الذكاء الاصطناعي هذه المقاسات من المرة الأولى، لكن البيانات التوضيحية في اللقطات لم أطلب منه استبدالها بمحتوى محايد إلا بعد أن اطلعتُ عليها.

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

الذكاء الاصطناعي قادر على إنجاز الأمور على الوجه الصحيح، لكن أيّ الأمور يصبح إنجازها على الوجه الصحيح مخاطرة، فهذا لا يعرفه إلا من جرّب.

الفجوة السادسة: هل تعرف ما الذي ينبغي أن تسأل عنه؟

في مرحلة متأخرة سألتُ سؤالًا واحدًا: «في المستقبل، التعديلات الصغيرة على الواجهة، هل يمكن ترقيتها مباشرة دون إعادة البناء في كل مرة؟»

هذا السؤال وحده جلب منظومة تحديثات فورية كاملة: بروتوكول expo-updates، وحزم تحديث مستضافة على خادمي الخاص؛ مع استراتيجية fingerprint لقيمة runtimeVersion، فالنسخ التي لا تغيّر إلا JS يتحدث بها التطبيق تلقائيًا بمجرد فتحه، ولا حاجة لإعادة البناء إلا إذا تغيرت الشيفرة الأصلية.

لو لم أسأل، لما فعلها من تلقاء نفسه. ليس لأنه لا يعرف كيف، بل لأنه لا يعرف أن الأمر مهم لي.

وبالمثل، نسخة HarmonyOS لم تبدأ إلا حين سألت: «هل يمكن بناء نسخة أصلية لـ HarmonyOS؟». فكتب نسخة بلغة ArkTS اجتازت البناء على GitHub Actions، وحلّ في الطريق عدة مطبات لا تعرفها إلا حين تخوض التجربة: مستودع ohpm التابع لـ Huawei كثيرًا ما يعيد الخطأ 503 لأجهزة GitHub، فلزم إضافة إعادة المحاولة؛ وimageknife من الإصدار 3.2.8 فما فوق يتطلب API 18، فلم يكن بُدّ من استخدام 3.2.7.

إلى حيث يصل سؤالك، يصل عمل الذكاء الاصطناعي. ومن يُحسن السؤال يحصل بطبيعة الحال على أكثر.

الفجوة السابعة: هل تستخدم حقًا «النموذج نفسه»؟

أخيرًا، حقيقة كثيرًا ما تُغفَل: حين يقول شخصان «أنا أستخدم Opus 5.5»، فقد لا يكون ما يستخدمانه الشيء نفسه أصلًا.

الفرق	ما هو تحديدًا
العميل	دردشة الويب، وClaude Code، وتطبيقات الواجهات الوسيطة المختلفة، ولكلٍّ منها موجّه نظام مختلف تمامًا
الأدوات	هل يستطيع قراءة الملفات، وتشغيل الطرفية، والتحكم في المتصفح والهاتف
شدة الاستدلال	مستوى التفكير، والوضع السريع؛ النموذج نفسه يتفاوت أداؤه كثيرًا بين المستوى العالي والمنخفض
السياق	سياق 1M أم طول عادي؛ وهل تُضغط المحادثات القديمة، وما الذي يضيع عند الضغط
المسار	واجهة API الرسمية، أم مزود سحابي، أم وسطاء مختلفون؛ والإصدار والقيود خلف كلٍّ منها ليست بالضرورة واحدة

استخدمتُ في بناء Ruzai أداة Claude Code: تقرأ مستودع الشيفرة كله وتكتب فيه، وتشغّل الأوامر، وتستدعي adb، وتتعامل مع GitHub. ومقارنتها بتجربة سؤال وجواب على صفحة ويب ليست عادلة من الأساس.

في الختام

لنضع الفجوات السبع جنبًا إلى جنب:

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

في المشروع كله، كانت الشيفرة تقريبًا من كتابة Opus 5.5، لكن كل منعطف فيه كان قرارًا بشريًا: التخلي عن uni-app x، وعدم استخدام Lynx، وحذف التدرجات اللونية، وتعديل نص المتجر، وإضافة التحديثات الفورية.

لذا، في المرة القادمة التي تشعر فيها أن الذكاء الاصطناعي «صار أغبى»، لا تتعجل في تغيير النموذج. ارجع إلى وصف العمل الذي أعطيته إياه، وانظر هل كان هو نفسه غير ذكي بما يكفي.

أما الأساليب الأكثر تقنية، مثل الاسترجاع وتنظيم السياق وميزانية الاستدلال والتحقق، فقد كتبتُ عنها في «قبل أن تغيّر النموذج، اجعل ذكاءك الاصطناعي أذكى»، ويمكن قراءتها مع هذه التدوينة.

إن كنت أنت أيضًا تبني منتجك الخاص بـ Claude Code أو بأي ذكاء اصطناعي آخر، فمرحبًا بك للحديث: linktr.ee/weiyii