اختبار إضافات Claude Code: من Evals إلى بوابة CI

لهذا التوقيت أهمية. فقد أضاف Claude Code 2.1.269 اختبارات تقييم الإضافات في 11 سبتمبر 2026. ومع ذلك، لا يزال أبرز شرح مؤرّخ يظهر لهذا الاستعلام يعتمد مشغّلًا مخصصًا بلغة Python. إذا كنت تدير إضافة محلية اليوم، فالمسار الأقصر بات مدمجًا في الأداة نفسها: أنشئ حالة سلوكية واحدة، وشغّلها في مقابل مجموعة ضابطة، وافحص التقرير، ثم اجعل CI يرفض تكرار الانحدار الذي أحدثته عمدًا.

ما الذي يقيسه اختبار إضافات Claude Code فعليًا؟

تقييم الإضافة هو اختبار A/B لسلوك الوكيل. تخيّل ورشتين متطابقتين تتلقيان بطاقة العمل نفسها؛ في إحداهما إضافتك مثبتة، وفي الأخرى لا توجد الإضافة. يكرر Claude Code المهمة في الورشتين، ويقيّم الناتج، ثم يعرض WITH وW/OUT وΔ، حيث تمثل الأخيرة نتيجة وجود الإضافة مطروحًا منها نتيجة غيابها.

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

افتراضيًا، تتحول الحالة الواحدة إلى ثلاث جلسات جديدة مع الإضافة وثلاث من دونها. تحصل كل جلسة على دليل منزلي ومجلد عمل وإعدادات Claude Code معزولة. ولا تنتقل إليها إعداداتك الشخصية، ولا ملف CLAUDE.md الخاص بالمشروع، ولا الإضافات الأخرى، ولا الذاكرة، ولا خوادم MCP الشخصية. يجعل هذا العزل المقارنة أنظف، لكنه يعني أيضًا أن الإضافة التي تعتمد سرًا على إعدادات حاسوبك ستفشل، وللسبب الصحيح. يوضح توثيق Anthropic لتقييم الإضافات عقد العزل والأمان كاملًا.

ابدأ بإضافة محلية تعمل بالفعل

اختبارات السلوك هي الفحص الثاني، لا الأول. يجب أن يحتوي مجلد الإضافة على plugin.json أو .claude-plugin/plugin.json أو بنية صالحة لمجلد المهارات. استخدم claude plugin validate لاكتشاف مشكلات الملفات والمخطط، واستخدم claude plugin eval للإجابة عن أسئلة من نوع: «هل اشتغلت المهارة عند تلقي طلب طبيعي، وهل أنتجت تنسيق الفريق المعتمد؟»

ستحتاج أيضًا إلى Claude Code v2.1.269 أو إصدار أحدث، وإلى بيانات المصادقة نفسها التي تستخدمها في الجلسات العادية. تُحتسب جلسات التقييم والمقيّمات القائمة على نموذج الحكم وأداة التهيئة التفاعلية من حصة خطتك أو على فاتورة API. وإذا كان إعداد Claude Code الأوسع لديك لا يزال جديدًا، فابدأ بسير العمل المحلي الأساسي قبل إضافة بوابة إصدار.

من جذر إضافة موثوقة، تحقّق من الإصدار وأنشئ حالة فارغة:

claude --version
claude plugin eval init --bare release-note

والبديل التفاعلي هو claude plugin eval init. يقرأ الإضافة، ويسألك كيف تبدو النتيجة الجيدة، ويقترح حالات ومقيّمات، ويجربها مرة واحدة، ثم يكتب الحزمة. أما مسار --bare فهو أنسب لفهم العقد، لأنه ينشئ الملفات من دون تشغيل أي شيء.

أنشئ حالة سلوكية واحدة يمكنك تفسيرها

