مهندسی عامل‌محور با کد Claude و Android CLI

سلام، من بن هستم، از بخش روابط توسعه‌دهندگان Android.

من استیون، مدیر محصول هستم.

و امروز می‌خواهیم درباره ساختن برنامه‌ها با Claude Code و Android CLI به‌صورت عاملی صحبت کنیم.

بنابراین، فکر می‌کنم منصفانه است که بگوییم نقش ما به‌عنوان توسعه‌دهنده کمی درحال تغییر است و چیزها با سرعت دیوانه‌واری درحال حرکت هستند، درواقع آن‌قدر سریع که، بیایید صادق باشیم، محتوای این گفتگو احتمالاً همین حالا هم قدیمی شده است، به‌ویژه اگر به‌صورت آنلاین تماشا می‌کنید.

بنابراین، ما با آنچه نوشتیم، با اطلاعاتی که ارائه می‌دهیم، موضعی آینده‌نگرانه اتخاذ کردیم، اما نسخه‌های نمایشی که امروز اجرا می‌کنند، بر واقعیت استوار هستند، بنابراین اکنون باید قابل اعتماد باشند.

نکته دیگر این است که ما از Claude Code برای این گفتگو استفاده کرده‌ایم، اما اطلاعات، مستقل از عامل است.

این بیشتر یک طرز فکر است، بنابراین باید برای هر چیزی که ترجیح می‌دهید هنگام ساختن برنامه‌هایتان استفاده کنید، اعمال شود.

بنابراین، می‌خواهیم به دنیایی فکر کنید که در آن تیم‌هایی از عوامل خودکار را مدیریت می‌کنید و آن‌ها را برای موفقیت آماده می‌کنید.

وقتی در پیاده‌سازی یک ویژگی یا چیزی شبیه به آن شکست می‌خورند، به‌جای اینکه فقط تسلیم شوند و بگویند «اوه، هوش مصنوعی هنوز نمی‌تواند این کار را انجام دهد»، باید یک قدم به عقب برگردیم و فکر کنیم که چه اطلاعاتی کم بوده است و به‌نوعی با آن همان‌طور رفتار کنیم که امروزه با اشکالات نرم‌افزاری رفتار می‌کنیم.

و اگر مطالبی را که از تیم‌های سازنده این زیرساخت‌های عامل، Claude Code،‏ Codex،‏ Antigravity منتشر می‌شود خوانده باشید، خواهید دید که تیم‌های آن‌ها درواقع این زیرساخت‌ها را به این شکل توسعه می‌دهند، و اگر آن‌ها را به‌عنوان نگاهی اجمالی به آینده درنظر بگیریم، احتمالاً همه ما به همین سمت می‌رویم.

بنابراین، احتمالاً هیچ‌وقت زمانی هیجان‌انگیزتر از حالا برای سازنده بودن، برای توسعه‌دهنده Android بودن وجود نداشته است، اما اگر مثل من باشید، شاید برایتان سخت باشد که بدانید دقیقاً روی چه چیزی باید تمرکز کنید.

و ما، به‌عنوان توسعه‌دهنده، به ابزارها و گردش کارهایی نیاز داریم که واقعاً با هوش مصنوعی مقیاس‌پذیر باشند، تا وقتی مدل جدیدی مرزها را گسترش می‌دهد، تمام تلاش‌های سخت ما بیهوده نشود.

می‌خواهیم هر بهبود مدل به گردش کار هوشمندتری برای نمایندگان ما منجر شود که درنهایت به نتایج بهتری برای کاربران ما ختم شود.

امروز چهار موضوع را پوشش می‌دهیم.

ابتدا توضیح می‌دهیم که چرا راه‌اندازی عوامل در محیط‌هایی که بتوانند موفق شوند بسیار مهم است.

سپس، نمای کلی‌ای از بافت و بهترین روش مدیریت آن ارائه می‌دهیم.

پس‌از آن، به برخی‌از بهترین ابزارهای دردسترس برای توسعه‌دهندگان Android که در داخل عامل‌ها کار می‌کنند اشاره خواهیم کرد و درنهایت، دلیلی برای افزودن حلقه‌ها به گردش‌های کاری عامل‌محور شما ارائه خواهیم داد.

بسیارخوب، بیایید شروع کنیم.

بنابراین، محیط.

اما این واقعاً به چه معنا است؟

خب، همان‌طور که می‌گفتم، ما در تلاشیم فضایی ایجاد کنیم که در آن نماینده ما بتواند موفق شود، و بتواند بدون اینکه شما مجبور باشید آنجا بنشینید و مدام، مثلاً، دوباره به آن پیام‌واره بدهید و آن را به مسیر درست برگردانید، موفق شود، زیرا وقتی این کار را می‌کنید، آن‌وقت است که می‌توانید نمایندگان موازی را اجرا کنید، و اینجاست که، مثلاً، بهره‌وری واقعی حاصل می‌شود، وقتی می‌توانید این تیم‌های نمایندگان را داشته باشید که همه کار شما را برایتان انجام می‌دهند.

