معظم المهارات التي يكتبها الناس كانت خاطئة: خمس نقاط تأمل بعد إعلان أنثروبيك عن منهجيتها الداخلية

المؤلف: فريق منتجات الذكاء الاصطناعي آي颖

قرأت مدونة كتبها فريق 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، أن يبحث في references عن الشرح المقابل.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مثال: في مهارة حل مشكلات الدفع، قد توجد جملة مثل:

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

هذه تنتمي إلى Instructions، لأنها خبرة. و check_payment_events() تنتمي إلى Script، لأنها تنفيذ.

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

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

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

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

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

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

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

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

الوصف يحمل وظيفة التوجيه الكاملة للمهارة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

لكن فريق Anthropic يبدو أن تنظيمهم خفيف جدًا.

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

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

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