Site icon AppTractor

Android Skills — что выпустил Google и почему большинство разработчиков используют навыки неправильно

AppTractor

Вы, скорее всего, уже видели анонс. Android Skills запустили в апреле; реакция превзошла ожидания Google, а в начале августа команда Android Developer Relations опубликовала подробный материал, в котором объяснила философию проекта.

Большинство разработчиков восприняли это как обычное описание релиза.

На самом деле это набор архитектурных решений о том, как должна выглядеть Android-разработка с помощью ИИ. И если их не понять, можно в итоге получить конфигурацию агента, которая будет стоить дороже, работать медленнее и выдавать результаты хуже, чем если бы вы вообще ничего не настраивали.

Что на самом деле представляют собой Android Skills

Skills — это модульные наборы инструкций в формате SKILL.md, написанные на Markdown. Они содержат техническую спецификацию конкретной задачи и автоматически активируются, когда ваш запрос соответствует метаданным навыка. То есть вам не нужно вручную прикладывать документацию к каждому запросу.

Первый набор охватывает настройку и миграцию на Navigation 3, поддержку edge-to-edge, миграции на AGP 9 и с XML на Compose, а также анализ конфигурации R8.

Но самое важное — понимать, чем навыки не являются. Это не универсальная база знаний по Android. Это хирургические изменения для конкретных областей, где современные передовые модели действительно генерируют неправильный код. На практике это различие чрезвычайно важно.

Скрытая цена слишком большого количества навыков

Вот контринтуитивное решение, на котором большинство разработчиков, скорее всего, ошибётся.

Каждый установленный навык добавляет примерно 100–200 токенов в базовый контекст каждой задачи. Если навык активируется, объём может вырасти уже до нескольких тысяч токенов. Для команды, которая выполняет 150 задач в день и держит 10 ненужных навыков, это легко превращается в лишние 500–600 долларов в год только на контекст с информацией, которую модель и так знает. Плюс качество ответов может ухудшаться из-за дополнительного шума.

Рекомендация Google здесь вполне однозначна: прежде чем устанавливать навык для базовой работы с Kotlin или Compose, стоит спросить себя, действительно ли он нужен вашей модели или она и без того достаточно хорошо знает эту тему.

Правильная ментальная модель выглядит так:

Android Knowledge Base first → Targeted Skills second → Custom Skills third

База знаний через android docs отвечает за широту знаний. Навыки закрывают подтверждённые проблемные места. Базу знаний имеет смысл устанавливать всегда. Навыки — только осознанно.

Реальная разница, которую дают навыки — типобезопасность Navigation 2.8+

Вот конкретный пример до и после для промпта: «Настрой навигацию с домашним экраном и экраном деталей, который получает идентификатор пользователя.»

// ❌ WITHOUT Navigation 2.8+ skill — Legacy / String-Based (Pre-2.8)

val navController = rememberNavController()
NavHost(navController = navController, startDestination = "home") {
    composable("home") {
        HomeScreen(
            onNavigateToDetail = { userId ->
                navController.navigate("detail/$userId")
            }
        )
    }
    composable(
        route = "detail/{userId}",
        arguments = listOf(navArgument("userId") {
            type = NavType.StringType
        })
    ) { backStackEntry ->
        DetailScreen(
            userId = backStackEntry.arguments
                ?.getString("userId") ?: ""
        )
    }
}
// ✅ WITH Navigation 2.8+ skill — Modern Type-Safe (2.8.0+)

@Serializable
object Home

@Serializable
data class Detail(val userId: String)

val navController = rememberNavController()

NavHost(
    navController = navController,
    startDestination = Home
) {
    composable<Home> {
        HomeScreen(
            onNavigateToDetail = { userId ->
                navController.navigate(Detail(userId = userId))
            }
        )
    }

    composable<Detail> { backStackEntry ->
        val detail: Detail = backStackEntry.toRoute()
        DetailScreen(userId = detail.userId)
    }
}

Почему это важно: оба варианта компилируются и работают. Но старый подход основан на строковом разборе маршрутов и ручном извлечении аргументов из Bundle, из-за чего легко получить опечатки и ошибки в рантайме. Типобезопасный подход 2.8+ позволяет ловить ошибки маршрутизации ещё на этапе компиляции и полностью убирает ручной разбор аргументов.

Как Google решает, нужен ли вообще новый skill

Google создаёт навык только тогда, когда существует проверяемый пробел в знаниях современных моделей. Перед публикацией каждый навык должен пройти полноценную оценку.

Например:

timeout_s: 1200
repository:
  working_dir: wear_compose_m3_empty_app
prompt: |-
  Add a horizontal pager to MainActivity.kt with three pages
  showing "Page 1", "Page 2", "Page 3" centered on screen.
commands:
  build:
    - ./gradlew assembleDebug
acceptance_criteria:
  project_builds: true
  llm_diff_judge:
    - Must use `HorizontalPagerScaffold`
    - Each page must use `AnimatedPage` wrapping `ScreenScaffold`

