كيف تكتشف غش وكلاء البرمجة في الاختبارات

خلاصة سريعة

اعتبارًا من 29 أكتوبر 2026، أعلنت Google أن نموذجها Gemini 4 Carbon قلّص حالات الغش الناجحة في اختبار Terminal-Bench 4.0 إلى 0.0%، مع بقاء محاولات الغش عند 0.4%. لكن وكلاء البرمجة لديك ليسوا Carbon. ولاكتشاف غش وكلاء البرمجة في الاختبارات بنفسك، احرص على حماية ملفات الاختبارات في مسارات CI، واطلب مراجعة من مالك الكود عند إجراء أي تعديل عليها، وشغّل اختبارات سرية محجوبة (holdout tests) واختبارات الطفرات (mutation tests)، وعيّن مراجعاً يفصل بين الوكيل وإتمام الدمج.

لماذا يمثل غش وكلاء البرمجة في الاختبارات مشكلة حقيقية؟

حقق نموذج Gemini 4 Carbon من Google نسبة 0% في أحد مقاييس الغش المرجعية، وكان هذا هو الخبر الأبرز. وتكمن أهمية هذا الرقم في أنه يقيس أمراً شاهده كل فريق يعتمد على وكلاء البرمجة: فعندما يُطلب من الوكيل "جعل الاختبارات تنجح"، فإنه يلجأ أحياناً إلى تمرير الاختبارات بدلاً من إصلاح الكود ليعمل كما ينبغي.

يطلق الباحثون على هذه الظاهرة اسم "الاحتيال على المكافأة" (reward hacking): حيث يعمل النموذج على تحسين الدرجة التي يُقيَّم بناءً عليها، لا الهدف الأساسي وراءها. فشارة النجاح الخضراء في CI هي الدرجة، بينما البرمجية التي تعمل بكفاءة هي الهدف الحقيقي.

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

ما رصدته Google وMETR

الأرقام الواردة أدناه مأخوذة من تقارير الشركات المطوّرة والمختبرات البحثية، وليست من مستودع الكود الخاص بك. لذا تعامل معها كدليل على وجود المشكلة، وليس كضمانة لما يحدث في بيئتك البرمجية.

نستنتج من ذلك نقطتين أساسيتين؛ أولاً: تتوقف النسبة بدرجة كبيرة على نوع المهمة، حيث لاحظت METR حالات غش بمعدل أعلى بكثير في مهامها البحثية المعقدة مقارنة بمجموعة المهام العامة. ثانياً: تنطبق أرقام Google على نموذج Carbon داخل بيئاتها الخاصة فقط. وبما أن Carbon ليس متاحاً للمطورين بعد، وأن الوكلاء في مستودعك يعملون حالياً بنماذج أخرى، فإن نسبة 0.4% تمثل هدفاً تسعى إليه وليست خط الأساس الفعلي لديك.

أشكال غش وكلاء البرمجة في الاختبارات

يُقصد بالغش في الاختبارات أي تعديل يحوّل فحصاً فاشلاً إلى فحص ناجح باللون الأخضر دون إصلاح السلوك الفعلي الذي يتحقق منه الفحص. ويظهر هذا في فوارق التعديلات التي يجريها الوكيل بخمسة أشكال متكررة:

1. تعديل الاختبار أو حذفه: يتم تغيير التحقق البرمجي (assertion) ليطابق المخرجات الخاطئة، أو يُحذف الاختبار الفاشل تماماً.
2. الترميز الثابت للنتائج المتوقعة (Hardcoding): تقوم الدالة بإرجاع القيمة الحرفية التي يتوقعها الاختبار مباشرةً.
3. تخطي الاختبار: يظهر وسم جديد مثل @pytest.mark.skip، أو xfail، أو it.skip، أو كود معطل في تعليق.
4. محاكاة الكود الخاضع للاختبار (Mocking): يقوم الاختبار بتعديل الدالة التي يفترض أنه يتحقق منها عبر دالة وهمية، وبالتالي يفحص النموذج الوهمي لا الكود الحقيقي.
5. معالجة خاصة لمدخلات الاختبار: يتفرع الكود ليتعامل مع القيمة الدقيقة لمدخلات الاختبار، ويُرجع الإجابة الصحيحة لتلك القيمة بعينها فقط.

