aiedit يخفي أسطرًا محددة من الشيفرة عن وكيل الذكاء الاصطناعي: 5 مستويات و857 اختبارًا

لا يحجب محرر aiedit الملفات عن وكيل الذكاء الاصطناعي، بل أسطرًا محددة منها، ويفعل ذلك على مستوى الكود لا عبر طلب في الـprompt. كتب المشروع مطوّر مبتدئ يتعلم Python منذ نهاية سبتمبر 2026، بينما كتب Claude الشيفرة بتوجيه منه. والنتيجة نحو 11 ألف سطر من الشيفرة، ونحو 10 آلاف سطر من الاختبارات، و857 اختبارًا تنجح على PySide6 وعلى PyQt6 معًا. الرخصة MIT، وتُرسل إلى النماذج طلبات HTTPS عادية دون SDK، لذلك يعمل المحرر مع Anthropic وOpenAI وأي خوادم متوافقة مع OpenAI.

لماذا لا تحمي ملفات ignore

نشأت الفكرة من نقاط ضعف في الأدوات القائمة. تنص وثائق Cursor صراحةً على أن أوامر الطرفية وأدوات MCP «قد تقرأ» ملفات .cursorignore. أما Cline فقد أزال .clineignore تمامًا: فبحسب المشروع، لم يكن الملف «مصمَّمًا يومًا كمنع للوصول»، ولا يريد المؤلفون منح شعور زائف بالأمان. وإضافة إلى ذلك، تعمل هذه الملفات مع الملفات الكاملة فقط. وإذا قُسّم المشروع إلى «مسموح للذكاء الاصطناعي» و«ممنوع عليه»، يعمل الوكيل معصوب العينين. يُبقي aiedit المشروع كاملًا ويغلق مواضع محددة: كصيغة حساب السعر أو التعامل مع المدفوعات، ويرى النموذج الباقي ويعدّله.

خمسة مستويات وسلسلة من خمس حمايات

تُغلق الأسطر مباشرةً في الحقل الذي يعرض أرقام الأسطر. مستويات الوصول هي:

• hidden: لا يتلقى النموذج سوى علامة مثل <<ai-hidden:0:5 lines>>، أي يعرف أن هناك شيئًا هنا وكم عدد الأسطر؛
• interface: الأسماء والتواقيع (signatures) دون أجسام الدوال (لـPython)؛
• readonly: الشيفرة كاملة مرئية، لكن أي تعديل عليها يُرفض؛
• confirm: الشيفرة كاملة مرئية، ولا تُقبل التعديلات إلا بموافقة المؤلف؛
• explain: يشرح النموذج هذه الشيفرة.

وفوق هذه المستويات تعمل سلسلة من الفحوص:

• ليس لدى النموذج طرفية، بل أدوات المحرر فقط (القراءة والبحث والتعديل)، أما المجلدات المغلقة فلا وجود لها بالنسبة إليه؛
• يُفحص كل تعديل بواسطة diff، وإذا لمس سطرًا مغلقًا يُرفض، ولا يُكتب شيء على القرص دون موافقة؛
• تُشغَّل الاختبارات والبرنامج داخل bubblewrap على نسخة من المشروع لا تحتوي الشيفرة المغلقة فعليًا، ودون شبكة أو مجلد المستخدم الرئيسي أو مفاتيح. وحتى طباعة جميع الملفات بترميز base64 لن تكشف شيئًا؛
• يبحث مرشّح البيانات الصادرة عن المفاتيح والكلمات الواردة في قائمة والأسطر المغلقة التي أُلصقت في الدردشة، ويقترح إخفاءها أو إرسالها أو الإلغاء؛
• يسجّل سجل محلي الملفات التي أُرسلت وعدد الأسطر المخفية وعدد الأحرف المرسلة، ويمكن التراجع عن أي عمل نفّذه الذكاء الاصطناعي.

ويوجد بشكل منفصل مسار متعدد النماذج: يكتب نموذج واحد الشيفرة، ويشغّل المحرر نفسه الاختبارات في بيئة العزل، ثم يبحث نموذج من مطوّر آخر عن الأخطاء والثغرات. ولا يرى المؤلف التغييرات إلا بعد ذلك، مع النتيجة الفعلية للاختبارات، لا بعبارة «كل شيء يعمل».

