الهندسة الوكيلة باستخدام Claude Code وAndroid CLI

مرحبًا، أنا "بن"، من فريق علاقات مطوّري برامج Android.

اسمي "ستيفن"، وأنا مدير منتجات.

واليوم، سنتحدّث عن إنشاء التطبيقات باستخدام Claude Code وAndroid CLI، بشكل آلي.

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

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

الأمر الآخر هو أنّنا استخدمنا Claude Code في هذه الجلسة، ولكنّ المعلومات لا تعتمد على وكيل معيّن.

إنّها طريقة تفكير، لذا يجب تطبيقها على أي أداة تفضّل استخدامها عند إنشاء تطبيقاتك.

لذلك، نريدكم أن تبدأوا بالتفكير في عالم تديرون فيه فِرقًا من الوكلاء المستقلين وكيفية إعدادهم لتحقيق النجاح.

عندما يفشل الذكاء الاصطناعي في تنفيذ ميزة أو شيء من هذا القبيل، بدلاً من الاستسلام والقول: "أوه، لا يمكن للذكاء الاصطناعي فعل هذا بعد"، علينا التراجع والتفكير في المعلومات التي كانت مفقودة، والتعامل معها بالطريقة التي نتعامل بها مع الأخطاء اليوم.

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

لذا، ربما لم يكن هناك وقت أكثر إثارة من الآن لتكون منشئًا أو مطوّرًا لنظام Android، ولكن إذا كنت مثلي، فقد تجد صعوبة في معرفة ما يجب التركيز عليه بالضبط.

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

نريد أن يؤدي كل تحسُّن مستند إلى نموذج إلى سير عمل أكثر ذكاءً لموظفي الدعم، ما يؤدي في النهاية إلى تحقيق نتائج أفضل للمستخدمين.

سنتناول اليوم أربعة مواضيع.

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

بعد ذلك، سنقدّم نظرة عامة على السياق وأفضل طريقة لإدارته.

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

حسنًا، لنبدأ.

إذًا، البيئة.

ولكن ماذا يعني ذلك في الواقع؟

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

لكن هذا يتجاوز مجرد الوصول إلى الكود.

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

هذا هو الأمر الواضح.

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

وأيضًا مثل سجل القرارات السابقة وطلبات السحب.

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

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

أعلم أنّها تبدو مذهلة ويمكنها تنفيذ أي مهمة، ولكنّ المحاكي يساعد كثيرًا.

وينطبق الأمر نفسه على أدوات تحليل الأداء.

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

ويمكن للوكيل أيضًا التفاعل مع أي خدمات خلفية يستخدمها تطبيقك.

وهنا يأتي دور Android CLI.

إذا لم تكن قد سمعت عنه، فقد تم ذكره في جلسة "الجديد في الأدوات" أيضًا، ولكن Android CLI هو واجهة سطر الأوامر الجديدة للتفاعل مع أدوات Android المختلفة.

وهي ليست منتجًا للذكاء الاصطناعي في حد ذاتها، بل هي مجرد واجهة سطر أوامر (CLI).

لذلك، يتيح لك الوصول إلى أشياء مثل Android SDK Manager، والقدرة على بدء المحاكيات، ومجموعة كاملة من الأشياء.

ويمكن ربطها أيضًا بأدوات وأنظمة خلفية مثل Crashlytics.

وهي تعمل مع أي وكيل تستخدمه، وتكون متوفّرة في مساحة واجهة الأوامر.

هذا صحيح.

يمكنك تثبيتها من خلال هذا الرابط، ولكن أعتقد أنّه من الأسهل رؤيتها أثناء العمل.

حسنًا.

لذا، بدلاً من مجرد شرح أهمية إعداد الوكلاء لتحقيق النجاح، أردنا تطبيق هذا المبدأ على تطبيق إنتاجي أنشأناه باسم Sideline.

وSideline هو تطبيق Android للاعبي التنس يقدّم لهم الملاحظات الفورية حول موقع الكرة وموقع اللاعب وموقع الملعب.

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

ويتم تنفيذ كل ذلك من خلال نماذج TF Lite المخصّصة التي تعمل مباشرةً على جهاز Android.

أولاً، أودّ أن أقول إنّه لا يمكننا حلّ المشاكل التي لا نعرف بوجودها.

