هل يزداد غباء Claude و Codex مع الاستخدام؟ لأن سياقك أصبح ممتلئًا جدًا

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

المؤلف: sysls

الترجمة: Deep潮 TechFlow

مقدمة Deep潮: كتب المدون المطور sysls، الذي لديه 2.6 مليون متابع، مقالًا عمليًا طويلًا حصد إعادة تغريد من 827 شخصًا وإعجابًا من 7000، وركز فيه على جملة واحدة فقط: غالبًا ما تكون الإضافات، وأنظمة الذاكرة، وجميع أدوات التوصيل (harness) التي تستخدمها تضر أكثر مما تنفع. لا يتحدث هذا المقال عن المبادئ العامة، بل يستخلص من مشاريع إنتاجية حقيقية مبادئ عملية قابلة للتنفيذ — من كيفية التحكم في السياق، ومعالجة ميل الذكاء الاصطناعي للمجاملة، إلى كيفية تحديد شروط إنهاء المهمة، وهو من أوضح ما رأيت من حيث ممارسة هندسة Claude/Codex.

النص الكامل أدناه:

مقدمة

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

تعتقد أن المشكلة في أدوات التوصيل (harness)، أو الإضافات، أو الطرفية (Terminal)، أو غير ذلك. استخدمت beads، opencode، zep، وكتبت ملف CLAUDE.md الخاص بك بـ 26000 سطر. لكن مهما حاولت، لا تزال لا تفهم لماذا تبتعد أكثر عن السماء، بينما الآخرون يلعبون مع الملائكة.

هذه هي المقالة التي كنت تنتظرها دائمًا.

بالإضافة إلى ذلك، ليس لدي مصلحة شخصية. أقول أن CLAUDE.md يشمل أيضًا AGENT.md، وأقول أن Claude يشمل أيضًا Codex، وكلاهما أستخدمه بكثافة.

خلال الأشهر القليلة الماضية، لاحظت شيئًا مثيرًا للاهتمام: يكاد لا أحد يعرف حقًا كيف يستغل قدرات الوكيل إلى أقصى حد.

يبدو أن هناك حفنة صغيرة من الناس يمكنهم جعل الوكيل يبني عالمًا كاملًا، بينما الآخرون يتخبطون في بحر الأدوات، ويصابون بمتلازمة الاختيار — يعتقدون أنهم وجدوا الحزمة أو المهارة أو أدوات التوصيل الصحيحة، وأن ذلك سيفتح لهم باب الذكاء الاصطناعي العام (AGI).

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

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

اليوم، أستخدم إعدادًا بسيطًا جدًا، يكاد يكون بسيطًا لدرجة لا يمكن أن تكون أبسط، باستخدام CLI الأساسي (Claude Code و Codex)، ومع فهم بعض المبادئ الأساسية لهندسة الوكيل، تمكنت من تحقيق أكثر إنجازات ملحوظة في مسيرتي.

فهم أن العالم يتقدم بسرعة

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

قبل عدة أجيال، إذا كتبت في CLAUDE.md شيئًا مثل “قبل أن تفعل أي شيء، اقرأ READTHISBEFOREDOINGANYTHING.md”، فاحتمال أن يقول لك “اذهب إلى الجحيم”، ثم يواصل فعل ما يريد بنسبة 50%. اليوم، يلتزم بمعظم الأوامر، حتى تلك المعقدة والمتداخلة — مثل أن تقول “اقرأ A أولاً، ثم B، وإذا كانت C، فاقرأ D”، وغالبًا ما يتبع ذلك بسرور.

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

عندما تستخدم العديد من المكتبات وأدوات التوصيل، فإنك تقيد نفسك بـ “حل واحد”، لكن هذا الحل قد لا يكون موجودًا أمام الجيل القادم من الوكلاء. هل تعرف من هو المستخدم الأكثر حماسًا واستخدامًا للوكيل؟ نعم — موظفو الشركات الرائدة، لديهم ميزانية غير محدودة من الرموز (tokens)، ويستخدمون أحدث النماذج.

هل تفهم ماذا يعني هذا؟ هذا يعني أنه إذا كانت هناك مشكلة حقيقية ولها حل جيد، فالشركات الرائدة ستكون أكبر مستخدم لذلك الحل. وماذا ستفعل بعد ذلك؟ ستدمج ذلك الحل في منتجاتها. فكر في الأمر — لماذا تسمح شركة ما لمنتج آخر بحل مشكلة حقيقية، وخلق اعتماد خارجي؟ كيف أعرف أن هذا حقيقي؟ انظر إلى المهارات، وأنظمة الذاكرة، وأدوات التوصيل، والوكلاء الفرعيين… كلها بدأت من حل مشكلة حقيقية، وتم اختبارها في الميدان، وأثبتت فعاليتها.

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

