كيفية استخدام JetBrains Air: دليل عملي لأول مهمة

يبدأ فهم كيفية استخدام JetBrains Air من وظيفتها الأساسية: تشغيل وكيل برمجة داخل بيئة JetBrains IDE، وتزويده بسياق محدد من المشروع، ثم مراجعة تعديلاته في المكان نفسه الذي تستخدمه لتصفح الشيفرة واختبارها. ولا ينبغي أن تكون البداية بإعادة هيكلة واسعة. ثبّت Air Alpha، واربط وكيلاً واحدًا، وأرسل إليه ملفًا واحدًا واختبارًا واحدًا فاشلاً، ثم لا تعتمد أي شيء قبل أن يصبح فرق التعديلات ونتيجة الاختبار منطقيين.

كيفية استخدام JetBrains Air باختصار

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

في الجلسة الأولى:

1. ثبّت Air Alpha من Marketplace داخل بيئة التطوير.
2. افتح مشروعًا أو فرعًا يمكن التخلص منه ويحتوي على اختبار تستطيع تشغيله.
3. اختر إعدادًا مسبقًا من New Session، وأبقِ الصلاحيات على Standard Access.
4. أرسل رسالتك الأولى، وأكمل تسجيل الدخول إذا طلبت Air ذلك.
5. أرفق الملف المعني باستخدام @file:.
6. اطلب إصلاحًا صغيرًا واحدًا واختبارًا له.
7. افحص كل ملف تغيّر داخل Agent Sessions.
8. شغّل الاختبار بنفسك، ثم قرر الإبقاء على التعديل أو تحريره أو تسجيله في commit أو التراجع عنه.

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

ما JetBrains Air فعليًا؟

Air هي الطبقة التي تصل مشروعك في JetBrains بوكيل برمجة واحد أو أكثر. ويمكن تشبيهها بمحطة فحص في ورشة نماذج: يضع الوكيل القطعة المقترحة على الطاولة، لكن بيئة التطوير تظل المكان الذي تقيس فيه الملاءمة، وتتحقق من الجودة، وتتخذ القرار النهائي.

وسّع إصدار 22 سبتمبر Air إلى منظومة تضم ثلاثة أجزاء مسماة: Air in JetBrains IDEs للعمل الفردي، وAir Teams للتنسيق والأتمتة، وAir Governance للسياسات والرؤية والتحكم في التكلفة. يركز هذا الدليل على المسار المحلي القابل للتنفيذ، وهو إضافة Air Alpha لبيئة التطوير.

ليست إضافة بيئة التطوير نموذجًا أساسيًا جديدًا. فهي تستطيع تشغيل Codex وGemini وGitHub Copilot وClaude وJunie مباشرة، وتذكر JetBrains أن وكلاء آخرين يمكنهم الاتصال عبر ACP. ويعمل ACP، أو Agent Client Protocol، كواجهة مشتركة بين بيئة التطوير ومنظومة عمل الوكيل الكاملة، بما فيها أدواته وآلية توجيه النماذج.

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

ما الذي ينبغي معرفته قبل التثبيت

Air Alpha إصدار ألفا عام، وليس أداة مستقرة تعمل بهدوء في الخلفية. تحذر JetBrains من احتمال تغير الواجهة والسلوك، وتقول إن التحديثات متوقعة كل أسبوع تقريبًا. لذا افحص التوافق قبل البحث عن أي عطل آخر.

في 23 سبتمبر 2026، كانت حزمة Marketplace الحالية لمسار 2026.2 هي Air 262.8665.463. وهي تدعم IntelliJ IDEA 2026.2 حتى 2026.2.3، وإصدارات 2026.2 المطابقة ضمن بيئات JetBrains المدرجة. كما يضم Marketplace حزمًا لمسار 2026.3، ولذلك قد يختلف رقم بناء الإضافة بحسب مسار إصدار بيئة التطوير لديك.

فحص التوافق في هذا التشغيل

حمّلت IntelliJ IDEA 2026.2.3، بالبناء IU-262.10968.63، إضافة Air 262.8665.463 داخل ملف تعريف معزول، وفهرست مشروع Node مؤقتًا من دون خطأ في الإضافة. وكان الوكيل المكتشف هو codex-cli 0.153.4، لكنه لم يكن مسجلاً للدخول، كما لم يكن النظام المضيف يشغّل جلسة رسومية. لذلك لا نزعم هنا تنفيذ مهمة تفاعلية في Air، أو إنشاء فرق تعديلات، أو نجاح اختبار كتبه الوكيل. وتعتمد خطوات الواجهة التالية على دليل البدء السريع الحالي من JetBrains وعلى التسميات المضمنة في هذا الإصدار من الإضافة.

كيفية استخدام JetBrains Air خطوة بخطوة