Такая проверка не просто смотрит, собирается ли проект. Она убеждается, что агент использовал именно правильные API Wear OS. Именно поэтому официальных скилов около 20, а не 200. Каждый из них соответствует подтверждённому и измеримому режиму плохой работы модели. Если модель стабильно справляется с задачей без подсказки, навык для этого не нужен. И его не должно быть.

AGENTS.md для реального проекта

Разница между посредственной и хорошей настройкой агента часто сводится к качественно написанному AGENTS.md.

Вот реалистичный шаблон для Android-проекта:

# AGENTS.md

## Documentation
Always consult the Android Knowledge Base (android docs)
before suggesting any Jetpack API.

## Architecture
- MVVM + Hilt — do NOT suggest Koin or manual DI
- ViewModels use StateFlow — never LiveData for new code
- Repository pattern required for all data access

## UI
- All new screens use Jetpack Compose — no new XML layouts
- Reference HomeScreen.kt as the Compose pattern for this project

## Navigation
- Navigation 3 with type-safe routes — not navigation-compose 2.x
- All routes must be @Serializable — reference NavGraph.kt

## Build
- AGP 9 — use libs.versions.toml, no direct build.gradle.kts deps

## Testing
- JUnit 5 + MockK for unit tests — not Mockito or Espresso
- Coroutine tests use runTest from kotlinx-coroutines-test

## Never
- Thread.sleep() → use delay()
- GlobalScope → use viewModelScope
- Broad catch(Exception) → handle specific types
- !! operator → handle nullability explicitly

Главное, чего не хватает большинству файлов AGENTS.md, — это ссылки на конкретные эталонные файлы вроде HomeScreen.kt и NavGraph.kt, чтобы у модели был реальный образец для подражания. Вторая важная вещь — явно перечисленные антипаттерны, чтобы модель случайно к ним не возвращалась.

Проблема устаревшей кодовой базы

Это самый распространённый практический сценарий — и именно здесь навыки особенно полезны. Когда агент работает с устаревшим проектом, он копирует окружающие шаблоны. Видит LiveData — пишет ещё больше LiveData. Видит ViewBinding — продолжает использовать ViewBinding. Он оптимизирует решение под согласованность с существующим кодом, а не под соответствие современным рекомендациям.

// ❌ Agent adding to a legacy screen WITHOUT modernisation skill
// Prompt: "Add an order history section to the user screen"
// Agent sees surrounding LiveData code and matches it

viewModel.orderHistory.observe(viewLifecycleOwner) { orders ->
    binding.orderCount.text = "Orders: ${orders.size}"
    binding.lastOrder.text = orders.firstOrNull()?.date ?: "None"
}

// ✅ Agent WITH a custom legacy migration skill
// Produces Compose alongside legacy code instead

binding.composeContainer.setContent {
    val orders by viewModel.orderHistory
        .collectAsStateWithLifecycle()
    AppTheme {
        OrderHistorySection(orders = orders)
    }
}

Кастомный навык с явным правилом вроде «при добавлении новых функций в устаревшие экраны используй Compose через ComposeView вместо расширения старых шаблонов» разрушает склонность агента закреплять устаревшую архитектуру. Это, пожалуй, самый недооценённый аргумент в пользу собственных навыков, даже если официальные вам особенно не нужны.

Как правильно начать

# 1. Install Android CLI from d.android.com/tools/agents

# 2. Test Knowledge Base first — you may not need a skill
android docs search "Navigation 3 type-safe routes"

# 3. Install only confirmed-necessary skills
android skills install navigation3   # Only if using Nav 3
android skills install edge-to-edge  # Only if targeting API 35+
android skills install agp9          # Only if on AGP 9

# 4. Quarterly — remove skills your model no longer needs
android skills list --installed

Из навыков сообщества стоит обратить внимание на несколько наборов. У Криса Бейнса есть большая коллекция для Compose и Kotlin. Иван Моргилло опубликовал навык для аудита Compose-проектов. Джевун Эум создал навыки для тестирования и производительности. А вот репозиториев с десятками автоматически сгенерированных ИИ навыков лучше избегать: они не протестированы и могут, наоборот, толкать агента к неправильным шаблонам.

Идея «создаются, чтобы устареть»

В конце публикации о философии проекта Google высказывает мысль, которая на первый взгляд звучит парадоксально:

Android Skills изначально создаются с расчётом на то, что со временем их можно будет удалить.

По мере улучшения передовых моделей отдельные навыки становятся ненужными. Google выводит их из использования, когда модели начинают успешно проходить соответствующие оценки даже без активного навыка. Навык для Navigation 3 существует потому, что сегодняшние модели делают в этой области ошибки. В тот день, когда модели начнут стабильно выдавать правильный результат самостоятельно, этот навык исчезнет.

Из этого следует важный вывод: со временем ваш набор навыков должен становиться меньше, а не больше. Проводите аудит раз в квартал. Удаляйте всё, без чего ваша модель уже справляется. Цель — компактная, точечная конфигурация, а не постоянно растущая библиотека файлов настройки агента.

Основные выводы

Надеюсь, статья была полезной. Спасибо за чтение.

Источник

Exit mobile version