تحليل الكود المصدري لـ Claude Code: لماذا يتفوق على أدوات البرمجة الأخرى بالذكاء الاصطناعي؟

العنوان الأصلي: "فهم الكود المصدري لـ Claude Code من Anthropic في مقال واحد: لماذا هو أفضل من غيره؟"

المؤلف الأصلي: Yuker، باحث في الذكاء الاصطناعي

في 31 مارس 2026، اكتشف الباحث الأمني Chaofan Shou أنه في إصدار npm الخاص بـ Claude Code من Anthropic، لم يتم حذف ملف خريطة المصدر (source map).

هذا يعني أن الكود المصدري الكامل لـ Claude Code بلغة TypeScript، والذي يضم 512,000 سطر و1903 ملفات، قد تم كشفه على الإنترنت العام.

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

1. ما هو الفرق الجوهري بين Claude Code وأدوات البرمجة الأخرى بالذكاء الاصطناعي؟

2. لماذا يبدو "شعور" كتابة الكود الخاص به أفضل من غيره؟

3. ما الذي يختبئ بالضبط في 510,000 سطر من الكود؟

بعد قراءته، كان رد فعلي الأولي: هذا ليس مجرد مساعد برمجة بالذكاء الاصطناعي؛ هذا نظام تشغيل.

أولاً. لنبدأ بقصة: لو كنت ستوظف مبرمجاً عن بُعد

تخيل أنك وظفت مبرمجاً عن بُعد ومنحته وصولاً عن بُعد إلى جهاز الكمبيوتر الخاص بك.

كيف ستتعامل مع الأمر؟

إذا كنت Cursor: ستجعله يجلس بجانبك، وفي كل مرة يحتاج فيها لكتابة أمر، ستلقي نظرة وتضغط على "سماح". الأمر مباشر، لكن عليك مراقبته في جميع الأوقات.

إذا كنت GitHub Copilot Agent: ستمنحه جهازاً افتراضياً جديداً تماماً ليعمل فيه. بعد الانتهاء، يقوم بإرسال الكود، وتراجعه أنت، ثم تدمجه. إنه آمن، لكنه لا يستطيع رؤية بيئتك المحلية.

إذا كنت Claude Code:

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

إليك ثلاث فلسفات أمنية مختلفة تماماً:

لماذا اختارت Anthropic المسار الأصعب؟

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

ولكن ما هي التكلفة؟ لقد كتبوا 510,000 سطر من الكود لهذا الغرض.

ثانياً. تصورك لـ Claude Code مقابل Claude Code الفعلي

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

مدخلات المستخدم ← استدعاء واجهة برمجة تطبيقات LLM ← الحصول على النتيجة ← العرض للمستخدم

يعمل Claude Code الفعلي هكذا:

مدخلات المستخدم
← تجميع ديناميكي لـ 7 طبقات من مطالبات النظام
← حقن حالة Git، واتفاقيات المشروع، والذاكرة التاريخية
← 42 أداة تأتي كل منها مع دليل
← يقرر LLM أي أداة يستخدم
← 9 طبقات من المراجعة الأمنية (تحليل AST، مصنفات ML، فحوصات بيئة الحماية...)
← حل سباق الأذونات (لوحة المفاتيح المحلية/IDE/الخطاف/مصنف الذكاء الاصطناعي تتسابق جميعها في وقت واحد)
← تأخير 200 مللي ثانية لمكافحة الإرهاق
← تنفيذ الأداة
← إرجاع النتائج بطريقة متدفقة
← هل يقترب السياق من الحد؟ ← ضغط ثلاثي المراحل (ضغط دقيق ← ضغط تلقائي ← ضغط كامل)
← هل تحتاج إلى توازي؟ ← توليد سرب من الوكلاء الفرعيين
← حلقة حتى اكتمال المهمة

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

ثالثاً. السر الأول: المطالبات لا تُكتب، بل "تُجمع"

افتح src/constants/prompts.ts، وسترى هذه الدالة:

لاحظ SYSTEM_PROMPT_DYNAMIC_BOUNDARY؟