لذا، باستخدام Android CLI، أضفنا Firebase Crashlytics إلى بيئة المطوّرين، ما سمح لنا بالعثور على بعض المشاكل التي لم نكن نعرف حتى أنّها تحدث.

الأول هو حدوث خطأ "التطبيق لا يستجيب" (ANR) على جهاز Pixel 11 Pro Fold، ولم يتكرر في المحاكي.

لحسن الحظ، تتيح واجهة سطر الأوامر في Android استخدام ميزة "بثّ Android على الجهاز".

وعندما طلبنا من الوكيل حلّ هذه المشكلة، أنشأ اتصالاً بالجهاز الذي حدث فيه خطأ ANR، وكان ذلك مفيدًا جدًا بالنسبة إليّ لأنّني لم أكن أملك هاتف Pixel 11 Pro Fold للتحقّق من الإصلاح.

لذلك، من خلال منح الوكيل إمكانية الوصول إلى الجهاز الذي يحتاجه للتحقّق من الإصلاح، تمكّنا في النهاية من توسيع نطاق الإمكانات المتاحة.

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

بدون الخوض في التفاصيل، كانت المشكلة التي واجهتنا هي استدعاء تقارب يتعلق بنظام Android 17.

كان الإصلاح سريعًا من سطرين، وبدا جيدًا بالنسبة لي.

setenv("KMP_AFFINITY", "disabled", 1);
setenv("KMP_INIT_AT_FORK", "false", 1);

لذلك، أنشأتُ طلب سحب ودمجته وحدّثته بإصدار جديد تم إرساله إلى Play.

لذا، إذا لم نقم بإعداد بيئة الترميز بالقدرات التي تحتاجها للنجاح، فلن نتمكن من تحديد مشكلة حقيقية، ولن نتمكن من التحقق من صحة الإصلاح.

لذا، مع الإصدارات 1.0، يمكنك أن ترى أنه تم حل المشكلة.

ومع ذلك، ظهرت مشاكل جديدة وسنتناولها لاحقًا.

حسنًا.

التالي: السياق.

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

ومع أنّ قدرات الاستيعاب قد استقرّت إلى حدّ كبير، لا تزال إمكانات النماذج في ازدياد.

هذا هو الإصدار 1.0 من Android Bench.

‫Android Bench هو معيارنا الذي يقيس قدرة الذكاء الاصطناعي على كتابة رموز Android البرمجية.

المهام فيه واقعية.

هذه هي أنواع الأشياء التي تعمل عليها، ويمكننا أن نرى أن قدرات الاستيعاب قد استقرت عند علامة المليون، ولكن قدرة النموذج تستمر في الارتفاع.

لكن السياق لا يزال ميزانية ثابتة، وتريد حفظه لما هو مهم.

لا تريد أشياء لا تساعد في حل المشكلة التي تعمل عليها بالضبط.

والكثير من أنظمة توجيه الوكلاء لا تتيح لك الاستفادة من قدرة الاستيعاب الكاملة التي تبلغ مليون رمز مميّز لأنّها ترى أنّ ذلك غير مفيد.

وتزداد النتائج سوءًا عندما يفعلون ذلك.

هناك حدّ أقصى يختلف حسب النموذج، ولكن إذا تمكّنت من إبقاء محادثاتك في حدود 150,000 رمز مميّز تقريبًا، ستحصل على الإمكانات الكاملة للنموذج بدون أي تدهور في السياق.

لكنّ السياق لا يقتصر على ما تكتبه.

[
  {
    "role": "system",
    "content": "You are an expert Android engineering agent..."
  },
  {
    "role": "workspace_context",
    "content": { "project_root": "/workspace/android-app", "build_system": "Gradle (Kotlin DSL)", "target_sdk": 35 }
  },
  {
    "role": "available_tools",
    "content": [ { "name": "read_file" }, { "name": "edit_file" }, { "name": "bash" }, { "name": "skill_android_cli" } ]
  },
  {
    "role": "user",
    "content": "ProfileViewModelTest is failing when loading errors. Fix the ViewModel and verify with unit tests."
  },
  {
    "role": "assistant",
    "tool_calls": [ { "name": "read_file", "arguments": { "path": "app/src/main/.../ProfileViewModel.kt" } } ]
  },
  {
    "role": "tool",
    "content": "class ProfileViewModel(...) : ViewModel() { ... // full file contents + Gradle output appended here }"
  }
]

