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

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

المؤلف: sysls

الترجمة: Deep潮 TechFlow

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

النص الكامل:

مقدمة

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

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

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

أيضًا، ليس لدي مصالح شخصية. أقول أن 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 (أي بعد كل ضغط على زر التلخيص). كجزء من قواعد الحصول على السياق، يمكن أن تكون بعض التعليمات البسيطة ذات تأثير كبير: إعادة قراءة خطة المهمة، وإعادة قراءة الملفات ذات الصلة قبل المتابعة.

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

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

هذا غالبًا ما يؤدي إلى نتائج محبطة جدًا: ينتهي الوكيل بمجرد إنشاء مجموعة من النماذج الأولية ويوقف.

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

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

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

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

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

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

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

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

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

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

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

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

أنشئ طبقة تنسيق تنشئ عقدًا جديدًا عند الحاجة، وتبدأ جلسة جديدة لمعالجة ذلك العقد.

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

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

هل استأجرت مساعدًا إداريًا، وتتوقع أن يعرف جدولك منذ اليوم الأول؟ أو كيف تشرب القهوة؟ أو هل تتناول العشاء في الساعة 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 قبل أن يبرمج، فستواجه نفس المشكلة — معلومات غير ضرورية تتراكم.

ماذا تفعل؟

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

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

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

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

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

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

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