هذا محدد ذاكرة مؤقتة. المحتوى الموجود فوق المحدد ثابت ويمكن تخزينه مؤقتاً بواسطة واجهة برمجة تطبيقات Claude لتوفير تكاليف التوكن. المحتوى الموجود أسفل المحدد ديناميكي - فرع Git الحالي الخاص بك، وتكوين مشروع CLAUDE.md، وذكريات التفضيلات التي قدمتها سابقاً... كل تفاعل فريد.

ماذا يعني هذا؟

تعامل Anthropic كلمات التلميح كمخرجات مترجم للتحسين. الجزء الثابت هو "الثنائي المترجم"، والجزء الديناميكي هو "معلمات وقت التشغيل". فوائد هذا النهج هي:

1. توفير التكلفة: يتم تخزين الجزء الثابت مؤقتاً، مما يتجنب الرسوم الزائدة

2. السرعة: تتخطى إصابات الذاكرة المؤقتة معالجة تلك التوكنات مباشرة

3. المرونة: يسمح الجزء الديناميكي لكل تفاعل بأن يكون على دراية بالبيئة الحالية

كل أداة لها "دليل المستخدم" الخاص بها

والأكثر إثارة للدهشة هو أن كل دليل أداة يحتوي على ملف prompt.ts - هذا دليل مستخدم مصمم خصيصاً لـ LLM.

انظر إلى BashTool (src/tools/BashTool/prompt.ts، حوالي 370 سطراً):

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

هذا هو السبب في أن Claude Code لا يقوم أبداً بـ git push --force بقوة من تلقاء نفسه، بينما قد تفعل بعض الأدوات ذلك - ليس لأن النموذج أذكى، بل لأن التلميحات قد أوضحت القواعد بالفعل.

بالإضافة إلى ذلك، فإن إصدار Anthropic الداخلي يختلف عما تستخدمه

يحتوي الكود على العديد من الفروع مثل هذا:

يشير ant إلى موظفي Anthropic الداخليين. يحتوي إصدارهم على إرشادات أكثر تفصيلاً لأسلوب الكود ("لا تكتب تعليقات إلا إذا كان السبب غير واضح")، واستراتيجية مخرجات أكثر عدوانية ("الكتابة الهرمية المقلوبة")، وبعض الميزات التجريبية التي لا تزال في اختبار A/B (وكيل التحقق، وكيل الاستكشاف والتخطيط).

هذا يوضح أن Anthropic هي أكبر مستخدم لـ Claude Code. إنهم يستخدمون منتجهم الخاص لتطوير منتجهم الخاص.

رابعاً. السر الثاني: 42 أداة، لكنك لم تر سوى قمة جبل الجليد

افتح src/tools.ts، وسترى سجل الأدوات:

42 أداة، لكن معظمها لم تره مباشرة. ذلك لأن العديد من الأدوات يتم تحميلها بكسل - فقط عندما يحتاجها LLM، يتم حقنها عند الطلب عبر ToolSearchTool.

لماذا يتم ذلك؟

لأنه مقابل كل أداة إضافية، تحتاج مطالبة النظام إلى وصف إضافي، ويحتاج التوكن إلى إنفاق المزيد من المال. إذا كنت تريد فقط من Claude Code مساعدتك في تغيير سطر واحد من الكود، فلا يحتاج إلى تحميل 'Cron Task Scheduler' و 'Team Collaboration Manager'.

هناك تصميم أذكى:

اضبط CLAUDE_CODE_SIMPLE=true، وسيتبقى لدى Claude Code ثلاث أدوات فقط: Bash، قراءة ملف، تعديل ملف. هذا باب خلفي للمتبسطين.

جميع الأدوات تأتي من نفس المصنع

انتبه إلى تلك القيم الافتراضية: isConcurrencySafe افتراضياً false، و isReadOnly افتراضياً false.

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

القانون الحديدي لـ 'القراءة قبل الكتابة'

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

هذا هو السبب في أن Claude Code لن "يكتب سحرياً مقتطف كود للكتابة فوق ملفك" مثل بعض الأدوات - **مطلوب منه الفهم أولاً قبل التعديل**.

