أنثروبيك أخيرًا كشفت عن منهجية المهارات الداخلية الخاصة بهم

شاهدت مدونة كتبتها فريق Anthropic بعنوان «الدروس من بناء Claude Code: كيف نستخدم المهارات». يجب أن تكون هذه الآن أعمق ملخص عملي حول المهارة التي رأيتها حتى الآن.

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

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

لكنني بعد تجربة الأمر بنفسي، اكتشفت أن الكثير من الأحيان يكون ذلك غير ممكن على الإطلاق.

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

وفي النهاية، غالبًا ما تظهر حالة: تم تعلم الأسلوب، لكن المحتوى أصبح سطحيًا، وتضعفت القدرة على التحليل.

وحالة أخرى شائعة.

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

ثم أدركت تدريجيًا أن الكثير من الأعمال التي تتكرر بشكل متكرر، تكون أكثر ملاءمة لتكون سكربتات، بدلاً من كتابة تعليمات طويلة.

بعد قراءة مقال Anthropic، كان أكبر انطباع لي هو أن الكثيرين يستخدمون المهارات، لكنهم قد لا يفهمونها حقًا.

المهارة في جوهرها هي هندسة السياق. متى يجب أن أضع المعرفة داخل المهارة، ومتى يجب أن أجزئها إلى مراجع، ومتى أكتبها كسكربت، ومتى أستخدم "Gotchas" لفرض قيود على النموذج، هناك الكثير من الخبرة في ذلك.

فهم مبدأ عمل المهارة، عند النظر إلى المهارات الممتازة، ستكتشف أن ما تحل مشاكله ليس هو كلمات التلميح، بل هو حل لمشاكل السياق، وتراكم الخبرات، وإعادة استخدام القدرات.

إذا أردتم دراسة المهارة بعمق، أوصيك بمراجعة مقالتين:

#01 لا تكتب كلامًا فارغًا

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

داخل Anthropic، يؤكدون دائمًا أن المهارة يجب أن تركز على "Gotchas"، أي الأخطاء الشائعة التي تقع فيها.

مثلاً:

1. لا يمكن ترتيب هذا الجدول حسب created_at

2. استجابة staging برمز 200 لا تعني النجاح

3. request_id و trace_id هما نفس الشيء

لأن هذه المعلومات غالبًا ما تكون موجودة في خبرة الموظفين. لذلك، من المهم أن تتذكر جوهر المهارة.

المهارة = تدوين خبرة الحرفيين.

من خلال المهارة، يتم ترسيخ الخبرات التي كانت مبعثرة في عقول أفراد مختلفين.

#02 المهارة في الواقع هي هندسة السياق

هذه واحدة من أعمق وجهات نظر Anthropic.

المهارة ليست ملف ماركداون، بل مجلد. بالنسبة لمن يستخدم المهارة، قد يبدو هذا كلامًا غير منطقي.

لكنني خلال الأيام الماضية، تكررت في التفكير، وأدركت تدريجيًا: هم يقصدون باستخدام شكل المجلد للتعبير عن مفهوم هندسة السياق.

لنراجع مرة أخرى الهيكل النموذجي للمهارة:

skill/  ├── SKILL.md  ├── references/ (تحتوي على شرح تفصيلي، مرجع API، حدود الاستخدام)  ├── scripts/ (تحتوي على سكربتات قابلة للتنفيذ)  ├── examples/ (أمثلة)  ├── assets/ (نماذج، صور، مواد ثابتة)

عند استدعاء مهارة معينة، النموذج يقرأ أولاً ملف SKILL.md. إذا وضعنا كل المعلومات في هذا الملف، فسيؤدي ذلك إلى انفجار السياق بسرعة.

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

إذا وضعت كل هذه المحتويات في SKILL.md، فكل مرة يتم استدعاء المهارة، على Claude أن يعيد قراءتها من جديد.

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

أما طريقة Anthropic فهي مختلفة تمامًا.

ملف SKILL.md يشبه صفحة التنقل. وظيفته أن يخبر النموذج، عندما يواجه خطأ Stripe، أن يبحث في قسم المراجع عن الشرح المقابل.

عندما يحتاج إلى الرجوع إلى أمثلة سابقة، يذهب إلى قسم الأمثلة. عندما يحتاج إلى تنفيذ عملية تحقيق فعلية، يشغل السكربتات الموجودة في scripts، وعند إنشاء تقرير التصحيح النهائي، يستخدم النموذج القوالب الموجودة في assets.

هذه العملية تدريجية وتكشف تدريجيًا.

الصورة أدناه، أنصح بشدة أن يقوم الجميع بحفظها.

#03 استخدم السكربتات قدر الإمكان

لا تجعل النموذج يضيع قدراته المحدودة على السياق والاستنتاج في العمل المتكرر. دع هذه المهام تكون من مسؤولية السكربتات.

مثلاً، كثير من الناس يكتبون المهارات على النحو التالي:

1. استعلام بيانات التسجيل؛ 2. استعلام بيانات الدفع؛ 3. حساب معدل التحويل؛ 4. تحليل أسباب الشذوذ.

