العنوان الأصلي: قواعد كارباتي الأربع في CLAUDE.md تقلل أخطاء كلاود من 41% إلى 11%. بعد 30 قاعدة برمجية، أضفت 8 أخرى
الكاتب الأصلي: @Mnilax
الترجمة: Peggy، BlockBeats

ملاحظة المحرر: في يناير 2026، أثار انتقاد Andrej Karpathy لطريقة كتابة Claude للرمز، مشكلة تبدو صغيرة لكنها حاسمة جدًا في سير عمل برمجة الذكاء الاصطناعي: ملف CLAUDE.md. ثم قام Forrest Chang بتنظيم هذه المشكلات في 4 قواعد سلوكية، بهدف تقييد الأخطاء الشائعة أثناء الترميز: الافتراضات الصامتة، الهندسة المفرطة، الضرر غير المقصود للكود غير المعني، وغياب معايير نجاح واضحة.

لكن بعد بضعة أشهر، لم تعد حالات استخدام Claude Code تقتصر على «دع النموذج يكتب قطعة من الكود». مع ظهور وكلاء متعدد الخطوات، سلاسل hook، تحميل المهارات، والتعاون عبر مستودعات الكود، بدأت أنماط فشل جديدة تظهر: فقدان السيطرة في المهام الطويلة، اجتياز الاختبارات دون التحقق من المنطق الحقيقي، تخطي الأخطاء بشكل صامت بعد الانتهاء من النقل، وخلط أنماط كود مختلفة بشكل خاطئ.

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

وفيما يلي النص الأصلي:

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

رأى Forrest Chang هذه السلسلة من التغريدات، فقام بتنظيم الشكاوى في 4 قواعد سلوكية، وكتبها في ملف CLAUDE.md منفصل، ونشره على GitHub. في أول يوم من إطلاق المشروع، حصل على 5828 نجمة، وخلال أسبوعين جمع 60000 حفظ، والآن لديه 120000 نجمة، ليصبح أسرع مستودع برمجي لملف واحد في عام 2026.

بعد ذلك، قمت خلال 6 أسابيع باختبارها على 30 مستودعًا برمجيًا.

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

بحلول مايو 2026، أصبحت مشاكل بيئة Claude Code مختلفة: تعارضات بين الوكلاء، تفعيل سلاسل hook، تعارضات تحميل المهارات، وانقطاع سير العمل متعدد الخطوات عبر الجلسات.

لذا أضفت 8 قواعد أخرى. إليك النسخة الكاملة من ملف CLAUDE.md التي تتضمن 12 قاعدة، مع شرح لماذا كل قاعدة مهمة، وأين تفشل النسخة الأصلية من نموذج Karpathy في 4 أماكن بشكل خفي.

إذا رغبت في تخطي الشرح، يمكنك نسخ الملف بالكامل من نهاية النص.

لماذا هذا مهم

ملف CLAUDE.md الخاص بـ Claude Code هو أحد أكثر الملفات تقليلًا من حيث التقدير في تقنية برمجة الذكاء الاصطناعي. معظم المطورين يرتكبون ثلاثة أخطاء رئيسية:

الأول: اعتباره سلة مهملات تفضيلات، ويضعون فيه كل عادتهم، مما يؤدي إلى تضخمه إلى أكثر من 4000 رمز، وانخفاض معدل الالتزام بالقواعد إلى 30%.

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

الثالث: نسخ قالب واحد وعدم الاهتمام به بعد ذلك. قد يكون فعالًا لمدة أسبوعين، لكنه يتوقف عن العمل مع تغير المستودع دون أن تلاحظ.

تقول وثائق Anthropic الرسمية بوضوح: أن ملف CLAUDE.md هو مجرد اقتراحات. يلتزم Claude به حوالي 80% من الوقت. وعندما يتجاوز 200 سطر، ينخفض الالتزام بشكل ملحوظ، لأن القواعد المهمة تتداخل مع الضوضاء.

حل Karpathy لهذه المشكلة هو قالب واحد، 65 سطر، 4 قواعد. وهو الحد الأدنى المطلوب.

