العنوان الأصلي:《شرح واحد يوضح شفرة مصدر Claude Code الخاصة بـ Anthropic: لماذا هي أفضل من غيرها في الاستخدام؟》

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

في 31 مارس 2026، اكتشف الباحث في مجال الأمن Chaofan Shou أن حزمة Claude Code التي نشرتها Anthropic على npm لم يتم تجريد ملفات source map منها.

وهذا يعني: تم كشف كامل شفرة TypeScript الخاصة بـ Claude Code، وعددها 512 ألف سطر، و1903 ملفات، هكذا ببساطة على الملأ.

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

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

2. لماذا يكون “الإحساس” عند كتابة الكود به أفضل من الآخرين؟

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

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

أولاً، لنحكِ قصة: إذا كنت تريد توظيف مبرمج عن بُعد

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

ماذا ستفعل؟

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

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

إذا كان أسلوب Claude Code:

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

هذه هي ثلاثة فلسفات أمان مختلفة تمامًا:

لماذا اختارت Anthropic أصعب طريق؟

لأن هذا هو الطريق الوحيد كي يتمكن الذكاء الاصطناعي من تنفيذ العمل باستخدام طرفك (terminal) وبيئتك وإعداداتك — هذه هي “المساعدة الحقيقية في كتابة الكود” وليست “كتابة مقطع كود في غرفة نظيفة ثم نسخه ولصقه”.

لكن ما الثمن؟ لقد كتبوا 510 آلاف سطر كود لهذا الغرض.

ثانياً، Claude Code الذي تتصوره مقابل Claude Code الحقيقي

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

إدخال المستخدم → استدعاء واجهة LLM API → إرجاع النتيجة → عرضها للمستخدم

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

إدخال المستخدم
→ تجميع ديناميكي لـ 7 طبقات من نظام prompts
→ حقن حالة Git، واتفاقيات المشروع، والذاكرة التاريخية
→ 42 أداة، لكل واحدة منها “دليل استخدام” خاص بها
→ يقرر LLM أي أداة يستخدم
→ فحص أمان من 9 طبقات (تحليل AST، مصنّف ML، فحص sandbox… )
→ تحليل تنازع الصلاحيات (لوحة مفاتيح محلية / IDE / Hook / مصنف AI يتنافسون في آن واحد)
→ تأخير 200ms لمنع النقرات/التلامسات العرضية
→ تنفيذ الأداة
→ إرجاع النتيجة بشكل streaming
→ السياق اقترب من الحد الأقصى؟ → ضغط من ثلاث طبقات (ضغط بسيط → ضغط تلقائي → ضغط كامل)
→ تحتاج إلى توازي؟ → توليد سرب من sub Agents
→ التكرار حتى يكتمل تنفيذ المهمة

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

ثالثًا، السر الأول: prompts ليست مكتوبة فقط، بل “مركّبة”

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

هل لاحظت SYSTEM_PROMPT_DYNAMIC_BOUNDARY؟

هذا حد فاصل في الكاش (cache). المحتوى فوق خط الفصل ثابت، ويمكن لـ Claude API تخزينه مؤقتًا، مما يوفر تكلفة التوكنات. المحتوى تحت خط الفصل ديناميكي — الفرع (Git) الحالي لديك، إعدادات مشروع CLAUDE.md، وتفضيلات الذاكرة التي أخبرته بها سابقًا… كل محادثة تختلف.

ماذا يعني ذلك؟

تتعامل Anthropic مع prompts كأنها ناتج “مخرجات مُجمِّع” (compiler output) لتحسينها. الجزء الثابت هو مثل “الـ binary بعد الترجمة”، والجزء الديناميكي هو “معاملات وقت التشغيل”. فوائد هذا النهج:

1. توفير المال: الجزء الثابت يستخدم الكاش ولا يتم تحصيل رسومه مرة أخرى

2. السرعة: عند نجاح الكاش يتم تخطي معالجة تلك الـ token

3. المرونة: الجزء الديناميكي يجعل كل محادثة تشعر ببيئتك الحالية

لكل أداة “دليل استخدام” مستقل

الأكثر صدمة بالنسبة لي هو: داخل كل مجلد أداة يوجد ملف prompt.ts — هذا مخصّص كدليل استخدام مكتوب للـ LLM.

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

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

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

والنسخة الداخلية لدى Anthropic تختلف عن النسخة التي تستخدمها

في الكود تظهر بكثرة فروع مثل هذه:

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

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

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

افتح src/tools.ts وسترى مركز تسجيل الأدوات:

هناك 42 أداة، لكن معظمها لم ترها أنت مباشرة أبدًا. لأن العديد من الأدوات يتم تحميلها بشكل متأخر (lazy loading) — لا يتم حقنها عبر ToolSearchTool إلا عندما يحتاجها LLM.

لماذا يفعلون ذلك؟

لأن كل إضافة لأداة تعني إضافة مقطع وصف في نظام prompts، وبالتالي تكلفة توكنات إضافية. إذا كنت تريد فقط من Claude Code تعديل سطر واحد من الكود، فلن يحتاج إلى تحميل “مجدول المهام” و“مدير تعاون الفريق”.

وهناك تصميم أكثر ذكاءً أيضًا:

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

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

لاحظ القيم الافتراضية: isConcurrencySafe افتراضيًا false، و isReadOnly افتراضيًا false.

هذا يُسمى تصميم fail-closed — إذا نسي مؤلف أداة ما أن يصرّح بخصائص الأمان، يفترض النظام أنها “غير آمنة ويمكن أن تكتب”. الأفضل أن نكون شديدي الحذر بدل أن نُفوّت أي خطر.

قانون “اقرأ أولاً ثم عدّل” الحازم

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

وهذا هو السبب في أن Claude Code لا يقوم مثل بعض الأدوات بـ “كتابة مقطع كود من العدم يغطي ملفاتك” — بل يُفرض عليه فهم ما يحدث أولاً ثم التعديل.

خامسًا، السر الثالث: نظام الذاكرة — لماذا يمكنه “تذكرك”

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

أنت تخبره “لا تُمثّل/تُحاكي (mock) قاعدة البيانات في الاختبارات”، وفي المرة التالية في الحوار لن يقوم بعمل mock. وتخبره “أنا مهندس خلفية، مبتدئ في React”، فسوف يستخدم استعارات من مجال الخلفية عند شرح كود الواجهة الأمامية.

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

استخدام AI لاسترجاع الذاكرة

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

ليس مطابقة كلمات مفتاحية، ولا بحثًا متجهيًا (vector search) — بل يُجري نموذج صغير مسحًا سريعًا لجميع ملفات الذاكرة من حيث عناوينها ووصفها، ثم يختار ما يصل إلى 5 من الأكثر صلة، وبعد ذلك يحقن محتواها الكامل ضمن سياق المحادثة الحالية.

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

وضع KAIROS: “حلم” ليلي

هذا الجزء هو الأكثر جعلني أشعر أنه خيال علمي.

يوجد في الكود وسم/ميزة تُسمى KAIROS. في هذا الوضع، لا يتم تخزين الذاكرة في جلسة طويلة داخل ملفات مُنظَّمة، بل داخل سجل لوج (append-only) حسب التاريخ. ثم توجد مهارة /dream تعمل “ليلاً” (في فترة انخفاض النشاط) لتقطير هذه السجلات الخام إلى ملفات مواضيع (موضوعات) مُنظَّمة.

يقوم الذكاء الاصطناعي بترتيب الذاكرة بينما “ينام”. هذا لم يعد هندسة فقط، بل استنساخ/محاكاة بيولوجية.

سادسًا، السر الخامس: ليس Agent واحدًا، بل مجموعة

عندما تطلب من Claude Code تنفيذ مهمة معقدة، فقد يقوم سرًا بعمل شيء من هذا النوع:

لقد أنشأ sub Agent.

وبالإضافة إلى ذلك، يتم حقن “وعي ذاتي” صارم للـ sub Agent لمنعه من توليد المزيد من sub Agents بشكل تكراري:

هذا الجزء من الكود يقول: “أنت عامل، وليس مديرًا. لا تفكر في توظيف أشخاص آخرين، اشتغل بنفسك.”

وضع Coordinator: نمط المدير

في وضع المُنسّق (coordinator)، يتحول Claude Code إلى مجرد مُوزّع/منسّق مهام (task orchestrator) بحت، فهو لا ينفذ بنفسه، فقط يُسنِّد:

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

“Parallelism is your superpower” مهام البحث للقراءة فقط: تشغيلها بالتوازي. مهام كتابة الملفات: تشغيلها على مستوى كل ملف بشكل تسلسلي (لتجنب التعارضات).

أقصى تحسين لكاش Prompt

من أجل تعظيم معدل نجاح كاش الـ sub Agent الناتجة عن كل fork،يتم استخدام نص placeholders متطابق لجميع نتائج أدوات الـ fork sub agents:

“Fork started—processing in background”

لماذا؟ لأن كاش prompt الخاص بـ Claude API يعتمد على مطابقة بادئات على مستوى البايتات. إذا كانت البايتات الخاصة بالبادئة البالغة 10 من sub agents متطابقة تمامًا، فإن الأول فقط يحتاج “بدءًا باردًا” (cold start)، بينما الـ9 الباقون يضربون الكاش مباشرة.

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