هناك في الواقع الكثير من الأمور التي تحدث وراء الكواليس ولا تراها.

ويتكوّن من عدد من الأجزاء.

الأول هو تعليمات النظام.

يتم توفير تعليمات النظام من قِبل وكيلك.

وهو يشبه طلبًا يخبره بكيفية العمل مع هذا الوكيل، ونوع السلوك الذي يجب أن يتّبعه.

بالإضافة إلى معلومات مساحة العمل، مثل دليل العمل الحالي، وحِزم تطوير البرامج (SDK) المتوفّرة لديك، وأي مهارات مثبّتة، سنتحدث عن ذلك بعد قليل، وأدوات MCP، وأي أدوات يوفّرها وكيلك أيضًا.

يحتاج النموذج إلى معرفة أنّه يمكنه استدعاء هذه الأدوات، ما يستهلك جزءًا من سياق المحادثة.

لكنّ الأهم هو أنّ سجلّ الرسائل الكامل وسجلّ طلبات الأدوات يتم إرسالهما مع كل طلب وكل رسالة جديدة ترسلها إلى وكيلك.

ويمكن أن يتراكم ذلك، خاصةً مع Gradle.

كما نعلم جميعًا، سجلّات Gradle طويلة جدًا ومفصّلة للغاية.

معظم هذه المعلومات غير مطلوبة.

إليك نصيحة سريعة للانتباه إلى ذلك.

يمكنك تشغيل Gradle في الوضع الهادئ.

./gradlew assembleDebug --quiet

أو أنّ أنظمة توجيه الوكلاء الأكبر حجمًا تقتطع هذا النص نيابةً عنك.

لذلك، لا نرسل سجلّ Gradle الكامل إلى Claude Code وAndroid Studio.

ولكن إذا كنت تستخدم أحد الوكلاء البسيطين، لأنّ فلسفتهم الكاملة هي إرسال كل شيء إلى النموذج، والنموذج يعرف أفضل، لذا فإنّ mini-SWE-agent يرسل سجلّ Gradle الكامل، وقد يصبح ذلك مكلفًا للغاية بسرعة كبيرة.

ولكن كيف يمكننا البقاء ضمن هذا الحد السحري البالغ 150,000؟

يكمن الحل في استخدام سير عمل.

وهناك الكثير من مهام سير العمل المتاحة.

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

لذا، يبدأ الأمر بمهارة تُسمى "grill-me".

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

لذا، يمكنك أن تقول، "اختبرني".

أريد إنشاء مدير منبّهات جديد في تطبيقي".

وسيبدأ بطرح أسئلة عليك حول ما يجب تنفيذه فيه، وأين ينتمي.

ويزيل كل الغموض من المشكلة ومن رأسك إلى مشكلة.

بعد ذلك، نُشغّل المهارة التالية، وهي كتابة مستند مواصفات كبير.

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

والفكرة هي أنّ كل عدد من هذه الأعداد يجب أن يتناسب تقريبًا مع هذا الإطار الذي يبلغ 150,000.

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

حسنًا.

لنتحدّث الآن عن AGENTS.md.

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

ولكن بما أنّها تُقدَّم لكل طلب، من المهم أن تقتصر على الأمور التي تنطبق بشكل مثالي في جميع الأوقات.

لذا، فإنّ أنواع الأمور التي تنجح هي قواعد البنية والوحدات.

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

ولكن من المهم حقًا فهمها فقط لحفظها في البداية حول المكان الذي تنتمي إليه هذه الميزة.

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

# AGENTS.md

- UI components belong in :core:designsystem

- Never use java.util.Date;
  always use kotlinx.datetime

## General guidance
- Avoid changing public API signatures. Anything under an `internal` directory
  is not part of the public API and may change freely.
- The SDK code is written for Java 8.

لذا، كما تعلم، في هذا المشروع، نفضل استخدام kotlinx.datetime، وأشياء من هذا القبيل.

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

تختلف سلوكيات النماذج المختلفة عندما يتعلّق الأمر بالسياق الإضافي.

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

وعندما تم إصدار Opus 5، أصدرت Anthropic بيانًا قالت فيه: "في الواقع، لم تعد العواصم تعمل بشكل جيد.

استخدِم الأحرف الصغيرة فقط".

وهذا ما أعنيه: عليك أن تظل على اطلاع دائم.

ولكن من الأمور التي ظلت عالمية إلى حد كبير هي إبقاء الأمر قصيرًا.