أتوقع أن تظهر في قسم التعليقات قريبًا عبارات مثل: “SysLS، أنا أستخدم حزمة معينة، وأعجبتني جدًا! أعادت بناء Google خلال يوم واحد!” — أقول: مبروك! لكنك لست الجمهور المستهدف، أنت تمثل مجموعة صغيرة جدًا من المجتمع، التي تفهم حقًا هندسة الوكيل.

السياق هو كل شيء

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

هل يمكنني أن أكتب لعبة تخمين كلمات باستخدام بايثون؟ بسيط. لحظة، ما هو الملاحظة “إدارة الذاكرة” قبل 26 محادثة؟ آه، المستخدم لديه شاشة عالقة قبل 71 محادثة بسبب كثرة العمليات الفرعية التي أنشأناها. هل يجب دائمًا كتابة ملاحظات؟ حسنًا… لا بأس… ما علاقة ذلك بلعبة التخمين؟

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

لذا، أكرر الدعوة — قم بإزالة كل الاعتمادات، ثم…

افعل شيئًا ذا فائدة حقيقية

وصف دقيق للتفاصيل التنفيذية

هل تتذكر أن السياق هو كل شيء؟

هل تتذكر أنك تريد أن تزود الوكيل بالمعلومات الدقيقة اللازمة لإكمال المهمة، لا أكثر ولا أقل؟

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

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

على العكس، إذا قلت: “استخدم bcrypt-12 لتجزئة كلمات المرور، وطبق JWT للمصادقة، مع تدوير رموز التحديث، وانتهائها بعد 7 أيام…” — فلن يحتاج إلى البحث عن بدائل أخرى، ويفهم تمامًا ما تريده، ويمكنه ملء السياق بالتفاصيل التنفيذية.

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

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

حدود ميل المجاملة

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

إذا جعلته يضيف كلمة “سعيد” بعد كل 3 كلمات، فسيحاول الالتزام بذلك — وهذا مفهوم للجميع. طاعته هي السبب في أنه منتج مفيد جدًا. لكن هناك خاصية مثيرة جدًا للاهتمام: هذا يعني أنه إذا قلت “ساعدني في العثور على خطأ في قاعدة البيانات”، فسيجد خطأ — حتى لو كان من الضروري “اختلاق” خطأ. لماذا؟ لأنه يرغب جدًا في أن يطيع أوامرك!

معظم الناس يشتكون بسرعة من أن نماذج اللغة الكبيرة (LLMs) تخلق أوهامًا وتختلق أشياء غير موجودة، لكنهم لا يدركون أن المشكلة تكمن في أنفسهم. أنت تقول له ماذا يبحث عنه، فيعطيك ما طلبت — حتى لو تطلب الأمر أن يمد يده قليلاً لتمديد الحقيقة!

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

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

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

لذا، أطلب من وكيل يبحث عن أخطاء أن يحدد جميع الأخطاء في قاعدة البيانات، ويعطي كل خطأ منخفض التأثير +1 نقطة، ومتوسط التأثير +5 نقاط، وخطير التأثير +10 نقاط. أعلم أن هذا الوكيل سيكون متحمسًا جدًا لتحديد جميع أنواع الأخطاء (حتى تلك التي ليست أخطاء حقيقية)، ثم يبلغني بنتيجة مثل 104 من 100. أعتبر هذا مجموعة شاملة لكل الأخطاء المحتملة.

ثم أطلب من وكيل مضاد أن يناقض، ويقول: “كل خطأ يتم دحضه بنجاح، يحصل على نقاط ذلك الخطأ، وإذا أخطأ في الدحض، يحصل على -2 ضعف نقاط ذلك الخطأ.” هذا الوكيل سيحاول دحض أكبر عدد ممكن من الأخطاء، ولكن بسبب العقوبة، سيكون حذرًا. لا يزال يندفع “للدحض” (حتى للأخطاء الحقيقية). أعتبر هذا مجموعة الأخطاء الحقيقية.