لنفترض أن الإضافة العاملة تحتوي على مهارة اسمها release-notes. قيمتها لا تقتصر على كتابة النص؛ بل ينبغي أن تتعرف إلى طلب طبيعي بشأن تغيير في المنتج، ثم تعيد صيغة ملاحظات الإصدار التي يعتمدها الفريق بأجزائها الثلاثة: Summary وImpact وRisk.

ضع طلب المستخدم الواقعي في prompt.md. ثم أضف مقيّمًا حتميًا للناتج وآخر للآلية. والمقيّم الحتمي يعني أن CLI يفحص التتبّع أو النص مباشرة، فلا يستدعي نموذج حكم.

# evals/release-note/prompt.md
---
name: release-note
tags: [smoke]
runs: 3
max_turns: 8
timeout_seconds: 180
allowed_tools: [Skill]
---

Turn this change into a customer-facing release note: checkout now retries a failed payment once before showing an error.

# evals/release-note/graders/format.md
---
type: regex
target: last_message
pattern: 'Summary[\s\S]*Impact[\s\S]*Risk'
flags: i
---

# evals/release-note/graders/skill-fired.md
---
type: tool_used
tool: Skill
input_match: '"skill"\s*:\s*"(?:[\w-]+:)?release-notes"'
---

استبدل release-notes بقيمة name الفعلية في ملف SKILL.md الخاص بمهارتك. يتجنب الطلب عمدًا تسمية المهارة أو إملاء العناوين الثلاثة؛ وبذلك يختبر ما إذا كانت الإضافة تتعرف إلى المهمة وتضيف تنسيقها. أما إذا احتوى الطلب نفسه على كل الإجابات، فقد ينجح المسار الخالي من الإضافة، وعندها ستخبرك الدلتا بأن الإضافة لم تضف الكثير.

تتبع البيانات التمهيدية هنا المخطط الأصلي المدعوم حاليًا. في prompt.md، تبقى حقول مثل runs وmax_turns وtimeout_seconds وmodel وtags وallowed_tools في المستوى الأعلى. وإذا احتجت إلى تجهيزات اختبار أو سجل محادثة أو مجلدات، فأضف case.yaml؛ إذ يتطلب هذا الملف schema_version: "1.1" وname، وينقل حقول التنفيذ إلى execution:.

شغّل التقييم واقرأ التقرير

من جذر الإضافة، شغّل claude plugin eval .. في هذه الحالة الواحدة، يطلق الأمر ثلاث جلسات مع الإضافة وثلاث جلسات مرجعية. وتعرض أسطر التقدم نتائج المقيّمات فور انتهاء كل جلسة، ثم يقدم الملخص WITH وW/OUT وΔ وRUNS وCOST وNOTES.

اقرأها بهذا الترتيب:

1. يجيب WITH عما إذا كانت الجلسات المزودة بالإضافة قد استوفت المقيّمات.
2. يوضح W/OUT عدد المرات التي حقق فيها Claude النتيجة نفسها بمفرده.
3. تقيس Δ مساهمة الإضافة. القيمة الموجبة مفيدة، والقيمة القريبة من الصفر تستحق التحقيق، والسالبة تعني انحدارًا.
4. يقدم COST تقديرًا وفق أسعار القائمة، وليس بالضرورة المبلغ المحتسب ضمن الاشتراك.
5. يشير NOTES إلى الإخفاق الأعلى وزنًا أو إلى خطأ التشغيل في مسار الإضافة.

كل حزمة تضم حالة واحدة على الأقل تكتب aggregate-result.json وتقرير report.html مكتفيًا بذاته داخل مجلد نتائج مؤرّخ. يتيح لك تقرير HTML فتح كل تشغيل، ورؤية حكم كل مقيّم وتفسيره، ومقارنة الطلب وتعريفات المقيّمات بما فعله Claude فعليًا. أما JSON فيحمل حقول CI مستقرة، منها النتيجة الإجمالية والحالات الناجحة ومتوسط الدلتا والحالة الجزئية وتقدير التكلفة والمدة وإصدار Claude Code.

أحدث انحدارًا واحدًا قبل أن تثق بالاختبار

