دليل المبتدئين في الذكاء الاصطناعي: ابدأ من هنا

يكون الخطأ «command not found: claude» في معظم الحالات مجرّد أن مجلد التثبيت (~/.local/bin) غير مُدرَج في PATH؛ الملف الثنائي موجود، فيكفي إضافة سطر واحد وإعادة تشغيل الطرفية. يغطي المقال طرق التثبيت ومواقعه، وإصلاح PATH، وتعارض عمليات التثبيت المتعددة، ومزالق Windows، والتحديث. خطأ npm EACCES يُحَلّ بالانتقال إلى المثبّت الأصلي لا بـ sudo، وعند التعثّر شغّل claude doctor.

أخطاء الشبكة/البروكسي في Claude Code (Unable to connect / fetch failed / SSL certificate verification failed) تعني أن الطلب لم يصل إلى خادم Anthropic أصلًا، وليست مصادقة أو تحميلًا زائدًا أو حدّ معدل. الأسباب المعتادة هي البروكسي المؤسسي وفحص TLS والجدار الناري. يشرح المقال ضبط HTTPS_PROXY، والوثوق بشهادة CA المؤسسية عبر NODE_EXTRA_CA_CERTS، والنطاقات الواجب السماح بها، وسير عمل التشخيص. لا تعطّل التحقق أبدًا عبر NODE_TLS_REJECT_UNAUTHORIZED=0.

حين يتوقّف Claude Code فجأة برسالة «API Error: 529 Overloaded» أو «500 Internal server error»، فهذان حدثان عابران من جانب الخادم — وليسا خطأً في طلبك أو إعداداتك، ولا نفادًا لاستخدامك. يشرح هذا المقال معنى 529 (ازدحام واجهة Anthropic API مؤقتًا) و500 (خطأ داخلي غير متوقّع)، وأنهما لا يستهلكان حصتك، وكيف يعيد Claude Code المحاولة تلقائيًا حتى 10 مرات بتراجع أسّي، والحلول من جانب المستخدم (الانتظار، والتبديل بـ/model، ومراجعة status.claude.com، و/feedback مع request_id)، والتمييز بينه وبين 429 وusage limit و400، وإرشادات المطورين، وكيفية تمييز الارتفاع العابر عن العطل المستمر.

رسالة «Claude usage limit reached» ليست خطأً، بل آلية عمل حدود اشتراك Pro / Max. الحدّ من طابقين: نافذة 5 ساعات متدحرجة ونافذة أسبوعية، وفي Max يوجد حدّ أسبوعي منفصل لـ Opus. أكبر مُستهلِك هو اختيار النموذج، يليه حجم السياق والتشغيل الطويل والوكلاء الفرعيون/MCP. يشرح المقال البنية وأسباب الاستهلاك وخمس خطوات لمواصلة العمل فوراً وكيفية رؤية ما تبقّى والفرق عن حدود API.

خطأ «Prompt is too long» في Claude Code والـ API ليس حدّ استخدام، بل يعني أن المدخل الذي حاولت إرساله (سجل المحادثة + الملفات + تعريفات الأدوات) تجاوز نافذة سياق النموذج. يشرح المقال ما الذي يملأ النافذة، وكيف يتجنبه Claude Code افتراضيًا عبر auto-compact، وأحجام النافذة (200K مقابل 1M)، والحلول السريعة (/compact و /clear و subagents و /context)، وكيف تميّزه عن max_tokens و usage limit.

هل يظهر خادم MCP في Claude Code كـ failed أو needs authentication أو pending approval عند فتح /mcp؟ يشرح المقال كيفية قراءة الحالة وتصنيف المشكلة إلى ثلاث عائلات: فشل الإطلاق المحلي (stdio)، والمصادقة عن بُعد (OAuth)، وأخطاء ملف الإعدادات. كما يغطي فخ npx الشائع على Windows وحلّه بـ cmd /c، وسير عمل التشخيص بـ claude --debug mcp وMCP Inspector، وقائمة تحقق للوقاية.