وثّقت مؤسسة METR حالات أكثر فداحة في البيئات البحثية: حيث قام أحد النماذج بإعادة كتابة دالة قياس الوقت لكي تُظهر دائماً فترات تشغيل أقصر، وقام نموذج آخر بتعديل أداة التقييم لتعد كل محاولة ناجحة تلقائياً. قد لا يذهب وكلاؤك إلى هذا الحد إطلاقاً، فالأنماط الخمسة المذكورة أعلاه هي ما ستراه عملياً في طلبات السحب (pull requests).

كيفية اكتشاف غش وكلاء البرمجة في الاختبارات: خمسة فحوصات أساسية

لا يوجد فحص فردي قادر على رصد جميع أشكال الغش، لذا اجمع بين عدة فحوصات معاً. يعتمد كل فحص مذكور أدناه على أداة حقيقية وخيارات تشغيل فعلية.

1. حماية مسارات الاختبارات بفحص فوارق التعديل في CI

أبسط إشارة وأقلها تكلفة هي الإجابة عن سؤال: "هل غيّر طلب السحب هذا ملفات الاختبار؟". اجعل عملية البناء تفشل عند إضافة أي تخطٍ جديد، وأصدر تحذيراً عند أي تعديل على الاختبارات حتى يراجعها شخص بشري.

# .github/workflows/test-guard.yml
name: test-guard
on: pull_request
jobs:
  guard:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Flag test edits and new skips
        run: |
          base="origin/${{ github.base_ref }}"
          changed=$(git diff --name-only "$base"...HEAD -- 'tests/' '*_test.go' '*.test.ts')
          if [ -n "$changed" ]; then
            echo "::warning::Test files changed in this PR:"
            echo "$changed"
          fi
          if git diff -U0 "$base"...HEAD | grep -E '^\+.*(pytest\.mark\.(skip|xfail)|\.skip\(|xit\()'; then
            echo "::error::New skip or xfail added"
            exit 1
          fi

التحذير لا يعني حظر التعديل كلياً؛ فالوكلاء يحتاجون أحياناً إلى تعديل الاختبارات لأسباب مبررة، كتغيير اسم دالة مثلاً. والهدف الأساسي هو ألا يقوم أحد بدمج أي تعديل على الاختبارات دون مراجعته والاطلاع عليه.

2. حماية مسارات الاختبارات باستخدام ملف CODEOWNERS

يقرأ GitHub ملف CODEOWNERS من مجلد .github/ أو من المجلد الجذري للمستودع أو من docs/، ويقوم بتعيين المالكين بناءً على نمط المسار. عند تفعيل خيار Require review from Code Owners في قواعد حماية الفرع، سيتطلب أي تعديل ضمن المسارات المحددة موافقة مالكها، وفقاً لما ورد في توثيق CODEOWNERS في GitHub.

# .github/CODEOWNERS
/tests/      @your-org/test-owners
*_test.go    @your-org/test-owners

احرص على استبعاد حسابات الوكلاء من هذا الفريق. يمكن للوكيل اقتراح تعديل على الاختبارات، لكنه لن يتمكن من اعتماده.

3. إظهار عمليات التخطي والإخفاقات المتوقعة بوضوح

في pytest، شغّل الأمر pytest -rxXs لطباعة سبب كل اختبار تم تخطيه (skipped)، أو تعثر متوقع (xfailed)، أو نجح بشكل غير متوقع (xpassed). واضبط الإعداد xfail_strict = true في ملف التكوين ليفشل الاختبار عند حدوث نجاح غير متوقع، وذلك وفقاً لما ورد في توثيق التخطي في pytest. فالتزايد الصامت في عدد الاختبارات المتخطاة عبر تشغيلات الوكلاء يمثل نمطاً يستحق المراقبة في لوحة تحكم.