حان وقت إثبات أن الاختبار قادر على الفشل. استبدل مؤقتًا وصف مهارة release-notes بوصف مبهم لا يسمّي المهمة التي يفترض أن تتعرف إليها. لا تغيّر حالة التقييم. شغّل الأمر نفسه مجددًا، وافحص التقرير الجديد، ثم أعد الوصف الحقيقي.

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

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

ضع ميزانية للدورة قبل إضافة حالات أخرى

تنشئ الحالة الافتراضية الواحدة ست جلسات للوكيل. وإذا أضفت مقيّم LLM واحدًا، فستضيف الحالة نفسها ثمانية عشر تصويتًا من نموذج الحكم، بواقع ثلاثة أصوات لكل جلسة من الجلسات الست. وقد تستغرق الجلسات نفسها عدة جولات؛ لذلك يمكن لحزمة صغيرة أن تستهلك استخدامًا يفوق ما يوحي به عدد حالاتها.

استخدم ثلاث ميزانيات لثلاثة قرارات مختلفة:

الدورة ذات التشغيل الواحد صاخبة بطبيعتها. استخدمها لاكتشاف الأخطاء الواضحة، ثم أكّد النتيجة عبر عمليات التشغيل الثلاث الافتراضية قبل قبول التغيير. فضّل regex وtool_used وtool_order وfile_exists في الفحوص المتكررة لأنها لا تضيف استدعاءات لنموذج الحكم. واحتفظ بمقيّم LLM للنتائج القصيرة التي لا يمكن التعبير عن جودتها بقاعدة مستقرة.

يحتاج خيار التكلفة إلى تنبيه. يضع --max-cost-usd سقفًا لتقدير CLI وفق أسعار القائمة قبل بدء كل تشغيل. لكن عمليات التشغيل الجارية تُستكمل، لذلك قد يتجاوز التقدير النهائي السقف. وإذا بُلِغ السقف، تبقى النتائج جزئية ويخرج الأمر بالرمز 2. إنه حاجز أمان، لا محفظة مدفوعة مسبقًا.

سلّم فحص الانحدار إلى CI

بعد أن يظهر الانحدار المتعمد وتنجح الإضافة بعد استعادتها، انقل الحزمة نفسها إلى نظام التحكم في الإصدارات. يثبت مثال CI من Anthropic نماذج الوكيل والحكم، ويكتب results.json، ويستخدم حدًا أدنى قدره 0.8، ويُبقي التقرير محليًا، ويضع سقفًا للتكلفة التقديرية قدره $20. كما يمرر --trust-plugin، وهو خيار مناسب فقط عندما تكون شفرة الإضافة والحزمة المستخرجة من المستودع موثوقة إلى حد أنك تقبل تشغيلها بنفسك.

أمر التسليم الدقيق هو claude plugin eval . --trust-plugin --json results.json --threshold 0.8 --model claude-sonnet-5 --judge-model claude-haiku-4-5 --no-publish --max-cost-usd 20. ضعه في المهمة بعد تثبيت Claude Code وإجراء المصادقة، ثم أرشف ملفي النتائج.

يكفي رمز خروج الأمر لحراسة عملية البناء. يعني الخروج بالرمز 0 أن كل حالة حُمّلت وبلغت الحد الأدنى. ويشمل الرمز 1 انخفاض النتيجة عن الحد وعدة أخطاء في الإعداد. أما الرمز 2 فيعني تشغيلًا جزئيًا سببه سقف التكلفة أو رفض بيانات الاعتماد عند البداية. أرشف results.json وreport.html حتى عند الفشل، كي يعرف صاحب التغيير هل تراجعت الإضافة، أم انتهت مهلة التشغيل، أم أوقفت الميزانية العملية.

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

سبعة سلوكيات في الإضافات تستحق الاختبار أولًا

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

ابدأ بأول سلوكين سيلحظهما المستخدمون إذا اختفيا. فعشر حالات مبهمة أقل فائدة من اختبار استدعاء واحد واختبار نتيجة واحد يكشفان عيبًا يمكنك إعادة إنتاجه.

