إدارة الـ sessions في Claude Code: العمل الجيّد مع context window بسعة مليون token

ثمة خيط مشترك يتكرّر حين يتحدّث الناس عن العمل مع Claude Code: الـ context window بحجم مليون token سلاح ذو حدّين. تتيح لـ Claude أن يعمل باستقلالية لمدة أطول بكثير ويتعامل مع مهام أكبر بموثوقية أعلى — لكنها تمنح الفوضى أيضًا مساحة أكبر لتتكدّس إن لم تكن مُتعمّدًا. فالمساحة الإضافية لا تُدير نفسها.

فتتكاثر الأسئلة. session واحدة في الـ terminal أم اثنتان؟ بداية جديدة مع كل prompt؟ متى تلجأ إلى compact أو rewind أو subagent — ولماذا تأتي بعض عمليات الـ compact أسوأ بكثير من غيرها؟ هنا عمقٌ أكبر مما يبدو، وكله تقريبًا يعود إلى مهارة واحدة: إدارة الـ context window خاصتك.

تمهيد في 60 ثانية: context، وcontext rot، وcompaction

الـ context window هي كل ما يستطيع النموذج رؤيته دفعة واحدة حين يكتب ردّه التالي — الـ system prompt خاصتك، والمحادثة كاملةً حتى الآن، وكل tool call ومخرجاته، وكل ملف جرت قراءته. في Claude Code، تتّسع هذه النافذة لمليون token.

استخدام تلك المساحة ليس مجانيًا. فكلما امتلأت النافذة، مال جودة النموذج إلى الانحراف — يتوزّع الانتباه عبر tokens أكثر، وتبدأ المواد الأقدم التي لم تعد ذات صلة في تشتيت الانتباه عن المهمة الحالية. هذا هو الـ context rot. وبالنسبة للنموذج بسعة 1M token، تبدأ في رؤية شيء منه عند حدود 300–400k token تقريبًا — لكن هذه منطقة مرنة تعتمد على المهمة، لا خطٌّ صارم.

الخط الصارم هو النافذة نفسها. فكلما اقتربت من نهايتها، تعيّن ضغط العمل الجاري إلى وصف أقصر كي يتمكّن من الاستمرار في نافذة جديدة. خطوة الضغط تلك هي الـ compaction — وقد تنطلق تلقائيًا، أو يمكنك تشغيلها بنفسك.

كل turn نقطة تفرّع

إليك الجزء الذي يتجاوزه معظم الناس. في اللحظة التي يُنهي فيها Claude turn، تحمل الـ context خاصتك كومة من المواد الجديدة — تعليمات، وtool calls، ومخرجاتها — ولديك خمسة خيارات حقيقية لما يأتي بعد ذلك، لا خيار واحد:

• Continue (المتابعة) — أرسل الرسالة التالية في الـ session نفسها.
• Rewind (الرجوع) (/rewind، أو نقر Esc مرتين) — اقفز رجوعًا إلى رسالة أسبق وحاول من هناك من جديد؛ وكل ما بعد تلك النقطة يسقط من الـ context.
• Clear (المسح) (/clear) — ابدأ session جديدة تمامًا، عادةً بموجز قصير خلَصته مما تعلّمته للتو.
• Compact (التلخيص) (/compact) — لخّص الـ session حتى الآن وأكمل فوق الملخّص.
• Subagent — سلّم الجزء التالي من العمل إلى agent له context نظيفة خاصة به، واسترجِع نتيجته فقط.

المتابعة هي ردّ الفعل الطبيعي. والخيارات الأربعة الأخرى موجودة تحديدًا كي تُشكّل ما في النافذة بدلًا من تركه يتراكم افتراضيًا. ومعرفة أيها تلجأ إليه هي معظم المهارة.

متى تبدأ session جديدة

النافذة الأكبر تُغيّر فعلًا ما هو ممكن — صار بإمكانك الآن أن تجعل Claude يبني تطبيقًا full-stack من الصفر في تشغيل واحد دون أن تبلغ السقف. لكن «النافذة ليست ممتلئة» ليست كـ «ينبغي أن تستمر فيها».

