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

يصل Remote Control تطبيق Claude على الهاتف أو صفحة claude.ai/code بجلسة Claude Code تعمل بالفعل على جهازك أنت، والنقطة التي تفوت معظم الشروح هي أن شيئًا لا ينتقل إلى السحابة: تنفيذ الشيفرة والوصول إلى الملفات يبقيان محليَّين طوال الوقت، والهاتف ليس إلا نافذة تطلّ على تلك الجلسة. ويعالج هذا المقال ما يشتريه لك هذا التصميم وما يكلّفك إياه. فنظام ملفاتك المحلي وخوادم MCP والأدوات وإعدادات المشروع تبقى كلها متاحة، والمحادثة وتقدّم الوكلاء الفرعيين يبقيان متزامنين بين الطرفية والمتصفّح والهاتف، وحاسوب محمول نائم أو اتصال ساقط أمر يمكن تجاوزه لأن Claude Code يعيد الاتصال ويسلّم التحديثات المصفوفة فور تعافيه. والشروط أصرم ممّا تبدو: خطة Pro أو Max أو Team أو Enterprise (ومفاتيح الـ API غير مدعومة)، وتسجيل دخول إلى claude.ai لا رمز طويل الأمد، واتصال مباشر بـ api.anthropic.com، وألّا يكون أيّ من متغيّرات البيئة الأربعة التي توقف القياس عن بُعد مضبوطًا، وهذا سبب إخبار المهتمّين بالخصوصية ممّن يضبطون DO_NOT_TRACK بأن الميزة غير مفعّلة على حسابهم. ويغطّي المقال المداخل الثلاثة لبدء الجلسة (نقل المحادثة الحالية كما هي، أو الإقلاع بالاتصال البعيد مفعّلًا، أو وضع الخادم برايات spawn و capacity بحدّها الافتراضي 32 و continue)، إلى جانب الفصل بين الأوامر المائلة التي تعمل عن بُعد وتلك المحلية فقط، ومهلة الخمس دقائق التي لا تسري على طلبات الأذونات، ومفتاحَي الإشعارات الفورية. أما في الأمان فالمقال متعمَّد: لا يُفتح أي منفذ وارد إطلاقًا، فيكاد سطح الهجوم الشبكي يتلاشى وينتقل الخطر إلى الحساب، ورمز QR اختصار لا مصادقة، والبوابة الافتراضية هي بالضبط حساب واحد مسجَّل الدخول، وهو ما يجعل مفتاح المرور أعلى الخطوات قيمة. ويكتمل العرض بمدد الاحتفاظ بنصّ الجلسة (5 سنوات أو 30 يومًا)، وما تفعله عند فقدان الهاتف، وTrusted Devices بنافذة تسجيل الدخول ذات الـ 18 ساعة، ومهلة العشر دقائق في وضع الخادم، ونافذة الاستعادة ذات الأربع ساعات، وضرورة tmux على الأجهزة البعيدة، وجدول تشخيص مبني على رسائل الخطأ الفعلية، ومقارنة مع Dispatch.