منتجان يستحقان البناء حول تقييم إضافات Claude Code

1. بوابة دلتا لطلبات السحب هي الفرصة الأقوى

ابنِ منتج CI خفيفًا يشغّل الأمر الأصلي، ويقرأ aggregate-result.json، وينشر مراجعة واحدة تتضمن تغير النتيجة والدلتا والتكلفة والمقيّم المخفق وروابط التقرير المؤرشف. فرق الإضافات ومسؤولو صيانة إضافات المتاجر يدفعون مقابل طبقة القرار، لا مقابل مقيّم آخر.

لا يزال الطلب في بدايته، لكنه واضح تجاريًا. تسجل عبارة claude code evals نحو 50 عملية بحث شهريًا في الولايات المتحدة، بنمو 600% على أساس سنوي، وتكلفة نقرة قدرها $17.61. كما توضح منصات التقييم الأوسع وجود ميزانيات للجودة؛ إذ تعرض Braintrust خطة Pro شهرية بسعر $249. هذا مؤشر مرجعي للفئة، وليس توصية بسعر منتج يغلّف أداة الإضافات.

أصغر نسخة قابلة للبيع هي GitHub Action مع تعليق على طلب السحب. تستقبل مسار الإضافة والحد الأدنى والنماذج المثبتة وسقف التكلفة التقديرية، وترفع JSON وHTML الأصليين، وتميز الرمز 1 من الخروج الجزئي بالرمز 2. لكن مخاطرة المنصة قائمة؛ فقد تضيف Anthropic تقارير طلبات السحب مباشرة. الطبقة القابلة للدفاع هي السياسات العابرة للمستودعات والمقارنات التاريخية وقواعد الموافقة، لا نسخة أجمل من التقرير الأصلي.

2. حزم تقييم منتقاة تخدم مؤلفي المهارات

يمكن بيع حزم حالات مُصانة لوظائف شائعة في الإضافات، مثل مراجعة الشفرة وكتابة سجل التغييرات وفرز الحوادث واختيار الأدوات بأمان. والحزمة ليست سوى مجلد evals/ عادي يضم طلبات واقعية إيجابية وسلبية مع مقيّمات حتمية، بحيث يستطيع الفريق تكييفه بدل اختراع معيار الجودة من الصفر.

تسجل العبارة المباشرة claude code skill evals نحو 10 عمليات بحث شهريًا في الولايات المتحدة. وهذا رقم ضئيل يجعلها إضافة مركزة، لا سوقًا مستقلة صالحة لمشروع ممول بالمخاطر. الحد الأدنى من المنتج هو حزمة ممتازة واحدة لفئة إضافات واحدة عالية القيمة، تُضبط إصداراتها وفق إصدارات Claude Code وتصاحبها إرشادات موجزة للمعايرة. والعقبة واضحة بالقدر نفسه: يقترح claude plugin eval init الحالات ويجربها أصلًا. لن تتفوق الحزم إلا إذا كانت سيناريوهات المجال ومعايير الفشل فيها أفضل من التوليد العام.

ما الذي لا يحله هذا الأمر؟

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

العزل قيد صريح آخر. يبدأ كل تشغيل من بيئة نظيفة، لذلك تغيب ملفات المشروع وإعدادات المستخدم والخطافات والخوادم الشخصية. وهذا ممتاز لقابلية إعادة الإنتاج، لكنه سيئ لحالة نسيت التصريح بتجهيزاتها. تحتاج الأدوات الخارجة عن مجموعة القراءة فقط إلى إذن صريح في سطر الأوامر. أما خوادم MCP الحقيقية التابعة للإضافة فتحتاج إلى تفعيل وأذونات إضافية، ويستحسن تشغيل الخطافات والخوادم الحقيقية في بيئة معزولة لأنها قد تعمل خارج صندوق حماية الوكيل.

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

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