التطوير بالذكاء الاصطناعي والبرمجة: بناء التطبيقات مع AI

إذا ظهرت في Claude Code في منتصف الرد رسالة «API Error: The response stopped arriving. The response above may be incomplete.»، فمعناها أن الاتصال ظل مفتوحًا لكن البيانات توقفت عن الوصول، فقطعه مؤقّت المراقبة في Claude Code. المخرجات المكتملة تبقى، فتحقّق من حالة العمل ثم أرسل continue لتستأنف من حيث توقف. وهذه الرسالة هي الاسم الجديد لما كان يُعرض قبل v2.1.227 بنص «Response stalled mid-stream». اعتمادًا على مرجع الأخطاء الرسمي ووثيقة إعدادات الشبكة، نرتّب الفرق بينها وبين Connection lost mid-response وThe response stalled before a response was produced وStreaming response ended before any complete data was received، وسبب عدم إعادة الإرسال، وطريقة التعامل معها في الوضع غير التفاعلي (-p) ولدى الوكلاء الفرعيين، وكيفية التحقق من الإصدار ومسار الاتصال ومؤقّتات المراقبة، والمعلومات التي تحفظها عند الإبلاغ. أما البلاغات الخمسة التي فتحناها على GitHub فنعاملها بمعزل عن الشرح الرسمي، على أنها حالات غير مؤكدة.

إذا عرض Claude Code الرسالة «Login expired · Please run /login»، فهذا يعني أن التجديد التلقائي لتسجيل الدخول المحفوظ رُفض وأن Claude Code حذف بيانات الاعتماد. لا تصل الأوامر اللاحقة إلى API بل تتوقف على جهازك، لذا أعد تسجيل الدخول عبر ‎/login بدل إعادة المحاولة. استنادًا إلى مرجع الأخطاء الرسمي، نشرح الفرق عن Not logged in وOAuth token has expired وYour account is on hold، وكيف تغيّرت الرسالة في v2.1.206، والخطوات من التحقق عبر ‎/status حتى إعادة تسجيل الدخول، وما تفعله مع claude -p وفي CI، وما تتحقق منه حين تتكرر: الإصدار وسلسلة المفاتيح والساعة وCLAUDE_CONFIG_DIR. ونعرض ستة بلاغات على GitHub بشكل منفصل بوصفها حالات لم يُحسم سببها.

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

Jev نموذج من TypeSafe يُعيد، بدل توليد النص، خيارًا أو قيمة تقييم أو احتمال نعم/لا. نشرح الفرق بين Choice وScore وNoul، وكيفية قراءة confidence، وكتابة طلب API لتوجيه الاستفسارات. كما نعرض نقاط الضعف الموثقة رسميًا، مثل الحسابات والتواريخ والصياغات الموجِّهة، والأسعار وحدود الإدخال، وخطوات التقييم قبل استخدامه بالعربية، لأن الحكم قد يخطئ حتى مع شكل صحيح.

تريد أن تُسند التخطيط وحده إلى نموذج ذكي، وأن تترك التنفيذ لنموذج أسرع وأرخص. وopusplan في Claude Code تحديدٌ للنموذج يفعل ذلك تلقائيًا: يعمل على Opus ما دمت في plan mode، وعلى Sonnet في ما عدا ذلك، ويمكن استخدامه عبر ‎/model opusplan‎ أو عبر model في settings.json. لكنه لا يظهر في قائمة ‎/model‎، ولأن النموذج يتبدّل في كل مرة تدخل فيها plan mode أو تخرج منه، تُعاد قراءة المحادثة كلها من دون تخزين مؤقت في كل تبديل. يرتّب هذا المقال، استنادًا إلى الوثائق الرسمية وسجل التغييرات وبلاغات GitHub حتى 15 سبتمبر 2026، طريقة الإعداد (بما في ذلك تثبيت الإصدارات وسياق 1M)، والانتقال من plan mode إلى الموافقة ثم التنفيذ، وكيف أُزيل من شاشة الاختيار في v2.0.0 وشرح أحد العاملين في Anthropic لذلك، وتقدير تكلفة التخزين المؤقت الناتجة عن التبديل وطرق خفضها، والفرق بينه وبين أداة advisor والوكلاء الفرعيين، والأعمال التي يناسبها والتي لا يناسبها.