اما این موضوع فراتر از صرفاً دسترسی به کد است.

آن‌ها به اسناد دقیق نیاز دارند که شامل مشخصات پروژه و قوانین نحوه کار در آن پروژه است.

این یکی از موارد واضح است.

برخی کارهای دیگری که افراد انجام می‌دهند، افراد اکنون عامل خود را به فضای گپ تیمی خود متصل می‌کنند، نه فقط برای راه‌اندازی عامل‌ها، بلکه برای ارائه زمینه نحوه تصمیم‌گیری‌هایی که منجر به ویژگی‌ای شده که به آن‌ها محول شده است، زیرا شما به‌عنوان توسعه‌دهنده، این نوع اطلاعات ناخودآگاهی است که هنگام حل مشکلات استفاده می‌کنید، و بنابراین می‌تواند برای عامل شما نیز مفید باشد.

همچنین مانند سابقه تصمیم‌گیری قبلی و درخواست‌های واکشی.

آن‌ها باید بتوانند نظراتی را که درباره درخواست‌های دریافتتان دریافت می‌کنید، چیزهایی که برایشان پینگ دریافت می‌کنند، و چیزهایی ازاین‌قبیل را ببینند و سپس متوجه خواهید شد که می‌توانند کار کنند و آن را اصلاح کنند.

همچنین، انتظار ندارید که بتوانید بدون دسترسی به دستگاه یا شبیه‌ساز، کد Android بنویسید، بنابراین نباید انتظار داشته باشید که عامل شما هم بتواند این کار را انجام دهد.

می‌دانم که به‌نظر می‌رسد آن‌ها شگفت‌انگیز هستند و می‌توانند هر کاری انجام دهند، اما شبیه‌ساز واقعاً کمک می‌کند.

همین موضوع برای نمایه‌سازها نیز صادق است.

اگر می‌خواهید روی عملکرد کار کنند، باید بتوانند نمایه کنند، که شامل دسترسی به دستگاه واقعی می‌شود.

و هر سرویس پس‌زمینه‌ای که برنامه‌تان استفاده می‌کند، در حالت ایده‌آل، عاملتان باید بتواند با آن‌ها نیز صحبت کند.

و اینجاست که Android CLI وارد عمل می‌شود.

اگر درباره آن نشنیده‌اید، در گفتگوی «جدیدترین‌ها در ابزارها» نیز به آن اشاره شد، اما Android CLI واسط خط فرمان جدید ما برای تعامل با ابزارهای مختلف Android است.

این ابزار به‌خودی‌خود محصول هوش مصنوعی نیست، بلکه فقط یک CLI (میانای خط فرمان) است.

بنابراین، به شما امکان می‌دهد به چیزهایی مثل «مدیر کیت توسعه نرم‌افزار Android»، راه‌اندازی شبیه‌سازها، و موارد بسیار دیگری دسترسی داشته باشید.

و همچنین به ابزارها و پس‌زمینه‌هایی مانند Crashlytics متصل می‌شود.

این ویژگی با هر عاملی که استفاده می‌کنید کار می‌کند و فقط در فضای پوسته شما قرار می‌گیرد.

بنابراین، بله.

می‌توانید آن را از این پیوند نصب کنید، اما فکر می‌کنم اگر آن را در عمل ببینیم راحت‌تر است.

بسیار خوب.

بنابراین، به‌جای اینکه صرفاً توضیح دهیم چرا آماده کردن عوامل برای موفقیت بسیار مهم است، می‌خواستیم این اصل را واقعاً در یک برنامه تولیدی که ساخته‌ایم، به نام Sideline، اعمال کنیم.

و Sideline یک برنامه Android برای بازیکنان تنیس است که بازخورد هم‌زمان درباره مکان توپ، مکان بازیکن، و مکان زمین به آن‌ها ارائه می‌دهد.

این دستگاه ازطریق بازپخش ویدیو، بازخورد مربیگری آفلاین ارائه می‌دهد و داده‌های تناسب اندام را برای مواردی مانند سریع‌ترین سرعت، مسافت طی‌شده، و طولانی‌ترین رالی‌ها ارائه می‌دهد.

همه این‌ها ازطریق مدل‌های سفارشی TF Lite که مستقیماً در دستگاه Android اجرا می‌شوند انجام می‌شود.

و اول از همه، می‌خواهم بگویم که ما بدیهی است نمی‌توانیم مشکلاتی را که نمی‌دانیم وجود دارند حل کنیم.

بنابراین، بااستفاده از Android CLI،‏ Firebase Crashlytics را به محیط توسعه‌دهنده خود اضافه کردیم که به ما امکان داد برخی‌از مشکلاتی را که حتی از وقوع آن‌ها مطلع نبودیم پیدا کنیم.

اولین مورد این بود که خطای «برنامه پاسخ نمی‌دهد» (ANR) در دستگاه Pixel 11 Pro Fold رخ می‌داد، اما در شبیه‌ساز بازتولید نمی‌شد.