هذا الأسلوب لا بأس به، والنموذج يمكن أن ينفذه. لكن في كل مرة يتم فيها التنفيذ، عليه أن يعيد تنفيذ كامل عملية التحليل من البداية.

استعلام البيانات، تنظيمها، التعامل مع الحالات الحدية، كلها أعمال متكررة.

وبما أن هذه القدرات تم اختبارها مرارًا وتكرارًا، فلماذا نعيد اختراع العجلة؟ من الأفضل ببساطة توفير سكربت محدد.

وبهذه الطريقة، يكون تنفيذ المهارة أكثر دقة، ويستهلك رموز توكن أقل.

من هذا المنظور، السكربتات في المهارة هي في الواقع ترسيخ لقدرات المنظمة. كل سكربت هو خلاصة أفضل الممارسات التي تعلمتها الفرق بعد تجارب مريرة.

عند ترسيخ هذه القدرات، يمكن لClaude أن يعمل دائمًا بناءً على هذه الخبرات، بدلاً من البدء من الصفر في كل مرة.

لذا، أعتقد أكثر فأكثر أن التعليمات (Instructions) والسكربتات (Scripts) في المهارة تعالج مشكلتين مختلفتين.

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

مثلاً، في مهارة تصحيح أخطاء الدفع، قد توجد جملة مثل:

"إذا أعاد Stripe رمز 200، لا تعتبر الدفع ناجحًا مباشرة، بل تحقق من جدول payment_events."

هذه تعتبر تعليمات، لأنها خبرة. أما check_payment_events() فهي سكربت، لأنها تنفيذ.

لو كانت هناك فقط سكربتات، فالنموذج يعرف كيف يتحقق، لكنه قد لا يفهم لماذا.

ولو كانت هناك فقط تعليمات، فالنموذج يعرف ما يجب أن يفعل، لكنه قد يضطر لإعادة التنفيذ في كل مرة. كلاهما ضروري.

#04 الوصف يشبه قواعد التوجيه

الطريقة التي يكتب بها الكثيرون وصف المهارة غالبًا خاطئة من الأساس.

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

لكن المشكلة أن النموذج لا يبحث عن المهارة بناءً على الوظائف، عند تشغيل Claude Code، يبدأ بمسح أسماء ووصف المهارات.

ثم يقرر، بناءً على المشكلة الحالية للمستخدم، أي مهارة يجب تحميلها.

لذا، أهم المعلومات في الوصف ليست ما يمكن أن تفعله المهارة، بل متى يجب أن يتم تحميلها.

الوصف في الواقع مسؤول عن توجيه مسار المهارة.

في العالم الحقيقي، نادرًا ما يقول أحد: ساعدني في استدعاء أداة إدارة PR. بل الأكثر شيوعًا أن يقول: راقب لي هذا PR، أو أن هناك مشكلة في CI.

لذا، يجب أن يصف الوصف بشكل جيد نية المستخدم، بدلاً من سرد الوظائف.

وأعتقد أنه يمكن استخدام طريقة بسيطة جدًا للتحقق.

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

إذا لم يستطع، فغالبًا يحتاج إلى تعديل.

#05 إدارة وتوزيع المهارات

هناك أيضًا موضوع إدارة المهارات.

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

عندما تتجاوز المهارات العشرات أو المئات، كيف يتم إدارتها؟ كيف يتم تحديثها؟ كيف يتم توزيعها على أعضاء الفريق؟

تجربة Anthropic في هذا المجال، أجدها جديرة بالاهتمام.

عندما يكون حجم الفريق صغيرًا، تتبع المهارات مستودع الكود. توضع في مجلد .claude/skills داخل المشروع. الجميع يشارك نفس مجموعة المهارات، ونفس طريقة العمل.

لكن مع تزايد عدد المهارات، تظهر مشكلة جديدة.

عند تشغيل Claude Code، يمر عبر جميع أسماء ووصف المهارات، ثم يقرر أي مهارة يجب استدعاؤها للمهمة الحالية. وكلما زاد عدد المهارات، زادت تكلفة التوجيه.

وهذا هو السبب في أن Anthropic بدأوا في بناء سوق (Marketplace). لكن الأهم أن طريقة إدارة السوق لديهم ذكية جدًا.

العديد من الشركات تواجه مشكلة كهذه، وتبدأ عادةً بوضع عملية اعتماد. من يكتب المهارة، يرسل طلبًا؛ بعد الموافقة، تُدرج في مكتبة المهارات الرسمية. لقد فعلنا ذلك سابقًا، لكنه كان مرهقًا جدًا، وإدارة فقط من أجل الإدارة.

لكنني لاحظت أن تنظيم Anthropic بسيط جدًا.

يتم نشر المهارات الجديدة على نطاق صغير أولاً، ويقوم الزملاء بتثبيتها واختبارها بأنفسهم.

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

لذا، هم لا يركزون على تقييم قيمة المهارة أولاً، بل يتركونها تتعرض للاختبار في الاستخدام الحقيقي. ومع زيادة الاستخدام، تدخل تلقائيًا في النظام الرسمي. والمهارات التي تبقى، هي في الغالب المهارات التي يحتاجها الفريق حقًا.