هل يمكن إبقاء الجلسة الرئيسية في Claude Code على Opus 5، وإسناد أعمال مثل الترجمة أو المراجعات الكثيرة وحدها إلى وكلاء فرعيين على Sonnet أو Haiku؟ الجواب: نعم. يُحدَّد نموذج الوكيل الفرعي بهذا الترتيب: التحديد عند الاستدعاء، ثم model في ملف التعريف، ثم متغير البيئة CLAUDE_CODE_SUBAGENT_MODEL، ثم نموذج الجلسة الرئيسية، ويمكن كذلك تحديد الجهد (effort) لكل وكيل فرعي. يرتّب هذا المقال، استنادًا إلى الوثائق الرسمية حتى 15 سبتمبر 2026، اختلاف هذا الترتيب بين الإصدارات، والإعداد CLAUDE_CODE_SUBAGENT_MODEL_FORCE الذي يثبّت الجميع على نموذج واحد، واختلاف وجهة الأسماء المختصرة بحسب جهة الاتصال، وأن Explore المدمج صار منذ v2.1.198 يرث نموذج الجلسة الرئيسية. ثم يعرض نتائج تشغيل وكلاء فرعيين فعليًا بنماذج أخرى والتحقق منها في سجلات المحادثة: أنها عملت بالنماذج المحدَّدة، وأن كل وكيل يقرأ عشرات آلاف التوكنات لمجرد التشغيل، وأن التخزين المؤقت للوكلاء الفرعيين ينتهي بعد 5 دقائق حتى مع الاشتراك، والفروق في الوقت والتكلفة وجودة الترجمة حين أُسندت الترجمة نفسها إلى Opus 5 وSonnet 5 وHaiku 4.5 مرتين لكلٍّ منها. وأخيرًا يلخّص أثر ذلك في التكلفة وحدود الاستهلاك، وما يُستند إليه في تحديد الأعمال التي تُنقل إلى نموذج أرخص.

حين تشغّل عدّة جلسات بالتوازي، تبدأ في التساؤل عن الجلسة التي تلتهم حدّك الأسبوعي. لكنّ ‎/usage‎ في Claude Code لا يعرض إلا أرقام الجلسة الحالية، إضافةً إلى استهلاك الخطة كلها مقسّمًا بحسب المهارة والوكيل الفرعي والإضافة وخادم MCP، أما حصّة كل جلسة فلا تظهر في حلقة الاستهلاك بتطبيق سطح المكتب ولا في صفحة الإعدادات على claude.ai (حتى سبتمبر 2026). الجواب موجود في سجلات المحادثة المحفوظة على جهازك (ملفات JSONL في ‎~/.claude/projects‎)، لكنّ جمعها كما هي يعطي نتيجة خاطئة، لأن الردّ الواحد يُكتب على عدّة أسطر، سطرًا لكل كتلة محتوى، ولأن سجلات الوكلاء الفرعيين موجودة في ملفات منفصلة. وفي قياس على جهازي، بلغ المجموع الساذج قرابة ضعف القيمة الصحيحة، ولأن حجم الخطأ اختلف من جلسة إلى أخرى، تبدّل حتى الترتيب. يتناول هذا المقال ما تعرضه الشاشات الرسمية وما لا تعرضه، وكيف تعدّ السجلات عدًّا صحيحًا بسكربت تجميع من نحو 50 سطرًا، ونتيجة القياس التي استحوذت فيها جلسة واحدة على قرابة ثلث الاستهلاك كله، وحدود ما تستطيع الأرقام أن تخبرك به، وكيف تضبط OpenTelemetry إن أردت المتابعة بمرور الوقت.

«كثرة المهارات تزاحم سياقك» — نصف هذه المقولة صحيح ونصفها الآخر خاطئ. فوفق وثائق Claude Code الرسمية، يستهلك فهرس المهارات ميزانية ثابتة مقدارها 1% من نافذة سياق النموذج، ومهما أضفت من مهارات فإنه يتوقّف عند ذلك الحدّ. وبدلًا من أن يتضخّم، يحدث شيء آخر: المهارات تكفّ عن أن تُستدعى، إذ يُسقط Claude Code عند الفيض أوصاف المهارات الأقلّ استدعاءً ولا يُبقي إلا أسماءها. والمهارة التي فقدت وصفها لم تعد ترتبط بما طلبته، ومع ذلك لا يظهر خطأ ولا يبطؤ شيء. يتناول هذا المقال اختلاف أدوار أدوات القياس الثلاث (‎/context و‎/usage و‎/skill-doctor)، وتعريف فقدان التخزين المؤقت بأنه 5% و2,000 توكن، وتغيّر عمر التخزين المؤقت من ساعة واحدة إلى خمس دقائق بحسب الخطة، وسبب بقاء أدوات CLI أخفّ رغم أن تعريفات أدوات MCP صارت تُحمَّل تحميلًا مؤجَّلًا افتراضيًا، والأساس الذي يقوم عليه إبقاء CLAUDE.md دون 200 سطر، ثم بماذا تبدأ الحذف بعد أن تقيس، مقتصرًا في ذلك كله على ما أمكن التحقّق منه في الوثائق الرسمية.