بنابراین، خوشبختانه Android CLI از «جاری‌سازی دستگاه Android» پشتیبانی می‌کند.

و کاری که نماینده پس‌از اینکه به آن گفتیم برود و این مشکل را برطرف کند انجام داد این بود که اتصالی به دستگاهی که ANR در آن رخ می‌داد ایجاد کرد، که این کار به‌ویژه برای من مفید بود چون در آن زمان، من Pixel 11 Pro Fold نداشتم تا حتی درستی رفع مشکل را در آن تأیید کنم.

بنابراین، با دادن این توانایی به عامل که بتواند به دستگاهی که برای اعتبارسنجی اصلاح نیاز داشت دسترسی پیدا کند، درنهایت توانستیم مجموعه قابلیت‌های ممکن را گسترش دهیم.

و برای صرفه‌جویی در زمان، همه آزمایش‌ها را ازقبل اجرا کردم و آن‌ها را در اینجا خلاصه کرده‌ام.

و بدون اینکه خیلی وارد جزئیات شویم، مشکلی که داشتیم یک فراخوانی قرابت مربوط به Android 17 بود.

یک اصلاح سریع دوخطی بود که به‌نظرم خوب بود.

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

بنابراین، درخواست pull را ایجاد کردم، آن را ادغام کردم، و با ساخت جدیدی که به Play ارسال شده بود به‌روزرسانی کردم.

بنابراین، اگر محیط کدنویسی را با قابلیت‌هایی که برای موفقیت نیاز داشت راه‌اندازی نکرده بودیم، نمی‌توانستیم مشکل واقعی را شناسایی کنیم و همچنین نمی‌توانستیم راه‌حل را اعتبارسنجی کنیم.

بنابراین، با ساخت‌های نسخه ۱.۰، می‌توانید ببینید که مشکل حل شده است.

اما مشکلات جدیدی پیش آمده است و بعداً به آن‌ها رسیدگی خواهیم کرد.

بسیار خوب.

مورد بعدی: بافت.

حدود یک سال و نیم یا دو سال پیش، که زمان زیادی نیست، اما در فضای هوش مصنوعی یک عمر محسوب می‌شود، رقابتی برای داشتن پنجره‌های بافت بزرگ‌تر و بزرگ‌تر وجود داشت و نظریه این بود که هرچه بیشتر بتوانیم به مدل ارائه دهیم، نتایج بهتری خواهیم گرفت و ما کارهای عجیبی می‌کردیم، مثلاً سعی کردیم کل developer.android.com را در پیام‌واره بگنجانیم، اما واقعاً کار نکرد.

اما بااینکه پنجره‌های بافت تا حد زیادی به ثبات رسیده‌اند، قابلیت‌های مدل همچنان درحال افزایش است.

بنابراین، این Android Bench 1.0 است.

Android Bench معیار ما برای محک زدن توانایی هوش مصنوعی در نوشتن کد Android است.

تکالیف موجود در آن واقع‌گرایانه است.

این‌ها چیزهایی هستند که روی آن‌ها کار می‌کنید، و می‌بینیم که پنجره‌های زمینه در آن علامت ۱ میلیون ثابت مانده‌اند، اما توانایی مدل همچنان درحال افزایش است.

اما بافت کلام همچنان بودجه ثابتی است و می‌خواهید آن را برای چیزهای مهم ذخیره کنید.

شما نمی‌خواهید چیزهایی در آنجا باشد که به حل مشکل دقیقی که روی آن کار می‌کنید کمک نمی‌کند.

و بسیاری از زیرساخت‌های عامل درواقع آن پنجره زمینه کامل ۱ میلیون داده‌واحدی را دراختیار شما قرار نمی‌دهند چون فکر می‌کنند، مثلاً، بی‌فایده است.

وقتی این کار را می‌کنند، نتایج بدتر می‌شود.

و درواقع یک نقطه بهینه وجود دارد که بسته به مدل تغییر می‌کند، اما اگر بتوانید مکالمه‌هایتان را در حدود ۱۵۰٬۰۰۰ نمانه نگه دارید، در این نقطه است که قدرت کامل مدل را بدون هیچ‌گونه پوسیدگی بافت دریافت می‌کنید.

اما بافت فقط چیزی نیست که تایپ می‌کنید.

[
  {
    "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 }"
  }
]

درواقع چیزهای زیادی در پشت صحنه وجود دارد که شما نمی‌بینید.

این بخش از تعدادی قسمت تشکیل شده است.

اولی دستورالعمل سیستم است.

دستورالعمل سیستم توسط نماینده شما ارائه می‌شود.

این دستورالعمل‌ها مثل پیام‌واره‌ای هستند که به آن می‌گویند چگونه با این عامل کار کند و چه نوع رفتاری باید داشته باشد.

