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

في هذه المقالة الأولى، بدلاً من استعراض كل ما يفعله Bob، نريد تحقيق ثلاثة أهداف:

إلقاء الضوء على بعض القدرات الأساسية لـ Bob.
مشاركة مجموعة من النصائح العملية لإعداد المستودع حتى يُقدّم Bob أفضل أدائه.
شرح نهجنا في الأمان لأداة تمتلك هذا المستوى من الوصول إلى كودك.

1. ما الذي يقضي المطوّرون وقتهم فيه فعلاً

يستطيع مساعد الذكاء الاصطناعي الحديث كتابة دالّة من وصف. هذا ممكن منذ فترة، ولم يعد السؤال المثير للاهتمام. السؤال المثير هو: ماذا يحدث حين لا يكون العمل "إنتاج كود جديد" بل "تعديل نظام موجود" — إيجاد المكان الصحيح لإجراء التغيير، وفهم الاتفاقيات التي استقرّ عليها الفريق، والحفاظ على الاتساق في الملفات التي تنمو منذ سنوات. هذا هو الجوهر الحقيقي لتطوير البرمجيات الاحترافي. بُني Bob لهذا النوع من العمل، وخياراته التصميمية المذكورة في بقية هذه المقالة تنبع من هذا التركيز.

1.1. الأوضاع: إخبار Bob بنوع العمل الذي تقوم به

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

Ask — للقراءة فقط. مثالي لـ"مرحلة الاستكشاف". يشرح Bob البنية والمنطق دون إجراء تغييرات. استخدمه عند التعمّق في نظام قديم أو إجراء فحص سلامة لمنطق لم تكتبه أنت.
Plan — يضع Bob خطة للتغيير الذي ستجريه: الملفات التي ستُعدَّل، وحالات الحافة التي يجب مراعاتها، والترتيب المقترح للعمل. الناتج خطة، لا كود.
Code — لإجراء التغييرات فعلياً. يقرأ Bob ويكتب ويختبر داخل مشروعك، مع الالتزام بالاتفاقيات والقواعد التي حددتها.
Advanced — يمتدّ على Code من خلال Model Context Protocol (MCP)، مانحاً Bob وصولاً إلى أدوات وخدمات مؤسستك الخاصة: واجهات APIs داخلية، وقواعد بيانات، وأدوات مخصّصة.
Orchestrator — للعمل متعدد الخطوات الذي يتجاوز الأوضاع. يتنقّل Bob بين الأوضاع بنفسه بناءً على متطلبات الخطوة الحالية، وهو الخيار الأمثل للأعمال الكبيرة التي تمزج بين الاستكشاف والتخطيط والتنفيذ.

اختيار الوضع المناسب في بداية الجلسة هو أحد أرخص الأدوات المتاحة للحصول على مخرجات أفضل. عادة جيدة، خاصةً في قواعد أكواد لا تعرفها جيداً أو لتغييرات ذات نطاق واسع، أن تبدأ بـ Ask أو Plan وتنتقل إلى Code فقط حين تكون لديك صورة واضحة عن العمل. الانتقال مباشرة إلى Code يبدو أسرع في اللحظة، لكنّه المكان الذي تتسرّب فيه الافتراضات كتغييرات حقيقية وتتراكم كديون تقنية.

1.2. Bob Tips: مقاييس التعقيد في الوقت الحقيقي

مررنا جميعاً بهذا: أنت غارق في "المنطقة"، تضيف شرطاً أخيراً لمعالجة حالة حافة، وفجأة أصبح في دالّة واحدة ثلاثون سطراً من الفوضى. في سير العمل المعتاد، لا تُحلّ هذه الفوضى حتى ينتبه إليها أحد الزملاء في طلب السحب بعد ساعات. يغيّر Bob Tips هذا النمط بتقديم اقتراح لإعادة البناء بينما لا يزال المنطق طازجاً في ذهنك. أثناء كتابتك، يراقب التحليل الساكن المستمر ملفاتك المفتوحة بصمت. حين تتجاوز دالّة حدّ التعقيد الدوري العالي أو تصبح صعبة الصيانة، يُعلمك Bob فوراً بخطّ أرجواني تحتها. الأداة تركّز كلياً على تقديم اقتراحات إعادة بناء قابلة للتنفيذ:

الذكاء السياقي: التحوّم فوق الخطّ الأرجواني لا يعرض تحذيراً فحسب — بل يقدّم استراتيجية محددة مولّدة بالذكاء الاصطناعي لفكّ تشابك المنطق في الحال. التنفيذ السلس: النقر على "Fix with Bob" يفتح محادثة مخصّصة فوراً. الذكاء الاصطناعي يحمل سياق الدالّة مسبقاً وهو جاهز لتنفيذ التنظيف معك.