لكن الحد الأعلى يمكن أن يكون أعلى. بعد إضافة الـ8 قواعد التالية، لن يغطي النموذج فقط مشاكل كتابة الكود التي اشتكى منها Karpathy في يناير 2026، بل أيضًا مشاكل تنسيق الوكلاء التي ظهرت في مايو 2026 — وهذه المشاكل لم تكن موجودة عند كتابة القالب الأصلي.

القواعد الأصلية الأربعة

إذا لم تكن قد اطلعت على مستودع Forrest Chang، فابدأ بهذا الإصدار الأساسي:

القاعدة 1: فكر قبل الترميز.

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

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

القاعدة 3: التعديلات الجراحية.
غير فقط الأجزاء الضرورية. لا تقوم بتحسين الكود المجاور، أو التعليقات، أو التنسيق بشكل عشوائي. لا تعيد هيكلة الكود غير التالف. حافظ على نمط الكود الحالي.

القاعدة 4: التنفيذ بهدف الوصول للهدف.
حدد معايير النجاح أولًا، ثم كرر حتى تتأكد من تحقيقها. لا تخبر Claude كيف يفعل كل خطوة، بل أخبره كيف يبدو النجاح، ودعه يكرر حتى يصل.

هذه القواعد الأربع يمكن أن تقلل من حوالي 40% من أنماط الفشل التي أراها في جلسات Claude غير المراقبة. أما الـ60% المتبقية، فهي مخفية في المناطق التالية.

الأسباب وراء إضافة الـ8 قواعد الجديدة

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

القاعدة 5: لا تجعل النموذج يعمل في غير النصوص

يمكن لـClaude التعامل مع: التصنيف، المسودات، الملخصات، استخراج المعلومات من النص غير المنظم.
لا تستخدمه في: التوجيه، إعادة المحاولة، معالجة رموز الحالة، التحويلات الحتمية.
إذا كانت حالة معينة قد أجابت على السؤال، فدع الكود العادي يتولى الأمر.

لم تغطِ هذه النقطة في قواعد Karpathy. لذلك بدأ النموذج يقرر مسائل يجب أن يعالجها الكود الحتمي: هل يعيد محاولة استدعاء API، كيف يوجه رسالة، متى يرفع مستوى المعالجة. والنتيجة أن القرارات أصبحت غير مستقرة، وتكلفتها تتغير بشكل عشوائي.

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

القاعدة 6: حدد ميزانية صارمة للرموز، بدون استثناء

ميزانية مهمة واحدة: 4000 رمز.
ميزانية جلسة واحدة: 30000 رمز.
إذا اقتربت من الحد الأقصى، لخص الحالة الحالية، وابدأ من جديد.
كن واضحًا بشأن تجاوز الميزانية، بدلاً من التظاهر بعدم وجود مشكلة.

ملف CLAUDE.md بدون قيود الميزانية هو بمثابة شيك على بياض. كل دورة يمكن أن تتسبب في تدفق سياق يتجاوز 50,000 رمز. النموذج لن يتوقف تلقائيًا.

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

القاعدة 7: أظهر الصراع، لا توازن بين الحلول

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

عندما يتعارض نمطان في الكود، يحاول النموذج إرضاءهما معًا، مما يؤدي إلى كود غير متماسك.

في ذلك الوقت، كان هناك نمطان لمعالجة الأخطاء: أحدهما باستخدام async/await مع try/catch، والآخر باستخدام معالجات أخطاء عالمية. النموذج كتب كودًا يدمج بينهما، مما أدى إلى تكرار معالجة الأخطاء، واستغرق الأمر 30 دقيقة لفهم أن الأخطاء تُهضم مرتين.

القاعدة 8: اقرأ قبل أن تكتب

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

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

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

القاعدة 9: الاختبار ليس اختيارياً، لكن الاختبار ليس هدفًا

كل اختبار يجب أن يوضح «لماذا هذا السلوك مهم»، وليس فقط «ماذا يفعل».
اختبار مثل expect(getUserName()).toBe(‘John’) لا قيمة له إذا كانت الوظيفة تتلقى معرفًا ثابتًا.
إذا لم تستطع كتابة اختبار يفشل عند تغير المنطق، فالوظيفة خاطئة.

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

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

القاعدة 10: العمليات طويلة المدى تحتاج إلى نقاط تفتيش

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