اما، همچنین، اطلاعات فضای کاری، و مثلاً، مثل دایرکتوری کاری فعلی شما، کیت‌های توسعه نرم‌افزاری که دارید، هر مهارت نصب‌شده‌ای، که به‌زودی درباره آن صحبت خواهیم کرد، و ابزارهای MCP، هر ابزاری که توسط عامل شما نیز ارائه شده است.

مدل باید بداند که می‌تواند آن‌ها را فراخوانی کند، بنابراین این کار بافت را اشغال می‌کند.

اما نکته مهم این است که کل پیام و سابقه فراخوانی ابزار با هر پیام‌واره، هر پیام جدیدی که ارسال می‌کنید، با عامل شما ارسال می‌شود.

و این، این واقعاً می‌تواند جمع شود، به‌ویژه با Gradle.

فکر می‌کنم همان‌طور که همه می‌دانیم، گزارش‌های Gradle واقعاً طولانی هستند، یعنی واقعاً واقعاً طولانی و بسیار پرجزئیات هستند.

بیشتر این اطلاعات لازم نیست.

بنابراین یک نکته سریع برای مراقبت از آن وجود دارد.

می‌توانید Gradle را در حالت بی‌صدا اجرا کنید.

./gradlew assembleDebug --quiet

یا زیرساخت‌های عامل بزرگ‌تر این کار را برای شما کوتاه می‌کنند.

بنابراین، Claude Code و Android Studio، ما گزارش کامل Gradle را ارسال نمی‌کنیم.

اما اگر از یکی از عوامل حداقلی استفاده می‌کنید، چون کل فلسفه آن‌ها این است که همه چیز را به مدل ارسال کنند، مدل بهتر می‌داند، بنابراین mini-SWE-agent، آن گزارش کامل Gradle را ارسال می‌کند، و این می‌تواند خیلی سریع خیلی گران شود.

اما چطور در این پنجره جادویی ۱۵۰٬۰۰۰ نفری باقی می‌مانیم؟

خب، نکته کلیدی استفاده از گردش کار است.

و گردش‌های کاری زیادی وجود دارد.

آن موردی که واقعاً دوست دارم از شخصی به نام مت پوکاک است و او مجموعه‌ای از مهارت‌ها را دارد که به شما کمک می‌کند این جلسات را مدیریت کنید.

بنابراین، با مهارتی به‌نام «grill-me» شروع می‌شود.

کاری که انجام می‌دهید این است که وقتی برای اولین‌بار کل پروژه یا فقط ویژگی جدیدی را در پروژه شروع می‌کنید، این مهارت را اجرا می‌کنید و این مهارت باعث می‌شود عامل شما مجموعه‌ای از سؤالات را از شما بپرسد.

بنابراین، می‌توانید بگویید «grill-me.

می‌خواهم نمی‌دانم، یک مدیر زنگ ساعت جدید در برنامه‌ام بسازم.»

و کاری که انجام می‌دهد این است که شروع می‌کند به پرسیدن سؤالاتی از شما، مثلاً اینکه در چه چیزی باید آن را پیاده‌سازی کنیم، به کجا تعلق دارد.

و این کار همه ابهامات را از مسئله و از ذهن شما خارج می‌کند و به یک مشکل تبدیل می‌کند.

سپس مهارت بعدی را اجرا می‌کنیم که به‌نوعی یک سند مشخصات بزرگ می‌نویسد.

مهارت دیگری وجود دارد که سپس آن را به مشکلات تقسیم می‌کند و ما آن‌ها را در هر مدیر مشکلی که ترجیح می‌دهید استفاده کنید، ثبت می‌کنیم.

و سپس ایده این است که هریک از این مسائل باید تقریباً در آن پنجره ۱۵۰٬۰۰۰ تایی جا بگیرد.

And then from there, you pick one issue either you're working in the terminal or your IDE, whatever you prefer, build, verify loop, we clear the context at the end, no more conversation history, and we stayed within the window.

بسیار خوب.

بعدی، بیایید درباره 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 استفاده کنیم، چیزهایی مثل این.

و من واقعاً می‌خواستم نوعی از روال‌های مطلوب را ارائه دهم که همیشه اعمال می‌شوند، اما واقعیت این است که این روال‌ها با هر انتشار مدل تغییر می‌کنند.

مدل‌های مختلف در مواجهه با بافت اضافی رفتارهای متفاوتی دارند.

بنابراین، برای مثال، در گذشته در Opus 4.6، خیلی رایج بود که حروف بزرگ بزرگی وجود داشت که می‌گفت: «هرگز این کار را نکنید.»

و سپس وقتی Opus 5 منتشر شد، Anthropic بیانیه‌ای صادر کرد و گفت: «درواقع، حروف بزرگ دیگر چندان خوب کار نمی‌کنند.

فقط از حروف کوچک استفاده کنید.»

منظورم این است: باید همیشه حواستان به آن باشد.

اما برخی‌از چیزهایی که تقریباً جهانی باقی مانده‌اند این است که آن را کوتاه نگه دارید.