المقاييس التي تعمل في الخلفية هي مجرد سبك. القيمة الحقيقية هي أن إشارة جودة الكود القديمة تُحرّك الآن اقتراح الذكاء الاصطناعي في اللحظة التي يكون فيها المطوّر داخل الملف، بدلاً من أن تظهر في مراجعة كود بعد ثلاثة أيام.

1.3. Review mode: مراجعة الكود مع قراءة النظام

أسهمت مراجعة الكود في جودة البرمجيات بقدر أي ممارسة أخرى في العقدين الماضيين، وهي أيضاً حيث تفقد الفرق زخمها. لا يحلّ Bob محلّ المراجعة البشرية. يتولّى الأجزاء الآلية ليتمكّن الآخرون من التركيز على البنية العليا والنية بدلاً من صيد الأخطاء "سهلة القطاف".

تعمل المراجعات من Review Panel في الشريط الجانبي أو عبر /review في المحادثة. هناك وضعان:

مقارنة الفروع. يتعامل هذا الوضع مع الفرق "الكلاسيكي". استخدم /review لمراجعة العمل غير الملتزم مقابل رأس فرعك الحالي، أو /review <branch> لاستهداف فرع بعيد محدد. إنه ضربة استباقية ضد "التعليقات البسيطة" التي تزدحم بها مراجعات الكود عادةً.
تغطية المشكلات. /review <issue-url> --issue-coverage يتحقّق من أن تغييراتك المحلية تعالج فعلاً ما تطلبه مشكلة GitHub. هذا الوضع الذي يخبرنا المطوّرون أنهم لم يدركوا أنهم يريدونه حتى جرّبوه. تظهر النتائج في لوحة مخصّصة حتى تتمكّن من مراجعتها وتقرير إصلاحها مع Bob. إنه فحص سلامة يؤكد أنك لم تكتب كوداً جيداً فحسب، بل الكود الصحيح.

1.4. الترميز الأدبي: النية مكتوبة بجانب الكود

حين تغوص في ميزة معقّدة تستدعي ملفات متعددة في نافذة محادثة، تجد نفسك تكتب "انظر إلى الواجهة في types.ts والخدمة في api.ts، ثم حدّث المنطق هنا..." يقلب Bob هذه الديناميكية. بنقل التفاعل مباشرةً إلى الملف المصدري من خلال Literate Coding، يصبح المحرر نفسه الواجهة. هذا ليس مجرّد تجنّب اللوحة الجانبية؛ بل يوفّر للذكاء الاصطناعي خريطة متطوّرة متعددة الملفات لنيّتك.

التعبير عن النية بشكل طبيعي: فعّل الوضع بـ Cmd+M واكتب منطقك بلغة عادية أو كود شبه صوري. تظهر تعليماتك في المحرر باللون الأزرق، في المكان المناسب تماماً للتنفيذ.
تجاوز السطر الواحد: بينما كثيراً ما تفقد المحادثة التقليدية "الخيط" لمشروع معقّد، يتطوّر Literate Coding في Bob لسدّ الفجوة بين الملفات. يمكن للمطوّرين الآن توفير سياق عبر وحدات متعددة، لضمان انعكاس التغيير في نموذج البيانات بدقة في الـ controller المرتبط.
التحقق الفوري: اضغط Cmd+Enter وسيولّد Bob التنفيذ في مكانه. بما أن النتيجة تظهر كفرق مضمّن، يمكنك مراجعة المنطق مقابل الكود المحيط قبل الالتزام بالتغيير.

الفائدة مباشرة: التعليمة تعيش حيث يعيش الكود، مع الملف المحيط يعمل بالفعل كسياق. النطاق الحالي ملفٌّ واحد؛ دعم الملفات المتعددة في خارطة الطريق.

1.5. Bob في الطرفية

يجلب Bob Shell قدرات Bob إلى سطر الأوامر، وهناك طريقتان لاستخدامه نجدهما مفيدتَين بشكل خاص.

الطرفية كمساحة عمل: أصبح العمل مع مساعد تطوير ذكاء اصطناعي داخل الـ shell شكلاً شائعاً بحدّ ذاته — فهو يتناسق بشكل طبيعي مع طريقة كثير من المطوّرين في إدارة Git والبناء والاختبار، وأصبح جزءاً من سير عمل الفرق اليومي. إنه الطريقة الأكثر موثوقية لجلب الذكاء الاصطناعي إلى الخوادم البعيدة أو البيئات التي لا يتوفر فيها تكامل أصلي مع IDE: في أي مكان لديك فيه طرفية، يمكنك الحصول على Bob.
من الأتمتة الحتمية إلى التكيّفية: يتألّق Bob Shell في الجلسات غير التفاعلية كالمهام المجدوَلة ونصوص النشر في مسارات CI/CD. في أي مكان يستدعي فيه سكريبت أداةً حتمية اليوم، يمكنه استدعاء Bob مع السياق الكامل للمستودع المحيط — والأتمتة الناتجة تكون أكثر تكيّفاً من خط أنابيب ثابت.