كيف كسرت الحماية الشيفرة التي كتبها النموذج

يعرض المؤلف المقارنة مع Claude Code دون تجميل. في مهمة «تطبيق بسيط على Flask» كتب Claude Opus 5.5 الشيفرة في aiedit وفي Claude Code على السواء، لكن GLM 5.3 راجع التعديلات إضافةً إلى ذلك في aiedit، فجاءت النتيجة أسوأ. وكشف السجل السبب. كتب النموذج في الاختبارات "password": "secret123"، فعدّ مرشّح الأسرار ذلك كلمة مرور حقيقية، وتحوّل السطر في بيئة العزل إلى raise NotImplementedError داخل القاموس مباشرةً. لم يعد الملف شيفرة Python صالحة. من 22 تشغيلًا في بيئة العزل فشل 13، ولم يصل pytest ولو مرة إلى الاختبارات نفسها. لم يفهم النموذج السبب، وكتب ستة ملفات اختبار إضافية للالتفاف على المشكلة.

الإصلاح: تُستبدل الآن القيمة وحدها، "password": "<hidden>"، وتبقى البنية النحوية سليمة. لم يعد المؤلف التشغيل على نماذج حقيقية، وتأكد الإصلاح باختبار يعيد إنتاج الحالة. والنتائج مع النماذج المحلية متفاوتة أيضًا: لم يحافظ qwen2.5-coder 7B على صيغة استدعاء الأدوات، وتعامل إصدار 32B مع المهام البسيطة، لكنه لم ينجز مهمة متعددة الملفات في 14 خطوة.

وأثناء قراءة الشيفرة اكتُشفت ثغرتان، وأُغلقتا كلتاهما. فإذا أُعيدت تسمية ملف أو نُسخ خارج المحرر، كانت المناطق المغلقة تضيع، أما الآن فيُتعرَّف على الشيفرة المغلقة عبر تجزئات (hashes) الأسطر. أما المشروع المثبَّت في .venv الخاص به عبر pip install . فكان موجودًا هناك كاملًا، وكان بوسع أمر في بيئة العزل قراءته، ولذلك صارت هذه النسخ مخفية.

أين تنتهي الحماية وما الذي يمكن الاستفادة منه

يسرد المؤلف القيود بصراحة. يلتقط المرشّح ما يستطيع مقارنته فقط: أنماط المفاتيح والكلمات الواردة في قائمة والأسطر المغلقة الملصقة حرفيًا، أما السر المعاد صياغته فسيخرج. والتوقيع مثل calc_discount_for_client_x() في منطقة interface يكشف المعنى أصلًا. وكل ما لم يُغلق يذهب إلى مزوّد النموذج. ولا يتعرف المحرر على نسخة معدَّلة من الشيفرة المغلقة. والتجزئات في *.aimarks.json بلا salt، لذلك يمكن تخمين سطر قصير مثل rate = 0.15 بالتجريب الشامل، ولا يجوز نشر هذه الملفات في مستودع عام. وتعمل بيئة العزل بشكل كامل على Linux، وهي تجريبية على macOS ولم تُختبر على جهاز Mac حقيقي، وعلى Windows لا تعمل إلا عبر WSL.

والخلاصة العملية للفرق التي تسمح للوكلاء بدخول الشيفرة التجارية: يجب أن تقع الحماية في طبقة الأدوات لا في نص الـprompt. فحرمان الوكيل من الطرفية، وبيئة عزل بنسخة خالية من الأسرار، وفحص التعديلات بـdiff، ومرشّح للبيانات الصادرة، كلها تمنح ضمانات يمكن التحقق منها. والأثر الجانبي واضح أيضًا: كلما كان الإخفاء أشد، زاد احتمال كسر صلاحية الشيفرة، وصارت سجلات الطلبات الأداة الرئيسية لتصحيح الأخطاء. الشيفرة متاحة على GitHub وGitFlic، ويطلب المؤلف إرسال أي طرق للالتفاف على الحماية.