إصلاح التعليمات البرمجية الفوضوية التي أنشأتها وكلاء الذكاء الاصطناعي وتقليل تكاليف الرموز (Tokens)
عندما وكلت البرمجة إلى الوكيل، تضاعفت الأبعاد البرمجية إلى مليون سطر وجاءتني فاتورة الاستخدام كالقنبلة. تدور هذه المقالة حول كيفية معالجة هذا الوضع.
التخلص من قاعدة التعليمات البرمجية التالفة
يمكن مسح التعليمات البرمجية المكررة التي أنشأها الوكيل في حلقة لا نهائية خلال 30 دقيقة. كل ما تحتاجه هو استخدام knip و jscpd.
أنشئ ملف knip.json في مجلد المشروع الرئيسي وقم بتدوين نقاط الدخول. اكتب npx knip في الطرفية للعثور على الحزم الوهمية التي استخدمها الوكيل ثم تخلص منها. بعد ذلك، قم بتنفيذ npx jscpd ./src -t 1 استخراج كتل الدوال المكررة التي زادت بسبب النسخ واللصق.
يمكنك التخلص من التعليمات البرمجية غير الضرورية دفعة واحدة في مستودع أحادي (monorepo) يضم 158 ملفاً. ثم افتح biome.json وقم بتشغيل قاعدة noUnusedVariables لمنع عودة التعليمات البرمجية الميتة.
تقييد تكاليف الرموز باستخدام بيئة آمنة (Sandbox)
إذا قمت بتمرير التعليمات البرمجية بأكملها إلى الوكيل في كل مرة، فسوف تتبخر الرموز (Tokens). يجب تطبيق هيكل Repo-Map على غرار Aider لعزل الملفات التي تعمل عليها حالياً فقط.
من خلال توفير الخيار --map-tokens 1024، يمكنك خفض الرموز المستخدمة لفهم هيكل المستودع إلى أقل من 2,000 رمز حتى في المشاريع التي تحتوي على أكثر من 1,000 ملف.
لفرض حد أقصى للتكاليف، فإن LiteLLM Proxy هو الحل الأمثل. قم بتكوين litellm_config.yaml وحدد الحد الأقصى لعدد الحلقات لكل جلسة بـ 15 حلقة. إذا قمت بتعيين الحد الأقصى للتكلفة على 2.50 دولار، فسيقوم الوكيل بقطع الاتصال بمجرد تجاوز الحد.
التحكم في الوكيل باستخدام الاختبارات التصريحية
لا فائدة من كتابة مطولات باللغة الماليزية. يجب تقديم اختبارات وحدات فاشلة أولاً حتى لا يقوم الوكيل بأشياء غير عادية.
وفقاً لبحث SWE-bench Verified، عندما تم تطبيق طريقة حقن حالات اختبار الوحدة أولاً، انخفض معدل الانحدار من 6.08 بالمائة إلى 1.82 بالمائة، وارتفع معدل حل المشكلات من 24 بالمائة إلى 32 بالمائة.
أنشئ ملف اختبار فاشل أولاً ووجه الوكيل لكتابة جزء التنفيذ الذي يجتاز هذا الاختبار فقط.
يجب أيضاً أتمتة نصوص التحقق. أنشئ ملف local_verifier.sh وأدخل الأوامر npx tsc --noEmit، و npx biome check ./src، و npx vitest run بالترتيب. حتى إذا أصر الوكيل على أنه انتهى من كتابة التعليمات البرمجية، فسيتم منع الالتزام (Commit) إذا لم تكن رمز إنهاء هذا النص هو 0.
سير عمل هجين يتدخل فيه البشر مباشرة
يتم تقسيم التعليمات البرمجية التي أنشأها الوكيل إلى وحدات طلب سحب (Pull Request) ومراجعتها بشرياً.
تحقق مما إذا كان عدد الأسطر المعدلة يتجاوز 200 سطر، وما إذا كانت هناك حزم غريبة متصلة بـ package.json، وما إذا تم إخفاء الأخطاء بشكل عشوائي باستخدام @ts-ignore. إذا قمت بربط Husky بـ lint-staged، فس يتم حظره مباشرة في وقت الالتزام إذا تجاوزت التعليمات البرمجية المكررة 2 بالمائة.
عند تقسيم المهام، انتقل عبر 3 مراحل. يقوم النموذج الأعلى بتقسيم المهام وإنشاء TODO.md. بعد ذلك، يقوم نموذج ذو قيمة جيدة مقابل المال بتنفيذ كل عنصر. وأخيراً، يقوم مطور أول (Senior) بالتحقق من فروق Git. باستخدام هذا الهيكل، يمكنك توفير أكثر من 70 بالمائة من التكاليف مقارنة بالاعتماد على نموذج رائد واحد فقط.