بنابراین، آن را زیر ۲۵۰ خط نگه دارید.

و این یکی، این مورد بعدی کمی قطبی‌کننده است، چون می‌دانم خیلی‌ها دوست دارند این کار را انجام دهند، اما مطالعه‌ای در فوریه امسال منتشر شد که نشان داد اگر به عامل خود اجازه دهید AGENTS.md خودش را تغییر دهد، عملکرد را حدود ۲ تا ۳ درصد کاهش می‌دهد، که می‌دانید، چندان مهم نیست.

اما بخش مهم این بود که هزینه‌ها را ۲۰٪ افزایش داد.

بنابراین، کمی از عملکرد را ازدست دادیم و هزینه‌هایمان به‌شدت افزایش یافت، همه این‌ها به‌خاطر این بود که به عامل اجازه دادیم AGENTS.md خودش را بنویسد.

یک راه حل برای این مشکل که دیده‌ام این است که می‌توانید از نماینده خود بخواهید در پایان هر درخواست واکشی یک بازنگری بنویسد، و سپس شما به‌عنوان یک تیم در بازنگری‌های خود می‌توانید همه آن‌ها را با هم بخوانید و تصمیم بگیرید که چه تغییراتی می‌خواهید ایجاد کنید، زیرا این فایل به نوعی به بخش کلیدی زیرساخت حیاتی تیم تبدیل می‌شود اگر در تیم‌های بزرگ با نمایندگان کار می‌کنید.

بنابراین، خیلی سریع، این AGENTS.md برای برنامه Sideline است که ما ساختیم.

درواقع دو چیز وجود دارد که می‌خواهم در اینجا به آن‌ها اشاره کنم.

اولین مورد این است که داشتن معماری مشخص و تعریف‌شده باعث صرفه‌جویی در مصرف توکن‌ها و طول بافت می‌شود.

اساساً این کار به عامل شما اجازه می‌دهد تا از بررسی مداوم پایگاه کد شما و انجام استنتاج‌های بیشتر و بیشتر اجتناب کند.

این کار دستورالعمل بسیار واضحی برای پیروی کردن ارائه می‌دهد.

و نکته دومی که می‌خواستم به آن اشاره کنم، به‌ویژه برای برنامه‌های منبع بسته است.

بدیهی است که اگر منبع بسته باشید، هیچ‌کدام از عامل‌ها نتوانسته‌اند مدل‌های زبانی بزرگ را روی پایگاه کد شما آموزش دهند.

بنابراین، در این موارد، بسیار مهم است که فقط آن زمان اضافی را صرف کنید، آن چرخه‌ها را صرف تمیز کردن، بازبینی، اصلاح، بهبود AGENTS.md خود کنید، زیرا در درازمدت به نفع شما خواهد بود.

پس اگر نباید همه چیز را در AGENTS.md قرار دهیم، چگونه باید رفتار عامل یا مدل را تغییر دهیم؟

خب، اولین مورد قلاب‌ها هستند، و قلاب‌ها درواقع برای چیزهایی که افراد در AGENTS.md قرار می‌دهند بسیار خوب هستند، مثلاً همیشه وقتی نوشتن را تمام کردید، خطایاب نحوی را اجرا کنید.

// settings.json

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

این می‌تواند یک قلاب باشد.

قلاب چیزی است که عامل شما همه این رویدادها را که می‌توانید در آن‌ها مشترک شوید درمعرض دید قرار می‌دهد، و برای تقریباً هر چیزی که فکرش را بکنید قلاب وجود دارد، اما قلاب‌های اصلی عبارت‌اند از شروع جلسه، توقف جلسه، خواندن و نوشتن فایل‌ها.

بنابراین، به‌جای اینکه در پایین AGENTS.md خود بنویسید «همیشه خطایاب نحوی را اجرا کن» یا «همیشه مجموعه آزمون من را قبل‌از اینکه بگویی کارت تمام شده است اجرا کن»، فقط یک قلاب توقف دارید که می‌تواند یک اسکریپت قطعی را اجرا کند و این به مهار کردن تصادفی بودن جزئی هوش مصنوعی کمک می‌کند.

مورد دیگر، اگر فایل‌هایی دارید که واقعاً نمی‌خواهید عاملتان بتواند آن‌ها را بخواند یا بنویسد، مثلاً فایل‌های محرمانه دارید، نمی‌خواهید آن فایل‌ها به سرور ارسال شوند، یا AGENTS.md، نمی‌خواهید عاملتان بتواند در آن بنویسد، می‌توانید برای آن یک قلاب داشته باشید.

بنابراین شما یک قلاب خواندن یا نوشتن دارید، فایلی را که می‌خواهد ویرایش کند به شما منتقل می‌شود، و شما می‌توانید فقط برگردانید، «نه، نمی‌توانید این کار را انجام دهید.»

این فقط راهی برای افزودن قطعیت است.

مورد بعدی مهارت‌ها است.