لذا، اجعلها أقل من 250 سطرًا تقريبًا.

هذه النصيحة التالية قد تثير بعض الجدل، لأنّني أعلم أنّ الكثيرين يحبّون اتّباعها، ولكن صدرت دراسة في فبراير من هذا العام أظهرت أنّه إذا سمحتم للوكيل بتعديل AGENTS.md الخاص به، سيؤدي ذلك إلى تراجع الأداء بنسبة تتراوح بين %2 و%3 تقريبًا، وهي نسبة ليست كبيرة.

لكن الجزء المهم هو أنه زاد التكاليف بنسبة 20٪.

وبالتالي، فقدنا جزءًا صغيرًا من الأداء، وزادت تكاليفنا بشكل كبير، وكل ذلك بسبب السماح للوكيل بكتابة AGENTS.md الخاصة به.

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

لذا، بسرعة، إليك AGENTS.md لتطبيق Sideline الذي أنشأناه.

هناك أمران أريد الإشارة إليهما هنا.

أولاً، إنّ استخدام بنية محدّدة بوضوح سيوفّر لك الرموز المميّزة وطول السياق.

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

فهو يوفّر إرشادات واضحة ومحدّدة ليتّبعها.

والنقطة الثانية التي أردت الإشارة إليها تتعلّق بالتطبيقات ذات المصدر المغلق.

بالطبع، إذا كان المصدر مغلقًا، لن يتمكّن أي من الوكلاء من استخدام النماذج اللغوية الكبيرة للتدريب على قاعدة الرموز البرمجية الخاصة بك.

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

إذا كان علينا عدم وضع كل شيء في AGENTS.md، كيف يمكننا تغيير سلوك الوكيل أو النموذج؟

الأول هو الخطافات، والخطافات جيدة حقًا لنوع الأشياء التي يضعها الأشخاص في AGENTS.md مثل، قم دائمًا بتشغيل linter عند الانتهاء من الكتابة.

// settings.json

"hooks": {
  "Stop": [{
    "command": "./gradlew lintDebug"
  }]
}

يمكن أن يكون ذلك بمثابة عامل جذب.

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

لذا، بدلاً من كتابة "يجب دائمًا تشغيل linter" أو "يجب دائمًا تشغيل الحزمة الاختبارية قبل الإشارة إلى الانتهاء" في أسفل AGENTS.md، يمكنك استخدام stop hook لتشغيل نص برمجي حتمي، ما يساعد في الحدّ من العشوائية الطفيفة للذكاء الاصطناعي.

مثال آخر، إذا كانت لديك ملفات لا تريد أن يتمكّن الوكيل من قراءتها أو الكتابة فيها، مثل ملفات سرية لا تريد إرسالها إلى خادم، أو AGENTS.md، لا تريد أن يتمكّن الوكيل من الكتابة فيها، يمكنك استخدام دالة ربط لذلك.

لذا، إذا كان لديك خطاف قراءة أو كتابة، فسيتم تمرير الملف الذي يحاول تعديله، ويمكنك فقط إرجاع، "لا، لا يمكنك فعل ذلك".

إنّها مجرد طريقة لإضافة الحتمية.

المهارات هي التالية.

وهناك مهارات لتحويل AGENTS.md إلى عبارات جذابة الآن.

هذا موضوع آخر تمامًا.

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

لذا، فإنّ AGENTS.md مخصّص للمحتوى الذي يظلّ دائمًا ذا صلة بموضوع البحث.

أما المهارات، فهي مخصّصة للأمور ذات الصلة بمواقف معيّنة، وبشكل أساسي التوثيق.

تتكوّن المهارات من ثلاثة أجزاء: الاسم والوصف، وهو الجزء المهم، ويقتصر على 1,024 حرفًا، ثم النص الأساسي.

---

name: android-cli
description: >
  Loaded into context (≤1024 chars)
---
# Skill Body

ويمكن أن يكون النص ضخمًا، ويمكن أن يتضمّن النص نصوصًا برمجية أخرى، وهو أمر شائع جدًا.

يمكنك تنفيذ الكثير من الإجراءات باستخدام المهارات.

لنلقِ نظرة على مثال.

هذا هو وصف Android CLI.

ليس عليك قراءة كل ذلك.

يُرجى العِلم أنّ هذا الوصف الموجز يوضّح الحالات التي يكون فيها Android CLI مفيدًا.