حين تظهر كلمة «court» ووسوم <invoke>/<parameter> الخام في Claude Code دون أن تُنفَّذ الأداة، فهذه ليست مشكلة في بيئتك بل خلل من جانب النموذج يفسد رمز التحكّم في لحظة التوليد. يرفضه الهيكل بنمط fail-closed فلا خطر من تشغيل أمر خاطئ، لكن بقاء الكتلة المكسورة في السجلّ يجعل النموذج يقلّدها فيتسلسل الفشل. القاعدة: أخفِق مرتين ثم اهرب إلى جلسة جديدة (/clear). يشرح المقال الآلية والأسباب وإصلاحات المستخدم والمطوّر وتمييزها عن الأخطاء المشابهة والموقف الرسمي.

في يوم ما يتوقّف حساب ChatGPT أو Claude عن العمل فجأة: في 2026 تتزايد التقارير عن إيقاف الحسابات والتحذيرات، والمخيف أنه يمكن حظرك بمخالفة الشروط دون قصد حتى من دون نية سيئة. يلخّص هذا المقال ما تحتاج معرفته لتجنّب فقدان حسابك على OpenAI (ChatGPT و Codex) و Anthropic (Claude و Claude Code) بالاستناد إلى سياسات الاستخدام المنشورة والتقارير، وهو ليس دليلًا للتهرّب من الكشف بل للالتزام بالقواعد. خمسة مُحفّزات شائعة بين الشركتين: المحتوى المحظور / jailbreak، والأتمتة أو الاستخلاص غير المصرّح، ومشاركة أو إعادة بيع الحسابات ومفاتيح API، وأنماط الوصول المريبة (تغييرات متكررة في IP والدولة، واستخدام مكثّف لـ VPN)، وعدم تطابق الدفع أو الاحتيال. أكبر فخ في 2026: استخدام رموز OAuth الخاصة بالخطة الشخصية (Free/Pro/Max) في أي منتج غير التطبيق الرسمي، بما في ذلك أطر مثل Agent SDK، يُعدّ مخالفة لشروط الخدمة للمستهلك تسبّبت في موجة حظر كبيرة؛ والنهج الصحيح هو تشغيل التطبيقات والوكلاء عبر API (الدفع حسب الاستخدام). على جانب OpenAI: التحايل على قيود الأمان، والأتمتة، وإساءة مفاتيح API، والاستخدامات غير القانونية. على جانب Anthropic: إساءة رموز OAuth، والوصول غير الرسمي، وبنود مكافحة التقطير، وjailbreak. قائمة وقاية من سبع نقاط، والتحذير فرصة للتصحيح، والمخالفات الطفيفة قابلة للاعتراض بينما الجسيمة دائمة. الخطة الصحيحة، للغرض الصحيح، بأمانة.

إعادة تدريب ذكاء اصطناعي ضخم من الصفر مكلفة للغاية، لكنك تريد تعديله ليناسبك فقط؛ يحقق LoRA (Low-Rank Adaptation) هذه الأمنية بتجميد النموذج الأصلي وتدريب جزء إضافي صغير (محوّل) فقط، مقلّصًا المعاملات القابلة للتدريب بنحو 90%. يجعل LoRA عملية fine-tuning أرخص وأسرع بكثير، وهو شائع جدًا في توليد الصور مثل Stable Diffusion بوصفه ملفًا صغيرًا يضيف شخصية أو أسلوبًا. يشرح هذا المقال الفكرة عبر تشبيه الرقعة. LoRA رائد fine-tuning كفؤ المعاملات (PEFT): اترك الأوزان الأصلية الضخمة مجمّدة، وأدرج مصفوفة إضافية صغيرة في كل طبقة، ودرّب تلك فقط (W = W0 + BA). من فوائده: معاملات أقل بنحو 90% (وعلى نطاق GPT-3 أقل بمقدار 10,000x)، وذاكرة GPU أقل (نحو 3x)، وتدريب أسرع وأرخص، ودون زمن استجابة إضافي بعد دمج المحوّل، وخطر فرط تطابق أدنى. أكبر قوته هي المحوّلات القابلة للتبديل: أبقِ أساسًا مشتركًا واحدًا وبدّل ملفات LoRA الصغيرة لكل حالة استخدام فوريًا. يلتقي كثيرون بـ LoRA أولًا في توليد الصور حيث تُشارَك LoRA الخاصة بـ Stable Diffusion التي تعلّمت شخصية أو أسلوبًا. يدمج QLoRA الـ quantization، فيدرّب LoRA فوق أساس 4-bit لذاكرة أقل بنحو 4x، مما يتيح fine-tuning نماذج ضخمة على GPU استهلاكية بفقدان دقة طفيف. ومقابل fine-tuning الكامل، يكفي LoRA لمعظم العمل.