وفي النهاية، أطلب من وكيل حكم أن يدمج نتائج الاثنين ويعطي تقييمًا. أخبره أن لدي إجابة صحيحة، وإذا أصاب، يحصل على +1 نقطة، وإذا أخطأ، يحصل على -1 نقطة. ثم يقيّم الوكيلان على كل “خطأ” بناءً على هذا. الوكيل الحكم يحدد الحقيقة، وأتحقق منها. في معظم الحالات، تكون هذه الطريقة عالية الدقة بشكل مدهش، وأحيانًا تخطئ، لكن هذا قريب جدًا من العمل بدون أخطاء.

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

كيف تعرف ما هو مفيد، وما هو جدير بالاستخدام؟

يبدو أن هذا السؤال معقد جدًا، وكأنك بحاجة إلى دراسة متعمقة، ومتابعة أحدث التطورات في الذكاء الاصطناعي على مدار الساعة، لكن في الواقع، الأمر بسيط… إذا كانت OpenAI وClaude قد حققتا ذلك أو استحوذت على شركات تحقق ذلك… فغالبًا ما يكون مفيدًا.

هل لاحظت أن “المهارات” (skills) أصبحت موجودة في كل مكان، وهي جزء من وثائق Claude و Codex الرسمية؟ هل لاحظت أن OpenAI استحوذت على OpenClaw؟ هل لاحظت أن Claude أضافت مؤخرًا وظائف الذاكرة، والصوت، والعمل عن بعد؟

ماذا عن التخطيط (planning)؟ هل تذكر أن الكثيرين اكتشفوا أن التخطيط قبل التنفيذ كان مفيدًا جدًا، وأصبح الآن وظيفة أساسية؟

نعم، تلك مفيدة جدًا!

هل تذكر أن “stop-hooks” لا تقدر بثمن، لأنها تقلل من رغبة الوكيل في أداء مهام طويلة جدًا… ثم، مع إصدار Codex 5.2، اختفى ذلك الطلب بين ليلة وضحاها؟

هذه هي المعلومات التي تحتاج إلى معرفتها… إذا كان شيء ما مهمًا وذو فائدة، فإن Claude و Codex سيحققانه بنفسه! لذلك، لست بحاجة للقلق كثيرًا بشأن استخدام “أشياء جديدة” أو “مألوفة”، ولا حتى إلى “البقاء على اطلاع”.

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

الضغط، والسياق، والافتراضات

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

“هل هذا الشيء ذكي؟ إنه أحمق حقًا!”

الفرق الأكبر هو ما إذا كان الوكيل مضطرًا لعمل افتراضات أو “ملء الفراغات”. اليوم، لا تزال قدراته على “ربط النقاط” و"ملء الفراغات" أو عمل الافتراضات ضعيفة جدًا. طالما يفعل ذلك، يمكنك أن تراه بوضوح، وتصبح الحالة أسوأ بشكل واضح.

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

إخبار الوكيل بكيفية إنهاء المهمة

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

هذا غالبًا ما يؤدي إلى نتائج محبطة جدًا: ينتهي الوكيل بتنفيذ مجموعة من القوالب (stubs) ويوقف.

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

ثم، ببساطة، تراجع عن الاختبارات، وعندما تمر جميعها، يمكنك أن تطمئن. يمكنك أيضًا أتمتة ذلك، لكن المهم — تذكر أن “إنهاء المهمة” طبيعي للبشر، وليس كذلك للوكيل.

هل تعلم أن هناك الآن طريقة عملية لتحديد نهاية مهمة؟ هي التقاط لقطات شاشة (screenshot) والتحقق منها. يمكنك أن تطلب من الوكيل تنفيذ شيء حتى تمر جميع الاختبارات، ثم يلتقط لقطة شاشة ويحقق من أن “التصميم أو السلوك” في الصورة يتوافق مع المطلوب.

هذا يتيح لك أن تكرر وتوجه الوكيل نحو التصميم الذي تريده، دون أن تقلق من توقفه بعد المحاولة الأولى!

الامتداد الطبيعي لذلك هو أن تخلق عقدًا (عقدة) مع الوكيل، وتدمجها في القواعد. على سبيل المثال، يحدد ملف {TASK}CONTRACT.md ما يجب القيام به قبل أن يُسمح لك بإنهاء الجلسة. في هذا الملف، تحدد الاختبارات، ولقطات الشاشة، والتحقق الآخر الذي يجب إتمامه قبل أن تعتبر المهمة منتهية.

الوكيل الذي يعمل دائمًا

السؤال الذي يُطرح كثيرًا هو: كيف يمكن للوكيل أن يعمل على مدار 24 ساعة ويظل ملتزمًا؟

