千万别误用Android Skills

本文译自「Android Skills --- What Google Just Released and Why Most Developers Are Already Using It Wrong」，原文链接medium.com/proandroidd...，由Dilipchandar发布于2026年8月8日。

你可能已经看到了相关公告。Android Skills 于四月发布；其反响远超谷歌预期。昨天，Android 开发者关系团队发布了一篇深度解析，阐述了该项目背后的理念。

大多数开发者将其视为发布说明。

实际上，这是一系列关于 AI 辅助 Android 开发的架构决策------如果你忽略了这些决策，最终得到的智能体配置不仅成本更高、运行速度更慢，而且产出还不如你什么都不做。

Android 技能的真正含义

技能是基于 Markdown 的模块化 SKILL.md 指令集，它为任务提供技术规范，并设计为在提示与技能的元数据匹配时自动触发------无需手动为每个提示附加文档。

初始版本涵盖 Navigation 3 的设置和迁移、边缘到边缘支持、AGP 9 和 XML 到 Compose 的迁移以及 R8 配置分析。

但最重要的是要理解技能不是什么。它们不是通用的 Android 知识库。它们是针对当前前沿模型经常产生错误输出的特定领域的精准干预。这种区别在实践中至关重要。

安装过多技能的隐性成本

大多数开发者都会犯一个与直觉相悖的错误。

每个已安装的技能都会在每个任务的基础上下文中注入 100-200 个令牌。如果该技能被激活，令牌数量将飙升至数千个。对于一个每天运行 150 个任务，且涉及 10 项不必要技能的团队来说，每年很容易浪费 500-600 美元的代币，这些代币用于模型已经掌握的上下文信息------此外，还会因为噪声增加而导致输出质量下降。

谷歌的指导非常明确：在安装用于编写基础 Kotlin 或 Compose 的技能之前，请考虑你的 LLM 是否真的需要它，或者它是否已经足够了解这些主题。

正确的思维模型：

sql 复制代码

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

知识库（通过 android docs）涵盖了广泛的知识。技能涵盖了已确认的故障模式。始终安装知识库。有目的地安装技能。

技能带来的真正差异 --- 导航 2.8+ 类型安全

以下是提示之前/之后的具体输出： _使用主屏幕和接收用户 ID 的详细信息屏幕设置导航 _

ini 复制代码

// ❌ 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") ?: ""  
        )  
    }  
}

less 复制代码

// ✅ 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)  
    }  
}

为什么重要： 两种方法都可以编译和运行。然而，传统方法依赖于字符串解析和手动捆绑提取，这很容易出现拼写错误和运行时崩溃。 2.8+ 类型安全方法可以在编译时捕获路由错误，并完全消除手动参数解析。

Google 如何决定一项技能是否应该存在

只有当最先进的模型存在可验证的知识差距时，谷歌才会创造一项技能。每项技能在发布前都必须通过全面评估：

vbnet 复制代码

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`

评估不仅仅检查它是否编译，它还验证代理使用了正确的 Wear OS API。这就是为什么官方技能有大约 20 种，而不是 200 种。每一种都代表一种已确认的、可测量的故障模式。如果一个模型可靠地得到了正确的结果，那么就不需要任何技能------也不应该有。

生产就绪的 AGENTS.md

平庸的代理设置和出色的代理设置之间的区别通常取决于编写良好的"AGENTS.md"。这是一个真实的 Android 项目模板：

markdown 复制代码

# 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"。它优化的是与现有代码的一致性，而不是针对当前标准的正确性。

scss 复制代码

// ❌ 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)  
    }  
}

一项自定义技能明确指出向旧屏幕添加功能时，使用通过 ComposeView 嵌入的 Compose，而不是扩展旧模式，打破了代理巩固旧代码的倾向。即使你不需要官方的技能，这是编写自己的技能的最有力的论据。

入门 --- 正确的顺序

bash 复制代码

# 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

值得考虑的社区技能：Chris Banes 拥有全面的 Compose 和 Kotlin 合集，Ivan Morgillo 发布了 Compose 项目审核技能，Jaewoong Eum 创建了测试和性能技能。避免使用包含数十种人工智能生成技能的存储库------它们未经测试，可能会将你的代理推向错误的模式。

为弃用而构建的见解

这篇哲学博客文章的结尾听起来有些矛盾：谷歌正在明确构建要弃用的 Android 技能。

随着前沿模型的改进，技能变得过时。当他们的评估通过但没有激活技能时，谷歌会让他们退休。导航 3 技能的存在是因为当今的模型出错了。一旦他们确实做到了这一点，这项技能就会消失。

这意味着你的技能设置应该随着时间的推移而变小，而不是变大。每季度审核一次。删除你的模型不再需要的内容。目标是精简、有针对性的设置，而不是不断增长的代理配置文件库。

要点

技能目标是已确认的模型故障模式------而不是一般知识。谨慎安装，而不是彻底安装
每项任务的每一项技能都需要花费代币------不必要的技能会降低产出并浪费金钱
首先使用"android docs"知识库 - 对于文档无法弥补的差距，技能次之
Navigation 3 输出之前/之后显示了真正的区别 - 类型安全的路线与基于字符串的模式（可以编译但不应该存在于新代码中）
带有参考文件和明确反模式的生产"AGENTS.md"值得十几个通用技能
自定义技能使代理摆脱传统模式的束缚------最被低估的用例
技能被设计为可弃用的------每季度审核一次，保持你的设置精益

希望这篇文章值得一读。感谢你阅读本文。

欢迎搜索并关注 公众号「稀有猿诉」 获取更多的优质文章！

保护原创，请勿转载！