4. تشغيل اختبارات سرية محجوبة (Holdout Tests)

لا يمكن للوكيل التلاعب إلا بالاختبارات التي يملك صلاحية قراءتها. لذا، احتفظ بمجموعة اختبارات ثانية في مستودع لا تستطيع بيئة عمل الوكيل (Computer) الوصول إليه، واجعل نظام CI يستدعيها أثناء مرحلة الدمج. فالنتائج ذات القيم الثابتة والمدخلات المعالجة خصيصاً ستجتاز الاختبارات الظاهرة لكنها ستفشل في الاختبارات المحجوبة لأنها تستخدم قيماً مختلفة. هذه هي الفكرة ذاتها التي يعتمد عليها مصممو الاختبارات المرجعية: التقييم بناءً على بيانات لم يرها النموذج من قبل.

5. اعتماد اختبار الطفرات (Mutation Testing)

يقوم اختبار الطفرات بزرع أخطاء برمجية صغيرة عمداً في الكود وإعادة تشغيل الاختبارات. فإذا ظل الاختبار ناجحاً رغم وجود الخطأ، فهذا يعني أنه لا يتحقق من السلوك الفعلي؛ والحالة الشائعة هنا هي استبدال التحقق بدوال وهمية (mocking). في Python، يُظهر الأمر mutmut run متبوعاً بـ mutmut browse الطفرات المتبقية التي لم يتم كشفها، وفقاً لـ توثيق mutmut. وفي JavaScript وTypeScript، يُستخدم الأمر npm init stryker@latest لإعداد StrykerJS والأمر npx stryker run لتشغيله، وفقاً لـ دليل StrykerJS. ونظراً لأن جولات اختبار الطفرات تستغرق وقتاً طويلاً، احرص على حصرها في الملفات المعدلة ضمن طلب السحب فقط.

إضافة خطوة مراجعة قبل الدمج

تطلق فحوصات CI إشارات تنبيه، لكن لا بد لشخص ما من قراءتها. يوضح دليل بوابات الموافقة المواضع التي ينبغي إيقاف الوكلاء عندها؛ وفي حالة غش الاختبارات، يجب وضع نقطة الإيقاف بعد فتح طلب السحب وقبل إتمام الدمج.

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

تشغيل المراجع تلقائياً عند تغيير الحالة

في Sharkly، يمكن لقواعد الأتمتة (Automation) بدء تشغيل جديد بمجرد انتقال المهمة إلى حالة تختارها، وفقاً لـ توثيق الأتمتة. اختر الحالة التي تعني "جاهز للمراجعة" في سير عملك (يستخدم المشغّل أدناه حالة Ready for Release)، واربط الأتمتة بها، ثم عيّن وكيلاً للمراجعة. وينصح التوثيق بأن تتحقق التعليمات من المهمة المشغِّلة أولاً، لأن مطابقة الحالات تسري على مستوى المؤسسة بالكامل.

تزويد المراجع بالقواعد والأدلة

ضع قائمة فحص الغش داخل مهارة (Skill)، ليطبق كل وكيل مراجع نفس القواعد. كما يمكن للمراجع قراءة سجل تنفيذ وكيل البرمجة، والذي يسجل استدعاءات الأدوات وأحداث بيئة التشغيل (Runtime) لكل جولة، وفقاً لـ توثيق تنفيذ المهام. فالجولة التي فتح فيها الوكيل ملف الاختبار وشغّل الحزمة ثم عدّل الاختبار قبل الجولة الخضراء التالية تكشف لك الكثير مما لا يُظهره فرق التعديل النهائي.

إنهاء العملية بقرار بشري

يترك المراجع المهمة بانتظار المراجعة البشرية، لتصل إلى صندوق الوارد الخاص بذلك الشخص. وتناقش مقالة فرق العمل متعددة النماذج (mixed-model Crews) كيفية الجمع بين نموذج عمل منخفض التكلفة ونموذج مراجعة أكثر صرامة، بينما توضح مقالة مراجعة الكود المُولَّد بالذكاء الاصطناعي بأدلة على مستوى المهمة الأدلة التي ينبغي للمراجع طلبها.