و درواقع مهارت‌هایی وجود دارد که AGENTS.md شما را به قلاب تبدیل می‌کند.

این موضوع کاملاً متفاوتی است.

اما مهارت‌ها نحوه افزودن بافت فقط درصورت مرتبط بودن است.

بنابراین AGENTS.md برای چیزهایی است که همیشه مرتبط هستند.

مهارت‌ها برای چیزهایی است که در موقعیت‌های خاص، عمدتاً مستندسازی، مرتبط هستند.

بنابراین مهارت‌ها از سه بخش تشکیل شده‌اند: نام دارند، شرح دارند، و این بخش مهم است، این شرح به ۱۰۲۴ نویسه محدود است، و سپس بدنه دارند.

---

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

و بدنه می‌تواند بسیار بزرگ باشد، بدنه حتی می‌تواند شامل اسکریپت‌های دیگر باشد، که بسیار رایج است.

با مهارت‌ها می‌توانید کارهای زیادی انجام دهید.

بیایید نگاهی به یک مثال بیندازیم.

این شرح Android CLI است.

لازم نیست همه آن را بخوانید.

فقط بدانید که این مثل شرح کوتاهی است که توضیح می‌دهد Android CLI چه زمانی مرتبط است.

و این هم بدنه است.

این فایل خیلی بزرگ است، بنابراین نمی‌خواهیم همیشه همه آن را بار کنیم، درست است؟

ما فقط زمانی می‌خواهیم این را بار کنیم که درحال تلاش برای استفاده از Android CLI هستیم، و این همان کاری است که یک مهارت به ما امکان می‌دهد انجام دهیم.

اما مهم است که در انتخاب مهارت‌هایی که نصب می‌کنید دقت کنید.

ما نمی‌خواهیم فقط به‌طور کورکورانه آن مخزن‌هایی را که در اینترنت می‌بینیم و صدها مهارت مهندسی عاملی دارند نصب کنیم.

اول اینکه این کار خطر امنیتی بزرگی است.

شما نمی‌دانید چه چیزی در آن مهارت‌ها وجود دارد، ممکن است به نماینده شما بگوید هر کاری انجام دهد.

و ما مجموعه‌ای از مهارت‌های Android داریم، قول می‌دهم آن‌ها را بررسی کرده‌ایم، آن‌ها این را نمی‌گویند.

اما دوم اینکه، ۱۰۰ شرح ضربدر ۱۰۰۰ نویسه می‌شود ۱۰۰٬۰۰۰ نویسه که شما قبل‌از اینکه حتی کدنویسی را شروع کنید، اضافه کرده‌اید.

بنابراین شما درحال‌حاضر به آن پنجره نزدیک شده‌اید.

به همین دلیل است که برای مهارت‌های Android، توصیه می‌کنیم فقط مهارت پایه 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، این پیوند است.

اما فرمان فهرست مهارت‌ها را دارد و سپس می‌گوید که Navigation 3 را در پروژه‌تان دارید.

android skills list
android skills add navigation-3

Navigation 3 کتابخانه نسبتاً جدیدی است، بنابراین هنوز آموزش زیادی روی آن انجام نشده است، می‌توانید مهارت Navigation 3 را اضافه کنید.

ما اغلب اوه، ببخشید.

مورد بعدی MCP است.

اما اغلب از ما پرسیده می‌شود که چرا Android CLI را به‌جای سرور MCP، به‌صورت CLI ساختیم؟

خب، ما این چیزهای CLI را خیلی قبل‌از وجود هوش مصنوعی، حتی خیلی قبل‌از وجود ماوس، می‌ساختیم، بنابراین سریع هستند، قابل‌ترکیب هستند، و چون به‌صورت محلی در جلسه پوسته شما اجرا می‌شوند، عملاً اجرای آن‌ها رایگان است.

و همچنین، معیارهایی مانند Terminal Bench به بزرگ‌ترین معیارها در زمینه مهندسی نرم‌افزار تبدیل شده‌اند، بنابراین سازندگان مدل به‌شدت درحال رقابت برای بهبود استفاده از پایانه هستند، درنتیجه این روزها در استفاده از CLI بسیار خوب عمل می‌کنند.

اما این بدان معنا نیست که MCP جایی ندارد.

سرورهای MCP برای سرویس‌های خارجی که ازقبل استفاده می‌کنید واقعاً عالی هستند، به‌ویژه اگر ازقبل میزبان یک سرویس MCP باشند.

می‌توانید مستقیماً به آن متصل شوید و این روشی بدون نیاز به نصب برای افزودن بافت اضافی به نماینده شما است.

درحال‌حاضر، پلاتفرم‌هایی مثل GitHub،‏ Figma، و Slack سرورهای MCP را ارائه می‌دهند.

و سپس چیزهایی که همیشه در پوسته اجرا می‌کردیم می‌توانند در پوسته باقی بمانند، بنابراین فرمان‌های Android ازطریق Android CLI، اما Perfetto و Gradle نیز منطقی است که آن‌ها را به‌صورت محلی داشته باشیم، جایی که به هر چیزی که در توسعه خود استفاده می‌کنید دسترسی دارند.

