لماذا يهم هذا الاختبار
غالبًا ما تكتفي فرق العمل بوضع ملف "قواعد" (rules) في المستودع (repo) وتتوقع من المساعد البرمجي المدعوم بالذكاء الاصطناعي الالتزام بتوجيهاته في كل طلب. في الواقع، قد لا يرى النموذج الملف أبدًا، أو قد يراه ولكنه يتجاهل محتواه. أظهرت تجربة حديثة مع Claude Code كلا المشكلتين؛ حيث تجاوزت الأداة بصمت ملف AGENTS.md بحجم 72 كيلوبايت، وعندما تم تغيير اسم الملف نفسه إلى CLAUDE.md، قام المساعد بتحميله مما أدى إلى زيادة عدد الرموز (tokens) في كل طلب. هذه الميزانية الإضافية من الرموز تزيد من زمن الاستجابة (latency) والتكلفة، ويمكن أن تتجاوز حدود الطلب المسموح بها للنموذج.
المطورون الذين يفترضون أن "وجود الملف" يعني "التزام النموذج بالقواعد" يخاطرون بحدوث عدم كفاءة خفية ومخرجات غير متوقعة. يفرض الاختبار المكون من ثلاث خطوات تقديم أدلة ملموسة في كل مرحلة: الإعداد (configuration)، والتحميل (loading)، والمنفعة (usefulness).
الأسئلة الثلاثة التي يجب طرحها
- الإعداد (Configured) – هل تم وضع الملف في المكان الذي يبحث فيه المساعد عنه؟ تبرمج الأدوات المختلفة المسارات أو اصطلاحات أسماء الملفات بشكل ثابت؛ وأي عدم تطابق يعني أن الملف لن يدخل أبدًا في مسار الأوامر (prompt pipeline).
- التحميل (Loaded) – هل يقدم المساعد أي دليل على استلامه للملف؟ يمكن للهاش (hash) تأكيد هوية الملف على القرص، ولكن تتبع عملية التسليم فقط (مثل سطر في السجل أو عدد الرموز) هو ما يثبت أن النموذج قد رآه بالفعل.
- المنفعة (Useful) – هل يحسن وجود الملف نتيجة المهمة؟ الملف الذي يتم تحميله ويزيد من عدد الرموز دون تغيير النتيجة يعد خسارة صافية.
إجراء الاختبار
الإجراء بسيط للغاية عن قصد حتى يمكن تكراره على أي منصة.
إنشاء قاعدة مرئية – اكتب تعليمات بسيطة وقابلة للملاحظة. على سبيل المثال: "قم بسرد ملفين بالضبط قبل التعديل". يمكن التحقق من تأثير القاعدة في استجابة المساعد.
التحقق من إصدار الأداة والنموذج – افتح جلسة جديدة، وسجل سلسلة الإصدار ومعرف النموذج. قد تغير الإصدارات المختلفة اسم الملف الذي تتعرف عليه.
تنفيذ تشغيلين التشغيل أ: استخدم اسم ملف لا تتعرف عليه الأداة (مثل AGENTS.md). التشغيل ب: استخدم اسم الملف الأصلي للأداة (مثل CLAUDE.md).
سجل ما يلي:
- الهاش المصدر للملف (لإثبات أن المحتوى على القرص لم يتغير).
- المسار الدقيق المستخدم.
- أي دليل سجله المساعد حول تحميل الملف (زيادة في عدد الرموز، رسالة صريحة مثل "loaded X.md"، إلخ).
- عدد الرموز لكل طلب.
- نتيجة المهمة (هل قام المساعد بسرد ملفين بالضبط؟).
إذا أظهر التشغيل (ب) الالتزام بالقاعدة وزاد عدد الرموز بالمقدار المتوقع، فهذا يعني أن الملف قد تم تحميله وهو مفيد أيضًا. أما إذا تم تجاهل القاعدة رغم زيادة عدد الرموز، فهذا يعني أن الملف يُقرأ ولكن تحليل الأوامر (prompt parsing) في النموذج يتجاهل التعليمات. في هذه الحالة، لن يساعد إضافة المزيد من النص إلى الملف؛ بدلاً من ذلك، انقل القاعدة إلى بوابة سياسة ثابتة (hard-coded policy gate) أو إطار اختبار (test harness).
ما تكشفه البيانات
أظهرت حالة Claude Code فجوة صارخة بين الإعداد والتحميل. كان الملف بحجم 72 كيلوبايت موجودًا، وله الهاش الصحيح، وتمت مزامنته مع المستودع، ومع ذلك لم يشر إليه المساعد أبدًا. أدى تغيير اسم الملف إلى CLAUDE.md الأصلي إلى تفعيل التحميل، ولكنه أضاف أيضًا عبئًا كبيرًا من الرموز. تستهلك كل رمز إضافي دورات حوسبة ويمكن أن يتجاوز الطلب حدود معدل الاستخدام (rate limits).
يكشف الاختبار المكون من ثلاث خطوات عن هذه التكاليف الخفية قبل أن تصبح عوائق في بيئة الإنتاج. ومن خلال رصد الفرق في عدد الرموز (token delta)، يمكن للفرق تحديد ما إذا كانت فائدة القاعدة تفوق تكلفتها.
الخلاصة
لا تفترض أبدًا أن ملف القواعد يؤدي وظيفة لمجرد وجوده في المستودع. استخدم الاختبار المكون من ثلاث خطوات — الإعداد، التحميل، وإثبات المنفعة — لتحويل هذا الافتراض إلى أدلة قابلة للقياس. عندما يثبت أن الملف ليس سوى مستهلك للرموز (token sink)، انقل المنطق من الأوامر (prompt) إلى بوابة حتمية (deterministic gate). والنتيجة هي سير عمل برمجي مدعوم بالذكاء الاصطناعي أكثر رشاقة وسرعة وقابلية للتنبؤ.