وهذا هو النص.

إنّه ضخم، لذا لا نريد تحميل كل هذه البيانات طوال الوقت، أليس كذلك؟

نريد تحميل هذا فقط عندما نحاول استخدام Android CLI، وهذا ما تمكننا المهارة من القيام به.

ولكن من المهم أن تكون انتقائيًا بشأن المهارات التي تثبّتها.

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

أولاً، يشكّل ذلك خطرًا أمنيًا كبيرًا.

ليس لديكم أي فكرة عمّا تتضمّنه هذه المهارات، فقد تطلب من الوكيل تنفيذ أي إجراء.

لدينا مجموعة من مهارات Android، وأعدكم بأنّنا راجعناها، وهي لا تقول ذلك.

ثانيًا، 100 وصف في 1,000 حرف يساوي 100,000 حرف أضفتها قبل أن تبدأ في الترميز.

لذا، أنت تقترب من تلك النافذة.

لهذا السبب، ننصحك بتثبيت مهارة Android CLI الأساسية لكل شيء، ومن هناك يمكن لـ Android CLI البحث عن المهارات المتاحة وتثبيت المهارات المناسبة لتطبيقك.

> android init

✓ Installed base skill: android-cli

# Audit & add skills only when needed:
> android skills find compose
> android skills add edge-to-edge

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

هناك مهارات لتدقيق المهارات، بالطبع.

لذلك، هناك /skill-doctor في Claude Code، وسيلقي نظرة ويخبرك بالمهارات التي تدرجها والتي لا يتم تفعيلها أبدًا، وبالتالي تضيع فرصة الاستفادة من الوصف الذي يتألف من ألف حرف.

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

مرة أخرى، Android CLI، هذا هو الرابط.

ولكن لديه أمر قائمة المهارات، ثم لنفترض أن لديك التنقل 3 في مشروعك.

android skills list
android skills add navigation-3

‫Navigation 3 هي مكتبة جديدة إلى حدّ ما، لذا لم يتم التدريب عليها كثيرًا بعد، ويمكنك إضافة مهارة Navigation 3.

غالبًا ما نستخدم، عذرًا.

الخطوة التالية هي MCP.

ولكن كثيرًا ما نتلقّى أسئلة حول سبب إنشاء Android CLI كواجهة سطر أوامر وليس كخادم MCP.

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

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

لكن هذا لا يعني أنّ MCP ليس له مكان.

تُعدّ خوادم MCP رائعة للخدمات الخارجية التي تستخدمها حاليًا، خاصةً إذا كانت تستضيف خدمة MCP.

يمكنكم ربط الوكيل به مباشرةً، وهو طريقة لا تتطلّب التثبيت للحصول على سياق إضافي في الوكيل.

وتوفّر حاليًا خدمات مثل GitHub وFigma وSlack خوادم MCP.

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

وكنت أعمل على تحسين الأداء.

كنت أقول دائمًا إنّ Perfetto هي الأداة الوحيدة التي تحتاج إليها لحلّ أي مشكلة في الأداء.

ولكن منحنى التعلم كان حادًا للغاية، كما رأينا للتو في المحادثة الأخيرة من راهول.

لنلقِ نظرة على كيفية مساهمة الذكاء الاصطناعي في تحسين الأداء.

شكرًا، أيمن.

لذلك، لكي يعمل تطبيقنا، Sideline، يجب أن يعمل بمعدل 30 إطارًا في الثانية، وفي الوقت الفعلي.

وكما ترون هنا على هاتف Pixel 10 Pro Fold، نحصل على حوالي 20 إلى 22 لقطة في الثانية فقط.

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

في Android CLI، تتوفّر أوامر Android Profiler.

وعندما نضيفه إلى وكيل الترميز، ونطلب منه تلبية متطلبات الـ 30 لقطة في الثانية، يحدث أمران مثيران للاهتمام.

الأولى هي العثور على حلّ باستخدام أمر محلّل Android.

وقد سجّلت سجلّات تتبّع النظام على جهاز Pixel 10 Pro Fold المرفق، ووجدت أنّ سلاسل الذكاء الاصطناعي كانت تعمل على أبطأ النواة في الجهاز.

والأمر الثاني هو أنّه استخدم ميزة البحث في مستندات Android، ومن المثير للاهتمام أنّه فعل ذلك بدون أن نطلب منه صراحةً، واستخرج الإرشادات الرسمية لواجهة Performance Hint API.