يتوقف بك العمل أثناء استخدام Claude، فتبحث عن الرسالة كما ظهرت حرفيًا، ولا يأتي البحث بشيء يُذكر. وخمسة نصوص تتصرف هكذا: The model returned no content because the response was blocked by content filtering، وThe response was blocked by the provider's content filter، وStreaming response ended before any complete data was received، وCould not locate the Claude CLI on PATH، وConnection to Claude's response was lost. Claude may still be working. ما يجمعها أنها ظهرت أثناء استخدام Claude، ومع ذلك يبدو أن البحث في مواد Claude نفسها لا يأتي بشيء، والسبب بسيط: البرنامج الذي كتب الرسالة على شاشتك ليس بالضرورة البرنامج الذي تظنّه. لا يشرح هذا المقال كل سبب على حدة من الصفر، وإنما هو مدخل يحدّد من كتب الرسالة ثم يوجّه القارئ إلى المقال الصحيح. يقسم أولًا المواضع التي قد تُكتب فيها الرسالة إلى أربع طبقات، وهي الواجهة الخلفية التي تقدّم النموذج، وClaude Code نفسه، والبرنامج المُطلِق من امتداد محرر أو غلاف، وعملاء الطرف الثالث، ثم يجري المطابقة. وتبيّن أن اثنين من الخمسة بندان في مرجع الأخطاء الرسمي لـ Claude Code. فالتعريف الرسمي لرسالة البثّ هو أن الترويسات عادت بينما لم يحمل الجسم أي رسالة من واجهة Claude البرمجية، وهذا ليس انقطاعًا في المنتصف إطلاقًا، وقراءتها على أنها اتصال سقط تأخذك في الطريق الخطأ. أما Could not locate the Claude CLI on PATH فترد في فصل مستقل عنوانه Wrapper and IDE errors، موصوفة بأن البرنامج المُطلِق يطبعها لا Claude Code نفسه، وقد يبلغ النص المعروض فعلًا أربع جمل بينما العنوان الرسمي جملة واحدة، ولهذا لا يأتي البحث عنه بشيء. وفي المقابل فإن نصّي مرشِّح المحتوى من مفردات الطرف الثالث، ويبلّغ البلاغ ‎#35736 في OpenCode بأن ثلاثة أعطال منفصلة تمامًا، وهي 404 في Vertex وانقطاع مقبس ورفض حقيقي، تظهر جميعها بالجملة نفسها عن الحجب بمرشِّح المحتوى. والصياغة صحيحة في واحد من الثلاثة فقط، فتصديقها وتخفيف صياغة المُوجّه لن يصلحا معرّف نموذج مضبوطًا خطأ. وتنصّ وثائق GitHub الرسمية كذلك على أن مُوجّهات الإدخال وإكمالات الإخراج تمرّ عبر مرشِّحات محتوى GitHub Copilot عند استخدام Claude، فاستخدام Claude لا يعني أن ترشيح Anthropic هو ما أوقفك. أما النص الباقي فلا يرد في مرجع الأخطاء الرسمي ولا في وثيقة Remote Control، فلم يتحدّد مصدره، ولا تُسمّى له أي أداة، وتُعرض بدلًا من ذلك أربع خطوات لتتبّعه في بيئتك أنت. وما تأكّد وما لم يتأكّد موسوم في المقال كله.