1. تثبيت Air Alpha

افتح إعدادات بيئة التطوير، واختر Plugins، ثم انتقل إلى Marketplace، وابحث عن Air Alpha، واضغط Install. أعد تشغيل بيئة التطوير إذا طلبت ذلك.

استخدام Air نفسها مجاني، لكن الوكيل الذي يعمل خلفها قد يظل بحاجة إلى حساب أو اشتراك أو فوترة عبر API. وإذا كانت التكلفة هي ما يؤخر قرارك، فإن مقال هل JetBrains Air مجانية؟ يوضح الفرق بين تكلفة الإضافة وتكلفة الوكيل.

2. افتح مشروعًا ذا عطل منخفض التكلفة

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

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

سجّل خط الأساس قبل فتح الجلسة:

• الفرع الحالي أو worktree المؤقت؛
• أمر الاختبار الدقيق؛
• ما إذا كان الاختبار ينجح أو يفشل حاليًا؛
• الملفات التي تتوقع أن تمسها المهمة.

بهذا تتحول المراجعة إلى مقارنة واضحة بدلاً من الاعتماد على الانطباع.

3. اختر إعدادًا مسبقًا من New Session

يشغّل زر New Session في شريط الأدوات الرئيسي الإعداد المسبق المحدد حاليًا. واستخدم السهم المجاور له عندما تريد اختيار إعداد آخر.

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

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

4. أرسل الرسالة الأولى وصرّح للوكيل

يتم التصريح عندما يحتاج الوكيل إليه فعليًا. اكتب رسالة أولى قصيرة واضغط Enter. إذا عثرت Air على بيانات اعتماد يستخدمها الوكيل بالفعل على جهازك، فستستمر الجلسة. وإلا فستعرض Choose a sign-in method to continue.

يختلف المسار المتاح بحسب الوكيل:

• يمكن متابعة تسجيل دخول الوكيل في المتصفح أو الطرفية؛
• يمكن لترخيص JetBrains AI مؤهل أو لمساحة عمل تابعة لمؤسسة أن يوفر الأرصدة؛
• يفتح Add an AI provider المسار Tools | Air | Accounts لإضافة اشتراك خارجي أو مفتاح API.

داخل Accounts، اختر More Providers، وأضف بيانات الاعتماد المطلوبة، واستخدم Test Connection، ثم احفظ عبر OK، وعد إلى الجلسة واختر مزود الخدمة.

لا تلصق أي سر داخل مطالبة المهمة. مكان بيانات الاعتماد هو مسار الاتصال بمزود الخدمة.

5. أضف السياق الذي تحتاجه المهمة فقط

تستطيع Air إرفاق الملفات وعمليات commit والمهارات من أداة إضافة السياق. ويمكنك كذلك كتابة @file: لملف أو @folder: لمجلد. والفرق مهم: إرفاق ملف واحد ذي صلة يشبه تسليم الفني القطعة المعطلة، أما إرفاق المستودع كله فيشبه إفراغ المرآب فوق طاولة العمل.

في التشغيل الأول، أرفق ملف التنفيذ واذكر أمر الاختبار. ولا تضف ملف الاختبار إلا إذا كان الوكيل يحتاج إلى فهم نمط قائم.

6. اطلب تغييرًا محدودًا ودليلاً على نجاحه

المطالبة الجيدة تحدد العطل، والنطاق المسموح، وأمر التحقق. على سبيل المثال:

أصلح التعامل مع المسافات البيضاء المتكررة في @file:src/slug.js. أضف أو حدّث أصغر اختبار ذي صلة. شغّل node --test. لا تغيّر التبعيات ولا تلمس ملفات غير مرتبطة. إذا تعذّر تشغيل أمر الاختبار، فتوقف واشرح السبب.

تمنح هذه المطالبة الوكيل خط نهاية واضحًا، بخلاف طلب عام مثل «حسّن هذه الدالة المساعدة».

7. تابع الجلسة، لكن لا تقيّم السرد

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

يوفر نص التقدم سياقًا مفيدًا، لكنه ليس دليلاً. الدليل هو فرق التعديلات الناتج مع اختبار تستطيع تكراره.

8. راجع التغيير داخل Agent Sessions

افتح Agent Sessions ووسّع الجلسة المكتملة. افتح فرق التعديلات لكل ملف تغير. تتضمن الحزمة الحالية الإجراءات Show Diff وGenerate summary... وRevert. ويوضح دليل البدء السريع من JetBrains أنه يمكنك الإبقاء على الملفات المعدلة أو تحريرها أو تسجيلها في commit أو التراجع عنها.

راجع بهذا الترتيب:

1. النطاق: هل تغيرت الملفات المتوقعة فقط؟
2. السلوك: هل يحل التنفيذ العطل المحدد بدقة؟
3. جودة الاختبار: هل كان الاختبار الجديد سيفشل من دون الإصلاح؟
4. الآثار الجانبية: هل تغيرت التهيئة أو التبعيات أو الواجهات العامة؟
5. التحقق: هل ينجح الاختبار عند تشغيله خارج سرد الوكيل؟

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

الحسبة التجارية

تغير Air بند التنسيق، لا تكلفة الذكاء الذي يعمل تحتها. تضيف الإضافة $0 إلى تكلفة البرمجيات، بينما قد يستهلك الوكيل المتصل من اشتراك قائم أو رصيد API أو أرصدة JetBrains AI.

وهذا مهم عندما يدفع الفريق بالفعل مقابل الوكلاء. فإضافة واجهة تحكم ثانية تعني غالبًا مقعدًا آخر قبل أن يعرف أحد ما إذا كانت تحسن المراجعة. وكمؤشر علني للمقارنة، تسعّر GitHub حاليًا Copilot Business عند $19 لكل مستخدم شهريًا، وEnterprise عند $39. وتبلغ تكلفة عشرة مقاعد Business مقدار $190 شهريًا قبل أي استخدام إضافي. تستطيع Air الاتصال بالوكلاء المدعومين من دون فرض رسم على إضافة Air، لكنها لا تلغي ترخيص بيئة التطوير، أو اشتراك المزود، أو استخدام API، أو وقت المراجعة البشرية.

لذلك ينحصر سؤال الميزانية العملي في الآتي: هل تستطيع واجهة مراجعة محلية مجانية واحدة تسهيل توجيه الإنفاق القائم على الوكلاء والتحقق من نتائجه؟ اختبر ذلك مع فريق واحد وفئة واحدة من المهام قبل شراء أي شيء آخر أو توحيده.

ست حالات استخدام مرتبة بحسب الأكثر استفادة

1. فرق JetBrains التي تدفع بالفعل مقابل عدة وكلاء

يمكن لفريق هندسي يستخدم Codex لنوع من العمل وClaude لنوع آخر تشغيل كليهما من بيئة التطوير نفسها، وإرفاق سياق المشروع نفسه، ومراجعة الملفات المعدلة في مكان واحد. لا يتمثل العائد الافتراضي في رموز أقل تكلفة، بل في تقليل التنقل بين الأدوات وترسيخ عادة مراجعة موحدة حول الاشتراكات التي يدفع الفريق تكلفتها بالفعل.

2. المشرفون الذين يعالجون أعطالاً صغيرة قابلة للاختبار

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

3. المستشارون الداخلون إلى قاعدة شيفرة غير مألوفة

يستطيع المستشار استخدام تنقل بيئة التطوير لفحص الرموز، وإرفاق الملفات المعنية فقط، ثم طلب تعديل محدود من الوكيل. ويساعد إبقاء العمل داخل فرع مؤقت مع Standard Access على تقليل احتمال أن تتحول أعراف المستودع غير المألوفة إلى تعديل واسع. أما العائد فهو فهم أسرع للمشروع، من دون الادعاء بأن الوكيل يعرف قواعد العميل غير المكتوبة.

4. مهندسو ضمان الجودة الذين يحولون عطلًا قابلاً لإعادة الإنتاج إلى اختبار انحدار

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

5. كبار المطورين الذين يعلّمون المراجعة من خلال فروق تعديلات حقيقية

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

6. فرق المنصات التي تقارن الوكلاء على المهمة نفسها

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

منتجان يستحقان البناء حول هذه التجربة

1. أداة جانبية لتوثيق أدلة مراجعة تعديلات الوكلاء

هذه هي الفرصة الأقوى. ابنِ أداة مصاحبة صغيرة تحوّل جلسة الوكيل إلى حزمة مراجعة تضم المهمة، والسياق المرفق، والملفات المعدلة، وأمر الاختبار، ونتيجته، والقرار البشري، ومرجع commit النهائي. سيدفع مديرو الهندسة والفرق الخاضعة للتنظيم مقابل سجل واضح يعلو الوكيل الذي أنتج الشيفرة، أيًا كان.

الطلب محدد بما يكفي ليكون مهمًا: يحصل الاستعلام ai powered code review platform على نحو 1,900 عملية بحث شهريًا في الولايات المتحدة، وله نية بحث تجارية. كما يبين سعرا GitHub البالغان $19 لمقعد Business و$39 لمقعد Enterprise أن الفرق تخصص ميزانيات بالفعل لمساعدة البرمجة والحوكمة.

