Google AI Studio 开始支持提示生成原生 Android 应用程序完成。
生成出来的是 Kotlin + Jetpack Compose 项目，可以在浏览器里的 Android Emulator 预览，也能安装到真机、发布到 Google Play 内测轨道，最后导出到 Android Studio 继续开发。
先跑原型
过去做一个 Android 原型，通常要先准备 Android Studio、SDK、Gradle、模拟器、项目模板和依赖配置。Android 开发者对这套流程比较熟，但产品、设计、运营、独立开发者未必愿意先跨过这道门槛。
过去制作的一个 Android 原型，通常需要先准备 Android Studio、SDK、Gradle、模拟器、项目模板和依赖配置。Android 开发者对这套流程比较熟悉，但产品、设计、运营、独立开发者未必愿意先跨越这道门槛。
AI Studio 把起点放到了浏览器里。你描述一个 App，它在云端生成项目，浏览器内置的 Android Emulator 可以直接跑起来，后续修改也在同一个页面里完成。
AI 工作室把起点放到浏览器里。你描述的一个应用程序，其在云端生成项目，浏览器内置的 Android 模拟器可以直接启动，后续修改也在同一个页面里完成。
这会改变早期原型的节奏。很多想法不需要先建本地工程，也不需要先等开发同学拉模板，能先进入可交互验证阶段。对团队来说，这类工具更适合把模糊想法变成一个能讨论的东西，而不是一开始就替代正式工程。
原生能力
AI 生成 App 这件事，过去更常见的是生成网页。网页预览快，部署简单，但到了手机设备上，很多需求最后还是要回到原生能力上。
离线能力、后台服务、GPS、蓝牙、NFC、相机、传感器、通知、系统权限、Wear OS、折叠屏姿态，这些不是普通 Web 页面能完整覆盖的。AI Studio 生成 Kotlin + Jetpack Compose 项目，意味着产物可以进入 Android 工程链路，而不只是停在一个可预览界面。
离线能力、后台服务、GPS、蓝牙、NFC、相机、传感器、通知、系统权限、穿戴操作系统、折叠屏模式，这些不是普通网页的完整覆盖面。AI Studio 生成的 Kotlin + Jetpack Compos 项目，意味着可以进入 Android 工艺链路的和服产品，而不仅仅是停留在一个可预览的界面。
当然，能生成项目不等于能长期维护。代码质量、状态管理、架构边界、依赖选择、异常处理、测试覆盖，仍然要靠开发者接手判断。但至少它进入的是 Android 正常技术栈，和"先生成 H5，再想办法打包"的路线不是一类东西。
真机安装
在 AI Studio 里创建和迭代时，浏览器内置 Android Emulator，所以本地不需要先下载模拟器镜像，也不需要先处理 SDK 环境。
真机验证也被接进来了。手机通过 USB 连接后，可以借助集成的 adb 直接从 AI Studio 安装到设备。如果你有 Google Play 开发者账号，AI Studio 还能创建应用记录、打包 bundle、上传到 Play Console 的 internal testing track。
这条链路对原型验证很实用。以前很多 App 想法会卡在"先建项目""先让别人装上""先发一个测试包"。现在这些动作被压缩到一个工具里，验证成本会低很多。
拿它做早期验证就够了。比如习惯记录、学习测验、活动行程、设备传感器 Demo、AI 小功能、内部流程工具、单人项目 MVP，都能用这种方式快速做出一个能跑的版本。
进入团队开发前，先把模块拆分、状态管理、网络层、权限说明、错误恢复、埋点和隐私处理逐项过一遍。AI Studio 能加速第一版，上线前的工程审查还是要回到团队自己的标准。
Play 内测
AI Studio 直连 Google Play internal testing track，比单纯"生成代码"更影响实际协作。App 不只是本机能跑，还要能发给别人试。
内部测试轨道解决的是小范围分发、安装、更新和反馈问题。AI Studio 如果能把创建应用、打包 bundle、上传内测串起来，原型就能从"我这里能跑"推进到"你也能装"。
这对非专业开发者尤其明显。他们不一定知道 AAB、签名、包名、测试轨道、Play Console 这些概念，工具把这段流程包起来，能减少大量前置成本。
对专业 Android 团队来说，它也能承担快速探索入口。产品想验证传感器交互，设计想看折叠屏动态布局，算法同学想把 Gemini API 放进移动端 Demo，AI Studio 生成的早期版本可以直接拿来讨论。讨论完之后，再决定要不要进入正式代码库。
导出后检查
AI Studio 不是 Android Studio 的替代品。项目可以下载成 ZIP，也可以导出到 GitHub，再进入 Android Studio 或其他 IDE 继续开发。
浏览器里的生成和预览适合快速推进想法，正式项目仍然需要本地工程能力。项目交接出来后，不要急着继续堆功能，先确认它能不能被正常工程化。
基础检查至少包括编译、Lint 和单元测试：
bash
./gradlew assembleDebug
./gradlew lintDebug
./gradlew testDebugUnitTest有设备测试时，把 connectedDebugAndroidTest 也放进检查项：
bash
./gradlew connectedDebugAndroidTest这些命令能尽早暴露 Gradle 配置、资源引用、Compose 编译、Manifest、权限声明、单元测试和设备运行问题。AI 生成的代码只要准备进入团队仓库，就必须先过这类检查。
Prompt 写法
这类工具的输出质量，很大程度取决于 prompt 的结构。一句"帮我做一个运动 App"通常不够，平台、页面、状态、数据、设备能力和限制都要写清楚。
一个最小可用的 Android prompt 可以这样写：
bash
Build a native Android app using Kotlin and Jetpack Compose.
The app is a habit tracker with two screens:
1. Today screen: show habits, completion state, and a quick add button.
2. Stats screen: show a 7-day completion chart.
Persist data locally.
Use Material 3 components.
Keep the UI usable on phones and tablets.
Do not require login.如果涉及硬件能力，prompt 还要写清楚权限和失败状态。相机不可用时怎么提示，定位权限被拒绝后怎么降级，蓝牙关闭后是否引导用户打开，这些细节决定 App 是"能演示"，还是"像一个真的 Android App"。
Wear OS、Pixel Fold、音乐练习这几个示例都用到了原生设备能力：手表传感器、折叠屏姿态、触摸交互、音频播放、本地保存、Gemini API。
最后
Google AI Studio 这次把 Android App 的起步门槛降到了浏览器和 prompt。对 Android 开发者来说，它更像快速原型和需求澄清工具，而不是完整替代 IDE、工程规范和发布审查。
真正需要看的是这条链路本身：Android 原生能力、Play 测试分发、Firebase、Android Studio、Gemini 正在被接到同一个入口里。