68 دقيقة يومياً لإعادة شرح الكود لكوبايلوت؟ هناك حل لذلك

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

تمت ترجمة هذا المنشور تلقائيًا. للنسخة الأصلية، انقر هنا.

أتعرف تلك اللحظة حين تصل جلسة Copilot الخاصة بك إلى /compact وينسى الوكيل تماماً ما كنت تفعله؟ تمضي الدقائق الخمس التالية وأنت تعيد شرح بنية الملفات، والاختبار الفاشل، والطرق الثلاث التي جرّبتها بالفعل. ثم يحدث الأمر مرة أخرى. ومرة أخرى.

قاس Desi Villanueva ذلك: 68 دقيقة يومياً — فقط في إعادة التوجيه. ليس في كتابة الكود. وليس في مراجعة PRs. فقط في إلحاق الذكاء الاصطناعي بما كان يعرفه بالفعل.

اتضح أن هناك سبباً ملموساً لهذا، وحلاً ملموساً أيضاً.

كذبة نافذة السياق

يأتي وكيلك برقم كبير على العلبة. 200 ألف رمز. يبدو هائلاً. عملياً، هو حد أعلى وليس ضماناً.

إليك الحساب الحقيقي:

200 ألف رمز من السياق الإجمالي
ناقص نحو 65 ألفاً لأدوات MCP المحمّلة عند البدء (~33%)
ناقص نحو 10 آلاف لملفات التعليمات مثل AGENTS.md أو copilot-instructions.md

هذا يترك لك تقريباً 125 ألفاً قبل أن تكتب كلمة واحدة. والأسوأ من ذلك — نماذج اللغة الكبيرة لا تتدهور بسلاسة مع امتلاء السياق. إنها تصطدم بجدار عند نحو 60% من السعة. يبدأ النموذج بفقدان أشياء ذُكرت قبل 30 دورة، ويخالف ردوداً سابقة، ويختلق أسماء ملفات كان قد ذكرها بثقة قبل 10 دقائق. وتسمّي الصناعة هذا مشكلة “lost in the middle”.

الحد الفعلي: 45 ألف رمز قبل أن تتدهور الجودة. وهذا ربما يعني 20-30 دورة فقط من الحوار النشط قبل أن يبدأ الوكيل بالابتعاد عن المسار. وهذا هو سبب وصولك إلى /compact كل 45 دقيقة — ليس لأنك ملأت 200 ألف رمز، بل لأن النموذج أصبح متدهوراً بالفعل عند 120 ألفاً.

ضريبة الدمج

كل /compact يكلفك حالة التدفق. أنت في جلسة تصحيح عميقة. السياق المشترك بُني خلال 30 دقيقة. الوكيل يعرف بنية الملفات، والاختبار الفاشل، والفرضية. ثم تأتي التحذيرات.

تجاهلها → يصبح الوكيل أضعف تدريجياً، ويبدأ باختلاق الحالة القديمة
نفّذ /compact → يحصل الوكيل على ملخص من فقرتين لتحقيق استمر 30 دقيقة

في كلتا الحالتين تخسر. في كلتا الحالتين أنت تعيد سرد مشروعك له كما لو كان موظفاً جديداً في يومه الأول.

الجزء القاسي؟ الذاكرة موجودة بالفعل. يكتب Copilot CLI كل جلسة إلى قاعدة بيانات SQLite محلية في ~/.copilot/session-store.db — كل ملف تم لمسه، كل دورة، كل نقطة تحقق. كل شيء موجود على القرص. الوكيل فقط لا يستطيع قراءته.

auto-memory: طبقة استرجاع، لا نظام ذاكرة

هذه هي الفكرة الأساسية وراء auto-memory: لا تبنِ نظام ذاكرة جديداً — ابنِ طبقة استعلام للقراءة فقط فوق النظام الموجود بالفعل.

pip install auto-memory

حوالي 1,900 سطر من Python. بلا تبعيات. يُثبّت في 30 ثانية.

بدلاً من إغراق السياق بنتائج grep، تمنح الوكيل وصولاً جراحياً إلى ما يهم فعلاً:

العملية	الرموز	ما الذي تحصل عليه
`grep -r "auth" src/`	~5,000–10,000	500 نتيجة، معظمها غير مهم
`find . -name "*.py"`	~2,000	كل ملفات Python، من دون سياق
إعادة توجيه الوكيل	~2,000	أنت تشرح ما كان ينبغي أن يعرفه
`auto-memory files --json --limit 10`	~50	الملفات العشرة التي عملت عليها أمس

هذه زيادة بمقدار 200 مرة. يتجاوز الوكيل الحفر الأثري ويذهب مباشرة إلى ما يهم.

النهج الموصى به: عندما تقترب من استخدام 50-70% من السياق، شغّل /clear ثم اكتب: “راجع الجلسات الأخيرة التي ناقشنا فيها الموضوع X”. بدلاً من حرق 12 ألف رمز في عمليات بحث عمياء، يستخرج auto-memory السياق الملائم في 50 رمزاً.

لماذا يهم هذا لمطوري .NET

إذا كنت تستخدم GitHub Copilot CLI في أعمال .NET — إعداد الخدمات، تصحيح استعلامات EF Core، التكرار على مكونات Blazor — فإن مشكلة تآكل السياق تضربك بالقدر نفسه. الحلول المعقدة ذات المشاريع المتعددة، والمكتبات المشتركة، وسلاسل الاستدعاء العميقة هي بالضبط نوع قواعد الشيفرة التي يفقد الوكيل تتبّعها أسرع من غيرها.

دليل التثبيت يشرح كيفية توجيه Copilot CLI إليه. إنها إعدادات لمرة واحدة.

بصراحة؟ استرجاع 68 دقيقة يومياً ليس مجرد تحسين بسيط لجودة الحياة. هذا يقارب 6 ساعات في الأسبوع.

خلاصة

تآكل السياق قيد معماري حقيقي، وليس خطأً سيُصلح لاحقاً. يتجاوز auto-memory هذا القيد بمنح وكيلك آلية استرجاع رخيصة ودقيقة بدلاً من إعادة استكشاف مكلفة ومضطربة. إذا كنت تقوم بتطوير جاد بمساعدة الذكاء الاصطناعي مع GitHub Copilot CLI، فهذه الإضافة تستحق 30 ثانية من التثبيت.