نموذج ضخم بحجم 70B يعمل على جهاز ألعاب منزلي واحد بدل رفّ من بطاقات GPU في مركز بيانات، وما يجعل هذا ممكناً هو التكميم الذي يخفض الدقة العددية لأوزان النموذج لتقليص الحجم والذاكرة بشكل كبير. بينما ينقل تقطير النماذج المعرفة إلى نموذج أصغر منفصل، يجعل التكميم النموذج نفسه أخف. يشرح المقال الفكرة عبر تشبيه ضغط الصور: يستبدل التكميم الأوزان المخزَّنة بصيغة FP16/FP32 بأعداد صحيحة INT8 أو INT4، فيقلل البايتات لكل وزن (FP32=4، INT8=1، INT4=0.5)؛ ومثل ضغط صورة RAW إلى JPEG تضحي بقليل من الدقة مقابل تخفيف كبير، والمفاجأة هي قلة ما تتنازل عنه. على صعيد الذاكرة، يستخدم 4-bit نحو ربع FP16: ينخفض نموذج 70B من نحو 140GB إلى 35GB، ونموذج 8B بـ4-bit يصبح نحو 4.5-5GB، فيتسع في GPU متوسط بذاكرة 8GB للاستخدام المحلي (دمقرطة LLM). على صعيد الدقة، INT8 شبه خالٍ من الفقد وINT4 يتدهور أقل من 4% في مهام المعرفة العامة، لكن الفقد أوضح في الرياضيات وتوليد الشيفرة والاستدلال الصعب (يظهر كارتفاع طفيف في perplexity)، فاختر عدد البتات للمهمة. الطرق الرئيسية: GPTQ (رائد 4-bit الدقيق)، وAWQ (يحمي أهم ~1% من الأوزان، وغالباً أدق بنسبة 1-2% وأسرع)، وGGUF (صيغة llama.cpp/Ollama، من Q2_K إلى Q8_0، مزج CPU+GPU، للتشغيل المحلي)، وQLoRA (أساس 4-bit مع LoRA للضبط الدقيق على GPU استهلاكي). يختلف عن التقطير (الانتقال إلى نموذج أصغر منفصل) والضبط الدقيق (إضافة معرفة المهمة)، وتُستخدم الثلاثة عادةً مجتمعة. للبدء، شغّل نموذج GGUF بـOllama بأمر واحد، واختر Q4/Q8 حسب VRAM، وتجنّب INT4 للشيفرة أو الحساب الدقيق. معظم النماذج الرئيسية تُوزَّع مُكمَّمة سلفاً فتنزّلها وتستخدمها فقط. احتفظ بالذكاء وأسقط الوزن فقط.

