نصائح عملية لبوريس "9 كود": اتضح أن تكوين الماستر "بسيط" جدا. بوريس شيرني لديه لقب في عالم الأنثروبيك: والد كلود كود. لقد كان نشطا مؤخرا على X، لذا يسأل الكثيرون بوريس: كيف تستخدم كلود كود بنفسك بالضبط؟ لقد شارك للتو 9 نصائح عملية عن X. لا توجد الكثير من الحيل كما تعتقد، وكل واحدة منها بسيطة. [1] الفلسفة الأساسية: لا توجد إجابة موصوفة لأفضل ممارسات كود في كلود افتتح بوريس بالقول: > إعدادي قد يكون عاديا بشكل مفاجئ! Claude Code يعمل بشكل ممتاز من العلبة، لذلك شخصيا لا أخصصه كثيرا. > قد يكون إعدادي "أصليا" كما تتوقع. كود كلود يعمل بشكل رائع من البداية، وشخصيا لم أقم بالكثير من التخصيص. من المفهوم أن تلك الممارسات المثلى، مثل المهارات والإضافات، قد تم تضمينها منذ زمن طويل في الميزات كمطورين لكود كلود. لا توجد طريقة واحدة صحيحة لاستخدام كود كلود. الفريق صمم اللعبة عمدا ليتم رميها بشكل عفوي، ويمكنك استخدامها كما تريد، وكيف تريد تغييرها، وكيف تريد تغييرها. كل شخص في فريق كود كلود يستخدمه بطريقة مختلفة تماما. لذا لا داعي للصراع في إيجاد "أفضل الممارسات"، الأهم هو أن تتناسب مع إيقاعك الخاص. [2] مهام متعددة الوكلاء بالتوازي: فتح أكثر من اثني عشر كلود في نفس الوقت روتين بوريس اليومي كالتالي: يفتح 5 نسخ من رموز كلود في الطرفية، يضع أرقام التبويب من 1 إلى 5، يفعل إشعارات النظام، ويتجاوز أي واحدة يجب إدخالها. وفي الوقت نفسه، يدير أيضا من 5 إلى 10 مهام على النسخة الإلكترونية. يمكن للطرفيات وصفحات الويب "تسليم" بعضها البعض: استخدام رمز & لنقل الجلسة المحلية إلى صفحة الويب، أو استخدام --التنقل للتبديل ذهابا وإيابا على كلا الجانبين. يطلق عدة مهام من تطبيق كلود على هاتفه كل صباح وخلال النهار، ويعود لاحقا لرؤية النتائج. المنطق الأساسي لهذه الطريقة "متعددة الخيوط" هو أن كود كلود جيد في الاستقلالية، والعديد من المهام لا تتطلب منك مراقبتها. تبدأ المهمة، تعطيها اتجاها، تتركها تعمل، وتفعل شيئا آخر بنفسك. قلل العدد عندما يحتاج إلى تأكيدك. هذا يختلف تماما عن الأسلوب التقليدي "الإنسان يكتب سطرا من الكود، الذكاء الاصطناعي يشكل عدة أسطر". ومع ذلك، هذا يتطلب أيضا متطلبات مستخدم أعلى، ويجب أن تكون جيدا في توزيع المهام للوكلاء وأن تكون قادرا على التبديل بين عدة مهام في أي وقت. هذا يمثل تحديا كبيرا لنماذج التطوير التقليدية التي اعتادت التطوير بنفسها ولديها مهمة واحدة فقط في نفس الوقت. أشعر بالخجل من القول إنه رغم أنني أستخدم Coding Agent بانتظام، إلا أنني ما زلت غير معتاد على تنفيذ الكثير من المهام في نفس الوقت، لذا سأقوي ممارستي في هذا المجال هذا العام. [3] اختيار النماذج: لماذا تستخدم أوبوس بدلا من السونيتة الأسرع يقول بوريس إنه يستخدم أوبوس 4.5 في جميع مهامه مع وضع التفكير. هذا أفضل نموذج برمجي استخدمه على الإطلاق. سيسأل البعض: أليس أوبوس أكبر وأبطأ من سونيت؟ إجابة بوريس هي أنه رغم أن الاستجابة الفردية أبطأ قليلا، إلا أنك تحتاج لتصحيحها أقل بكثير، وأن استدعاءات الأدوات أكثر دقة، والنتيجة النهائية أسرع. في الواقع، لطالما اتفقت أن كتابة الكود لا يمكن أن تكون سريعة، بل يجب أن تكون عالية الجودة، وإذا كان النموذج السريع يتطلب تصحيحه ثلاث مرات، فمن الأفضل استخدام نموذج بطيء للقيام بذلك دفعة واحدة. الوقت ليس فقط عن وقت استجابة النموذج، بل يتعلق أيضا بانتباهك وتكاليف جهدك. المشكلة الوحيدة هي أن أوبوس أغلى. 【4】 هو ملف تكوين خاص من كود كلود، موضوع في جذر المشروع. في كل مرة تبدأ فيها Claude Code، يقرأ الملف تلقائيا ويعتبر محتواه "معرفة خلفية". يمكنك أن تفهم الأمر كالتالي: هذه هي مواصفة المشروع التي كتبتها إلى الذكاء الاصطناعي، تخبره بهيكل المشروع ومواصفاته واحتياطاته. نهج فريق بوريس هو أن يتم الحفاظ على مستودع كلود كود بالكامل في Git واحد. كل أسبوع، يضيف الناس أشياء إلى ريغانو. القاعدة بسيطة: في كل مرة ترى فيها كلود يفعل شيئا خاطئا، اكتب فيها "لا تفعل هذا"، وفي المرة القادمة سيعرف. وما هو أكثر إثارة للاهتمام أنهم يستخدمون هذه الآلية أيضا عند مراجعة الكود. سيقوم بوريس @.claude في العلاقات العامة لزميله ويطلب من كلود إضافة قاعدة جديدة إلى . يتم تحقيق ذلك من خلال GitHub Action الخاص ب Claude Code. يصف دان شيبر هذا بأنه "مشروع فائدة مركبة": كل تصحيح خطأ يصبح أصلا للفريق، مما يسمح الذكاء الاصطناعي بفهم مشروعك بشكل أكثر فأكثر. إذا لم تستخدم الأمر بعد، سيقوم Claude تلقائيا بتحليل هيكل المشروع وإنشاء نسخة أولية. ثم تضيف حسب الاستخدام، وتضيف ما هو خطأ عندما تراها. [5] وضع الخطة: فكر بوضوح قبل أن تفعل ذلك يقول بوريس إنه يبدأ معظم جلساته في وضع الخطة. انقر مرتين على Shift+Tab في كود كلود للتبديل. في وضع الخطة، لا يغير كلود الكود مباشرة، بل يعطيك خطة التنفيذ أولا. يمكنك مناقشة ومراجعة خطتك ذهابا وإيابا حتى تشعر بالرضا. ثم ينتقل إلى وضع القبول التلقائي، وهو ما يفعله كلود عادة دفعة واحدة. "التخطيط الجيد مهم جدا"، هذه العادة تنقل فعليا الحكمة الكلاسيكية لتطوير البرمجيات إلى التعاون الذكاء الاصطناعي: التصميم أولا ثم البرمجة. المشكلة التي تجعل الكثير من الناس يستخدمون الذكاء الاصطناعي لكتابة الكود هي بدء البرمجة مباشرة، والنتيجة هي أن تكلفة إعادة العمل مرتفعة بسبب الاتجاه الخاطئ. قضاء بضع دقائق في تنسيق خطتك يوفر ساعات من إعادة التصميم. [6] أتمتة العمل المتكرر: أوامر القطع والوكلاء الفرعيين كان لدى بوريس عدة عمليات كان عليه القيام بها عشرات المرات يوميا، وجعلها أوامر قطع. على سبيل المثال، "/commit-push-pr" يكمل إنشاء التقديم، والدفع، وإنشاء العلاقات العامة بنقرة واحدة. أوامر الشريحة هي في الأساس ملفات ماركداون توضع تحت مجلد .claude/commands/. يمكنك كتابة أوامر بلغة طبيعية، ويمكنك أيضا تضمين سكريبتات bash للحصول على بعض المعلومات مسبقا، مما يقلل عدد المكالمات ذهابا وإيابا على النموذج. يمكن إرسال هذه الأوامر إلى Git ومشاركتها من قبل الفريق بأكمله. بالإضافة إلى أمر القطع، يستخدم أيضا وكيلا فرعيا (الوكيل هو حالة منفصلة من كلود متخصصة في أنواع معينة من الأعمال). على سبيل المثال، لديه وكيل فرعي لمبسط الشيفرة يقوم تلقائيا بتبسيط الكود بعد أن يكمل كلود الرئيسي عمله. هناك أيضا وكيل فرعي للتحقق من التطبيق مسؤول عن الاختبار من طرف إلى طرف. ما يجمع هاتان الميزتان هو أنك تثبت ما تفعله مرارا وتكرارا وتدع كلود يسميه بنفسه. لا تحتاج إلى تكرار الشرح في كل مرة أو تذكر تفاصيل الأمر. استخدم PostToolUse Hook لتنسيق الكود الذي يولده كلود. عادة ما يولد كلود كودا منسقا جيدا تلقائيا، ويتعامل هذا الخطاف مع آخر 10٪ من الكود لتجنب سوء التنسيق لاحقا في عملية التكامل المستمر (CI). [7] الأمان والتكامل: تكوين الأذونات والأدوات الخارجية بوريس لا يستخدم خيار --تخطي الأمور بشكل خطير. بدلا من ذلك، يوافق مسبقا على بعض أوامر الأمان الشائعة باستخدام أمر /permissions لتجنب فتح صندوق التأكيد في كل مرة. يتم حفظ هذه التكوينات في ملفات .claude/settings.json ويتم مشاركتها من قبل الفريق. والأكثر قوة هو دمج خوادم MCP. MCP، اختصار ل Model Context Protocol، هو بروتوكول قياسي أطلقته شركة Anthropic يسمح الذكاء الاصطناعي بالاتصال بأدوات خارجية. مع MCP، يمكن لكلود كود أن يصدر مباشرة ما يلي: - البحث وإرسال رسائل Slack - تشغيل استعلامات BigQuery للإجابة على أسئلة البيانات - سحب سجل الأخطاء من Sentry كما قدم فريق بوريس تكوين MCP الخاص بسلاك إلى المستودع، واستخدمه الجميع مباشرة من العلبة. هذا يعني أن Claude Code ليس مجرد أداة برمجة، بل هو "مساعد شامل في واحد" يمكنه استدعاء سلسلة أدواتك بالكامل. [8] معالجة مهمة طويلة: دع كلود يتحقق بنفسه بالنسبة للمهام الطويلة، لدى بوريس عدة استراتيجيات: الأول هو السماح لكلود باستخدام وكيل الخلفية تلقائيا للتحقق من النتائج بعد الانتهاء. يمكنك طلبها في الطلب، أو يمكنك استخدام خطاف إيقاف لتفعيله بشكل أكثر حتمية. ملاحظة >: الخطاف هو آلية "الخطاف" الخاصة بكلود كود التي تتيح لك إدخال منطق مخصص في لحظات محددة عندما يقوم كلود بإجراء معين. يمكنك اعتباره "محفز": عندما يحدث حدث، نفذ تلقائيا الأمر أو السكريبت المعين مسبقا. > أوقف هوك هو عندما يرد كلود ويكون مستعدا لتسليم السيطرة. > وثائق ذات صلة: الثاني هو استخدام إضافة ralph-wiggum التي هي في الأساس حلقة Bash": تخيل حلقة ميتة بسيطة (رغم أنها صحيحة) تستمر في تغذية نفس بيان المهمة (ملف الطلب) إلى وكيل الذكاء الاصطناعي، مما يجعله يحسن عمله مرارا وتكرارا حتى ينتهي تماما. الثالثة هي استخدام --permission-mode=dontAsk أو --dangerously-skip-permissions في بيئة الصندوق المفتوح، حتى لا يقاطع كلود بتأكيد الإذن ويعمل حتى النهاية بنفسه. الفكرة الأساسية هي: بما أنها مهمة طويلة، فلا تدعها تنتظرك. امنحه الاستقلالية الكافية والقدرة على التصحيح الذاتي. [9] الأهم: منح كلود قدرات التحقق من صحة يضع بوريس هذا في النهاية، قائلا إن هذا ربما هو العامل الأهم لتحقيق نتيجة جيدة. إذا تمكن كلود من التحقق من عمله، يمكن زيادة جودة الإنتاج النهائي بمقدار 2 إلى 3 مرات. أعطى مثالا: لكل تغيير يقدمونه إلى ، سيختبر كلود نفسه باستخدام إضافات كروم: يفتح المتصفح، يختبر واجهة المستخدم، ويكرر التحديث عندما يجد مشكلة حتى يعمل بشكل صحيح وتصبح التجربة معقولة. تختلف طرق التحقق حسب السيناريو. قد يكون ذلك بتشغيل أمر bash، أو تشغيل مجموعة اختبار، أو اختبار تطبيق في متصفح أو محاكي هاتف محمول. الشكل ليس مهما، لكن الأهم هو: دع الذكاء الاصطناعي يمر بحلقة تغذية راجعة. هذه الحقيقة بسيطة جدا. يعتمد المهندسون البشريون أيضا على دورة "الكتابة واختبار الشيفرة ورؤية النتائج والتعديل" لضمان الجودة. وينطبق الأمر نفسه على الذكاء الاصطناعي. إذا كان بالإمكان كتابته فقط وليس قياسه، فهو مثل القيام بأشياء وعيناك مغمضتان، والجودة تعتمد على الحظ. اقتراح بوريس هو الاستثمار في ترسيخ آلية التحقق. هذا هو أعلى عائد على الاستثمار. [10] يستخدم الأساتذة السيوف للفوز بدون حركات في روايات الفنون القتالية، لا يمتلك الأساتذة الكثير من الأجراس والصفارات بالسيوف، ولا توجد حركات للفوز. بوريس لا يعرض تكوينات مخصصة معقدة، ولا يحتوي على محفزات خاصة غامضة، ويستخدم وظائف رسمية. الفرق هو أنه يفهم حقا المنطق وراء هذه الميزات ثم يدمجها في سير عمل فعال. يتم العمل المتوازي لأن كلود يمكنه التنفيذ بشكل مستقل؛ يستخدم أوبوس بسبب الكفاءة العامة الأعلى؛ بل هو تحويل تصحيح الأخطاء إلى أصول؛ وضع الخطة هو التفكير بوضوح قبل القيام بذلك؛ أوامر القطع والوكلاء الفرعيون هي عمل متكرر مؤتمت؛ آلية التحقق هي إعطاء تغذية راجعة الذكاء الاصطناعي بحلقة مغلقة. إذا كنت تبدأ للتو مع كلود كود، فلا داعي للعجلة في التكوينات المتقدمة. استخدم الأساسيات جيدا أولا: تعلم العمل بالتوازي، تعلم التخطيط، وتعلم كيفية جمع طرق التحقق من الذكاء الاصطناعي. عندما تواجه عنق زجاجة فعلا، لم يفت الأوان بعد لرمي تلك الزهور.

