تقليل هدر التوكنز والتخبط العشوائي لعملاء Claude باستخدام إعدادات Fallow
makedream1 mai 2026
0
Computing/Software
Comments (0)
Log in to leave a comment
No posts yet
makedreammakedreamLog in to leave a comment
No posts yet
ستدرك سريعاً عند استخدام عملاء الذكاء الاصطناعي (AI Agents) في المستودعات البرمجية الضخمة (Monorepos) أنهم يقرأون آلاف الملفات بشكل عشوائي، مما يستنزف ميزانيتك، بينما تكون الكود البرمجي الناتج غالباً عديم الفائدة ويفتقر إلى السياق. قبل إلقاء اللوم على ذكاء العميل، علينا أولاً النظر فيما نقدمه له من بيانات. إليك طريقة محددة لاستخدام Fallow، أداة تحليل الكود القائمة على Rust، لجعل العميل يركز فقط على قراءة "الكود الخطير فعلياً".
من عدم المسؤولية إلقاء كامل قاعدة الكود للعميل. عندما تزداد المعلومات بشكل مفرط، يعاني النموذج من ظاهرة "الضياع في المنتصف" (Lost in the Middle)، حيث ينسى المحتوى الموجود في سياق الوسط. يجب استخدام ميزات الفهرسة في Fallow للحد مادياً من نطاق الاستكشاف الذي يقوم به العميل.
.fallow.json في جذر المشروع. أضف **/dist/** و **/tests/** والحزم القديمة (Legacy) إلى مصفوفة exclude. تقليل الضجيج هو الأولوية.rules حدد عتبة high-complexity عند القيمة 15 تقريباً. هذا الإجراء يجبر العميل على البدء بفحص الوحدات البرمجية ذات التعقيد الإدراكي العالي أولاً.strictBoundaries. هذا يمنع الكارثة التي تحدث عندما يتجاهل العميل حدود الحزم ويقوم بخلط الاعتمادات (Dependencies) ببعضها.بفضل هذه الإعدادات وحدها، سينخفض عدد الملفات التي يقرأها العميل بشكل حاد. في الواقع، يمكن توفير أكثر من 40% من تكاليف واجهة برمجة التطبيقات (API) بمجرد منع قراءة الملفات غير الضرورية.
لا تجعل العميل يقرأ الكود سطراً بسطر للبحث عن المشكلات؛ فهذا إهدار للمال. من الأسرع والأكثر دقة تزويده ببيانات هيكلية ملخصة تم حسابها مسبقاً بواسطة Fallow.
قم بتشغيل fallow audit --format json > audit_report.json في الجهاز الطرفي لاستخراج تقرير عن انتهاكات البنية البرمجية وتعقيد الكود. أدخل بيانات JSON هذه مباشرة في نافذة سياق Claude أو قم بالإشارة إليها في ملف CLAUDE.md. وفي موجه النظام (System Prompt)، اكتب: "قبل البدء في التعديل، يجب التحقق من نقاط verdict و complexity في التقرير، وابدأ العمل من الوحدات ذات النقاط المنخفضة".
بهذه الطريقة، لا يحتاج المطور لشرح كل التفاصيل. سيبدأ العميل مباشرة في "إجراء الجراحة" على أكثر الأجزاء تعفناً في الكود بناءً على الأولويات المرتبة بالبيانات.
التحليل الساكن (Static Analysis) وحده لا يخبرك ما إذا كان الكود يعمل فعلياً أم لا. "الكود الزومبي" الذي لا يزال يمتلك مراجع تشير إليه ولكنه لا يُستدعى أبداً هو المذنب الرئيسي في تضخم الـ Monorepo. وكما أثبت إطار عمل SCARF من Meta، فإن الجمع بين التحليل الساكن وتغطية الكود الديناميكية (Dynamic Coverage) هو السبيل الوحيد للحذف الآمن.
بعد جمع بيانات تغطية V8 (NODE_V8_COVERAGE)، قم بتشغيل ميزة runtime-sync في Fallow. ستحصل على قائمة بالدوال التي "تمتلك مراجع ساكنة ولكنها لم تُنفذ قط خلال الشهر الماضي". قدم هذه القائمة للعميل واطلب منه طلب إذن للحذف. ستسمع حينها من العميل مبرراً مثل: "هذه الدالة لم تسجل أي استدعاء منذ 6 أشهر، لذا فمن الآمن حذفها".
لا ينبغي دمج الكود الذي كتبه العميل لمجرد أنه يعمل في الوقت الحالي؛ بل يجب التأكد مما إذا كان يضر بقابلية القراءة على المدى الطويل. يحسب Fallow مؤشر قابلية الصيانة (MI) من خلال الجمع بين تعقيد Halstead وعدد المسارات المنطقية.
أضف خطوة fallow audit --base main --format json إلى GitHub Actions. اجعل عملية البناء (Build) تفشل إذا انخفضت درجة health_score عن 70 نقطة.
هذه البوابة وحدها توفر على المطورين المحترفين (Seniors) أكثر من ساعتين من وقت المراجعة أسبوعياً. فبدلاً من تنظيف الفوضى التي قد يخلفها العميل، سيكون عليك فقط مراجعة تصميم الكود عالي الجودة الذي تم التحقق منه آلياً بالفعل. في التعاون مع عملاء الذكاء الاصطناعي، يكمن الفرق في الإنتاجية في مدى حزمك في استخدام مثل هذه الأدوات الحتمية.