و من قبلاً روی عملکرد کار می‌کردم.

من همیشه می‌گفتم Perfetto تنها ابزاری است که برای حل هر مشکل عملکردی به آن نیاز دارید.

اما منحنی یادگیری بسیار تند بود، همانطور که در آخرین صحبت راهول دیدیم.

بیایید ببینیم هوش مصنوعی چگونه می‌تواند به بهبود عملکرد کمک کند.

متشکرم، بهروز.

بنابراین، برای اینکه برنامه ما، Sideline، کار کند، باید با سرعت ۳۰ فریم در ثانیه و به‌صورت هم‌زمان اجرا شود.

و همان‌طور که در این Pixel 10 Pro Fold می‌بینید، فقط به حدود ۲۰ تا ۲۲ فریم در ثانیه می‌رسیم.

این فریم‌های حذف‌شده مشکل‌ساز خواهند بود، زیرا به این معنی است که برنامه آن‌طور که تبلیغ شده کار نخواهد کرد، بنابراین واقعاً باید این مشکل را برطرف کنیم.

با Android CLI، فرمان‌های نمایه‌ساز Android را داریم.

و وقتی آن را به عامل کدنویسی خود اضافه می‌کنیم و به آن دستور می‌دهیم که این شرط ۳۰ فریم در ثانیه را برآورده کند، دو اتفاق جالب رخ می‌دهد.

اولین مورد این است که بااستفاده از فرمان نمایه‌ساز Android، راه‌حلی پیدا می‌کند.

این ابزار ردگیری‌های سیستم را در دستگاه Pixel 10 Pro Fold متصل‌شده ضبط کرد و متوجه شد که رشته‌های هوش مصنوعی آن روی کندترین هسته‌های دستگاه اجرا می‌شوند.

و دوم اینکه از جستجوی اسناد Android استفاده کرد، جالب اینکه بدون اینکه ما صریحاً از آن بخواهیم این کار را انجام دهد، و راهنمای رسمی Performance Hint API را استخراج کرد.

آنچه که عامل یاد گرفت انجام دهد، بهینه‌سازی زمان‌بندی سیستم بود و با انجام این کار، توانست الزامات ۳۰ فریم در ثانیه را برآورده کند.

بنابراین، اساساً آنچه اتفاق افتاد این است که اصلاحیه از راهنمایی پیروی کرد.

بنابراین، با Android CLI، نکته کلیدی این است که، می‌دانید، ازطریق اتصال آن به عامل، به شما کمک می‌کند تا ابزار مناسب را پیدا کنید، حتی اگر با آن ابزار آشنا نباشید، برای هر کاری که باید بتوانید انجام دهید.

بنابراین، وقتی آن را اجرا می‌کنیم، می‌بینید که Sideline نیاز کاربران به ۳۰ فریم در ثانیه را برآورده می‌کند و اکنون در Pixel 10 Pro Fold کار می‌کند.

بسیار خوب.

اکنون، می‌خواهیم همه این‌ها را با حلقه‌ها کنار هم قرار دهیم.

مطمئنم همه ما این کار را کرده‌ایم، از عاملتان می‌خواهید تغییر بزرگی را اعمال کند، و عامل برمی‌گردد و می‌گوید انجام شد.

و اگر آن را نصب می‌کنید و به‌نوعی خودتان به‌صورت دستی در برنامه کلیک می‌کنید و اشکال‌ها را تایپ می‌کنید، این همان کاری است که باید انجام آن را متوقف کنیم.

باید از آزمایش‌کننده تضمین کیفیت عامل بودن دست برداریم و از همان ابتدا تعریف کنیم که چه چیزی را «انجام‌شده» می‌دانیم.

بنابراین، این یک مثال است.

می‌خواهیم کل پروژه را به Nav3 منتقل کنیم، و سپس عامل می‌رود، مدتی طول می‌کشد، اما با اطمینان برمی‌گردد و می‌گوید: «انتقال کامل شد.

من بهترینم.»

اما بعد، البته، تلفن را می‌چرخانید، برنامه از کار می‌افتد، همه انتقال‌های اسلاید را ازدست می‌دهد، فایل Gradle خود را پاک‌سازی نمی‌کند.

این تقریباً شبیه دنیایی است که درحال‌حاضر در آن هستیم.

در حالت ایده‌آل، ما مجبور به انجام این کار نیستیم، اما این واقعیت فعلی است.

بنابراین، باید ابتدا همه این موارد را درباره آنچه انتظار داریم تعریف می‌کردیم و این کار به عامل اجازه می‌داد تا زمانی که همه این معیارها را برآورده کند، در حلقه بماند.

این همان حلقه درستی‌سنجی است.

و ما درواقع داده‌های بسیار قوی‌ای درباره اثربخشی این موضوع داریم.