يتوقف Claude Code في منتصف الرد فتظهر العبارة «API Error: Connection lost mid-response. The response above may be incomplete.»، ثم لا يعثر من يبحث عنها حرفيًا على شيء تقريبًا، والسبب أن النص نفسه جديد. يقول مرجع الأخطاء الرسمي ذلك صراحة: قبل v2.1.227 كانت Connection lost mid-response تُعرض باسم Connection closed mid-response، وفي الدفعة نفسها صارت Response stalled mid-stream هي The response stopped arriving، وصارت Connection closed while thinking, before producing a response هي Connection lost before a response was produced. فالحدث ليس جديدًا، وإنما تبدّلت الكلمة المعروضة وحدها، ولهذا يظل ما كُتب تحت الاسم القديم صالحًا كما هو، ولهذا أيضًا لا بد أن يشمل البحث في البلاغات الصيغتين معًا. ينطلق المقال من واقعة إعادة التسمية هذه معتمدًا على الوثائق الرسمية والبلاغات العلنية وحدها. يعرض التعريفات الرسمية للرسائل الست للانقطاع في منتصف الرد، وهي Server error وConnection lost وYour computer went to sleep وThe response stopped arriving وPart of the response never arrived وThe response stream was malformed، ويبيّن لماذا يُحتفظ عمدًا بالمخرجات التي ظهرت على الشاشة، إذ إن إعادة إرسال الطلب قد تُنفّذ استدعاء الأداة نفسه مرتين، ولماذا تكون خطوة الاستئناف هي الرد بكلمة continue لا البدء من جديد. ثم يشرح سبب غياب إعادة المحاولة التلقائية عبر مسارات Automatic retries الرسمية: الانقطاع قبل اكتمال أي شيء يُعاد إرساله بتراجع أسّي حتى عشر مرات، والانقطاع بعد التفكير وقبل أي مخرجات يُعاد إرساله مرتين على الأكثر ثم ينتهي الدور برسالة Connection lost before a response was produced، والانقطاع بعد اكتمال كتلة لا يُعاد إرساله إطلاقًا. ومن هناك يرسم الطبقات الثلاث التي قد ينقطع عندها البثّ، وهي جهازك وخطك، والمسار عبر الوسطاء والبوابات، وجانب الخادم مع إعادة استخدام الاتصال، ويضيف الحالة الرابعة التي يسهل إغفالها وهي تدوير شهادات mTLS وسلوك إعادة تحميلها منذ v2.1.232، ثم يقدّم قائمة عزل من تسع خطوات. ويسرد مؤقتات مراقبة البثّ الأربعة بقيمها الافتراضية، أي 180 ثانية لأول بايت و300 ثانية على مستوى الأحداث و180 ثانية على مستوى البايتات وخمس دقائق لخمول الجسم، إلى جانب CLAUDE_CODE_MAX_RETRIES وCLAUDE_CODE_RETRY_WATCHDOG وAPI_TIMEOUT_MS ومتغيّري مهلة البثّ، مع التوضيح بأن رفع عدد مرات إعادة المحاولة لا يُقلّل هذه الرسالة بالذات. ويفصل جدول مقارنة بين ثماني رسائل يسهل الخلط بينها، ويعرض بلاغين علنيين هما ‎#86473 و‎#85979 يكتمل فيهما HTTPS الخام وcurl بينما تسقط الطرفية وحدها بـ ECONNRESET. ويختم بفصل ما تأكد رسميًا عمّا هو مجرد بلاغ، ومنه أن الإصدارات السابقة لـ v2.1.222 كانت قد تعرض هذا الإشعار حتى حين يكون الرد قد اكتمل فعلًا.