خامساً. السر الثالث: نظام الذاكرة - لماذا يمكنه "تذكرك"

أي شخص استخدم Claude Code لديه شعور: يبدو أنه يعرفك حقاً.

تخبره "لا تحاكي قاعدة البيانات في الاختبارات"، ولن يحاكي في التفاعل التالي. تخبره "أنا مهندس خلفية، مبتدئ في React"، وسيشرح كود الواجهة الأمامية باستخدام قياسات الخلفية.

وراء هذا نظام ذاكرة كامل.

استخدام الذكاء الاصطناعي لاسترجاع الذكريات

يستخدم Claude Code ذكاء اصطناعياً آخر (Claude Sonnet) لتحديد "أي الذكريات ذات صلة بالمحادثة الحالية"

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

الاستراتيجية هي "الدقة فوق الاستدعاء" - بدلاً من تفويت ذاكرة مفيدة محتملة بدلاً من حقن ذاكرة غير ذات صلة تلوث السياق.

وضع KAIROS: "الحلم" الليلي

هذا هو الجزء الأكثر خيالاً علمياً بالنسبة لي.

هناك علامة ميزة في الكود تسمى KAIROS. في هذا الوضع، لا يتم تخزين الذكريات من المحادثات الطويلة في ملفات منظمة ولكن في إدخالات تشبه السجل الملحقة بالتاريخ. ثم، هناك مهارة /dream التي تعمل أثناء "الليل" (نشاط منخفض) لتقطير هذه السجلات الخام إلى ملفات موضوعية منظمة.

ينظم الذكاء الاصطناعي الذكريات أثناء "النوم". هذا لم يعد هندسة؛ إنه بيونيكس.

سادساً. السر الخامس: إنه ليس وكيلاً، إنه مجموعة

عندما تجعل Claude Code ينفذ مهمة معقدة، قد يقوم بهدوء بما يلي:

إنه يولد وكيلاً فرعياً.

والوكيل الفرعي لديه حقن صارم لـ "الوعي الذاتي" لمنعه من توليد المزيد من الوكلاء الفرعيين بشكل متكرر:

هذه القطعة من الكود تقول: "أنت عامل، لست مديراً. لا تفكر في توظيف المزيد من الناس، قم بالعمل بنفسك."

نمط المنسق: نمط المدير

في نمط المنسق، يصبح Claude Code منسق مهام خالصاً، لا يقوم بالعمل بنفسه، بل يفوض فقط:

المبادئ الأساسية المكتوبة في تعليقات الكود:

"التوازي هو قوتك الخارقة" لمهام البحث للقراءة فقط: تشغيل بالتوازي. لمهام كتابة الملفات: تشغيل بالتسلسل لكل مجموعة ملفات (لتجنب التعارضات).

تحسين ذاكرة المطالبة المؤقتة إلى أقصى حد

لتعظيم معدل إصابة الذاكرة المؤقتة للوكلاء الفرعيين، تستخدم جميع نتائج أدوات الوكلاء الفرعيين المتفرعة نفس النص النائب:

"Fork بدأ - المعالجة في الخلفية"

لماذا؟ لأن ذاكرة مطالبة واجهة برمجة تطبيقات Claude تعتمد على مطابقة البادئة على مستوى البايت. إذا كانت بايتات البادئة لـ 10 وكلاء فرعيين متطابقة، فإن الأول فقط يحتاج إلى "بداية باردة"، والـ 9 المتبقية تصيب الذاكرة المؤقتة مباشرة.

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

سابعاً. السر السادس: ضغط ثلاثي الطبقات لضمان حوارات "لا تتجاوز الحدود أبداً"

جميع LLMs لديها حد لنافذة السياق. كلما طالت المحادثة، زادت الرسائل التاريخية، وسوف تتجاوز الحد في النهاية.

صمم Claude Code ضغطاً ثلاثي الطبقات لهذا الغرض:

الطبقة 1: الضغط الدقيق - تكلفة دنيا

