لماذا يعيد Claude Code قراءة المشروع بالكامل وكيفية إصلاح ذلك

وثائق Ailoot: واجهة API والمفاتيح والاتصال.

لماذا يعيد Claude Code قراءة المشروع من البداية في كل مرة؟#

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

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

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

كم عدد الرموز التي يستهلكها هذا فعلًا؟#

تبدأ التكلفة قبل طلبك. يوضح ذلك قياس مستقل بسيط: يرسل Claude Code نحو 33,000 رمز من موجه النظام وأوصاف الأدوات قبل قراءة الحرف الأول من رسالتك. للمقارنة، يبدأ OpenCode بنحو 7,000.

ثم تبدأ إعادة القراءة. فكل بحث عن ملف وكل قراءة تضيف رموزًا إلى السياق. وتقول وثائق Claude Code الرسمية ذلك بوضوح: قراءة الملفات هي المكوّن الأكبر لاستخدام السياق. تحليل auth.ts الذي يحتوي على 2,400 رمز يعني أن Claude اطّلع على 2,400 رمز، وينطبق الأمر نفسه على كل ملف يفتحه أثناء الاستكشاف.

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

ما ذاكرة الشيفرة الدائمة؟#

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

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

تُوصَل هذه الخريطة عبر MCP، وهي الطريقة القياسية لإضافة أداة خارجية إلى Claude Code (تناولتُ ربط خوادم أخرى في دليل «خوادم MCP لـ Claude Code»). تضيف أداة ذاكرة الشيفرة أوامرها الخاصة للبحث في الخريطة، ويستخدمها Claude تلقائيًا عندما يحتاج إلى فهم بنية المشروع.

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

أسلوبان لذاكرة الشيفرة: ما أوجه اختلافها؟#

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

أعداد نجوم GitHub حتى 15 يوليو 2026 (وفقًا لواجهة GitHub API). الأداتان مجانيتان ومفتوحتا المصدر، وتعملان مع Claude Code، وتتصلان به كخادمي MCP.

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

متى تختار Serena أو claude-context؟#

لا تتنافس الأداتان على جائزة واحدة. فهي تتذكر أشياء مختلفة، ولذلك يعتمد الاختيار على المهمة.

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

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

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

يتطلب claude-context قاعدة بيانات متجهية خارجية، ومفتاحًا لموفر embeddings، وإصدارًا حديثًا من Node. وهو الأكثر تعقيدًا في الإعداد بين الأداتين، لذا أوصي المبتدئين بالبدء بشيء آخر.

ما الذي يمكنك فعله مباشرةً في Claude Code من دون أدوات خارجية؟#

قبل تثبيت أدوات خارجية، استفد إلى أقصى حد مما يتضمنه Claude Code بالفعل. هذه الأوامر مجانية وتعمل مباشرةً.

1. يعرض /context تحليلًا مباشرًا لما يشغل النافذة: موجه النظام وCLAUDE.md والذاكرة والأدوات والملفات. ويعرض الأمر /mcp تكلفة كل خادم متصل، بينما يعرض /memory ما تم تحميله عند بدء التشغيل.
2. يضغط /compact سجل المحادثة في ملخص قصير ويتابع المهمة نفسها. يمكنك توجيه التركيز بإضافة ما تريد الاحتفاظ به إلى /compact.
3. يتخلص /clear من سجل المحادثة بالكامل. والتوصية الرسمية هي تشغيله عند الانتقال إلى مهمة غير مرتبطة، كي لا تزاحم المحادثة القديمة الملفات التي تحتاج إليها.
4. يشخّص /doctor (المعروف أيضًا باسم /checkup، الذي طُرح في 8 يوليو 2026) الإعداد ويقترح إصلاحات: يزيل العناصر المكررة في CLAUDE.md، ويعثر على الأدوات والخوادم غير المستخدمة، ويكشف المعالجات البطيئة.

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

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

هل سيؤدي خادم MCP إضافي إلى زيادة حجم السياق؟#

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

حساب ذاكرة الشيفرة بسيط: حمل ثابت صغير لأسماء الأدوات مقابل آلاف الرموز التي يتم توفيرها لأن الوكيل لم يعد يعيد قراءة الملفات. ومن الواضح أن الميزان يميل لصالح الفهرس.

وهناك نقطتان صريحتان حتى لا تتوقع معجزات. يجب إعادة إنشاء الفهرس من حين لآخر—فالخريطة تعكس الشيفرة كما كانت وقت الفحص، وتحتاج إلى تحديث بعد التعديلات الكبيرة (يختلف ذلك بحسب الأداة: بعضها يفعل ذلك تلقائيًا، بينما يتطلب بعضها الآخر تشغيل أمر). كذلك، تصف الادعاءات الكبيرة مثل «رموز أقل بـ120 مرة» أفضل نتيجة في استعلامات مختارة، لا ما ستراه في كل مهمة. التوفير الفعلي أكثر تواضعًا، لكنه يظل ملحوظًا. إذا أردت التعمق أكثر في تجنب استنفاد الحدود عمومًا، فهناك تحليلي المنفصل «كيفية تجنب استهلاك حدود Claude Code».

من أين تبدأ اليوم؟#

إذا استبعدت كل ما لا حاجة إليه، فخطة اليوم بسيطة:

1. شغّل /doctor ونظّف ما يقترحه: العناصر المكررة في CLAUDE.md والأدوات غير المستخدمة.
2. قلّص CLAUDE.md إلى 200 سطر، وانقل المواد المرجعية إلى المهارات.

بعدها اختر وفقًا لاحتياجاتك: إذا كنت تجري كثيرًا من عمليات إعادة الهيكلة، فأضف Serena للتعديلات الدقيقة؛ وإذا احتجت إلى البحث بحسب المعنى، فأعد إعداد claude-context. ذاكرة الشيفرة والسياق المنظم يحلان المشكلة الأساسية اليوم.

إذا كنت بحاجة إلى الوصول إلى نماذج الذكاء الاصطناعي عبر Ailoot، فتفضل بزيارة Ailoot.