225 ألف نجمة لملف Markdown واحد: كلام كارباثي في أربع قواعد

مستودع لا يحتوي إلا على ملف Markdown واحد بلغ 225,000 نجمة. وقد كسب نحو 4,000 نجمة إضافية هذا الأسبوع. لا شيفرة فيه، ولا خطوة بناء، ولا إصدار، ولا جدول قياسات أداء — فقط أربعة مبادئ ومجموعة تعليمات حول الكيفية التي ينبغي أن يتصرف بها نموذج لغوي عندما يُطلب منه تعديل قاعدة شيفرة.

اسم الملف CLAUDE.md، وهو في مستودع يُدعى andrej-karpathy-skills ويصونه forrestchang. يضغط الملف سلسلة من الانتقادات التي وجّهها Andrej Karpathy إلى سلوك نماذج LLM في البرمجة، في صيغة يقرأها الوكيل فعلاً في مستهل كل جلسة. القيمة الأهم هنا هي عدد النجوم لا المضمون، لأنه يقول شيئاً عن الطريقة التي يُرقَّع بها سلوك الوكلاء حالياً: بصفة غير رسمية، بالنثر، وعلى يد أفراد.

الانتقادات، بكلمات كارباثي

ثلاثة اقتباسات من النص الأصلي الذي بُني عليه المستودع:

«تضع النماذج افتراضات خاطئة نيابةً عنك ثم تمضي بها دون أي تحقق. لا تدير ارتباكها، ولا تطلب توضيحاً، ولا تُظهر التعارضات، ولا تعرض المقايضات، ولا تعترض حين ينبغي لها ذلك.»

«إنها تحب تعقيد الشيفرة وواجهات API، وتضخيم التجريدات، ولا تنظّف الشيفرة الميتة… تنفّذ بناءً منتفخاً يتجاوز 1,000 سطر حيث يكفي 100.»

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

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

ماذا تقول المبادئ الأربعة فعلاً

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

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

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

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

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

التثبيت، وحقيقة أنه سطران

مسارَان، وكلاهما بديهي.

/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

أو، لكل مشروع على حدة:

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

وهناك أيضاً قاعدة Cursor محفوظة في المستودع عند .cursor/rules/karpathy-guidelines.mdc، فتنطبق الإرشادات نفسها عندما يُفتح المشروع في Cursor. برخصة MIT.

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

لماذا أظل متشككاً في هذا التأطير

ثلاثة تحفظات، بروح الملف نفسه.

المبادئ ليست اختبارات. «البساطة أولاً» تفضيل لا معيار. والوكيل الذي يقرأها سيظل ينتج حلاً من 300 سطر حيث يكفي 80، لأن النموذج لا يملك وسيلة لقياس التعقيد. والمبدأ الوحيد العامل فعلاً في الملف — التنفيذ الموجّه بالهدف — يعمل تحديداً لأنه يستبدل تفضيلاً بفحص: اختبار إما ينجح أو لا ينجح.

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

لا أحد يقيس ما إذا كانت تنفع. يسرد المستودع مؤشرات: تغييرات غير ضرورية أقل في الفوارق، وإعادات كتابة أقل، وأسئلة توضيح قبل التنفيذ لا بعده. هذه مؤشرات حقيقية وقابلة للملاحظة. لكن لا توجد مجموعة ضابطة. ثبّتت ملفاً يقول «اسأل قبل أن تفترض»، فصار الوكيل يسأل قبل أن يفترض. فهل السبب هو الملف، أم أن كتابته جعلتك تلاحظ سلوكاً كان موجوداً أصلاً؟

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

النسخة التي كنت سأكتبها فعلاً

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

قبل التعديل، اسرد الملفات التي تنوي مسّها وتوقف إذا كانت القائمة أطول مما يقتضيه الطلب. هذا يحوّل «التعديلات الجراحية» من مزاج إلى بوابة.

وقبل الانتهاء، شغّل الاختبارات وألصق المخرجات. هذا يجعل «التنفيذ الموجّه بالهدف» غير قابل للتفاوض، وهو التعليمة الأكثر أثراً التي يمكن أن تضعها أمام وكيل.

وإذا كان للمهمة أكثر من تفسير معقول، فاكتب التفسيرين واسأل أيهما المقصود. هذا يحوّل «فكّر قبل أن تكتب» من أمنية إلى دور في المحادثة.

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

لا شيء من ذلك موجود في الملف، ولا حاجة إليه. مهمة الملف أن يضع موقفاً. أما الفحوص فهي مهمة من يملك المستودع.

ما يقوله عدد النجوم حقاً

معظم أدوات الوكلاء التي صدرت هذا العام تتعلق بالقدرة: سياق أطول، وأدوات أكثر، وتنفيذ متوازٍ. هذا الملف يتعلق بضبط النفس، وقد نال من الاهتمام أكثر من معظم إعلانات القدرة.

هذه الفجوة معبّرة. فمن يدفعون ثمن هذه الأدوات خلصوا إلى أن عنق الزجاجة لم يعد ما يستطيع النموذج فعله، بل حمله على الكف عن أشياء لم يُطلب منه فعلها. وملف Markdown بـ 225,000 نجمة إشارة واضحة على نحو غير معتاد إلى موضع الإحباط الحقيقي.

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