لا تحتاج أصغر نسخة قابلة للبيع إلى التحكم في الوكيل. يكفي أن تستقبل فرق التعديلات ومخرجات الاختبار، وتفرض قائمة تحقق على المراجع، وتصدر سجلاً موقعًا بصيغة Markdown أو JSON. لكن الخطر يكمن في المنصة: Air ما زالت في مرحلة ألفا، وقد تتغير واجهاتها أسبوعيًا، وربما تضيف JetBrains بنفسها خصائص أوسع للأدلة أو التدقيق. لذلك يجب أن يكون عنصر الحماية هو السياسات العابرة للوكلاء والتقارير الدائمة، لا مجرد زر بسيط داخل بيئة تطوير واحدة.

2. مستشار لإعداد الوكيل بحسب المستودع

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

الطلب العام كبير: يحصل الاستعلام ai coding assistant على نحو 18,100 عملية بحث شهريًا في الولايات المتحدة، بينما يحصل ai powered coding agent على نحو 8,100. ويمكن أن تبدأ النسخة الأولية القابلة للبيع باستبيان عن المستودع مع ملاحظات إعداد مولدة، ومطالبات بداية محدودة، وقائمة تحقق لاختبار سريع. ولا يلزم في البداية أي تكامل عميق مع بيئة التطوير.

التحدي هو قابلية الدفاع عن المنتج. فقد تستوعب JetBrains أو شركات الوكلاء أو قوالب المستودعات نصائح الإعداد العامة. ويحتاج المنتج القابل للاستمرار إلى فحوص سياسات خاصة بكل مؤسسة، وإلى دليل على أن إعداداته الموصى بها تقلل التعديلات الفاشلة أو الواسعة أكثر من اللازم.

القيود والرأي الصريح

تكون Air في أفضل حالاتها عندما تفضل بالفعل بيئة JetBrains وتريد الاختيار بين الوكلاء من دون التخلي عن المراجعة المدمجة في بيئة التطوير. لكنها ليست مبررًا لتفويض تعديل خطِر لا تستطيع التحقق منه.

هناك ثلاثة قيود مهمة الآن:

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

كذلك لا يعني Standard Access أن الوصول للقراءة فقط. فهو يسمح بالتعديل وتشغيل الأوامر داخل المشروع. استخدم فرعًا أو worktree مؤقتًا، وافحص فرق التعديلات، وأعد تشغيل الاختبار بنفسك.

الخلاصة واضحة: تستحق Air التجربة في تعديل صغير واحد إذا كانت JetBrains مساحة عملك اليومية بالفعل. لكن من المبكر جعلها المسار الإلزامي للمستودعات الحساسة من دون خطة تراجع، وسياسة لمزودي الخدمة، وأدلة مراجعة.

خطوة يوم الاثنين

اختر عطلاً واحدًا له اختبار يعمل بأمر واحد. ضعه على فرع مؤقت، وثبّت بناء Air Alpha المطابق على جهاز مطور واحد، واختر Standard Access، وأرفق ملفًا واحدًا ذا صلة، ثم اطلب أصغر إصلاح مع اختبار انحدار. لا تُبقِ التعديل إلا إذا كان فرق التعديلات ضيقًا ونجح الاختبار عندما شغلته بنفسك. ستخبرك هذه الحلقة الواحدة بأكثر مما يقدمه أسبوع من عروض الوكلاء.

ما وظيفة JetBrains Air؟

تنسق JetBrains Air وكلاء البرمجة وما يرتبط بهم من سياق وجلسات ومراجعة داخل بيئات JetBrains وخارجها. وفي إضافة بيئة التطوير المحلية، تختار وكيلاً، وترسل إليه مهمة مع سياق المشروع، ثم تفحص التعديلات الناتجة داخل Agent Sessions.

ما أبرز الفروق بين JetBrains Air وClaude Code؟

Claude Code وكيل برمجة واحد. أما Air فهي واجهة تحكم ومراجعة متعددة الوكلاء تستطيع تشغيل Claude إلى جانب Codex وJunie وGitHub Copilot وGemini وOpenCode والوكلاء المتوافقين مع ACP، بحسب التكاملات والتصاريح المتاحة.

ما أفضل بيئة تطوير للبرمجة بالوكلاء؟

لا يوجد خيار واحد يتفوق للجميع. تصبح Air جذابة عندما يعتمد فريقك بالفعل على أدوات JetBrains للتنقل والفحص وعرض فروق التعديلات. والخيار الأفضل هو البيئة التي تستطيع فيها تقييد عمل الوكيل وفحصه واختباره والتراجع عنه بثقة.

هل استخدام JetBrains مجاني؟

إضافة Air Alpha مجانية. وقد تكون لبيئة JetBrains وللوكيل الذي يعمل خلف Air تكاليف منفصلة للترخيص أو الاشتراك أو API.

إذا كنت تريد سير عمل آمنًا للوكلاء ومصممًا حول مستودعاتك وقواعد المراجعة لديك، فاطلع على تطوير وكلاء الذكاء الاصطناعي.