نموذج Karpathy يفترض تفاعلًا واحدًا، لكن في الواقع، غالبًا ما يكون العمل مع Claude متعدد الخطوات: إعادة هيكلة عبر 20 ملفًا، بناء وظيفة في جلسة واحدة، تصحيح عبر عدة commit. بدون نقاط تفتيش، خطأ واحد قد يفسد كل التقدم السابق.

في ذلك الوقت، كانت هناك مهمة إعادة هيكلة من 6 خطوات، فشل في الخطوة 4، وعندما اكتشفت ذلك، استمر النموذج في إكمال الخطوتين 5 و6 بشكل خاطئ، مما استغرق وقتًا أطول في الإصلاح من إعادة العمل من الصفر. وجود نقطة تفتيش كان سيمكن من اكتشاف المشكلة في الخطوة 4.

القاعدة 11: الاتفاقية تتقدم على الابتكار

إذا كانت قاعدة المستودع تستخدم snake_case، وأنت تفضل camelCase، فالتزم بـ snake_case.
إذا كانت المكونات تعتمد على class، وأنت تفضل hooks، فالتزم بـ class.
الاختلافات يجب أن تُناقش، لكن داخل المستودع، الاتساق أهم من التفضيل الشخصي.
إذا كنت تعتقد أن قاعدة معينة ضارة، اقترحها بشكل واضح، ولا تفتح فرعًا بشكل غير معلن.

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

في ذلك الوقت، أدخل النموذج hooks في مستودع React يعتمد على class components، ونجح في التشغيل، لكنه كسر نمط الاختبار القديم الذي يعتمد على componentDidMount، واستغرق الأمر نصف يوم لإزالته وإعادة كتابته.

القاعدة 12: فشل بشكل واضح، لا بشكل صامت

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

أخطر فشل لنموذج Claude هو تلك الأخطاء التي تظهر وكأنها نجاح: وظيفة «تعمل»، لكنها تعيد بيانات خاطئة؛ أو أن عملية نقل «اكتملت»، لكنها تخطت 14% من السجلات التي تتسبب في تعارضات؛ أو أن الاختبارات «نجحت»، لكنها كانت خاطئة من الأساس.

في ذلك الوقت، أعلن النموذج أن عملية نقل قاعدة البيانات «اكتملت بنجاح»، لكن في الواقع، تخطى بشكل صامت 14% من السجلات التي تتسبب في تعارضات، وتم تسجيل ذلك في السجلات دون إظهار واضح. بعد 11 يومًا، عندما بدأت البيانات في التقلب، اكتشفنا المشكلة.

نتائج البيانات

خلال 6 أسابيع، تتبعت مجموعة من 50 مهمة تمثيلية، عبر 30 مستودعًا، بثلاث تكوينات مختلفة.

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

معدل الالتزام هو: احتمالية أن يطبق النموذج القاعدة بشكل صريح عندما تكون مناسبة.

النتائج المثيرة ليست فقط أن معدل الأخطاء انخفض من 41% إلى 3%. الأهم أن توسعة القواعد من 4 إلى 12 لم ترفع عبء الالتزام بشكل كبير، حيث انخفض معدل الالتزام من 78% إلى 76%، لكن معدل الأخطاء انخفض بمقدار 8 نقاط مئوية. القواعد الجديدة تغطي أنماط فشل لم تكن معالجة في القواعد الأربعة الأصلية، ولم تتداخل معها في الميزانية.

أماكن قد تتوقف فيها فعالية نموذج Karpathy

حتى بدون إضافة قواعد جديدة، القالب المكون من 4 قواعد لم يعد كافيًا في 4 مناطق رئيسية:

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

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

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

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

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

طرق لم تنجح

قبل اعتماد الـ12 قاعدة بشكل نهائي، جربت بعض الحلول الأخرى.

إضافة قواعد رأيتها على Reddit / X.
معظمها إما تكرار لنفس قواعد Karpathy بصياغة مختلفة، أو قواعد خاصة بمجال معين لا يمكن تعميمها، مثل «استخدام Tailwind دائمًا». تم حذفها جميعًا.

