Android CLI：Google 让安卓开发拥抱 AI

一、为什么我重新对安卓开发燃起兴趣

曾经尝试学习安卓开发。每次起手，面对的都是 SDK、Gradle、AVD、Manifest 这套庞杂的体系——光是配置好一个能跑起来的开发环境，就要耗费大量心力，这套东西的复杂度远远超过了预期，最终每一次尝试都以放弃告终。

最近一年，我开始重度使用 Claude Code，用它写后端、写脚本、做各种日常的编程任务，逐渐习惯了"用自然语言描述需求，由 AI 完成实现"的工作方式。在这套流程里，我几乎不再被某个语言或框架的入门门槛所困扰——只要 AI 能读懂文档、能跑代码，它就能帮我趟平大部分障碍。

但安卓开发在印象里一直是个例外。长久以来，安卓开发与 Android Studio 深度绑定：项目结构、模拟器、调试器、可视化编辑器，几乎所有核心环节都被收拢在这一个 IDE 之内。这让我很难想象，一个第三方的编程 Agent 如何能在 Android Studio 之外独立完成安卓应用的开发。

直到前阵子，我看到 Google 发布了 Android CLI——一套专门为 AI agent 设计的命令行工具。它的出现传递了一个明确的信号：Google 开始让安卓开发主动拥抱 AI。有了官方提供的命令行接口、技能和知识库，AI agent 终于可以在不依赖 Android Studio 的前提下，以程序化的方式完成安卓开发的核心工作流。

这让我觉得，自己亲手做一个安卓 App，第一次成为了一件现实可行的事。

二、Android CLI：为 AI agent 而生的命令行工具

要理解 Android CLI 的价值，首先要理解一个前提：当 AI agent 拥有轻量级、程序化的接口去与 SDK 和开发环境交互时，它的表现最好。 反过来说，如果 agent 只能靠"猜"——猜项目结构、猜构建命令、猜配置参数——它的效率就会急剧下降，token 消耗也会飙升。

这正是 Android CLI 要解决的问题。它是 Google 官方提供的命令行接口，定位是"以智能体为先（agent-first）的工作流的核心"。它标准化了安卓开发中最关键的几类操作，让任何 agent——无论是 Android Studio 内置的 Gemini，还是 Claude Code、Codex 这类第三方工具——都能用同一套确定性命令完成工作，而不必各自摸索。

它的核心命令大致可以归为三类：

项目与环境管理。android create 可以在几秒内基于官方模板生成一个新项目（默认使用 empty-activity-agp-9），这意味着从第一行代码起就遵循 Google 推荐的架构与最佳实践。android sdk install 则允许按需下载所需的 SDK 组件，避免安装臃肿的全套工具链。

设备与运行控制。android emulator create / start / stop 提供了对虚拟设备的完整生命周期管理，android run 则负责把构建好的 APK 部署到设备上并启动。这一套命令把传统开发中"构建—安装—启动"的繁琐循环，压缩成 agent 可以直接调用的几个原子操作。

界面感知能力。 这是 Android CLI 尤其巧妙的一环。android layout 能以 JSON 格式输出当前应用的界面布局树，android screen capture 可以截图并在元素上标注边界框，android screen resolve 则把视觉标签换算成真实的屏幕坐标。也就是说，agent 不再是"盲写"代码，而是能真正"看见"应用运行时的样子——这对 UI 调试和自动化测试意义重大。

不过，如果只停留在命令工具层面，Android CLI 还算不上颠覆性。真正让它成为"安卓开发的 AI 基础设施"的，是它内置的知识库访问能力。通过 android docs 命令，agent 可以走一个两步流程来获取官方权威信息：先用 android docs search <query> 搜索问题，得到一批以 kb:// 开头的文档地址；再用 android docs fetch <kb-url> 把具体内容拉取到终端。这个知识库的内容源自 Android 开发者文档、Firebase、Google Developers 和 Kotlin 官方文档，并且持续更新。

这一点为什么重要？因为大模型的训练数据天然是滞后的。即便一个模型的训练截止日期就在一年前，它对最新框架、最新 API 的认知仍然可能是过时的。而 android docs 相当于给 agent 接上了一条实时更新的"官方知识管道"，让它始终基于 Google 当前推荐的方案来生成代码，而不是凭记忆输出可能已经废弃的写法。

Google 公布的内部实验数据也印证了这套设计的有效性：相比 agent 仅使用标准工具集去完成任务，Android CLI 能把 LLM 的 token 消耗降低 70% 以上，任务完成速度提升约 3 倍。这两个数字直观地说明了"消除猜测"带来的收益——agent 不再需要反复试错，而是沿着确定性的路径直达目标。

三、Android Skills：给 AI 灌输最佳实践的指令集

如果说 Android CLI 解决的是"agent 如何动手"的问题，那么 Android Skills 解决的就是一个更隐蔽、却同样关键的问题：agent 动手时，依据的是什么。

这里要回到一个容易被忽视的矛盾。传统技术文档——包括 Google 自己的开发者文档——本质上是描述性的、概念性的、偏高级别的。它们对人类学习者很友好，因为人类擅长举一反三。但大模型不是这样工作的：要让它精确地执行一个复杂工作流，它需要的是精确、可操作、步骤明确的指令，而不是一段泛泛的背景介绍。如果只喂给它概念性文档，它往往会照着过时的模式或废弃的库去生成代码。

