# كيف تمنع جلسات البرمجة الطويلة من فقدان السياق؟ > امنع فقدان السياق بنقل الحقائق الدائمة من الدردشة إلى سجل مهام موجز وسجل قرارات وسجل اختبارات ونقاط تحقق في المستودع. أعد تحميل هذه المواد قبل ضغط السياق أو تبديل النموذج. تفشل الجلسات الطويلة عادة بالانحراف التدريجي لا بفقدان مفاجئ للذاكرة. يتذكر الوكيل الهدف العام لكنه ينسى قيدًا صغيرًا، أو يثق بنتيجة اختبار قديمة، أو يكرر التحقيق، أو يعدّل وفق خطة لم تعد تطابق repository. العلاج هو حالة خارجية دائمة أقصر وأكثر موثوقية من نص المحادثة. تعامل مع المحادثة كذاكرة عمل ومع repository كمصدر للحقيقة. عند كل نقطة تحقق مهمة، دوّن ما تغيّر وما تم التحقق منه وما بقي غير مؤكد وما يجب فعله بعد ذلك. ## تتبع أربعة أنواع من السياق افصل الحقائق بحسب وظيفتها كي لا يتحول الملخص إلى قصة غير منظمة. | نوع السياق | أمثلة | مكان الحفظ الدائم | |---|---|---| | الهدف | نتيجة المستخدم ومعايير القبول | سجل المهمة | | القيود | التوافق والأمان والأسلوب والنطاق | سجل المهمة | | حالة repository | الملفات المعدلة والفرع الحالي | Version control | | الأدلة | الاختبارات والسجلات والصور والمعايير | سجل التحقق | أضف الافتراضات كنوع خامس فقط عندما تكون معلّمة بوضوح. أرفق بكل افتراض أقل إجراء تكلفة لتأكيده أو رفضه. ## حافظ على سجل مهمة موجز السجل المفيد يتسع في شاشة واحدة. حدّثه بعد المراحل المهمة، لا بعد كل رسالة. ```md Objective: Ship model-switch support without changing existing tool behavior. Constraints: * Preserve the public API. * No destructive migration. Current state: * Parser adapter added in src/stream.ts. * Unit tests pass; cancellation test still fails. Decisions: * Buffer tool arguments until the final event. Evidence: * npm test: 142 passed, 1 failed. Next action: Fix duplicate execution after stream cancellation. ``` احتفظ بالمسارات والأوامر وأسماء الأخطاء الدقيقة. لا تحوّل السجل إلى يوميات لنقاش العمل. ## أنشئ نقاط تحقق حول حالة متحقق منها يجب أن تتبع نقطة التحقق نتيجة تستطيع الجلسة التالية إعادة إنتاجها، مثل مجموعة اختبارات ناجحة أو تغيير صغير محفوظ أو استجابة API مؤكدة أو قرار تصميم مدعوم بـ fixture. سجّل الملفات المعدلة قبل تبديل النموذج أو ضغط السياق. لا تقل إن الميزة تعمل لمجرد كتابة الكود؛ اربط الادعاء باختبار أو build أو artefact قابل للملاحظة. | الادعاء | الدليل المطلوب | |---|---| | يدعم parser استدعاءين | Fixture بمعرّفي call ID مرتبطين | | Retry آمن | اختبار idempotency عند الانقطاع | | يحافظ refactor على السلوك | نجاح الحزم القديمة والجديدة | | الواجهة صحيحة | فحص render بالأحجام المستهدفة | ## استرجع المصدر بدل إعادة الدردشة عندما تكون التفاصيل مهمة، افتح الملف أو المخطط أو الوثيقة الرسمية الحالية. قد يصف نص الدردشة القديم كودًا تغيّر بالفعل. أعط الوكيل المسارات وعبارات البحث كي يفحص الحالة الأحدث. يجب أن يكون retrieval محدودًا. حمّل الواجهة والتنفيذ والاختبار الفاشل والسجل المرتبط قبل repository كامل، حتى يبقى مجال للتفكير. ## اضغط مع الحفاظ على القرارات والأدلة يزيل الضغط الجيد تكرار المحادثة لكنه يحفظ القيود والقرارات الصعبة الرجوع والبدائل المرفوضة والتحقق. افصل بين `verified` و`observed` و`assumed` و`pending`. لا تلخص تجربة فاشلة كأنها التصميم النهائي. احتفظ بسبب رفض الخيار إذا كان قد يبدو جذابًا مرة أخرى. ## قيّد مخرجات الأدوات قبل دخول السياق تستهلك السجلات الطويلة والملفات المولدة الانتباه بسرعة. اطلب النطاقات أو الأعداد أو الأسطر المطابقة فقط. احفظ المخرجات الكاملة كـ artefact وأعد ملخصًا قصيرًا مع المسار. في فشل الاختبار، احتفظ بأول stack trace مفيد والـ assertion الفاشل وبيانات البيئة. تجنب إرسال مئات الإطارات المتكررة إلى النموذج. ## استأنف بطقس حتمي بعد التوقف أو ضغط السياق أو تبديل النموذج: * اقرأ الهدف والقيود. * افحص حالة version control والتغييرات الأخيرة. * افتح الملفات المذكورة في الحالة الحالية. * أعد تشغيل آخر فحص ذي صلة. * تأكد من أن الإجراء التالي المسجل ما زال صالحًا. يكشف هذا الطقس الملخصات القديمة قبل أن تسبب تعديلات جديدة. ## اختر النماذج من دون الاعتماد على ذاكرة المحادثة يسهّل gateway تبديل النموذج، لكن الحالة تبقى مسؤوليتك. يقدم Atlas Cloud عدة بروتوكولات LLM على Base URL واحد؛ افحص [مصفوفة البروتوكولات](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) و[كتالوج النماذج](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) الحالي قبل نقل وكيل يعمل. امنح النموذج البديل سجل المهمة وملفات المصدر ذات الصلة ونتيجة تحقق جديدة. لا تعتمد على state handles خاصة بالمزود ما لم يتأكد البروتوكول والسلوك نفسيهما. ## الخلاصة تحافظ جلسة البرمجة الطويلة على السياق عندما تكون الحالة الدائمة موجزة ومدعومة بالأدلة وسهلة إعادة التحميل. حافظ على سجل من شاشة واحدة، وأنشئ نقاط تحقق عند التغييرات المتحقق منها، واسترجع المصدر الحالي بدل إعادة الدردشة، وقيّد مخرجات الأدوات، واستخدم طقس استئناف حتميًا. تساعد نافذة سياق كبيرة، لكن الحالة الخارجية المنضبطة هي ما يجعل العمل قابلًا للاستعادة. ## FAQ ### هل تكفي نافذة سياق أكبر لجلسة برمجة طويلة؟ لا. المساحة الأكبر تؤخر الضغط فقط، ولا تضمن بقاء القيود القديمة بارزة أو تصحيح الملاحظات التي أصبحت قديمة. ### ما الذي يجب أن يتضمنه سجل جلسة البرمجة؟ سجّل الهدف والقيود والخطة الحالية والملفات المعدّلة والقرارات الأساسية ونتائج التحقق والمخاطر المفتوحة والإجراء التالي بدقة. ### كم مرة يجب على الوكيل إنشاء نقطة تحقق؟ بعد تغيير مهم في الحالة، مثل نجاح مجموعة اختبارات أو إكمال خطوة انتقال أو اتخاذ قرار تصميم أو اكتشاف يغيّر الخطة. ### هل يجب لصق النص الكامل للمحادثة في نموذج جديد؟ غالبًا لا. قدّم نقطة تحقق منتقاة وملفات المصدر والسجلات ذات الصلة، ثم دع النموذج يفحص الحالة الحالية للمستودع. ### كيف أمنع الملخص من الاحتفاظ بخطأ قديم؟ افصل الحقائق المتحقق منها عن الافتراضات، واربط الأدلة مثل الأوامر أو مواقع الملفات، واسحب الادعاءات عندما تنقضها اختبارات جديدة. ### ما الطريقة الأكثر أمانًا للاستئناف بعد انقطاع؟ أعد تحميل سجل المهمة، وافحص حالة version control، وأعد تشغيل آخر تحقق ذي صلة، ثم ابدأ من الإجراء التالي المسجل.