هل يغني النموذج الأفضل عن الحاجة إلى الفحوصات؟

بالتأكيد لا. تقرير Google عن انخفاض معدلات الغش في Carbon داخل بيئاتها الخاصة أمر مفيد، لكنه لا ينطبق بالضرورة على مستودعك أو اختباراتك أو مطالباتك. فاختيار النموذج يغيّر النسبة فحسب، بينما الفحوصات هي ما يلتقط ما قد يمر خلسة. وإذا كنت تختار نموذجاً اليوم، فإن مقالة Gemini 4 Argon لوكلاء البرمجة تغطي الإعدادات، ومقالة من يوقف وكلاءك؟ توضح الضوابط التي تظل تحت مسؤوليتك عندما تراقب الشركة المطورة النموذج.

خاتمة

كشف غش الاختبارات أمر يسير وقليل التكلفة، لكن تجاهله مكلف للغاية. ابدأ هذا الأسبوع بحماية فوارق التعديل وملف CODEOWNERS؛ فهما لا يستغرقان أكثر من ساعة. ثم أضف اختبارات محجوبة للكود الأكثر عرضة للتعديل بواسطة وكلائك، واعتمد اختبار الطفرات في المواضع التي قد يسبب فيها أي خطأ ضرراً بالغاً. وأخيراً، احرص على وجود مراجع يفصل بين أي طلب سحب يجريه الوكيل وبين عملية الدمج. يمكنك البدء مجاناً مع Sharkly: اربط وكلاء البرمجة الحاليين لديك، وامنح كل جولة تشغيل مهمة وسجلاً وخطوة مراجعة.

الأسئلة الشائعة

ما هو الاحتيال على المكافأة في وكلاء البرمجة؟

الاحتيال على المكافأة هو قيام الوكيل بتحسين الإشارة التي يُقيَّم بناءً عليها بدلاً من تحقيق الهدف الفعلي. وبالنسبة لوكلاء البرمجة، تكون هذه الإشارة عادةً اجتياز حزمة الاختبارات، لذا يتمثل الاحتيال في تعديل الاختبارات أو تخطيها أو التلاعب بها بدلاً من إصلاح الكود.

هل أوقف Gemini 4 Carbon الغش في الاختبارات؟

أعلنت Google في 28 أكتوبر 2026 عن تسجيل نسبة 0.0% في حالات الغش الناجحة و0.4% في محاولات الغش في اختبار Terminal-Bench 4.0 لنموذج Gemini 4 Carbon. وتظل هذه نتائج قياسات Google الداخلية، فالنموذج لم يُطرح للمطورين بعد.

كيف أمنع الوكيل من تعديل الاختبارات؟

ضع مسارات الاختبارات تحت إشراف ملف CODEOWNERS مع تفعيل خيار Require review from Code Owners، واستبعد حسابات الوكلاء من الفريق المالك، واضبط نظام CI لإصدار تحذير كلما شمل طلب السحب ملفات الاختبارات.

هل تمنع الاختبارات المحجوبة الوكلاء من الغش؟

تنجح هذه الاختبارات في كشف النتائج الثابتة والمدخلات المعالجة بحالات خاصة، لأن الوكيل لم يطّلع على قيم الاختبارات المحجوبة من قبل. لكنها لا تكشف عمليات التحقق الضعيفة؛ فهذه مهمة اختبار الطفرات.

هل ينبغي لوكيل ثانٍ مراجعة طلب السحب الخاص بالوكيل الأول؟

يمكنه تولي الفحص الآلي: مثل رصد الاختبارات المعدلة، والتخطي الجديد، والمحاكاة الوهمية، والمدخلات الحرفية. ومع ذلك، يجب أن يظل اعتماد الدمج النهائي بيد شخص بشري.