Android Skills 正是为了弥合这道鸿沟而设计的。它是一套模块化的、以 Markdown 编写的指令集（每个技能对应一个 SKILL.md 文件），为特定任务提供精确的技术规范。更巧妙的是它的触发机制：当你的提示与某个技能的元数据匹配时，该技能会自动激活，省去每次手动附加文档的麻烦。从 agent 的视角看，这相当于它的知识库里常驻着一批"即插即用的专家手册"。

在初始版本中，Google 在 Android 技能的 GitHub 仓库里提供了若干覆盖常见工作流的技能：

• • Navigation 3 的设置与迁移；
• • 边缘到边缘（edge-to-edge） 显示的实现；
• • AGP 9 与 XML 到 Compose 的迁移；
• • R8 配置分析 等等。

这套技能库还在持续扩充。使用上，它通过一组 skills 命令管理：android skills list 查看可用技能，android skills find 'performance' 按关键词检索，android skills add --skill=edge-to-edge 则把指定技能安装到对应 agent 的技能目录中。值得一提的是，官方技能可以与你自定义的技能、以及社区贡献的第三方技能共存——这意味着整个生态是开放的，而非封闭在 Google 自己的工具链里。

把三个组件放在一起看，整个设计的逻辑就清晰了：CLI 给 agent 一双手（确定性操作），Knowledge Base 给它一双看最新文档的眼睛（docs），Skills 则给它一套遵循最佳实践的工作方法。 三者各司其职，共同把"在 Android Studio 之外用 AI 开发安卓应用"从一句口号，变成了一个有官方背书、有确定性路径、有质量保证的可行流程。

四、真正上手之后：两点体会

讲了这么多工具的原理，终究要落到真实使用上。就在今天，我用这套工具从零尝试了一次完整的安卓开发。整体比我预想的顺利，但过程中也暴露出两个值得记录的问题。

体会一：技术门槛降了，UI 与交互的门槛还在

Android CLI 解决的是"让代码能跑起来"的问题——它把环境配置、项目搭建、设备调试这些硬骨头都啃下来了。但"让 App 跑起来"和"让 App 出色"，是两件完全不同的事。

一个真正有吸引力的应用，需要的远不止功能正确。它需要交互流畅、视觉有辨识度、能提供所谓"情绪价值"——也就是那种让用户一眼记住、愿意留下的设计风格。而这恰恰是当前 AI 工具最难覆盖的领域。技术层面的可行性，并不等于产品层面的吸引力。

我也尝试用 Google Stitch 来补这一环。Stitch 是 Google 推出的 AI UI 生成工具，口号是 “From idea to app”，由 Gemini 驱动，能根据文字描述或草图快速生成 UI 界面和前端代码。实际用下来，效果确实还可以——生成一个结构合理、可用的界面并不难。但问题也很明显：Stitch 的产出倾向于一种"安全、通用"的风格，足够得体，却缺乏个性。如果目标是做一个有独特气质的 App，这部分的设计仍然得靠自己来主导，AI 只能充当快速起稿的助手。

换句话说，Android CLI 把开发的下限拉高了，但应用的上限——那个决定它是否出色的部分——依然取决于人。

体会二：复杂项目里，Spec-Driven 流程与 Android CLI 如何咬合

安卓开发算是我近来做过比较复杂的一个项目，代码量大、涉及的概念多。这种规模下，我决定用上 Superpowers——一套强调 Spec-Driven Development（规约驱动开发）的技能体系。坦白说，我以前一直觉得它有些臃肿：头脑风暴、设计文档、执行计划……中间产物太多，小项目用起来反而拖慢节奏。但当项目复杂到一定程度，这套流程的价值就显现出来了，它让 AI 的每一步都有据可依，而不是漫无目的地写代码。

不过，这也带来一个新的挑战：在 Superpowers 那套充满中间步骤的流程里，怎么让 AI 持续、正确地使用 Android CLI？

Superpowers 的典型链路是"设计文档（Spec）→ 执行计划（Plan）→ 实现"，每一步都会产生需要 AI 决策的中间产物。如果不加干预，AI 很容易在某个环节"脱轨"——比如基于自己记忆中过时的 API 去设计，而不是遵循 Google 当前的最佳实践。

我在这段实践里摸索出的做法是两点。第一，在每一个中间步骤，都明确提示 AI：用 Android CLI 去核对官方文档。第二，也是更关键的一点——既然这是 Spec-Driven 流程，那么就在每一份 Spec 产生之后，通过 Android CLI 的 docs 知识库能力去复核它。也就是说，设计文档里写下的每一个技术决策，都要拿去和知识库里的最新指南比对，确认没有引用过时的模式或废弃的库，才进入下一步。

这样做的效果是把 Android CLI 从一个"偶尔调用的工具"，变成了贯穿整个开发流程的"事实校验器"。AI 不再是凭记忆设计，而是始终锚定在 Google 官方的最新实践上。Spec-Driven 保证了流程的严谨，Android CLI 的知识库则保证了每一步内容的准确——两者咬合在一起，才撑得起一个复杂项目的质量。

回过头看，Android CLI 真正改变的不是某一项技术，而是安卓开发的"可及性"。它把过去那套庞大、封闭、令人生畏的工具链，拆解成了 agent 能直接使用的确定性命令、实时更新的知识库和即用的最佳实践技能。对一个像我这样曾被门槛劝退的人，这意味着"亲手做一个安卓 App"第一次落入了现实可行的范围。

但这次实践也让我清醒：工具降低了实现的难度，却没有降低做好一个产品的难度。代码能跑起来，靠的是 Android CLI；而应用是否出色，靠的依然是人对交互和设计的判断。技术是基础设施，品味才是天花板。