مرّت طريقة تفكير Claude بتغيير جيلي كامل. كان التفكير الموسع القديم يفرض عليك تحديد ميزانية توكنات في كل طلب — thinking: {"type": "enabled", "budget_tokens": N} — لكن الميزانية المناسبة تختلف من مهمة إلى أخرى ولا يمكن تخمينها مسبقًا، وتغييرها يُبطل ذاكرة التخزين المؤقت للموجّه. أما التفكير التكيفي الحالي فسطر واحد، type: "adaptive": قرار التفكير من عدمه ومدى عمقه قرار يتخذه النموذج بنفسه بحسب صعوبة الطلب. وقد جرى الترحيل على مراحل: أُهمل budget_tokens في Opus 4.6 / Sonnet 4.6 ويُرفض بخطأ 400 من Opus 4.7 فصاعدًا. يكثّف هذا المقال قواعد كل نموذج في جدول واحد — Fable 5.1 وOpus 5.5 يفكّران دائمًا (لا يمكن تعطيله)، وSonnet 5.5 يأتي والتفكير مفعّل افتراضيًا ويرفض disabled بخطأ 400، لكن between_tools يوقف التفكير المسبق وحده (effort بمستوى high أو أدنى)، والنموذجان القديمان (Legacy) Opus 5 وSonnet 5 يأتيان والتفكير مفعّل افتراضيًا (على Opus 5 لا يُسمح بالتعطيل إلا عند effort بمستوى high أو أدنى)، وOpus 4.8 / 4.7 يتطلبان ضبط adaptive صراحةً، والنماذج التي لا تدعم إلا التفكير الموسع مثل Haiku 4.5 / Sonnet 4.5 ما تزال تستخدم budget_tokens وضعًا وحيدًا. انتقل التحكم في العمق إلى output_config: {"effort": ...} بخمسة مستويات (الافتراضي high في معظم النماذج وmedium في Opus 5.5 وHaiku 5.5)، وتغيير effort يُبطل الذاكرة المؤقتة كما كان يفعل تغيير الميزانية. وتحكم الرؤيةَ قيمةُ display: افتراضي الجيل الجديد هو "omitted" (كتل تفكير فارغة)، وتُحاسَب على كامل توكنات التفكير في الحالتين — قِسها عبر usage.output_tokens_details.thinking_tokens؛ ولا يعيد أي إعداد سلسلة الأفكار الخام. ولتعطيل التفكير على Opus 5 آثار جانبية موثقة (استدعاءات أدوات تُكتب نصًا عاديًا، وتسرّب وسوم داخلية)، لذا فإن خفض effort هو رافعة التكلفة الأكثر أمانًا. والتفكير المتداخل — الاستدلال بين استدعاءات الأدوات — تلقائي في الوضع التكيفي دون الحاجة إلى ترويسة beta القديمة. وعند الحاجة إلى السرعة، يشغّل الوضع السريع نموذج Opus نفسه بسرعة تصل إلى نحو 2.5 مرة مقابل ضعف السعر (Opus 5.5/5/4.8 فقط، ويُبدّل عبر ‎/fast في Claude Code). وكل ذلك مستند إلى وثائق Anthropic الرسمية Thinking وExtended thinking وFast mode.