يلمس الضغط الدقيق فقط نتائج استدعاء الأداة القديمة - استبدال "محتوى الملف المكون من 500 سطر الذي تمت قراءته قبل 10 دقائق" بـ [تم مسح محتوى نتيجة الأداة القديمة].

يتم الاحتفاظ بكلمات المطالبة وخيط الحوار بالكامل.

الطبقة 2: الضغط التلقائي - تقليص استباقي

عندما يقترب استهلاك التوكن من 87% من نافذة السياق (حجم النافذة - 13,000 مخزن مؤقت)، يتم التشغيل تلقائياً. هناك قاطع دائرة: إيقاف المحاولات بعد 3 إخفاقات متتالية في الضغط لتجنب حلقة.

الطبقة 3: الضغط الكامل - تلخيص الذكاء الاصطناعي

اجعل الذكاء الاصطناعي يولد ملخصاً للمحادثة بأكملها ثم استبدل جميع الرسائل التاريخية بالملخص. هناك مبدأ صارم أثناء توليد الملخص:

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

ميزانية التوكن المضغوطة:

· استعادة الملف: 50,000 توكن

· الحد لكل ملف: 5,000 توكن

· محتوى المهارة: 25,000 توكن

هذه الأرقام ليست عشوائية - إنها تمثل نقطة توازن بين "الاحتفاظ بسياق كافٍ لمواصلة العمل" و "توفير مساحة كافية لتلقي رسائل جديدة."

ثامناً. ما تعلمته بعد قراءة هذا الكود المصدري

90% من عمل وكيل الذكاء الاصطناعي خارج "الذكاء الاصطناعي"

ضمن 510,000 سطر من الكود، من المحتمل أن يكون الجزء الذي يستدعي واجهة برمجة تطبيقات LLM أقل من 5%. ماذا عن الـ 95% المتبقية؟

· فحوصات الأمان (18 ملفاً فقط لـ BashTool واحد)

· نظام الأذونات (سماح/رفض/سؤال/تمرير قرار تربيعي)

· إدارة السياق (ضغط ثلاثي الطبقات + استرجاع ذاكرة الذكاء الاصطناعي)

· استعادة الخطأ (قاطع الدائرة، التراجع الأسي، استمرار النسخ)

· تنسيق الوكلاء المتعددين (تنسيق السرب + اتصال صندوق البريد)

· تفاعل واجهة المستخدم (140 مكون React + جسر IDE)

· تحسين الأداء (استقرار ذاكرة المطالبة المؤقتة + الجلب المسبق المتوازي عند البدء)

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

هندسة المطالبات الجيدة هي هندسة النظم

لا يتعلق الأمر فقط بصياغة مطالبة لطيفة. تتضمن مطالبات Claude Code:

· تجميع ديناميكي من 7 طبقات

· تأتي كل أداة مع دليل مستخدم مستقل

· حدود الذاكرة المؤقتة محددة بدقة

· الإصدارات الداخلية والخارجية لها مجموعات تعليمات مختلفة

· ترتيب الأدوات ثابت للحفاظ على استقرار الذاكرة المؤقتة

هذه إدارة مطالبات هندسية، وليست حرفية.

التصميم للفشل

كل تبعية خارجية لها سياسة فشل مقابلة:

تعامل Anthropic مع Claude Code كنظام تشغيل

42 أداة = نظام أذونات استدعاء النظام = نظام مهارة إدارة أذونات المستخدم = بروتوكول MCP لمتجر التطبيقات Protocol = سرب وكيل برنامج تشغيل الجهاز = إدارة العمليات ضغط السياق = إدارة الذاكرة استمرار النسخ = نظام الملفات

هذا ليس "روبوت محادثة بالإضافة إلى بضع أدوات"؛ هذا نظام تشغيل مع LLM في جوهره.

ملخص

510,000 سطر من الكود. 1903 ملفات. 18 ملفاً آمناً فقط لأداة Bash واحدة.

9 طبقات من التدقيق فقط لجعل الذكاء الاصطناعي يساعدك بأمان في كتابة أمر.

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

وتكلفة نظام الثقة هذا هي 510,000 سطر من الكود.

المنشور الأصلي