شيء واحد لم يذكره بوريس هو سير عمل CI/مراجعة الكود الأساسي، والذي قد يكون أمرا طبيعيا لشركاتهم الكبيرة ويجب أن يكون موجودا بشكل افتراضي على سبيل المثال، عندما يكمل مهمة باستخدام كود كلود، لا يقول أن يتم الاندماج مباشرة مع الفرع الرئيسي، بل يقدم طلب إقامة شخصية. بعد تقديم طلب الإقامة الدائمة، سيتم تشغيل جميع اختبارات الوبر والاختبارات الآلية تلقائيا على خادم CI، وإذا فشل الاختبار، لا يمكن دمج الPR. المسؤول الرسمي يجتاز جميع الاختبارات الآلية ويحتاج إلى شخص يقوم بمراجعة الكود (بالطبع، المساعدة الذكاء الاصطناعي ممكنة، لكنها لا تزال بحاجة إلى تأكيد)، وإذا وجدت مراجعة الكود مشاكل، يجب مراجعتها. بالنسبة للعديد من المطورين الأفراد، فهم غير معتادين على بناء سير عمل CI/مراجعة الكود، ولا يقومون حتى بإدارة كود Git، لذلك لا يمكنهم التراجع إذا حدث خطأ ما.

[10] تلك الأشياء التي لا يمكنك رؤيتها شيء واحد لم يذكره بوريس هو سير عمل التحكم في المصدر/CI/مراجعة الكود الأساسي، والذي قد يكون أمرا طبيعيا في شركاتهم الكبيرة ويجب أن يكون موجودا بشكل افتراضي على سبيل المثال، عندما يكمل مهمة باستخدام كود كلود، لا يقول أن يتم الاندماج مباشرة مع الفرع الرئيسي، بل يقدم طلب إقامة شخصية. بعد تقديم طلب الإقامة الدائمة، سيتم تشغيل جميع اختبارات الوبر والاختبارات الآلية تلقائيا على خادم CI، وإذا فشل الاختبار، لا يمكن دمج الPR. المسؤول الرسمي يجتاز جميع الاختبارات الآلية ويحتاج إلى شخص يقوم بمراجعة الكود (بالطبع، المساعدة الذكاء الاصطناعي ممكنة، لكنها لا تزال بحاجة إلى تأكيد)، وإذا وجدت مراجعة الكود مشاكل، يجب مراجعتها. هذه أيضا أساس قدرتهم على تعدد المهام بالتوازي، وبدون هذه السير العملي الأساسي، لا يمكنهم القيام بتعدد المهام بالتوازي. بالنسبة للعديد من المطورين الأفراد، فهم غير معتادين على بناء سير عمل CI/مراجعة الكود، ولا يقومون حتى بإدارة كود Git، لذلك لا يمكنهم التراجع إذا حدث خطأ ما.