ما تعلّمه الوكيل هو تحسين جدول النظام، وبذلك تمكّن من تلبية متطلبات الـ 30 لقطة في الثانية.

إذًا، ما حدث في الأساس هو أنّ الإصلاح اتّبع الإرشادات.

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

بعد تشغيل التطبيق، يمكنكم ملاحظة أنّ Sideline يستوفي متطلبات المستخدمين المتمثلة في عرض 30 لقطة في الثانية، ويعمل الآن على هاتف Pixel 10 Pro Fold.

حسنًا.

والآن، سنجمع كل ذلك معًا باستخدام الحلقات.

أنا متأكد من أنّنا جميعًا مررنا بهذا الموقف: نطلب من الوكيل إجراء تغيير كبير، فيعود ويقول إنّه تم.

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

علينا التوقف عن اختبار جودة الوكيل وتحديد ما نعتبره منجزًا مسبقًا.

إليك مثالاً على ذلك.

نريد نقل المشروع بأكمله إلى Nav3، ثم يختفي الوكيل، ويستغرق الأمر بعض الوقت، ولكنّه يعود بثقة ويقول: "اكتملت عملية النقل.

أنا الأفضل".

ولكن بعد ذلك، بالطبع، تقوم بتدوير الهاتف، ويتعطل التطبيق، ويفوت جميع انتقالات الشرائح، ولم يقم بتنظيف ملف Gradle الخاص به.

هذا يشبه إلى حد ما العالم الذي نعيش فيه الآن.

من الناحية المثالية، لن نضطر إلى القيام بذلك، ولكن هذا هو الواقع الحالي.

لذا، كان علينا تحديد كل ذلك مسبقًا أولاً بشأن ما نتوقعه، وكان ذلك سيسمح للوكيل بالتكرار حتى يستوفي كل هذه المعايير.

هذا ما يُعرف بحلقة التحقّق.

ولدينا بيانات قوية جدًا حول فعالية هذه الطريقة.

هذا هو Android Bench 2.0، وهو الإصدار الجديد من مقياس أداء الذكاء الاصطناعي الذي ذكرته في بداية حديثي.

تبلغ معدلات النجاح حاليًا حوالي 40%.

هذه المهام صعبة للغاية، وهي كبيرة وواقعية، ولكن إحداها هي Nav2 إلى Nav3، وهي من نوع الأشياء التي تقوم بها في مشاريعك في الوقت الحالي.

وإذا أخذنا Fable 5.1، فإنّ معدّل نجاحه هو %22، وهذا ما يحصل عليه فقط من خلال إعداد الطلب الطبيعي، مثل "نقل Nav2 إلى Nav3".

ولكن إذا قدّمنا له حزمة اختبارية غير ناجحة مسبقًا، فهذا لا يعني أنّنا نقدّم له الإجابات، ولا نُخبره بكيفية الانتقال إلى Nav3، بل نقدّم له حزمة اختبارية غير ناجحة بالفعل وستنجح عند اكتمال كل هذه الأمور، فترتفع معدلات نجاحه في المعيار بأكمله إلى %90.

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

وبالتالي، ليس عليك كتابة حزمة اختبارية كاملة غير ناجحة مسبقًا.

يمكن أن تكون حلقات التحقّق بسيطة مثل إضافة طلبات.

لنفترض أنّك تعمل على واجهة المستخدم، يمكنك أن تطلب من Gemini عرض معاينة Compose والتأكّد من تطابقها مع مواصفات Figma، ثم عرض النتائج لك.

يبدو أنّ هذه الطريقة فعّالة عندما تطلب منه عرض النتائج وإثبات أنّه تم تنفيذها، بدلاً من قبول الردّ النصي "لقد انتهيت".

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

هناك مهارة مضمّنة في Claude Code لمساعدتك في إنشاء حلقات التحقّق الآن.

لذا، تأكَّد من الاطّلاع عليها.

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

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

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

ولكن يستغرق تشغيل الرحلات بعض الوقت.

لذا، ما يمكنك فعله أيضًا هو تصنيف مستويات حلقة التحقق.

لذا، يمكننا أن نطلب منه أولاً التأكّد من أنّ اختبارات الوحدات ومعاينات Compose يتم عرضها بشكل صحيح.

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

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