سابعًا، السر السادس: ضغط من ثلاث طبقات، لجعل المحادثة “لا تتجاوز الحدود” أبدًا

جميع نماذج LLM لديها حد لنافذة السياق (context window). كلما طالت المحادثة وزادت الرسائل التاريخية، فلابد في النهاية أن يتجاوز الحد.

صمم Claude Code لذلك ضغطًا من ثلاث طبقات:

الطبقة الأولى: ضغط دقيق — أقل تكلفة

يحرّك الضغط الدقيق فقط نتائج استدعاءات الأدوات القديمة — يستبدل “محتوى ملف من 500 سطر تم قراءته قبل 10 دقائق” بـ [Old tool result content cleared].

تظل prompts وخط المحادثة الرئيسي محفوظين بالكامل.

الطبقة الثانية: ضغط تلقائي — انكماش استباقي

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

الطبقة الثالثة: ضغط كامل — ملخص بواسطة AI

يُطلب من AI توليد ملخص لكل المحادثة، ثم يتم استبدال جميع الرسائل التاريخية بالملخص. وعند توليد الملخص توجد تعليمات أولية صارمة:

لماذا هذه القسوة؟ لأن إذا قام الـ AI أثناء عملية التلخيص أيضًا باستدعاء أدوات، فسيؤدي ذلك إلى المزيد من استهلاك التوكنات، وهذا عكس المطلوب. هذه الـ prompts تقول حرفيًا: “مهمتك هي التلخيص، لا تفعل شيئًا آخر.”

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

· استعادة الملفات: 50,000 tokens

· حد لكل ملف: 5,000 tokens

· محتوى المهارات: 25,000 tokens

هذه الأرقام لم يتم اختيارها عشوائيًا — إنها نقطة توازن بين “الحفاظ على سياق كافٍ للاستمرار في العمل” و“تخصيص مساحة كافية لاستقبال رسائل جديدة”.

ثامنًا، ماذا تعلمت بعد قراءة هذه الشفرة المصدرية

90% من عمل AI Agent يتم خارج “الذكاء الاصطناعي”

في 510 آلاف سطر كود، قد لا تتجاوز نسبة الجزء الذي يستدعي واجهة LLM API 5%. الباقي 95% هو ماذا؟

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

· نظام الصلاحيات (قرار رباعي الحالات: allow/deny/ask/passthrough)

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

· استعادة الأخطاء (قاطع/熔断器، backoff أسي، Transcript Persistence)

· تنسيق متعدد Agent (تنظيم سرب (蜂群) + تواصل عبر البريد الإلكتروني)

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

· تحسين الأداء (استقرار prompt cache + جلب مسبق متوازٍ عند التشغيل)

إذا كنت تقوم بإنتاج منتج AI Agent، فهذا هو المشكل الذي يجب أن تحله فعلًا. ليس ما إذا كان النموذج ذكيًا كفاية، بل ما إذا كان “السقالات/الدعامات” الخاصة بك قوية بما يكفي.

هندسة prompts الجيدة هي هندسة نظام كاملة

ليس الأمر أنك تكتب prompt جميلة ثم تنتهي. prompts الخاص بـ Claude Code هي:

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

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

· تقسيم حدود الكاش بدقة

· مجموعات تعليمات مختلفة بين النسخة الداخلية والنسخة الخارجية

· ترتيب الأدوات ثابت للحفاظ على استقرار الكاش

هذه هي إدارة prompts بشكل “هندسوي/تحويلي” وليست “حرفة يد”.

مصمم للفشل

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

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

42 أداة = نظام استدعاءات (system calls) + نظام الصلاحيات = إدارة صلاحيات المستخدم
مهارات (skills) نظام = متجر تطبيقات
بروتوكول MCP = تعريفات/تعريفات أجهزة (device drivers)
Agent سرب = إدارة عمليات (process management)
ضغط السياق = إدارة الذاكرة
Transcript persistence = نظام الملفات

ليس هذا “روبوت محادثة مع عدة أدوات”؛ بل نظام تشغيل مبني على LLM كقلب.

الخلاصة

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

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

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

وثمن نظام الثقة هذا هو 510 آلاف سطر كود.

الرابط الأصلي

اضغط لمعرفة المزيد حول التوظيف في BlockBeats في وظائف شاغرة

مرحبًا بانضمامك إلى مجتمع BlockBeats الرسمي:

Telegram مجموعة الاشتراك: https://t.me/theblockbeats

Telegram مجموعة الدردشة: https://t.me/BlockBeats_App

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