الذكاء الاصطناعي الضخم وعالي الأداء ذكي لكنه ثقيل ومكلف؛ ويحل تقطير النماذج (تقطير المعرفة) ذلك بنقل معرفة نموذج معلّم كبير إلى نموذج طالب صغير، مع الحفاظ على أكثر من 95% من أداء المعلّم بعُشر الحجم وبسرعة أكبر. يشرح المقال ذلك بتشبيه المعلّم والطالب. المفتاح هو الـ soft labels: التدريب العادي يُعلّم فقط «الجواب قطة» (hard label)، بينما يمرّر التقطير توزيع الاحتمالات الكامل للمعلّم مثل «90% قطة، 8% كلب، 2% ثعلب»، حيث تحمل درجة التردد معلومات غنية؛ ويقوم معامل temperature بتليين الاحتمالات لكشف العلاقات الدقيقة (مثال واقعي: GPT-4o mini مُقطَّر من GPT-4o). الفوائد: سريع ورخيص، أصغر بنحو 10x مع الحفاظ على أكثر من 95% من الأداء، يعمل على الـ edge، وقوي في التخصص. منهجان: white-box (وصول كامل للأوزان والتمثيلات الداخلية، نقل أعمق؛ لنماذجك أو نماذج OSS) و black-box (المخرجات/استجابات API فقط؛ استخدام API شركة أخرى كمعلّم قد يخالف الشروط). ويختلف عن quantization (ضغط دقة أوزان النموذج نفسه) و fine-tuning (مواصلة تدريب نموذج موجود لمهمة) — فالتقطير ينقل المعرفة إلى نموذج صغير منفصل، والثلاثة قابلة للدمج. كان الواقع القانوني وشروط الخدمة قضية كبيرة في 2026: التقنية مشروعة، لكن لدى OpenAI و Anthropic و Mistral و xAI بنود منع تقطير منافس تحظر استخدام المخرجات لبناء نماذج منافسة. نزاع OpenAI ضد DeepSeek يُظهر أن التقييم يعتمد على شروط API مَن تنطبق، وأُفيد بأن Claude Fable 5/Mythos 5 تُقيّد الردود على الأعمال المُصنّفة كتقطير. نصائح: استخدم نماذجك أو نماذج OSS مرخّصة كمعلّم، وتحقق من بنود منع التقطير قبل استخدام API تجاري. الأرقام مقتبسة من مواد عامة وتوجيهية.

قلنا في "كيف تبني نظامًا متعدد الوكلاء" إنه يجب تجهيز القياس لكل عملية تسليم قبل إضافة الوكلاء؛ والتقنية التي تشغّل هذا القياس في الإنتاج هي AI observability. فهي تُظهر ما تفعله LLMs والوكلاء فعليًا في الإنتاج (أي نموذج وبأي prompt، وأي أدوات وعمليات بحث، وما الذي أُعيد، وكم استغرق وكلّف) حتى تتبّع رجوعًا إلى السبب. الفرق الحاسم عن مراقبة التطبيقات العادية: قد يعيد الذكاء الاصطناعي 200 OK في 50ms ومع ذلك يهلوس بثقة، فمعظم الإخفاقات إخفاقات جودة (هلوسة، استرجاع ضعيف، إجابات غير آمنة، مهام غير مكتملة) لا إخفاقات بنية تحتية. تقوم الـobservability على ثلاث ركائز: traces (طلب واحد كشجرة spans) وmetrics (زمن الاستجابة والتكلفة والـtokens) وlogs. والمعيار OpenTelemetry GenAI يلتقط الـprompts والاستجابات والـtokens واستدعاءات الأدوات بمخطط محايد قابل للتغذية في Datadog/Grafana. الفرق الأكثر خلطًا هو observability مقابل evals: الأولى تُظهر ما حدث، والثانية تقيس جودة الإجابة (الدقة وgroundedness والأمان). تنقسم المقاييس إلى تشغيلية (تكلفة، زمن استجابة، tokens) وجودة (هلوسة، groundedness الأهم لـRAG، أمان، إتمام المهمة)، مع كشف الهلوسة عبر LLM-as-a-judge ودرجات groundedness. الأدوات الرئيسية: LangSmith وLangfuse وArize Phoenix وMLflow وAgentOps وOpenTelemetry. ابدأ بالتقاط traces ثم صوّر المقاييس واربط evals قبل الإطلاق. للأنظمة متعددة الوكلاء المراقبة ضرورية لأن الإخفاقات تختبئ في سلاسل متعددة الخطوات.