هناك طريقة بسيطة جدًا. أنشئ “stop-hook”، يمنع الوكيل من إنهاء الجلسة إلا بعد إكمال جميع أجزاء {TASK}_CONTRACT.md.

إذا كان لديك 100 عقد واضح المعالم، يتضمن كل ما تريد بناؤه، فإن stop-hook سيمنع الوكيل من إنهاء الجلسة حتى يكتمل جميع العقود، بما في ذلك جميع الاختبارات والتحقق المطلوب.

نصيحة محترف: أجد أن الجلسات التي تستمر 24 ساعة ليست فعالة جدًا في “العمل”. السبب جزئيًا هو أن هذا الأسلوب يفرض من الناحية الهيكلية تضخم السياق، لأن جميع العقود غير ذات الصلة تدخل في نفس الجلسة!

لذا، لا أوصي بذلك.

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

أنشئ طبقة تنسيق (Orchestration layer) تخلق عقدًا جديدًا عند الحاجة، وتدير جلسات جديدة لكل عقد.

هذا سيغير تمامًا تجربة استخدام الوكيل لديك.

التكرار، التكرار، التكرار

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

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

ثم، أضف تفضيلاتك تدريجيًا. كيف تفعل ذلك؟

القواعد

إذا كنت لا تريد أن يقوم الوكيل بشيء معين، فقم بكتابته كقاعدة. ثم أخبر الوكيل في CLAUDE.md أن يتبع هذه القاعدة. على سبيل المثال: “قبل كتابة الكود، اقرأ coding-rules.md.” يمكن أن تتداخل القواعد، ويمكن أن تكون شرطية! إذا كنت تكتب كودًا، اقرأ coding-rules.md؛ إذا كنت تكتب اختبارًا، اقرأ coding-test-rules.md؛ إذا فشل الاختبار، اقرأ coding-test-failing-rules.md. يمكنك إنشاء قواعد منطقية متعددة يتبعها الوكيل، وClaude (و Codex) سيكون سعيدًا باتباعها، طالما أن التعليمات واضحة في CLAUDE.md.

في الواقع، هذه هي نصيحتي العملية الأولى: اعتبر CLAUDE.md بمثابة دليل منطقي ومتداخل، يوضح أين تبحث عن السياق في حالات وظروف معينة. يجب أن يكون مختصرًا قدر الإمكان، ويحتوي فقط على منطق IF-ELSE يحدد أين تبحث عن السياق في كل حالة.

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

المهارات (Skills)

المهارات (Skills) تشبه القواعد، لكنها أكثر ملاءمة لوصف “خطوات التشغيل” أو الإجراءات. إذا كانت لديك طريقة معينة تريد أن يتم بها إنجاز شيء، فقم بدمجها في مهارة.

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

كيف تعرف الوكيل بوجود هذه المهارة؟ نعم! اكتب في CLAUDE.md: “عندما أواجه هذا السيناريو، اقرأ ملف المهارة هذا SKILL.md.”

التعامل مع القواعد والمهارات

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

بمجرد أن تبدأ في ذلك، ستشعر أن الوكيل كأنه سحر. سيفعل “كما تريد”. وعندها، ستشعر أنك “فهمت” هندسة الوكيل.

ثم…

ستبدأ الأداءات في الانخفاض مرة أخرى.

ماذا يحدث؟!

بسيط جدًا. مع إضافة المزيد من القواعد والمهارات، ستبدأ في التناقض، أو ستظهر مشكلات تضخم السياق بشكل كبير. إذا كان عليك أن تقرأ 14 ملف markdown قبل أن تبدأ في البرمجة، فستواجه نفس المشكلة — وجود الكثير من المعلومات غير الضرورية.

ماذا تفعل؟

نظف. اجعل وكيلك “يعمل سبا” (SPA)، ودمج القواعد والمهارات، ووضح تفضيلاتك المحدثة لتقليل التناقضات.

عندها، سيشعر وكأنه سحر مرة أخرى.

هذه هي السر الحقيقي. حافظ على البساطة، واستخدم القواعد والمهارات، واعتبر CLAUDE.md بمثابة دليل، وكن حذرًا جدًا من سياقاتها وقيود تصميمها.

تحمل المسؤولية عن النتائج

لا يوجد وكيل مثالي اليوم. يمكنك أن تترك الكثير من التصميم والتنفيذ للوكيل، لكنك مسؤول عن النتائج.

لذا، كن حذرًا… واستمتع!

اللعب بألعاب المستقبل (وفي الوقت نفسه، تستخدمها بجدية) هو متعة حقيقية!