B 站「谷歌刚发布 AndroidCLI，会让 AndroidStudio 失业吗？」的评论区里，吵得很实在：顶评「我认为 Studio 还是无法替代的」拿了 10 赞，楼下补刀「CLI 连不了真机调试，图形化界面还是有必要」。哔哩哔哩但另一句高赞语境相同的话把当下 Android 开发者接入 AI 的真实处境摆了出来——有人「需要 CLI 来测试嵌套滑动问题」，因为「手动测试太难受了」。代码生成早就不缺了，缺的是「改完之后，怎么证明它真的没问题」。
2026 年 8 月底，知乎上刚开的新问题问的就是它：项目开发成本真的下降了吗？知乎 这个问题恰好撞上 Google 那套 Android CLI + Android Skills 从「发布」走到「能干活」的窗口期。值得把这条工具链掰开看清楚：它补的是什么洞、哪些环节现在就能交给 Agent、哪些坑踩了会付出真实成本。
先看时间线：为什么 4 月发布的工具，8 月才值得写
信息增量恰恰藏在这半年里。4 月 Google 推出面向 Android 开发工具和 AI Agent 的这套组合，B 站快讯视频播放冲到 2.7 万，讨论集中在「替代焦虑」上。哔哩哔哩 5 月就出现了「借助 Android CLI 与 Android Skills 让任意 AI 智能体构建应用」的实操向视频，工具开始被真实工程试跑。哔哩哔哩到 8 月 11 日，有开发者完成了带版本号的环境核验：Android CLI 版本为 1.0.15985488，android/skills 仓库最新标签为 v1.0.7，仓库中共有 22 个 SKILL.md；8 月 18 日，基于这套核验环境的最佳实践长文在知乎发出。知乎
也就是说，「会不会失业」的情绪讨论是 4 月的事；到 8 月，这套东西已经沉淀出了可复述的版本号、可执行的工作流和真实的评论区反馈。现在能回答的不是「Agent 能不能替代 Android 开发」，而是「你的项目里，Agent 已经能接管到哪一步」。
这套组合到底干什么：给 Agent 装上手和眼
先把最容易写歪的地方澄清掉：Android CLI 不是用来替代 Gradle、ADB、SDK Manager 或 Android Studio 的。它做的事是把 Android 工程里的常见操作整理成 AI Agent 容易发现、调用、解析的结构化命令，能力分五组：环境与 SDK（`android info`、`android sdk list/install`，输出 SDK 路径、补齐平台组件，减少 Agent 对环境的猜测）；工程与构建产物（`android create`、`android describe`，describe 会分析项目并输出描述构建目标和 APK 产物位置的 JSON）；设备与模拟器（`android emulator`、`install / run`，管理 AVD、部署 APK、启动组件）；界面检查（`android layout`、`screen capture/resolve`，拿布局树 JSON、截图，把标注截图的目标转成点击坐标）；文档与 IDE（`android docs` 两步式查询官方知识库、`android studio` 连接正在运行的 Studio 与 Gemini）。
而 Android Skills 是另一半：每个技能是一个 SKILL.md，按 Agent Skills 开放规范固化具体任务的官方工作流、约束和参考资料，Agent 按 name 和 description 判断要不要加载。官方 README 有个很聪明的取向：技能建设优先选择评测中 LLM 表现较弱的任务，基本 Compose 最佳实践这类模型已经熟悉的反而不是重点。知乎所以它的正确定位是「任务级操作规程」，不是 Android 百科全书——这也解释了为什么只有 22 个技能而不是一堆。两者配合之后，Agent 才能从「生成一段代码」走到「读取工程→查官方文档→修改代码→部署设备→检查结果」的完整闭环。
六阶段验收链：最容易偷懒的是第 1 步和第 6 步
8 月那篇核验文给出了一个很实用的拆解——把 Agent 任务分成六个阶段，每阶段都有可复查的证据：
阶段 | 产出证据 |
|---|---|
1 环境基线 | CLI 版本、SDK 路径、设备序列号、Git 状态 |
2 选择技能 | 技能名称、适用条件、版本前提 |
3 查询资料 | 文档地址（kb://）、API 版本、库版本 |
4 修改与静态检查 | diff、测试结果、Lint 输出 |
5 部署交互 | APK 路径、设备序列、启动状态 |
6 验收证据 | 布局 JSON、截图 PNG、trace 结果 |
没有第 1 步，Agent 会在错误的 SDK、模块或设备上干活；没有第 6 步，「代码已修改」就只是文件变了，不等于问题解决了。评论区「改完没法验收」的痛点，本质就是大多数人的 Agent 工作流只有第 3、4 步。拿评论区里「我需要 cli 来测试嵌套滑动问题，手动测试太难受了」这个场景来说，`android layout` 的 `–diff` 返回相对上一次布局快照发生变化的元素，适合检查点击、展开、键盘弹出后的 UI 状态，不用肉眼盯回放。哔哩哔哩知乎验收 UI 时布局树和截图也别二选一——一个回答「节点在哪里、属性是什么」，一个回答「最终画面长什么样」。
哪些环节现在能交给 Agent，哪些必须留人
按这半年的实操信号和官方约束，可以给一个相对清晰的分工。
可以放心让 Agent 跑的：查文档（把「先搜索知识库、再用返回的 kb:// 地址读正文」写进任务要求，别让它凭记忆答 API 版本）、部署启动（`android run`；多模块项目先跑 `describe` 读结果再决定 APK 路径，而不是默认产物总在 app/build/outputs/apk/debug/）、UI 证据采集（布局树、标注截图、`screen resolve` 坐标）。
必须留人的地方，官方甚至替你写进了约束：r8-analyzer 默认只分析并输出报告，不允许直接修改文件。知乎R8 keep rule 涉及反射、序列化和 JNI，删掉一条看似宽泛的规则可能只在 Release 包的低频路径上崩溃——正确用法是让 Agent 出报告，人工确认反射入口和回归测试后再开单独的修改任务。perfetto-trace-analysis 同样要求先在证据链里记录已验证证据、沿线程阻塞关系追到依赖方，不允许「看到长 slice 就当 CPU 执行很久」。至于调试类工作，尤其真机断点，CLI 并不覆盖——4 月评论区的抱怨今天依然成立。
几个真实成本坑，踩之前先看一眼
接入前最值得核对的是数据收集边界：Android CLI 会记录命令与子命令的调用、非位置参数名称、部分预定义选项值，以及匿名化后的异常堆栈；不会收集 CLI 返回内容、用户自定义输入、Maven 坐标、本地文件路径或项目名称。知乎公司内部项目动手前，按你们的开发工具与网络策略综合评估，别默认它「什么都不传」。另外三条短账记在心里：`skills add --all` 别当默认动作，技能装太多反而增加 Agent 触发冲突和读无关材料的概率，团队共享操作规程走项目级安装、`android-cli` 这类跨项目通用技能再全局装；改过官方技能要先改名，否则下次更新直接覆盖；实测中位置参数与 README 的 `–skill=` 写法存在差异，先跑本机 `android help` 确认。`studio` 子命令目前要求项目开在 Android Studio Quail 2 Canary 1 或更高版本并登录 Gemini——Canary 这个前提本身就说明它是给尝鲜者准备的，IDE 没连上就回落到 Gradle、源码检索和设备验证，别让整条流水线卡在这一个子命令上。
最后说回「失业」那个问题
就业焦虑簇最近确实热：「安卓开发真的凉了，根本没有人学了」这种标题的视频评论区，转桌面端、劝退、唱衰挤在一起；知乎上「现在Android开发找不到工作」的老问题最近一条回答，4 天浏览冲到 5.8 万。哔哩哔哩知乎但把这条工具链看完，结论应该更精确一点：Agent 替代不了的，恰好是这条验收链上「定义证据、审查证据」的人。当你能把一个任务连目标、范围、约束、验收方式一起交给 Agent，再基于布局 JSON 和 trace 做判断，你的产出结构和 5 月那条「让任意 AI 智能体构建应用」的演示已经是同一种工作方式；反过来，如果接入姿势只是「让 AI 帮我写两个 Kotlin 文件」，那确实只是在给旧简历添一行。
值得继续盯的三个信号：android/skills 仓库从 22 个技能继续扩张的方向（是不是开始覆盖你真机调试和 CI 的痛点）、`studio` 命令何时脱离 Canary 前提、以及增量安装 `–use-delta-install`（首次安装或安装异常时记得关掉重装）会不会成为团队协作的默认姿势。这三件事哪个先落地，哪个就值得回来重读一遍这篇文章。
