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

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

المؤلف: sysls

الترجمة: Deep潮 TechFlow

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

المحتوى بالكامل:

مقدمة

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

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

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

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

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

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

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

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

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

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

وكيل يعمل بشكل دائم

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

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

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

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

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

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

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

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

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

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

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

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

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

ثم…

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

ماذا يحدث؟!

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

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

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

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

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

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

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

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