رأينا في الفيديو السابق أن النموذج لا ينتبه إلا لنافذة ثابتة من الـ tokens، وأن كل ما يستخدمه ليجيب يجب أن تتّسع له هذه النافذة. يتناول هذا الفيديو ما يضعه الـ harness في هذه النافذة نيابةً عنكم. سنرى ما يوجد فيها قبل أن تكتبوا شيئًا، وماذا يحدث عندما تمتلئ النافذة، ونوعَي الذاكرة اللذين ينتقلان بين الجلسات.
هذه نافذة السياق مرة أخرى، مرسومة كصندوق. يرى النموذج بالضبط ما بداخلها، ولا شيء غيره. النموذج نفسه لا يقرّر ما يدخل إليها. الـ harness هو الذي يقرّر. كل ما يعرفه النموذج عن مشروعكم وضعه الـ harness هناك، وجزء كبير من آليات الوكيل هو في الحقيقة إدارة هذه النافذة الواحدة.
أول ما يدخل، قبل أن تكتبوا كلمة واحدة، هو مجموعة تعليمات من الـ harness إلى النموذج. تقول له كيف يتصرّف، وكيف يستخدم الأدوات، وكيف ينسّق إجاباته. تُسمّى الـ system prompt. تعرض الطرفية عادةً محادثتكم، لا الـ system prompt، لكن النموذج يتلقّى كليهما.
تحتوي النافذة أيضًا على تعريفات الأدوات. كل تعريف يذكر اسم الأداة والغرض منها ووسائطها، كي يطلب النموذج استخدامها. بهذا يعرف النموذج الأدوات المتاحة له لقراءة ملف أو تشغيل أمر. إذا حذفتم التعريفات، فسيظلّ قادرًا على كتابة نص لكم، لكن لن تكون لديه أي طريقة لطلب إجراء.
ثم يحمّل الـ harness ملفات التعليمات، وهي بضعة ملفات قصيرة فيها تعليمات عن المشروع، وسنعود إليها بعد قليل. كل هذا موجود قبل أن تكتبوا أول prompt. الجلسة الجديدة لا تكون فارغة فعلًا أبدًا.
بينما يعمل الوكيل، يضيف الـ harness رسائلكم وردود النموذج ونتائج الأدوات. قد يشمل ذلك محتوى الملفات ومُخرَجات الأوامر، مختصرةً أحيانًا لتتّسع. الملفات ومُخرَجات الأدوات هي عادةً الجزء الأكبر. ملف سجلّ واحد كبير قد يشغل وحده مساحةً أكبر من كل ما حمّله الـ harness في البداية.
تذكّروا من الفيديو السابق أن المحادثة إكمالٌ لنصّها كاملًا. لذلك يرسل كل طلب النافذة كلها من جديد، من الـ system prompt حتى آخر رسالة لكم. سؤال من سطر واحد، في جلسة مفتوحة طوال اليوم، لا يزال يحمل معه هذه النافذة كلها. بعد ضغط المحادثة، يصبح جزء من سجلّ المحادثة ملخصًا بدلًا من النص الأصلي.
يمكنكم أن تنظروا إلى النافذة بأنفسكم. الأمر /context يعرض ما فيها، فئةً فئة، بالـ tokens، وكم بقي من النافذة فارغًا. في Claude Code، قد يتراوح حجم النافذة بين 200 ألف token ومليون، بحسب النموذج والإعدادات. راقبوا نسبة الاستخدام لتعرفوا كم بقي من المساحة في نافذتكم.
لملفات التعليمات سطر خاص بها، يبيّن كم تشغل من النافذة. إذا تجاهل الوكيل قاعدة ما، فتحقّقوا أولًا من أن الملف الذي يحتويها مُدرَج في القائمة. الأمر /memory يساعدكم في إيجاد الملف وتعديله. لكن حتى القاعدة المحمَّلة قد يُغفَل عنها، أو تتعارض مع تعليمات أخرى.
لنتحدّث الآن عمّا ينتقل من جلسة إلى التي تليها. الجلسة الجديدة لا تبدأ بالمحادثة السابقة كاملةً. يحمّل الـ harness التعليمات والملاحظات المحفوظة في نافذة سياق جديدة. ونميّز هنا بين نوعين من الذاكرة المحفوظة.
الأول هو ملف التعليمات. إنه ملف اسمه CLAUDE.md، يمكنكم مراجعته وتعديله. يشرح كيفية العمل في هذا المستودع: أوامر بنائه واختباره، والاصطلاحات التي يتّبعها الكود، وكيف يُنظَّم المشروع، والقواعد التي كنتم ستعيدون شرحها في بداية كل جلسة. يمكنكم وضع تعليماتكم الشخصية في مجلدكم الرئيسي، وتعليمات المشروع المشتركة في المستودع، وملاحظات المشروع المحلية في ملف تُبقونه خارج Git. يحمّل Claude Code الملفات المعنيّة معًا. أدوات CLI أخرى قائمة على الوكلاء تقرأ ملفًا مشابهًا اسمه AGENTS.md. ويقرؤه Claude Code أيضًا، إذا لم يكن في المشروع CLAUDE.md. وإذا وُجد الملفان معًا، فسطر استيراد واحد يُدخله. وسنرى كيف بعد قليل.
والثاني هو الذاكرة التلقائية: ملاحظات قد يحفظها Claude Code أثناء عملكم، مثل التصحيحات والتفضيلات، وحقائق عن المشروع يصعب استنتاجها من الكود. توجد الملاحظات داخل مجلدكم الرئيسي، في مجلد منفصل لكل مشروع، مع ملف فهرس اسمه MEMORY.md. يُحمَّل أول 200 سطر من هذا الفهرس عند بدء التشغيل، وهناك أيضًا حدّ لحجمه. ويقرأ الوكيل الملاحظات المفصّلة عند الحاجة. عندما ترون "saved two memories" في الطرفية، فقد كتب ملاحظات هناك. عند تفعيلها، تُحمَّل الذاكرة التلقائية مع ملفات التعليمات. ويمكنكم فحص النوعين كليهما وتعديلهما وحذفهما.
الصورة الذهنية هنا بسيطة: النموذج ينسى. الـ harness ينقل نوعين من الملاحظات بين الجلسات، لكن ما يجب أن يعرفه الوكيل عن مشروعكم تبقى كتابته مهمتكم، وكذلك التحقّق منه.
فكيف تُنشئون ملف تعليمات؟ أسهل طريقة هي تشغيل /init. يفحص الوكيل المستودع ويكتب مسودة تعليمات من أوامر البناء والاصطلاحات والملفات التي يجدها. راجعوا هذه المسودة، وجرّبوا الأوامر، وصحّحوا أي شيء أساء فهمه.
يجمع Claude Code التعليمات من عدة أماكن. يقرأ التعليمات الأعمّ قبل الأخصّ منها. ويجب أن تتّفق فيما بينها، لأن تحميل ملف لاحقًا لا يحلّ التعارض بشكل موثوق.
الأعمّ هو ملف مستوى المستخدم في مجلدكم الرئيسي. هذه قواعدكم الشخصية التي تنطبق على كل مشاريعكم.
يليه ملف مستوى المشروع، إما في جذر المستودع أو داخل مجلد .claude فيه. هذا الملف يُسجَّل في Git ضمن commit، فيتشاركه فريقكم كله. ووكيل كل واحد منكم يقرأ القواعد نفسها.
الملف المحلي يحتوي ملاحظاتكم الشخصية لهذا المشروع. أضيفوه إلى قائمة التجاهل في Git كي لا تدخل هذه الملاحظات في أي commit.
وهناك إضافتان مفيدتان. علامة @ متبوعة بمسار تستورد ملفًا آخر إلى تعليماتكم. هكذا يُدخل ملف CLAUDE.md ملفًا اسمه AGENTS.md: سطر واحد نصّه @AGENTS.md. الأمر /memory يفتح ملفات التعليمات للتعديل، فتستطيعون إضافة قاعدة أو إصلاحها دون مغادرة الجلسة. ويفتح أيضًا مجلد الذاكرة التلقائية.
فما الذي يجعل ملف التعليمات جيدًا؟ تذكّروا الغرض منه. إنه يشرح كيفية العمل في هذا المستودع، كي لا يضطرّ الوكيل إلى التخمين: الأوامر، والاصطلاحات، والبنية، والقواعد. لنبنِ واحدًا خطوة بخطوة. سنبدأ بعنوان بسيط يحمل اسم المشروع.
أولًا يأتي قسم البناء، وفيه الأوامر الدقيقة. وهي هنا أوامر تشغيل الاختبارات وفحص الكود بالـ linter. اجعلوا الملف قصيرًا: أقل من 200 سطر تقريبًا، كقاعدة عامة. اعتبروه ورقة مرجعية مختصرة للأوامر والقواعد الدائمة. واتركوا التوثيق المفصّل في ملفات المشروع.
ثم يأتي قسم الأسلوب. مثلًا: صرّحوا بالأنواع دائمًا، وشغّلوا mypy في الوضع الصارم. استخدموا العناوين والقوائم القصيرة لتجميع التعليمات المترابطة. هذا يسهّل عليكم صيانة الملف، ويسهّل إيجاد القواعد.
ثم يأتي قسم «لا تلمس». نذكر هنا أن مجلد migrations يُولَّد آليًا، لذلك على الوكيل ألّا يلمسه. وإليكم المبدأ الثالث: كونوا محدّدين. أعطوا أوامر دقيقة ومسارات حقيقية، لا أمنيات غامضة.
التعليمة المحدّدة تعطي الوكيل إجراءً واضحًا ينفّذه. «اكتب كودًا نظيفًا» تترك خيارات كثيرة مفتوحة. «شغّل ruff check قبل الإنهاء» تسمّي فحصًا محدّدًا. وعندها يمكنكم البحث عن نتيجته في الجلسة. اكتبوا قواعد قابلة للتحقّق. وضعها في الملف يجعلها متاحة، لكنه لا يضمن أن يتّبعها الوكيل.
لنرَ الآن ماذا يحدث عندما تمتلئ النافذة. الجلسة الطويلة تصل إلى ذلك أسرع مما تظنّون، مع ملفات كبيرة وكثير من مُخرَجات الأدوات. رأينا في الفيديو السابق أن الطلب الذي لم يعد يتّسع لا يمكن إرساله أصلًا. لذلك على الـ harness أن يُفسح مكانًا، وهو يفعل ذلك بضغط المحادثة.
ضغط المحادثة يلخّص الأجزاء القديمة منها، فيستبدل الـ harness جزءًا كبيرًا من المحادثة بملخص أقصر. وقد يُحتفَظ بالأجزاء الأحدث على حدة. يفعل Claude Code ذلك تلقائيًا عندما تقترب النافذة من حدّها، والأمر /compact يفعله عند الطلب. ويمكنكم أن تحدّدوا له ما يحتفظ به، مثلًا /compact: "focus on the auth bug".
الـ system prompt وتعريفات الأدوات تبقى متاحة. فهي منفصلة عن المحادثة التي يجري تلخيصها. ملف تعليمات المشروع يُحمَّل من جديد من القرص. والملاحظات المحفوظة وملفات المشروع تبقى متاحة، وإن كان الـ harness قد يحتاج إلى قراءتها مرة أخرى. أما التفاصيل الموجودة في المحادثة فقط، فتعتمدون فيها على ما احتفظ به الملخص.
قاعدة كُتبت في المحادثة فقط قد تضيع حين تُلخَّص المحادثة. هذا هو الفرق العملي بين سجلّ المحادثة وملف التعليمات. يمكن تحميل ملف تعليمات المشروع من جديد بعد ضغط المحادثة أو مسحها. ضعوا قواعد المشروع الدائمة هناك، كي لا تضطرّوا إلى تكرارها في كل محادثة.
لننظر الآن إلى كلفة النافذة الكبيرة. كل طلب يرسل النافذة كلها من جديد، لكن مزوِّد الخدمة يستطيع أن يعيد استخدام ما حسبه لبداية الطلب التي لم تتغيّر، وتُسمّى البادئة. هذا هو التخزين المؤقت للـ prompt: النص المكرَّر لا يزال يُرسَل، لكن لا حاجة إلى إعادة حسابه ما دامت النسخة المخزَّنة صالحة. لهذا قد تبدو الجلسة الطويلة سريعة رغم ذلك. فمعظم النافذة عولج في طلب سابق.
إذا انتهت صلاحية التخزين المؤقت أو تغيّرت البادئة، فعلى النموذج أن يعالج المدخلات غير المخزَّنة قبل أن يجيب. في نمط الـ attention الكامل الذي رأيناه سابقًا، كل موضع token يستخدم المواضع التي قبله، لذلك تعني المدخلات الأطول مقارنات أكثر بكثير. عندما تكون النافذة ممتلئة جدًا، فهذا قدر كبير من الحوسبة قبل أول token في الإجابة. وكلما كبرت المدخلات غير المخزَّنة، طالت المعالجة وزادت tokens الإدخال التي تدفعون ثمنها.
هناك كلفة ثانية، وهي تتعلّق بالجودة. تُظهر الأبحاث أن النماذج لا تستخدم النافذة الطويلة بشكل متساوٍ. في دراسة معروفة اسمها Lost in the Middle، وُضعت معلومة واحدة ذات صلة في مواضع مختلفة من سياق طويل. كان استرجاعها أفضل حين تكون قرب البداية أو النهاية، وأسوأ بوضوح حين تكون في المنتصف. ودراسة أحدث من عام 2025، شملت 18 نموذجًا، وجدت أن الأداء يصبح أقل موثوقية كلما طالت المدخلات، حتى في المهام البسيطة. كلما زاد النص في النافذة، زاد التنافس على انتباه النموذج.
أن تتّسع المدخلات في النافذة هو مجرد الشرط الأول. المدخلات الطويلة قد تكلّف أكثر في المعالجة، وقد يُغفَل عن تفاصيل ذات صلة. والعادات التالية تساعد على إبقاء السياق مفيدًا.
المحادثة القديمة غير المرتبطة بالمهمة تشغل مكانًا يمكن أن تملأه معلومات مفيدة عن المشروع.
لذا استخدموا /clear بين المهام غير المرتبطة. لا فائدة من جرّ سياق المهمة السابقة إلى مهمة جديدة، فهو لن يفعل سوى شغل المساحة.
إذا احتجتم إلى مواصلة عمل مرتبط في جلسة طويلة، فاستخدموا /compact وحدّدوا ما يجب أن يحتفظ به الملخص. وتحقّقوا من بقاء التفاصيل المهمة قبل المتابعة.
عندما تشعرون أن النافذة مزدحمة، استخدموا /context لتفحصوا ما الذي يملؤها فعلًا. يُريكم فيمَ تُستهلك المساحة، وما نسبة النافذة المستخدمة حتى الآن. هذه النسبة تساعدكم في اتخاذ القرار التالي. إذا كانت النافذة مشغولة في معظمها بالمهمة التي ما زلتم تعملون عليها، فاضغطوا المحادثة وتابعوا. وإن كان معظمها عملًا قديمًا غير مرتبط، فامسحوها وابدؤوا من جديد.
تذكّروا أن ملف التعليمات القصير يترك مكانًا أكبر للعمل الحقيقي، وهو موجود في النافذة مع كل طلب. وهذا سبب آخر لإبقائه مختصرًا.
استخدموا /clear للعمل غير المرتبط، واضغطوا المحادثة عندما تحتاجون إلى الحفاظ على خيط مهمة طويلة، وأبقوا ملف التعليمات مركّزًا على القواعد الدائمة. هذه العادات تساعد الوكيل على العمل بالسياق الذي يحتاجه.
تشغيل /context شيء عليكم أن تتذكّروا القيام به. وهناك أيضًا طريقة لإبقاء تلك النسبة أمامكم طوال الوقت. يستطيع Claude Code عرض سطر حالة تحت سطر الإدخال، وأنتم تقرّرون ما يظهر فيه. هذا هو السطر الذي أستخدمه. يعرض اسم الجلسة، الذي تحدّدونه بالأمر /rename، ثم المجلد، وفرع Git مع عدد الملفات المعدَّلة وغير المتتبَّعة، والنموذج، ومقدار ما استُخدم من نافذة السياق. هذا الرقم الأخير يصبح أصفر عند نصف النافذة، وأحمر عند ثلاثة أرباعها، فألاحظه دون أن أبحث عنه.
سطر الحالة يأتي من سكربت. يعطيه Claude Code معلومات الجلسة بصيغة JSON، منها المجلد والنموذج، واستخدام السياق. ويطبع السكربت النص الذي يظهر تحت سطر الإدخال. لاحقًا في المساق ستشغّلون عدة وكلاء في وقت واحد، كل واحد في نسخته الخاصة من المستودع، وتُسمّى worktree. اسم الـ worktree موجود في هذا الـ JSON أيضًا، ووضعه في السطر هو طريقتكم للتمييز بين الجلسات.
لا تحتاجون إلى كتابة السكربت بأنفسكم. اكتبوا /statusline، وصِفوا السطر الذي تريدونه، وسيكتب وكيل إعداد مدمج السكربت والإعداد نيابةً عنكم. هذه أول مرة في المساق تغيّرون فيها الأداة بوصف النتيجة التي تريدونها، بدلًا من تعديل ملف إعدادات يدويًا.
ماذا يحدث للمحادثة عندما تمسحون النافذة؟ في الجلسة العادية، يحفظ Claude Code المحادثة على القرص. مسح النافذة يبدأ محادثة جديدة دون حذف الجلسة المحفوظة، ودون التراجع عن تغييرات ملفات المشروع.
للعودة إلى أحدث جلسة لكم في هذا المجلد، شغّلوا claude مع --continue، أو باختصار -c. سيحمّل سجلّ المحادثة المحفوظ لتلك الجلسة. وإذا بدأتم جلسة أخرى منذ المسح، فاختاروا الجلسة السابقة من قائمة الاستئناف.
إذا أردتم جلسة أقدم، فالخيار --resume يعطيكم قائمة بجلساتكم السابقة لتختاروا منها. وإذا كنتم داخل جلسة بالفعل، فالأمر /resume ينقلكم إلى جلسة أخرى دون الخروج.
مسح النافذة الحالية وحذف جلسة محفوظة إجراءان مختلفان. يمكنكم استخدام سياق جديد لعمل جديد، والعودة إلى محادثة محفوظة عندما تحتاجونها.
لنجمع كل ذلك. الـ harness يقرّر ما يوجد في النافذة. قبل أن تكتبوا، يكون قد حمّل الـ system prompt وتعريفات الأدوات وملفات التعليمات، ثم تملأ المحادثة الباقي.
ضغط المحادثة يختصرها. والقواعد الدائمة في ملف التعليمات يمكن تحميلها من جديد، فلا تعتمد على ما قد يحتفظ به الملخص مصادفةً.
ذاكرتان تنتقلان بين الجلسات. هناك ملف التعليمات، CLAUDE.md، الذي تكتبونه أنتم، وهناك الذاكرة التلقائية، التي يكتبها Claude Code لنفسه.
الشيء الوحيد الذي يجب أن تأخذوه من هذا الفيديو هو أن النموذج ينسى، وأن إدارة ما يجب أن يتذكّره هي مهمتكم.