Claude Code بلا سحر: Habr يفكك البنية المعمارية وضوضاء السياق والممارسات الهندسية

نشر موقع Habr ترجمة لنص عملي مطوّل عن Claude Code، يستند إلى نصف عام من العمل المكثف مع الوكيل. وليس النص عرضاً لميزات الأداة، بل تحليلاً لأسباب بدء أداة الذكاء الاصطناعي المخصصة للتطوير بالتعثر حين تُمنح في وقت واحد قدراً مفرطاً من السياق والقواعد والحرية.

أين يضيع السياق

الفكرة المحورية في المقال بسيطة: لا يتعطل Claude Code لأن النموذج «ليس ذكياً بما يكفي»، بل لأن البيئة الهندسية المحيطة به سيئة التصميم. ويصف المؤلف الوكيل بأنه حلقة تتألف من جمع السياق، ثم تنفيذ الإجراء، ثم التحقق من النتيجة. وإذا أُثقلت طبقة واحدة على الأقل من هذه الحلقة، تراجعت الجودة بحدة: فملف CLAUDE.md الطويل يولّد ضوضاء، وعشرات الأدوات تعقّد عملية الاختيار، وغياب التحقق السريع يجعل كل تعديل أشبه بيانصيب. وفي هذا الوضع يبدأ المطوّر بإعادة صياغة الـ prompts بلا نهاية، مع أن المشكلة تكمن في مكان أعمق.

ويتناول المقال بصورة منفصلة كلفة السياق. فمن الناحية الشكلية، يملك Claude Code نافذة سياق كبيرة، لكن جزءاً كبيراً من الـ tokens يُستهلك قبل بدء العمل أصلاً: على التعليمات النظامية، وواصفات skills، وأوصاف أدوات MCP، وحالة LSP، والذاكرة، وملف CLAUDE.md الخاص بالمشروع. ويورد المؤلف حسابات توضيحية: فخادم MCP واحد نموذجي قد يشغل آلاف الـ tokens لمجرد مخططات الأدوات، وعدة خوادم متصلة معاً تستهلك بسهولة حصة ملحوظة من النافذة المتاحة. أضف إلى ذلك المخرجات الطويلة للاختبارات وأوامر grep والسجلات، وسيبدأ تاريخ الحوار المفيد بالتزاحم والإزاحة تلقائياً.

• التعليمات النظامية والقواعد الأساسية
• أوصاف skills وأدوات MCP
• ذاكرة المشروع ومحتوى CLAUDE.md
• نتائج استدعاءات shell والاختبارات والبحث
• تاريخ الجلسة المضغوط، لكنه لم يعد دقيقاً دائماً

ويترتب على ذلك استنتاج عملي: ينبغي ألا تُحفظ المعرفة نادرة الاستخدام داخل سياق محمّل بصورة دائمة. وعند تغيير المهمة يُفضَّل تكرار تفريغ الجلسة، أما عند مواصلة الاتجاه نفسه فالأفضل استخدام الضغط المُدار. ومن النصائح الأخرى في المقال أن يُطلب من الوكيل، قبل بدء جلسة جديدة، إعداد ملف HANDOFF.md يتضمن التقدم المحرز والمسارات المسدودة وحالة التحقق. وهذا أرخص وأكثر موثوقية من التعويل على أن يحفظ الـ compaction التلقائي القرارات المعمارية المهمة فعلاً.

Skills وhooks والوكلاء

يتناول المحور المهم الثاني تقسيم الأدوار. ويقترح المؤلف عدم خلط MCP وtools وskills وhooks وplugins وsubagents في كومة واحدة. والمنطق هنا كالتالي: الأداة تمنح قدرة جديدة، وskill يحدد سير العمل، وhook يُدمج فحصاً تلقائياً إلزامياً، وsubagent ينقل مهمة منفصلة إلى سياق معزول. وهذا توضيح مفيد، لأن فرقاً كثيرة تحاول معالجة أي خلل بـ prompt جديد أو tool إضافي، مع أن المشكلة قد تُحل على مستوى مختلف تماماً.

ويشرح المقال بصورة منفصلة كيف ينبغي أن يكون الـ skill الجيد. فله واصف قصير ودقيق، وشرط استخدام واضح، ومدخلات ومخرجات محددة، وشرط توقف منصوص عليه. وكل ما هو ثقيل، من أمثلة وrunbooks وملفات مساعدة، ينبغي أن يُستدعى عند الطلب، لا أن يبقى معلقاً في ملف SKILL.md الرئيسي. وفي الإجراءات ذات الآثار الجانبية ينصح المؤلف بتعطيل التشغيل التلقائي من قبل النموذج صراحةً. والفكرة أن يرى الوكيل أولاً الفهرس والمسار، ولا يحمّل التفاصيل إلا في اللحظة التي يحتاجها فيها فعلاً.

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

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

من أكثر أجزاء النص إثارة للاهتمام شرحُه إلى أي مدى ترتبط معمارية Claude Code بـ prompt caching. ويكتب المؤلف أن البادئة المستقرة للـ prompt لا توفر المال فحسب، بل تقلل أيضاً الاحتكاك مع الحدود المفروضة. ومن هنا تنشأ عدة قواعد غير بديهية: عدم إدراج بيانات ديناميكية في الـ prompt النظامي، وعدم تبديل ترتيب الأدوات، وعدم تغيير النموذج في منتصف جلسة طويلة دون ضرورة، وتأجيل التحميل الكامل لمخططات tools النادرة قدر الإمكان. وحتى Plan Mode، كما يُشار في المقال، من الأنسب تنفيذه دون تغيير مجموعة الأدوات بأكملها، كي لا تتعطل الذاكرة المؤقتة.

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

«إذا لم تكن قادراً على شرح كيف تعرف أن

Claude أنجز المهمة بشكل صحيح، فالأرجح أن المهمة غير مناسبة للتنفيذ الآلي الكامل».

ماذا يعني ذلك

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