سننشر مقالة متابعة حول ما تعلّمناه من تشغيل Bob بشكل غير تفاعلي في CI: الأنماط التي تعمل بشكل جيد عملياً، بما فيها ملخّصات طلبات السحب، وتحديد المخاطر، والتكامل في الأتمتة الموجودة.

2. اجعل مستودعك جاهزاً لـ Bob

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

اختبارات سريعة وموثوقة. إن كان npm test (أو ما يعادله) يستغرق خمس دقائق أو يفشل أحياناً، تتباطأ حلقة التكرار وتتدهور إشارة التغذية الراجعة. الاختبارات التي تنتهي في أقل من دقيقة تُضاعف إنتاجية أي مطوّر؛ وبالنسبة لمساعد ذكاء اصطناعي يعمل في دورات قصيرة، فهي ضرورة.

توثيق أوامر البناء والاختبار. Makefile، أو قسم سكريبتات في package.json، أو مقطع README — مكان يمكن لـ Bob أن يجد فيه "كيف أُشغّل هذا". بدونه، يضطر Bob للاستنتاج، والاستنتاج هو حيث تدخل الأخطاء.

أسلوب قابل للتنفيذ. Linters و formatters تعمل عند الحفظ أو في CI. يستوعب Bob اتفاقياتك منها. القواعد الصريحة القابلة للتحقق الآلي تتفوّق على الاتفاقيات الضمنية في كل وقت.

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

توثيق البنية بصيغة markdown، بجانب الكود. حتى الوثائق القصيرة مفيدة. ملف docs/architecture.md يصف الوحدات وحدودها يُمكّن Bob من الإجابة عن "أين يذهب هذا؟" دون إعادة استنتاج التصميم من الاستيرادات.

بعض ما تعلّمناه على طول الطريق:

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

3. الأمان والتحكّم

يمتلك Bob عدة طبقات من الحماية تعمل معاً بدلاً من أن يتولّى أيّ حاجز واحد كل المسؤولية. الملخّص القصير، المناسب لمقالة أولى:

وافق يدوياً على كل إجراء، أو وافق تلقائياً حسب فئة الأداة (للقراءة فقط مقابل الكتابة) حين تثق في سير العمل.
يُبقي .bobignore Bob بعيداً عن الملفات التي لا ينبغي له قراءتها — بيانات الاعتماد، والمصنوعات المولّدة، وأي شيء حساس.
تُطبّق القواعد المخصّصة معايير الكود على Bob بنفس الطريقة التي تُطبَّق بها على المطوّرين.
تجعل نقاط التحقق التلقائية التعافي من تغيير غير مرغوب فيه عملية بنقرة واحدة.
موجّهاتك لا تُستخدم كبيانات تدريب!

الموافقة التلقائية، تحديداً، تستحق التأمّل. إنها أحد أهم عناصر التحكّم التي تملكها على مقدار ما يمكن لـ Bob فعله بين نقاط التحقق معك، وتوسيعها يمنحك مكسباً في الإنتاجية ولكنّه يطلب منك أيضاً تحديداً أكبر لما يقع داخل هذا النطاق وما لا يقع. الإعداد الافتراضي المعقول لمعظم المطوّرين هو الموافقة التلقائية على أدوات القراءة فقط، وترك إجراءات الكتابة على الموافقة اليدوية لأسابيع قليلة على الأقل، وتوخّي الحذر الشديد مع أي شيء يُشغّل أوامر shell أو يصل إلى أنظمة تتجاوز شجرة العمل المحلية. باقي عناصر التحكّم في القائمة — .bobignore، والقواعد المخصّصة، ونقاط التحقق — مصمَّمة لتتكامل مع الموافقة التلقائية لا لتحلّ محلّها.

4. ابدأ

ثبّت IBM Bob من موقعنا، أو ثبّت Bob Shell عبر طرفيتك المفضّلة.
راجع دليل أفضل الممارسات واطّلع على إرشادات الأمان لدينا.
ابدأ بمهمة حقيقية — تتعلّم بشكل أفضل حين يساعدك Bob في مشكلات حقيقية.

روابط