تجاوز 12 قاعدة.
اختبرت حتى 18 قاعدة. بعد 14 قاعدة، انخفض معدل الالتزام من 76% إلى 52%. الحد الأقصى هو 200 سطر، وبعده يبدأ النموذج في التوافق مع النمط بدلًا من قراءة القواعد بشكل دقيق.

اعتماد أدوات معينة.
مثل «استخدام eslint دائمًا»، لكن إذا لم يُثبت eslint، تتوقف القاعدة عن العمل بشكل صامت. غيرت ذلك إلى صياغة لا تعتمد على أدوات محددة، مثل «اتباع نمط الكود المطبق في المستودع».

وضع أمثلة بدل القواعد في CLAUDE.md.
الأمثلة تستهلك سياقًا أكثر، وتؤدي إلى overfitting، لأنها محددة أكثر من القواعد المجردة. القواعد أفضل لأنها عامة.

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

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

النسخة الكاملة من ملف CLAUDE.md بـ12 قاعدة

إليكم النسخة الكاملة التي يمكن نسخها ولصقها مباشرة.

لا يمكن عرضها خارج مستند Feishu حاليًا.

احفظها في جذر المستودع باسم CLAUDE.md. أضف قواعد خاصة بمشروعك أسفلها، مثل تقنية التكديس، أو أوامر الاختبار، أو أنماط الأخطاء. لا تتجاوز 200 سطر، وإلا ستنخفض نسبة الالتزام بشكل ملحوظ.

كيفية التثبيت

خطوتان فقط:

1. أضف القواعد الأربع الأساسية لـ Karpathy إلى ملف CLAUDE.md الخاص بك
   curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

2. الصق القواعد 5–12 من هذا النص أدناه

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

نموذج العقل

CLAUDE.md ليست قائمة أمنيات، بل عقد سلوك، لوقف أنماط الفشل التي لاحظتها.

كل قاعدة يجب أن تجيب على سؤال: ماذا تمنع من الخطأ؟

القواعد الأربعة لـ Karpathy، تمنع أنماط الفشل التي رأيتها في يناير 2026: الافتراضات الصامتة، الهندسة المفرطة، التدمير غير المقصود، وضعف معايير النجاح. هي الأساس، لا تتجاهلها.

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

بالطبع، تعتمد الفعالية على الاستخدام. إذا لم تكن تتعامل مع مهام متعددة الخطوات، فالقواعد 10 و11 أقل أهمية. إذا كان لديك نمط موحد في الكود، وتطبقه أدوات مثل linter، فالقواعد 11 و12 قد تكون زائدة. بعد قراءة الـ12 قاعدة، احتفظ بتلك التي تتوافق مع أخطائك، واحذف الباقي.

ملف CLAUDE.md مخصص لنمط فشل حقيقي، أفضل من نسخة تحتوي على 12 قاعدة، منها 6 لا تستخدمها أبدًا.

الخاتمة

تلك التغريدة في يناير 2026 كانت في الأصل شكوى. حولها Forrest Chang إلى 4 قواعد. وفي النهاية، حصلت على 120 ألف مطور على GitHub على إعجاب. ومعظمهم لا يزال يستخدم تلك القواعد الأربعة فقط.

النموذج تطور، والبيئة تغيرت. وكلاء متعددون، سلاسل hook، تحميل المهارات، التعاون عبر المستودعات — كلها لم تكن موجودة عند كتابة التغريدة. القواعد الأصلية لم تعالجها، وليست خاطئة، لكنها غير مكتملة.

أضفنا 8 قواعد، واختبرنا 30 مستودعًا خلال 6 أسابيع، وانخفض معدل الأخطاء من 41% إلى 3%.

احفظ هذه المقالة الآن، ونسخ الـ12 قاعدة إلى ملف CLAUDE.md الخاص بك. إذا ساعدتك على تجنب أسبوع من الأخطاء، شاركها مع الآخرين.

[رابط النص الأصلي]

انقر لمعرفة وظائف BlockBeats في التوظيف

انضم إلى المجتمع الرسمي لـ BlockBeats:

قناة Telegram: https://t.me/theblockbeats

مجموعة Telegram: https://t.me/BlockBeats_App

حساب Twitter الرسمي: https://twitter.com/BlockBeatsAsia