القاعدة العامة بسيطة: المهمة الجديدة تستحق session جديدة. فالبدء نظيفًا يمنع الـ turns الفاشلة والطرق المسدودة وقراءات الملفات غير ذات الصلة من المهمة السابقة من التسرّب إلى التالية.

المنطقة الرمادية هي العمل ذو الصلة — حيث لا يزال بعض الـ context القديم مفيدًا لكن ليس كله. لنقل إنك نفّذت feature للتو وتريد الآن كتابة docs له. يمكنك أن تبدأ من جديد، لكن عندها على Claude أن يُعيد قراءة كل الملفات التي كتبها للتو، وهو أبطأ وأكثر كلفة. وبما أن كتابة الـ documentation ليست مهمة حسّاسة للذكاء بشكل خاص، فالـ context المتبقّي يستحق الاحتفاظ به على الأرجح من أجل الكفاءة. والحكم تقريبًا هو: كم تستفيد هذه المهمة التالية من صفحة نظيفة مقابل ما هو محمّل أصلًا؟

الرجوع (rewind) أفضل من التصحيح

إن كانت هناك عادة واحدة تدل على إدارة جيّدة للـ context، فهي الرجوع (rewind).

نقر Esc مرتين (أو تشغيل /rewind) يتيح لك القفز رجوعًا إلى أي رسالة أسبق وإعادة التوجيه من هناك — والرسائل التي تلي تلك النقطة تُسقط من النافذة. هذا الجزء الأخير هو بيت القصيد.

تخيّل هذا: يقرأ Claude خمسة ملفات، ويجرّب أسلوبًا، فلا ينجح. ردّ الفعل هو أن تكتب «هذا لم ينجح، جرّب X بدلًا منه». لكن ذلك يترك المحاولة الفاشلة بأكملها قابعة في الـ context بوصفها ضوضاء. والحركة الأفضل هي أن ترجع إلى ما بعد قراءة الملفات مباشرة وتُعيد التوجيه بما تعرفه الآن:

لا تستخدم الأسلوب A — فـ module الـ foo لا يُتيح ذلك. اذهب مباشرة إلى B.
Don't use approach A — the foo module doesn't expose that. Go straight to B.

المعلومة نفسها، ونافذة أنظف بكثير. يسلك Claude المسار الأفضل دون أن يُثقل طريق مسدود انتباهه.

يمكنك أيضًا استخدام «summarize from here» لتجعل Claude يخلُص ما تعلّمه للتو إلى ملاحظة تسليم قبل أن ترجع — وهي عمليًا رسالة من نسخة Claude التي جرّبت شيئًا واصطدمت بجدار، إلى النسخة التي على وشك المحاولة من جديد.

compact مقابل clear

حالما تثقُل الـ session، لديك طريقتان لإنقاص الوزن، تبدوان متشابهتين لكنهما تتصرّفان بشكل مختلف جدًا.

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

/compact ركّز على إعادة هيكلة الـ auth، واترك debugging الـ tests
/compact focus on the auth refactor, drop the test debugging

Clear هو النسخة المتعمّدة. تكتب ما يهم — «نحن نُعيد هيكلة الـ auth middleware، والقيد هو X، والملفات المهمّة هي A وB، وقد استبعدنا الأسلوب Y» — وتبدأ نظيفًا. إنه جهد أكبر، لكن الـ context الناتجة هي بالضبط ما قرّرتَ أنت أنه ذو صلة، دون أي شيء لم تختره.

دليل تقريبي: compact حين يكون الخيط نظيفًا والاستمرارية مهمّة؛ وclear حين تبدأ فعلًا من جديد أو حين تكون الـ session قد انجرفت إلى مكان لا تريد حمله إلى الأمام.

ما الذي يصنع compact سيّئًا

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