تكون منهمكاً في عملك حين يتجمّد Claude Desktop فجأة، فتموت معه كل جلسات Claude Code المفتوحة دفعةً واحدة، وحين تغلقه قسراً وتحاول تشغيله من جديد قد تجده لم يعد يبدأ أصلاً — وآخر سطر في السجلّ يكون في الغالب GPU process gone مصحوباً بالرمز exitCode 101457950 أي 0x060C201E. يبدأ هذا المقال بالفصل الذي يوفّر عليك وقتاً طويلاً: المنهار ليس Claude Code بل عملية GPU في تطبيق سطح المكتب المبني على Electron، والتمييز سهل لأن السطر السابق مباشرةً لإعادة التشغيل في ‎%APPDATA%\Claude\logs\main.log يحسم الأمر، فيما ينقطع السجلّ عند تلك النقطة ويأتي بعده Starting app. ثم يشرح لماذا تُجرّ جلسات لا علاقة لها بالأمر: عملية GPU في Chromium مورد مشترك لا توجد منه سوى نسخة واحدة لكل تطبيق، تتشاركها كل النوافذ والألسنة والجلسات، ولذلك تُسقط صفحة ثقيلة واحدة كل ما هو مفتوح، ولا يستطيع المستخدم عزلها بأي إعداد. وعن المُشغِّل، يوضّح المقال أن المتصفح المدمَج هو الأكثر تكراراً في المشكلات المعلَنة (#80444، و#82967 الذي يحصر السبب في التقاط لقطة الشاشة الخاصة بالمعاينة، و#83478 مع معاينة تتحدّث باستمرار)، لكنه ليس الوحيد: إذ يبلّغ #68049 عن السقوط بالرمز نفسه عند بدء التشغيل على بيئة ARM64 دون أي تعامل مع المتصفح. كما يحذّر المقال من دليل زائف شائع، فتحذير requestAdapter الذي يظهر في السجلّ نفسه رسالة عادية من Chromium حول عدم فاعلية powerPreference على Windows، ولا يصحّ اتّخاذ وجوده دليلاً على انهيار. ويأتي بعد ذلك الجانب العملي: ثلاثة ملفات تكفي للجزم، وجدول يفرّق بصمة هذه الحالة عن رمزَي الخروج الطبيعيَّين، وترتيب الاستعادة حين لا يعود التطبيق يبدأ، أي إنهاء العمليات المقيمة ثم خيار «إصلاح» ثم إعادة التثبيت أخيراً، مع الإشارة إلى بلاغ وصلت فيه الحزمة إلى Modified, NeedsRemediation فلم ينفع «إصلاح» إطلاقاً ولم تُعدها سوى إزالة تثبيت كاملة. وعن البيانات: ما حُفظ يبقى على القرص، أما العمل الذي كان قيد التنفيذ فلا يعود، وهناك بلاغ بضياع نتائج وكلاء فرعيين كانوا يعملون بالتوازي. ويختم بقائمتين صريحتين لما ينفع وما لا ينفع: لا يمكن استخدام disable-gpu على إصدار MSIX لأنه يُرفض برسالة رفض الوصول، وتعطيل ميزة المتصفح يوقف ما ينشأ عن المتصفح فقط ولا ينفع مع عائلة السقوط عند بدء التشغيل، ونصيحة تثبيت أفضلية البطاقة في التركيبات الهجينة لم يرد أي بلاغ بنفعها في هذا العَرَض تحديداً. ويضيف تمييزاً لظاهرة يسهل الخلط بينها وبينه، وهي الإنهاء القسري الذي يفرضه تحديث Microsoft Store، ويُعرف بسطر Windows session ending (close-app) دون ظهور GPU process gone.

لا تستطيع دعوى عامة أن تجيب عن سؤال "إن كان الذكاء الاصطناعي قادرًا على التعديل مباشرة، فهل ما زلنا بحاجة إلى لوحة إدارة؟"، لأن عبارة "لوحة الإدارة" وحدها تغطّي كومة من الوظائف مختلفة الطبائع تمامًا. وهذا المقال، المبني على تجربة حذف لوحة إدارة هذا الموقع بالكامل، يستبدل بذلك السؤال سؤالًا أحدّ: هل تقدّم تلك الشاشة شيئًا لا يقدّمه أصلًا كلٌّ من CLI والذكاء الاصطناعي؟ وما كشفه الحذف الكامل هو أن معظم الوظائف التي أُزيلت لم تكن "غير مستعمَلة" بل "معطّلة بنيويًا". فعمليات CRUD للمقالات لم يكن ممكنًا أن تعمل أصلًا، لأن مصدر الحقيقة للمقالات يعيش في الشيفرة وكل عملية نشر تكتب فوق قاعدة البيانات، فأي شيء يُحرَّر في الشاشة كان يتبخّر عند النشر التالي. وكان طابور اعتماد التعليقات فارغًا على الدوام لأن المشاركات تُوسم بالاعتماد لحظة إرسالها، فلا ينشأ تعليق غير معتمد أصلًا. والوظيفة التي لا يستعملها أحد هي وظيفة لا يستطيع أحد أن يعرف أنها مكسورة. أما القدرة الوحيدة التي تعذّر حذفها فهي حذف التعليقات، وحتى هي لم يكن فيها ما يوجب لوحة إدارة: فقد تبيّن أن زرّ حذف في صفحة المقال نفسها أفضل، لأن التعليق المسيء يُزال في المكان نفسه الذي يُقرأ فيه. ويؤول القرار إلى ستة أسئلة. من الذي يشغّلها، إذ يرجّح الموظفون غير التقنيين أو دور يتبدّل أصحابه بقاء الواجهة، بينما لا يحتاجها المطوّرون الذين يعيشون في الطرفية. وهل هي قابلة للتراجع، فالإجراءات التي لا رجعة فيها تحتاج إلى بوابة. وهل تحتاج إلى حكم بشري، أي هل هناك انتقال بين حالتين بالاعتماد أو الرفض. وهل يلزم فصل الصلاحيات. وهل يعرف المشغّل ما هو ممكن، فالقائمة تقوم مقام التوثيق. وهل هناك أثر للتدقيق. والصلاحيات وأثر التدقيق بوجه خاص يبدوان غير ضروريين في مشروع فردي، ويصيران أول ما يلزم في اللحظة التي يصل فيها شخص ثانٍ. والتغييرات التي تمرّ عبر الشيفرة تستقرّ في git، لكن ترك الذكاء الاصطناعي يكتب في قاعدة البيانات مباشرة لا يسجّل شيئًا افتراضيًا، وسجلّ المحادثة يحفظ ما طُلب لا ما حدث. ومن بين المحاور الستة، لا يحمل وزنًا مختلفًا سوى قابلية التراجع. ففي 18 يوليو 2025 حذف وكيل ذكاء اصطناعي من Replit قاعدة بيانات الإنتاج الخاصة بـ SaaStr أثناء تجميد فعلي للشيفرة، واختلق 4,000 مستخدم، وزعم خطأً أن التراجع مستحيل فأخّر التعافي (AI Incident Database #1152) — وهي حالة تُظهر مشكلة تصميم أمكن فيها بلوغ إجراء لا رجعة فيه دون المرور ببوابة بشرية، أكثر مما تُظهر خطر الذكاء الاصطناعي نفسه. ويتناول المقال كذلك ثلاثة أشياء ينبغي تهيئتها قبل نقل الثقل إلى الذكاء الاصطناعي وإلى CLI، وهي أن تخلّف التغييرات أثرًا باقيًا، وأن توجد عتبة أمام الإجراءات التي لا رجعة فيها، وأن يكون الإجراء مكتوبًا وموثّقًا لأن حذف الواجهة يحذف معها قائمة ما هو ممكن. ويضيف قائمة تحقّق تجريها قبل أن تبني أي شيء، والخيار الثالث المتمثّل في منتجات الأدوات الداخلية مثل Retool و Forest Admin بدلًا من كتابة اللوحة باليد.

يضغط كثيرون أمر ‎/compact في Claude Code وفق قاعدة من نوع "كل 30 دقيقة" أو "متى تجاوز السياق 70%"، لكن ما توصي به الوثائق الرسمية ليس ساعة ولا نسبة مئوية: إنه حدّ فاصل في العمل. شغّل ‎/compact عند حدّ فاصل طبيعي، مثلًا بين مهمة وأخرى، بدلًا من انتظار الضغط التلقائي ليعمل في منتصف مهمة. يتخذ هذا المقال وثائق Claude Code كما هي في 4 أكتوبر 2026، وأحدث إصدار حينها v2.1.289، مصدرًا أوليًا، ويشتقّ من المواصفات جوابًا عن مسألة الضغط اليدوي. يبدأ من الآلية نفسها: يجري الضغط على ثلاث مراحل، هي إسقاط مخرجات الأدوات القديمة، ثم الضغط التلقائي، ثم الضغط اليدوي الذي تضغطه أنت. والمرحلتان الثانية والثالثة هما المعالجة نفسها، فضغطه بنفسك يشتري لك شيئين بالضبط: اختيار التوقيت، وتحديد ما يُحتفظ به. أما تكرار الضغط فلا يوفّر سياقًا إضافيًا. ثم يأتي جدول بما ينجو من العملية. فملف CLAUDE.md في جذر المشروع والذاكرة التلقائية يُعاد حقنهما من القرص، بينما تُفقد القواعد التي تحمل paths: وملفات CLAUDE.md المتداخلة في المجلدات الفرعية إلى أن يُقرأ ملف مطابق مرة أخرى، ويُعاد حقن متون المهارات التي استدعيتها ضمن سقف قدره 5,000 توكن لكل مهارة و25,000 إجمالًا، مع إسقاط الأقدم أولًا، والاقتطاع يُبقي بداية الملف. وفي شأن التكلفة، لا يحدّد سعر الضغط حجمُ السياق بل حرارة التخزين المؤقت للمطالبة. اضغطه أثناء الجلسة فتُقرأ البادئة من الذاكرة المؤقتة وتكون التكلفة زهيدة؛ واضغطه بعد استراحة أطول من عمر التخزين المؤقت، وهو ساعة واحدة مع اشتراك Claude وخمس دقائق افتراضيًا عبر مفتاح API أو مزوّد سحابي، فيُعاد معالجة السجل كاملًا بلا تخزين، وتلك أغلى حالات هذا الأمر على الإطلاق. ومن هناك يتناول المقال كيفية المفاضلة بين ‎/compact و ‎/clear و ‎/rewind و ‎/recap و ‎/context، وكيف يحرّك ‎/autocompact منذ الإصدار v2.1.221 نقطة الانطلاق التلقائي في أي موضع بين 100K و1M توكن، وترتيب أولوية المواضع الأربعة التي قد يأتي منها الإعداد، والمصيدة المتمثلة في أن متغيّر البيئة CLAUDE_CODE_AUTO_COMPACT_WINDOW وحده لا يقبل إلا عددًا صحيحًا مجرّدًا فتُقرأ 500k على أنها 500 وتُقصَر إلى الحد الأدنى 100K، وأن نسبة used_percentage في شريط الحالة تقيس دائمًا مقابل نافذة السياق الكاملة للنموذج فلا تعود تدلّ على لحظة الانطلاق. ويختم بمعنى الرسالتين Not enough messages to compact. و Autocompact is thrashing: the context refilled to the limit... وخطوات التعافي منهما، مع تنبيه إلى أن تسمية "الضغط المصغّر" ليست مصطلحًا رسميًا حتى 8 أغسطس 2026.

تحاول فتح Claude Desktop على Windows فيظهر بدلاً من ذلك مربّع حوار عنوانه Can't open this app يطلب منك الانتقال إلى الخيارات المتقدّمة الخاصة بـ Claude واختيار Repair — وتنفيذ ما تقوله الرسالة حرفياً ينجح فعلاً. لا إزالة تثبيت، ولا إعادة تعيين تُلقي ببياناتك. لكن في المنتصف خطوة واحدة يتعثّر عندها الناس، وهي محور هذا المقال: الضغط على الإصلاح قد يعود برسالة تقول إن التطبيق ما زال قيد التشغيل، رغم أنه لا توجد أي نافذة مفتوحة لـ Claude. السبب أن Claude Desktop يظلّ يعمل في علبة النظام بعد إغلاق نافذته، وما دامت تلك العملية المقيمة ممسكةً بملفات الحزمة فإن الإصلاح لا يمرّ. والحل بسيط: أنهِ العمليات صراحةً ثم اضغط الإصلاح. وهذه الحقيقة نفسها تشير إلى سبب العطل الأصلي — العملية ذاتها أفسدت التحديث ثم منعت الإصلاح. يجيب المقال أيضاً عن السؤال الذي يطرحه معظم الناس أولاً: هل تُمحى جلساتك؟ الجواب ينقسم ثلاثاً. سجلّ محادثات claude.ai يقيم على خوادم Anthropic ولا يُمسّ. وجلسات Claude Code تقيم في ‎%USERPROFILE%\.claude\projects\‎ خارج حزمة التطبيق، فتنجو من الإصلاح ومن إعادة التعيين بل ومن إزالة التثبيت (جهاز حقيقي احتوى 2,977 ملفاً بنحو 3.0GB موزّعة على 52 مشروعاً). الشيء الوحيد المعرَّض للخطر هو إعدادات التطبيق في ‎%APPDATA%\Claude، و«إصلاح» يُبقي حتى هذه — فـ Windows يوضّح الفرق على الشاشة نفسها: الإصلاح لا يؤثر في بيانات التطبيق، وإعادة التعيين تحذفها. ومن هناك يغطّي المقال فحص الحالة بـ PowerShell للقراءة فقط، وروتين نسخ احتياطي، وتصعيداً متدرّجاً حين يظلّ التطبيق لا يفتح (التأكد من تشغيل vmcompute وhns، وإزالة الحزمة ثم إعادة التثبيت، إذ لا يعمل -PreserveApplicationData مع التثبيت العادي)، والسبب المُستنتَج المتمثّل في حزمة MSIX نصف مُسجَّلة إلى جانب مشكلات GitHub (#55465 حيث نجح التثبيت دون إنشاء نقطة تنفيذ، و#50285 و#48437 — وكلها أُغلقت بوصفها غير مخطَّط لها ودون إصلاح رسمي)، وكيفية تقليل احتمال التكرار، ومقارنةً بإصدار المُثبِّت القديم حيث سجَّل أحدث إصدار MSIX والجهاز العامل بالصيغة القديمة الرقم 1.24012.9 نفسه.

يتوقف Claude Code في منتصف الرد برسالة «API Error: Connection closed mid-response. The response above may be incomplete.» وهذه ليست مشكلة في صياغة الأمر، بل الاتصال الذي كان يحمل الرد المتدفق أُغلق بينما الرد لا يزال قادمًا. يعتمد هذا المقال حصريًا على مرجع الأخطاء الرسمي وسجل التغييرات الرسمي وبلاغات مدعومة بالتقاط حزم الشبكة. يبدأ بالتعريفات الرسمية: Connection closed تعني أن الوصلة قُطعت، وResponse stalled تعني أنها صمتت، وServer error تعني وصول خطأ 5xx في منتصف التدفق؛ ويشرح لماذا تُحفظ المخرجات الجزئية عمدًا (لأن إعادة الإرسال قد تنفّذ الاستدعاءات نفسها للأدوات مرتين) وأن خطوة الاستعادة الموثّقة هي الرد بـ continue. ثم يفصل الطبقات الثلاث التي قد ينشأ منها الإغلاق (جهازك ووضع السكون، أو القطع عند الخمول في بروكسي أو VPN، أو إغلاق يبدأ من الخادم)، ويعرض القياسات التي نشرها صاحب البلاغ #67766: كانت الحالات العشر جميعها إغلاقًا سليمًا من الخادم، وظهر الخطأ بعد 3 إلى 105 مللي ثانية من FIN، وكان قد وصل 7 إلى 20 كيلوبايت من الرد، وبلغ جسم الطلب 1 إلى 2.5 ميغابايت، ونجح اتصال جديد خلال نحو 20 مللي ثانية، وظهرت 200 رسالة خطأ في 171 حادثة خلال 23 يومًا، منها 87 بعد أقل من خمس ثوانٍ من الاستدعاء السابق. أما جوهر الفائدة العملية فهو جدول زمني لبنود حقيقية في سجل التغييرات — 2.1.179 يحفظ الجزء المستلَم، و2.1.185 ينقل تنبيه التوقّف من 10 إلى 20 ثانية، و2.1.198 يعيد محاولة الانقطاعات العابرة بتراجع تدريجي، و2.1.199 يحفظ الجزء المستلَم عند أخطاء الخادم داخل التدفق، و2.1.214 يعطّل مجمّع keep-alive بعد خطأ اتصال قديم — مقارنًا بإصدارات البلاغات (2.1.173 و2.1.181 و2.1.183) وكلها أقدم من 2.1.198. ويختم بالظروف التي ترفع الاحتمال، وقائمة تحقّق من ثماني خطوات، وستة إرشادات للمطورين، وكيفية التمييز عن Unable to connect وPrompt is too long، وفصل واضح بين المؤكَّد رسميًا وغير المؤكَّد.

تفتح Hugging Face لتشغيل نموذج لغوي محلي فتجد للنموذج نفسه جداراً من الملفات (Q4_K_M، Q5_K_S، GPTQ، AWQ، IQ3_M) فتتجمد. تجيب هذه المقالة عملياً عن أي ملف مُكمَّم تنزّل حتى يعمل النموذج، تاركةً مفهوم ما هي التكميم لمقالة أخرى ومركّزةً على اختيار الصيغة. الاختيار خطوتان: أي صيغة (= أي محرك ستشغّله عليه)، ثم أي عمق بتات. الحقيقة الأهم أن الملف المُكمَّم لا يعمل إلا على المحركات التي تدعم صيغته. GGUF هي الصيغة المعتادة الشاملة المحلية التي تعمل على المعالج المركزي وMac وGPU جزئي (llama.cpp/Ollama)؛ أما GPTQ/AWQ/EXL2 فهي لـ GPU أولاً (vLLM)؛ وbitsandbytes يُكمِّم عند التحميل في Transformers بلا معايرة. تسمية GGUF مثل Q4_K_M ثلاثة أجزاء: Q4 (4 بتات اسمياً، الأعلى أفضل وأكبر)، K (K-quant عبر كتل فائقة؛ المجرد/_0/_1 قديمة)، M (S/M/L = مقدار ترقية بعض التنسورات المهمة؛ البتات الفعلية تفوق التسمية، Q4_K نحو 4.5 bpw). عائلة IQ (I-quants) تذهب لحجم أصغر عند البتات نفسها لكنها أثقل في الاستدلال وتحتاج imatrix (مصفوفة أهمية من المعايرة تحمي الأوزان المهمة). GPTQ يقلّل الخطأ طبقةً بطبقة؛ AWQ يحمي الأوزان البارزة عبر التنشيطات (لا واحدة أفضل على الإطلاق). لعمق البتات، عند التردد اختر Q4_K_M (افتراضي Ollama لنماذج كثيرة)، وارتقِ إلى Q5_K_M/Q6_K مع VRAM فائض، وQ8_0 شبه خالٍ من الخسارة لكنه غير مُوصى به، وIQ2/IQ3 فقط لحشر نموذج كبير. نحو 4.5 إلى 5 bpw هي النطاق اللذيذ (قاعدة استرشادية). اعثر على الملفات عبر library=gguf، أو bartowski/mradermacher (النشاط يتغيّر)، أو وسوم Ollama model:size-variant-quant. الأرقام تقريبية وتختلف حسب النموذج والبناء.

بعد تحديث Claude Desktop (على Windows) مباشرةً، يؤدي تشغيل التطبيق إلى ظهور "يوجد برنامج آخر يستخدم هذا الملف حاليًا" ولا يبدأ — ويبقى معطّلاً حتى تُعيد تشغيل الحاسوب. هذه علّة معروفة في إصدار متجر Microsoft (MSIX) (GitHub #53247 وغيره). النقطة الأساسية: إعادة تشغيل الحاسوب بالكامل ليست ضرورية بالضرورة — ففي كثير من الحالات يكفي تسجيل الخروج من Windows ثم الدخول مجدداً لاستعادة التشغيل (لا إعادة تشغيل الحاسوب، ولا تسجيل الخروج من Claude)، لأن المقبض المُعلَّق الكامن وراءه يبقى لكل جلسة مستخدم Windows. إيقاف CoworkVMService أو إعادة تسجيل الحزمة مُبلَّغ عن أنه لا ينفع. ورغم صياغة مربّع الحوار، تأكّد عدم وجود قفل ملف في مساحة المستخدم (handle.exe / Process Explorer): الفشل الحقيقي في طبقة حاوية AppX/Desktop Bridge، عند تحويل Job Object إلى Silo (0x80070020 = ERROR_SHARING_VIOLATION، الحدثان 215/208). للمُحفِّز تفسيران لم يُحسما — إمساك الخدمة بـ Job Object (#57221) مقابل تعطُّل عند البدء يترك التنظيف دون تنفيذ (#53247) — ولم يُطلَق أي إصلاح رسمي. الحل الدائم هو الانتقال إلى إصدار Squirrel (المُثبِّت). يستند إلى جهاز واحد (Windows 11 Home 10.0.26200) جرت مقارنته بمشكلات GitHub؛ مع تصنيف الثقة في كل موضع.

«كم يقلّص الذكاء الاصطناعي جهد تطوير البرمجيات؟» مع ظهور البرمجة الوكيلية في 2025–2026، تغيّرت وحدة القياس نفسها. كانت سابقًا «بكم نسبة مئوية تصبح مهمة واحدة أسرع»؛ أما الآن فهي قصة رتب من حيث المقدار: «دورة تطوير كانت تستغرق أسابيع تُضغط إلى ساعات أو أيام» (TechTarget). أنجز Claude Fable 5 هجرة Stripe بحجم 50 مليون سطر في يوم؛ ووفّرت TELUS 500,000 ساعة مطوّر؛ وانتقل زمن الدورة من 9.6 ← 2.4 يوم. أرقام عصر الإكمال التلقائي — تجربة Copilot أسرع بـ55.8%، وMcKinsey 20–50% حسب المهمة — صارت الآن الحد الأدنى. لكنه ليس 10× بشكل موحّد: وفق تقرير Anthropic لعام 2026 Agentic Coding Trends Report، يستخدم المطوّرون الذكاء الاصطناعي في نحو 60% من عملهم، ومع ذلك يمكن تفويض 0–20% فقط من المهام بالكامل (فجوة التفويض)، لذا المراجعة البشرية مطلوبة، ونحو 27% من عمل الذكاء الاصطناعي عمل جديد لم يكن موجودًا (تقليص الجهد = إنتاج أكثر). ومع تصميم سياق جيد، أخطاء أقل بنسبة 40% وسرعة أعلى بنسبة 55%. حتى نتيجة METR لعام 2025 «الخبراء أبطأ بنسبة 19%» تنعكس في 2026، مع اعتراف المؤلفين بأن القياس يقدّر الواقع بأقل مما هو عليه. يفصل هذا المقال ذلك الاستقطاب بمصادر مسمّاة (GitHub، McKinsey، Anthropic، METR، DORA) ويعرض كيف تحصّل وفر الجهد فعليًا.

أثناء العمل الطويل في Claude Code قد يتحوّل الرد إلى تكرار «court court court…» عشرات إلى مئات المرات ثم يتوقف بالرسالة «API Error: Response stalled mid-stream. The response above may be incomplete.». هذا ليس خطأك، بل تسلسل عطلين معروفين: تكرار النموذج للرمز نفسه (degeneration) بوسمة area:model، وتوقّف بث الرد في المنتصف. تشرح المقالة حقيقة الطبقتين وعوامل التحفيز والحل الفوري (Esc ثم جلسة جديدة أو ‎/clear) ووقاية المطوّرين عبر API/SDK، وكيف تميّزها عن خطأ تسرّب وسم court/invoke والأخطاء المشابهة.

خطأ «API Error: 400 Output blocked by content filtering policy» الذي يظهر فجأة في Claude Code أو الـ API ليس حدّ استخدام ولا تجاوزًا للسياق، بل هو حالة أوقف فيها مرشّح الأمان «المخرَج» الذي كان Claude بصدد إرجاعه. غرضه الأساسي منع إعادة الإنتاج الحرفي للأعمال المحمية، وكثيرًا ما يقع إنذار كاذب (false positive) دون نية سيئة في توليد النص الكامل لتراخيص قياسية مثل MIT/Apache، أو أعمال «المطابقة» لمصدر موجود، أو استنساخ مستندات طويلة. يرتّب هذا المقال: الشرح الرسمي (كيف يكتشف مرشّح مرحلة المخرَج إعادة إنتاج العمل المحمي ويحظره بـ 400)، وأنماط الإنذارات الكاذبة في مسائل Claude Code الفعلية (التهيئة الأولية لمستودع مفتوح المصدر، ومطابقة القوائم، والتشخيص الخاطئ بأنه حدّ الرموز في نهاية تشغيل وكيل طويل)، وطرق الإصلاح الآن (الحصول على النصوص بأداة بدل النسخ الحرفي، وإعادة صياغة المطالبة نحو التوليد/التلخيص، وإيقاف حلقة إعادة المحاولة بـ Esc، وتقسيم المهمة، والإبلاغ عن الإنذارات الكاذبة للدعم)، وكيفية تمييزه عن Prompt is too long و usage limit و 529 Overloaded و max_tokens.