بنابراین، این Android Bench 2.0 است، نسخه جدید محک هوش مصنوعی ما که در ابتدای صحبت به آن اشاره کردم.

درحال‌حاضر نرخ قبولی حدود ۴۰٪ است.

این تکالیف واقعاً سخت هستند و واقعاً بزرگ و واقع‌گرایانه هستند، اما یکی از آن‌ها Nav2 به Nav3 است، این‌ها از نوع کارهایی هستند که شما درحال‌حاضر در پروژه‌هایتان انجام می‌دهید.

و اگر Fable 5.1 را درنظر بگیریم، نرخ قبولی آن ۲۲٪ است، این همان چیزی است که فقط با راه‌اندازی پیام‌واره طبیعی به‌دست می‌آید، مانند «انتقال Nav2 به Nav3».

اما اگر ازقبل یک مجموعه آزمون ناموفق به آن بدهیم، یعنی پاسخ‌ها را به آن نمی‌دهیم، به آن نمی‌گوییم چگونه به Nav3 مهاجرت کند، فقط یک مجموعه آزمون به آن می‌دهیم که درحال‌حاضر ناموفق است و وقتی همه آن موارد تکمیل شوند موفق خواهد شد، نرخ موفقیت آن در کل محک به ۹۰٪ می‌رسد.

و این نشان می‌دهد که این مدل‌ها اکنون واقعاً قادرند تقریباً هر تکلیف Android را که فکرش را بکنید اجرا کنند، فقط همیشه نمی‌دانند «انجام شد» یعنی چه.

بنابراین، لازم نیست ازقبل یک مجموعه آزمون ناموفق کامل بنویسید.

حلقه‌های درستی‌سنجی می‌توانند به‌سادگی افزودن پیام‌واره باشند.

بنابراین، فرض کنید درحال کار در میانای کاربر هستید، می‌توانید از آن بخواهید پیش‌نمایش Compose را ارائه دهد و مطمئن شوید که با مشخصات Figma مطابقت دارد، و نتایج را به من نشان دهد.

به‌نظر می‌رسد وقتی از آن می‌خواهید نتایج را به شما نشان دهد و ثابت کند که کار انجام شده است، واقعاً کار می‌کند، نه اینکه فقط پاسخ نوشتاری «انجام شد» را بپذیرید.

اگر روی منطق کسب‌وکار کار می‌کنید، می‌توانید از آن بخواهید که آزمایش‌های واحد شما را اجرا کند، یا همان‌طور که در ابتدا دیدیم، اگر روی رفع خرابی کار می‌کنید، می‌توانید به آن بگویید که ازطریق آزمایشگاه آزمایش ازراه‌دور، برطرف شدن خرابی را در دستگاه واقعی که خرابی در آن اتفاق افتاده است اعتبارسنجی کند.

درواقع مهارتی در Claude Code تعبیه شده است که به شما کمک می‌کند اکنون حلقه‌های درستی‌سنجی بسازید.

پس حتماً آن را بررسی کنید.

و اگر در «استودیو Android» با عامل خودتان کار می‌کنید، «استودیو Android» ابزارهای زیادی را ارائه می‌دهد که می‌توانید بسته به کاری که انجام می‌دهید، حلقه‌هایی را در اطراف آن‌ها بسازید.

بنابراین، مانند خطایاب نحوی، می‌توانید به آن بگویید تا زمانی که همه خطاهای نحوی برطرف نشده‌اند متوقف نشود، یا چیزی که من واقعاً دوست دارم سفرها است، می‌توانید از آن بخواهید سفرهای شما را اجرا کند و مطمئن شود که هنوز کار می‌کنند.

یا اگر سفری نوشته‌اید، چون نوشتن سفرها بسیار آسان است، آن‌ها فقط پیام‌واره‌هایی درباره ویژگی‌ای هستند که روی آن کار می‌کنید، می‌توانید به آن بگویید که آن سفر را اجرا کند و مطمئن شود که قبل‌از اعلام اتمام کار، آن را با موفقیت پشت سر می‌گذارد.

اما اجرای سفرها کمی طول می‌کشد.

بنابراین، کاری که می‌توانید انجام دهید این است که سطوح حلقه درستی‌سنجی خود را رده‌بندی کنید.

بنابراین، می‌توانیم از آن بخواهیم ابتدا مطمئن شود که آزمون‌های واحد و «پیش‌نمایش‌های 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 به پانل می‌آیند تا درباره نحوه اجرای این موضوع در کارهایشان صحبت کنند.

همچنین، واقعاً بازخوردتان را می‌خواهیم.

واقعاً می‌خواهیم بدانیم آیا چیزهایی که می‌سازیم واقعاً به شما کمک می‌کند یا نه.

بنابراین، لطفاً نظرسنجی را تکمیل کنید.

آن را روی صفحه می‌گذارم.

و، بله.

از اینکه گوش دادید، سپاس‌گزاریم.

متشکریم.