الفخ الكلاسيكي هو أن ينطلق الـ auto-compact في نهاية session طويلة من الـ debugging — فيُلخّص التحقيق بإخلاص — ثم تكون رسالتك التالية «الآن أصلِح ذلك الـ warning الآخر الذي رأيناه في bar.ts». لكن الـ session كانت كلها عن الـ debugging، فالـ warning غير ذي الصلة سقط على الأرجح من الملخّص. التفصيل الذي احتجته تاليًا هو بالضبط التفصيل الذي رماه الـ compaction.

ما يجعل هذا شائكًا هو التوقيت: بسبب الـ context rot، يكون النموذج في أقل حالات حدّته تحديدًا حين يُطلب منه أن يُجري compact لنافذة شبه ممتلئة. والحل الذي تشتريه لك نافذة الـ 1M هو متّسع لتكون استباقيًا — تُشغّل /compact مبكرًا، بشروطك، مع ملاحظة عن وجهتك (/compact keep the bar.ts warning, we're fixing that next) بدلًا من انتظار واحد تلقائي ليُخمّن.

الـ subagents: استعارة نافذة نظيفة

الـ subagents هي إدارة الـ context في صورة بنيوية، وتتألّق حين تعرف مسبقًا أن جزءًا من العمل سيقذف كمًّا كبيرًا من المخرجات الوسيطة التي لن تحتاجها مرة أخرى أبدًا.

حين يُطلق Claude subagent (عبر الـ Agent tool)، يحصل ذلك الـ agent على context window نظيفة خاصة به. ويمكنه أن يقوم بكل العمل الفوضوي الذي يحتاجه — قراءة عشرات الملفات، وتشغيل عمليات بحث، وتدوين ملاحظات — ثم يُجمّع، فلا يعود إلى الـ session الأم سوى التقرير النهائي. أما الضوضاء الوسيطة فلا تحطّ أبدًا في نافذتك الرئيسية.

الاختبار الذي نستخدمه سؤال واحد: هل سأحتاج مخرجات هذا الـ tool مرة أخرى، أم الخلاصة فقط؟ إن كانت الخلاصة فقط، فذلك subagent.

سيلجأ Claude Code إلى الـ subagents من تلقاء نفسه، لكن كثيرًا ما يستحق الطلب صراحةً:

أطلِق subagent للتحقّق من نتيجة هذا العمل مقابل ملف الـ spec التالي.
Spin up a subagent to verify the result of this work against the following spec file.

أطلِق subagent ليقرأ هذا الـ codebase الآخر ويُلخّص كيف نفّذ flow الـ
auth — ثم نفّذه بالطريقة نفسها هنا.
Spin off a subagent to read through this other codebase and summarize how it
implemented the auth flow — then implement it the same way here.

أطلِق subagent لكتابة الـ docs لهذا الـ feature بناءً على تغييرات git خاصتي.
Spin off a subagent to write the docs for this feature based on my git changes.

الصورة الأكبر

تراجع خطوة إلى الوراء يتّضح النمط: في كل مرة يُنهي فيها Claude turn وتكون على وشك الكتابة، تكون عند نقطة قرار — ليس فقط ماذا تقول، بل أين تقوله. continue، أو rewind، أو clear، أو compact، أو التفويض. ومعظم تجربتك مع Claude Code يُشكّلها مدى إتقانك للعمل عند ذلك المفترق.

مع الوقت، توقّع أن يتولّى Claude المزيد من هذا نيابةً عنك. أما الآن، فهو من أكثر الروافع مباشرةً التي تملكها على جودة ما يعود إليك. جرّب أرخص عادة أولًا: في المرة القادمة التي يفشل فيها أسلوب، ارجع (rewind) إلى ما قبل أن يُخطئ بدلًا من التصحيح فوقه — ولاحظ كم تكون المحاولة الثانية أكثر حدّة. وإن أردت المفهوم الكامن وراء كل هذا، فدليلنا حول الـ context engineering هو القطعة الرفيقة.