لأنّ النماذج واثقة جدًا من نفسها.

لذلك، يعتقدون دائمًا أنّهم أكملوا المهام، وأنّهم سيجتازون جميع الاختبارات من المرة الأولى.

لذا، لنلقِ نظرة على ذلك في Sideline.

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

وبما أنّنا لا نملك أجهزة بعد، سنستخدم بالطبع محاكي XR ونطلب من وكيل الترميز توسيع نطاق Sideline ليتوافق مع شكل الجهاز الجديد.

عند إجراء ذلك، سنطلب من وكلائنا تحديدًا تكرار اختبارات JVM واختبارات معاينة Compose واختبارات المحاكي بهذا الترتيب.

ويتم توجيه كل حلقة للبناء على الحلقة السابقة لها.

وعندما نفعل ذلك، فإن أول شيء نلاحظه هو أنه بين الحلقة الأولى والثانية، فإن اختبارات JVM هي التي تُستخدم لتحديد حالات معاينة Compose الست.

بالطبع، لم يتم استدعاء أي محاكي، لذا يتم تشغيله بسرعة كبيرة.

وبالمثل، بين الحلقة الثانية والحلقة الثالثة، يتم رصد المشاكل مثل السلاسل الطويلة وحلّها حتى قبل تشغيل المحاكي.

أخيرًا، بعد تشغيل حلقة المحاكي، يتم العثور على أخطاء إضافية لم يتمكّن اختبار JVM ومعاينات Compose من إصلاحها.

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

وإليك النتيجة.

يُظهر الفيديو أنّ النظارات تعرض الآن نوع الضربة وسرعة الكرة التي تخرج من المضرب، ما يتيح لك لعب التنس والحصول على ملاحظات حول طريقة لعبك في الوقت الفعلي بدون أن ترفع عينيك عن الكرة.

لقد ذكرتُ سابقًا أنّنا سنعود إلى مشكلتَي Crashlytics اللتين ظهرتا من قبل.

بما أنّنا تأكّدنا من فعالية هذا النهج، يمكننا استخدام الأمر ‎/schedule في Claude Code لتكرار العملية، ويمكننا ضبط أي وتيرة نريدها، وبذلك يصبح لدينا تطبيق ذاتي الإصلاح يعالج جميع الأخطاء ويتأكّد من إصلاحها، ثم يرسلها كطلبات سحب إلى المهندسين لمراجعتها ودمجها.

رائع.

هذا كل شيء لليوم.

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

هذه هي الطريقة التي نتيح بها الوكلاء المتوازيين.

ستجد الكثير من النصائح حول هذا الموضوع على الإنترنت، والكثير منها سيتعارض مع بعضها البعض.

وهذا هو واقع هذه البيئة السريعة الحركة.

لذا، أفضل ما يمكنك فعله هو كتابة تقييماتك الخاصة لمشروعك.

وعندما تظهر نصيحة جديدة أو نموذج جديد، يمكنك قياسه ومعرفة ما إذا كان مفيدًا لك.

وبالطبع، هناك مهارة لكل شيء.

تتوفّر مهارة لمساعدتك في إنشاء تقييمات في Claude Code.

/claude-api build-eval

أنصحك بالاطّلاع عليها.

تحدّثتُ اليوم عن Android Bench.

‫Android Bench هو أداة التقييم التي نستخدمها.

وهي الطريقة التي نقيس بها للتأكد من أن الأمور تتحسن.

إذا أردت معرفة الدروس التي تعلّمناها من إنشاء هذا المعيار لتجنُّب ارتكاب الأخطاء نفسها، يمكنك الاطّلاع على جلسة Android Bench.

هناك أيضًا لوحتان.

هناك واحد في الولايات المتحدة، وهناك واحد في لندن.

سيتم نشر كلاهما على الإنترنت، وهما يتناولان هذا المفهوم من الناحية العملية في المنتدى.

لذلك، سينضم إلينا أعضاء من منتدى مطوّري Android للتحدّث عن كيفية تطبيق هذه الممارسات في وظائفهم.

ونريد أيضًا معرفة ملاحظاتك.

نريد حقًا معرفة ما إذا كنا ننشئ الأشياء التي تساعدك بالفعل.

لذا، يُرجى ملء الاستطلاع.

سأترك ذلك على الشاشة.

وهذا كل شيء.

شكرًا على الاستماع.

شكرًا لك.