الانتقال إلى Claude Fable 5.1 ليس مجرد استبدال معرّف النموذج ثم اعتبار الأمر منتهيًا. فـ Anthropic تصنّف ثلاثة من التغييرات بوصفها جذرية، واثنان منها يظهران بعيدًا عن الموضع الذي نشآ فيه. الأول يرمي خطأً فورًا: تمرير النوع القسري إلى معامل اختيار الأداة يعيد خطأ طلب غير صالح برمز 400، لأن إجبار النموذج على استدعاء أداة يتخطّى التفكير الذي يمارسه دائمًا، فتنخفض معه جودة وسائط الاستدعاء. أما الثاني فهو الصامت. صارت كتل التفكير تسجّل أي نموذج أنتجها ولا تُنقل إلا في اتجاه واحد، فالمحادثة التي تنتقل إلى Fable 5.1 تحتفظ باستدلالها، بينما الموجّه أو الاحتياطي الذي يعيدها إلى جيل أسبق يفقد ذلك الدور بالكامل. وافتراضيًا تتخلّص الواجهة من الكتل غير المقروءة قبل أن يراها النموذج، ولأن الرموز المطروحة لا تُحتسب ولا تُفوتر فلا يظهر شيء في الفاتورة. وإظهار ذلك يتطلب ترويسة بيتا مخصصة. أما الثالث فهو الأوسع أثرًا: تغيير أي شيء يسبق كتلة تفكير من Fable 5.1، بما في ذلك مطالبة النظام أو مصفوفة الأدوات أو أي رسالة أسبق، يُبطلها ويُبطل كل كتلة بعدها. وسريان ذلك يتوقف على تاريخ إنشاء حسابك، ما يعني أن بيئة اختبار أنشأتها للتو قد تفشل بينما لا يفشل الإنتاج. ويتناول المقال أيضًا ما لم يسُؤ: الدخل باقٍ عند $10 والخرج عند $50 لكل مليون رمز، بينما تهبط قراءة الذاكرة المؤقتة إلى $0.25، أي 0.025 من سعر الدخل الأساسي مقابل 0.1 في بقية نماذج Claude. وتذكر Anthropic وفرًا يقارب الربع في أحمال العمل المعتادة ويصل إلى نحو النصف تقريبًا في الأعمال ذات الطابع الوكيلي الكثيف. وهناك سبعة سلوكيات تتغيّر دون تغيير أي شيفرة، منها تراجع الاستدعاءات المتوازية للأدوات، وتقلّص سرد التقدم عند الجهد المرتفع، وكثرة الإجابة من الذاكرة عند الجهد المنخفض. وتُحصي Anthropic خمس إضافات، إحداها خفض سعر قراءة الذاكرة المؤقتة الذي أُفرد له قسم مستقل، وبين الأربع الباقية ميزات بيتا وُضعت تحديدًا لتحل محل الأنماط التي منعتها التغييرات الجذرية.

ظلّت النماذج المحلية قادرة على كتابة الشيفرة سنوات، لكن بوصفها إكمالًا فحسب: ملء بقية السطر الذي بدأت كتابته. أما النمط الوكيلي، حيث يقرأ النموذج المستودع ويعدّل عدة ملفات ويشغّل الاختبارات، فكان أثقل من أن يعمل في البيت. وقد تغيّر ذلك عبر أواخر 2025 و2026، وأوضح دليل عليه أن مطوّري النماذج صاروا يسوّقون له مباشرة: فبطاقة نموذج Qwen تذكر CLINE بالاسم وتقدّم صيغة استدعاء دوال مصمَّمة لهذا الغرض، وأطلقت Mistral نموذج Devstral Small 2 بحجم 24B برخصة Apache 2.0 إلى جانب Devstral 2 بحجم 123B في 9 ديسمبر 2025. ويرتّب هذا المقال ما يمكن بلوغه فعليًا اليوم اعتمادًا على المصادر الأولية وحدها، لأن عدة مقالات تجميع تبيّن أنها نسبت درجة نموذج بحجم معيّن إلى نموذج بحجم آخر. والعقبة المركزية تفصيلة ضبط لا يكاد أحد يذكرها: فـ Ollama لا يستعمل طول سياق افتراضيًا ثابتًا، بل يشتقّه من مقدار VRAM لديك، أي 4k تحت 24 GiB، و32k من 24 إلى 48 GiB، و256k فوق ذلك. وحاسوب الألعاب المعتاد يقع في الصف الأول، فيتجاوز الوكيل النافذة فورًا ويُقتطع أول المحادثة بصمت. ولا يظهر أي خطأ. ينسى التعليمات، ويكرّر العمليات، ويفقد الهدف، فيبدو الأمر كله كأنه نموذج غبيّ لا كأنه سياق مرميّ. ويوثّق Ollama ضرورة 64000 رمز على الأقل لأدوات البرمجة، وتُضبط عبر متغيّر البيئة الخاص بطول السياق، لكن رفعها يرفع استهلاك الذاكرة أيضًا، فيلزم التأكّد من أن النموذج ما زال يتّسع على المعالج الرسومي. ويغطّي المقال كذلك لماذا Continue و Cline أداتان مختلفتان بمتطلّبات عتاد مختلفة، والدرجات المنشورة لـ Qwen3.6-35B-A3B (73.4 على SWE-bench Verified، و3B نشطة من أصل 35B) و Devstral Small 2 (68.0%)، وأحجام التنزيل وإرشاد الذاكرة بحسب فئة VRAM، وإعدادًا من أربع خطوات، ولماذا لم تعد مقارنات «المحلي بلغ كذا بالمئة من السحابة» تصمد بعد أن أخذ جانب الطليعة يبتعد عن نشر SWE-bench Verified، ومحاسبة صريحة لما تكلّفه «المجانية» فعلًا.