达尔文小姐Android Studio 正式支持 Gemma 4 这个消息出来之后，不少做移动端的朋友第一时间跑来问我：这跟之前那个云端 AI 助手有什么区别？本地的 Gemma 4 到底能干什么？我的回答很直接——这是整个 Android 工具链第一次把真正意义上的智能体编码模型拉到本地，不是那种随手补个括号的玩具，是真的能读懂项目上下文、自己改代码、跑测试的干活工具。这篇文章我就从为什么选本地模型、怎么把 Gemma 4 跑起来、怎么在 Android Studio 里调教它、以及我踩过的一堆坑这几块，完整分享一遍。如果你是刚接触本地模型的小白，或者已经用 Ollama 部署过模型但还没跟 IDE 打通，这篇应该都能帮上忙。
1. 为什么是 Gemma 4：从云端 AI 助手到本地智能体的转折
1.1 Android Studio 的 AI 编码功能演进
Android Studio 从 Hedgehog 版本开始就在探索 AI 辅助编码，那会儿主要靠云端服务，比如 Studio Bot 之类的东西。说实话，早期体验挺尴尬的，每次问个问题都要等网络往返，代码补全延迟高，最要命的是项目敏感代码会被传到云端。到了 Giraffe、Quail 这一代，Google 明显在往本地推理方向转型，但始终没有拿出一款真正能离线跑完整智能体任务的模型。
这次官方把 Gemma 4 定义为"最强大的智能体编码本地模型"，我理解它跟之前的补全模型有两个本质区别。
第一，它不再是单点预测。以前的模型看到 setContentView 会猜你下一步要写 findViewById，本质是 n-gram 概率游戏。Gemma 4 会先读一遍当前文件、相关资源文件、甚至 Gradle 配置，在内存里建一个轻量的项目索引，然后基于这个上下文生成改动方案。
第二，它支持多步工具调用。智能体编码不是"给你补完这行就完事"，而是能自己调用 IDE 的 API：搜索某个符号的定义、跳转到报错位置、执行 Gradle 任务、读完测试结果再回来改代码。这种能力以前只有 Claude Code、Qoder 这类外部工具配合本地模型才能做到，现在 Android Studio 原生集成了。
1.2 本地模型的真实优势与选型考量
为什么非要跑本地？三个字：隐私、延迟、成本。
隐私这块不用多说，企业项目里的代码资产比什么都重要。之前我接过一个金融类 App 的活，客户明确要求任何代码片段都不能出内网，云端 AI 直接没法用。本地模型跑在自己的机器上，模型文件就在磁盘里，推理全在 CPU/GPU 上完成，数据不出内存，合规压力小很多。
延迟方面，本地模型省掉了请求上传和结果返回的网络开销。实测下来，Gemma 4 的中等量化版本在 M 系列芯片或者 RTX 4070 上，单次补全的响应时间在 500 毫秒到 1.5 秒之间，虽然比云端旗舰模型略慢，但胜在稳定。云端模型高峰期排队能等十几秒，那个体验真的会让人抓狂。
成本也是硬指标。云端 AI 助手按 token 计费，一个稍大的项目每天轻松烧掉几十万 token，一个月下来账单够买一张显卡了。本地模型一次性买断硬件成本，之后的调用随便造。
当然，Gemma 4 也不是没有短板。它目前的上下文窗口和跨语言理解能力跟云端超大模型还有差距，尤其是冷门第三方库的 API 理解，偶尔会一本正经地给出不存在的类名。所以我的建议是：日常编码用本地 Gemma 4，遇到特别复杂的架构设计问题再转向云端大模型，两边互补。
提示：如果你是第一次接触本地模型，不要一上来就追求最大参数版本。先跑通 7B 或 8B 的量化版，确认 workflow 顺畅，再考虑上更大的模型。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备：把 Gemma 4 跑起来的最小可行方案
2.1 硬件要求与模型量化版本选择
要跑 Gemma 4，先别急着下载 Android Studio，先把模型运行环境搞定。官方文档给的参考配置是内存 16GB 起步，但我实际测下来，16GB 跑 7B 量化模型会有点勉强，建议 32GB 以上。显卡方面，NVIDIA 显卡有 CUDA 加成，体验最好；Apple Silicon 芯片靠 Metal 也能跑，M2 Pro 以上就比较流畅了；纯 CPU 跑也能用，就是响应会慢不少，适合偶尔用一下的场景。
模型文件选择是第一个坑。Gemma 4 有多个量化版本，常见的文件名里带 q4_K_M、q5_K_M、q8_0 这样的标记。q 后面的数字代表量化位数，数字越小文件越小、速度越快，但精度损失越大。我个人的推荐顺序是：
- 如果显存 8GB 以下：选
q4_K_M，文件大概 4-5GB，跑起来显存占用控制在 6GB 左右。 - 如果显存 12GB-16GB：选
q5_K_M或q6_K，质量和速度比较均衡。 - 如果显存 24GB 以上：直接上
q8_0，几乎无损，推理速度依然很快。
别选那些极端压缩的 q2_K 或 q3_K，代码补全场景对 token 的准确性要求很高，量化太狠了容易生成语法错误。
2.2 Ollama 部署与 Android Studio 配置
本地模型的管理工具我首推 Ollama，没有别的原因，就是省心。安装过程很简单，官网下载对应系统的安装包，装完打开终端跑一句 ollama run gemma4 就能把模型拉起来。如果你之前已经用过 Ollama 部署其他模型，只需要再执行 ollama pull gemma4 拉取新的模型文件即可。
拉取完成后，先验证模型能不能正常对话。在终端执行：
bash复制ollama run gemma4
然后输入一句"写一个 Kotlin 的单例类"，看看输出是否正常。这一步过了，再打开 Android Studio。
Android Studio 里需要做两件事。第一，在设置面板中找到 AI 助手相关的入口，把模型提供方改成"本地模型"；第二，填上 Ollama 的服务地址，默认是 http://localhost:11434。如果不确定地址对不对，可以在终端执行：
bash复制ollama list
这个命令会列出所有本地模型和对应的名称，确认模型名称跟 Android Studio 里填的一致就行。很多人在这一步卡住，明明模型拉下来了但 IDE 报错找不到模型，八成是名称拼写问题。
2.3 没有独立显卡的临时方案
如果你的电脑没有独立显卡，也别急着放弃。我试过用 WSL2 跑 Ollama，再让 Windows 版的 Android Studio 去连 WSL2 里的服务，虽然配置复杂一点，但完全可行。注意 WSL2 的 IP 地址不是 localhost，需要在 Android Studio 里填 WSL2 的虚拟网卡 IP，这个地址可以通过 WSL 终端里的 hostname -I 查出来。
注意：如果用的是 Intel HAXM 或 AMD Hyper-V 方案跑 Android 模拟器，同时又在跑本地模型，会争抢 CPU 资源。我遇到过模拟器掉帧 + 模型响应变慢同时出现的情况，解决办法是给模拟器分配更少的内核，把 CPU 资源让给推理。
3. Android Studio 集成细节与实操配置
3.1 在 Android Studio 中启用 Gemma 4 智能体
打开 Android Studio，进入 Settings -> Tools -> AI Assistant。如果你用的是新版，这里会直接看到 Gemma 4 的选项。选择本地模型模式后，界面会多出一个"智能体设置"分组，里面有三个关键参数：
- 最大生成长度：建议 2048，太小了生成的代码容易被截断。
- 温度：代码生成场景推荐 0.2 到 0.4，太高了容易胡编，太低了又缺乏灵活性。
- 上下文窗口：根据你的内存大小来，32GB 内存可以开到 8192，16GB 就老老实实保持 4096。
设置完之后，重启 IDE 让配置生效。第一次启动时 Android Studio 会跟本地模型建立一个连接，这个握手过程快则几秒，慢则半分钟，取决于模型文件是否已经加载到内存里。
3.2 代码补全、代码解释与项目上下文增强
Gemma 4 在 Android Studio 里最常用的三个功能是补全、解释和重构建议。
补全功能跟之前的内置补全不同，它不只是在你敲代码的时候补右边的内容，还能感知你在某个方法里想干什么。比如你写了一个空方法 fun fetchUserData()，然后回车换行，Gemma 4 会根据方法名、参数列表、以及项目里已有的网络层代码，自动生成一套基于 Retrofit 或 Ktor 的实现。这个"根据项目已有风格推断后续代码"的能力，是本地模型最大的卖点。
解释功能则是选中一段代码，右键选择“解释代码”，模型会把这个文件的上下文、相关依赖、方法调用链都读一遍，然后给出注释。这个对接手别人项目特别有用，尤其是那种几千行的 Activity 老代码。
上下文增强是进阶功能。Android Studio 会把你的项目结构信息（build.gradle、AndroidManifest.xml、资源文件列表）打包成精简索引，喂给模型当作参考。这样当你问"这个按钮为什么点不动"的时候，模型能结合布局文件和 Activity 代码一起分析，而不是瞎猜。
3.3 与 AGP、Gradle、模拟器的兼容性注意
很多人在热搜里搜“Android Studio Hedgehog 支持 AGP 8 吗”，担心新版功能会跟老配置冲突。实际测试下来，Gemma 4 智能体对 AGP 版本的要求并不高，我这边从 AGP 7.4 到 8.5 都试过，只要 Gradle 能正常构建，模型就能正常读取项目信息。唯一要注意的是，如果项目用了比较老的 Gradle 版本，Android Studio 的索引构建可能会卡住，会导致模型拿不到最新的代码上下文。解决办法是在设置里触发一次 File -> Sync Project with Gradle Files，让索引重建。
模拟器方面，Gemma 4 本身不依赖模拟器，但如果你的开发机配置不高，同时开模拟器和本地模型会很吃力。我的做法是开发时用真机调试，模拟器留给 UI 测试和截图场景。如果你非要用模拟器，记得把模拟器的分辨率调低一点，或者用 -no-window 模式跑 headless 测试，能省不少内存。
4. 智能体编码的典型场景与工作流
4.1 基于自然语言生成 Compose UI
本地模型最能打的场景之一就是 Jetpack Compose UI 生成。以前写一个带状态管理的可滚动物料列表，需要手动搭 LazyColumn、remember、mutableStateOf 这一整套。现在你只需要在编辑器里用自然语言写清楚需求，比如"创建一个商品列表页面，每个 item 显示缩略图、标题、价格，点击跳转详情页"，Gemma 4 就会生成一整套 Composable 函数。
关键在于，它生成的代码会把项目里已有的主题颜色、字体样式、导航库都考虑进去。我试过在一个已经用了 Navigation Compose 的项目里让它生成页面跳转，它直接用了现有的 NavController，而不是另起炉灶，这点确实聪明。
生成的代码不一定一次就对，但初稿质量已经很高了，剩下就是微调。我建议生成之后手动过一遍 import、资源引用和命名，因为本地模型偶尔会用错资源 ID。
4.2 单元测试生成与 Bug 修复
单元测试生成是 Gemini 模型的传统强项，Gemma 4 也不例外。选中一个方法，右键选择"生成测试"，模型会读取方法的签名、参数、返回值、以及方法体里用到的依赖，然后生成 JUnit 测试和 Mockito mock。遇到私有方法会自动反射调用，遇到 Android 依赖会自动加 Robolectric 注解，这些细节处理得相当到位。
Bug 修复场景更有意思。IDE 自带的分析器会报出 lint 错误和编译错误，Gemma 4 能直接读取错误信息，结合出错的代码块给出修复建议。有一次我遇到了一个典型的 ConcurrentModificationException，它不仅能指出是遍历集合时修改列表导致的，还自动给我重构成用 Iterator 删除元素。这种深层次修复，以前的普通补全模型根本做不到。
4.3 Room 数据库与性能优化场景
热搜词里很多人问怎么用 Room 数据库，这个场景也很适合 Gemma 4。你只需要描述实体结构，比如"一个用户表，字段包括 id、name、age、email，需要按年龄倒序查询"，模型就会生成带注解的实体类、DAO 接口、以及数据库配置。它生成的 SQL 查询语句会注意索引和游标关闭，比手写靠谱多了。
性能优化场景主要是分析线程和内存问题。你可以在代码里选中一段可疑的循环逻辑，让模型分析复杂度并给出优化建议。它会结合 Android Studio Profiler 的输出日志，帮你定位到具体是哪个方法阻塞了主线程。不过这里有个前提，你需要先把 Profiler 导出的 trace 文件路径告诉它，否则它只能基于静态代码猜测。
5. 常见问题与排查技巧实录
5.1 模型加载慢或 OOM
这是被问得最多的一个问题。现象是第一次在 Android Studio 里调用 AI 助手时，要等很久，然后报 OutOfMemoryError 或者 model load failed。绝大多数情况是并发导致的：Android Studio 自身的 JVM 堆内存跟 Ollama 的显存/内存占用撞车了。
解决方法是给两者各自分配资源。Android Studio 里改 studio.vmoptions 文件，把最大堆调到 4GB 到 8GB 就够用了；Ollama 则通过环境变量限制模型占用的显存比例，比如执行 OLLAMA_MAX_LOADED_MODELS=1 OLLAMA_NUM_PARALLEL=1 ollama serve。
如果是纯 CPU 跑，OOM 更容易出现在模型加载到内存的那一下。建议先把其他应用关掉，尤其是 Chrome，这货吃内存是真的猛。
5.2 补全结果质量差
补全结果不行，十有八九是上下文窗口太小。Android Studio 传给模型的是当前文件 + 相关类摘要，窗口太小的话模型看不到关键信息。如果你发现它生成的代码总是缺 import 或者用错变量名，先把上下文窗口从 4096 调到 8192。
另一个常见原因是温度太高。有人喜欢把温度调到 0.7，觉得这样代码有创意。但代码不是文案，创意意味着随机性，随机性意味着语法错误。我建议代码补全场景温度不要超过 0.3，如果还是乱生成，检查一下是不是同时开了太多 AI 功能导致请求排队，互相污染了上下文。
5.3 WSL2/虚拟化与本地模型冲突
在 Windows 上开发的朋友会遇到一个比较隐蔽的坑：Android Studio 本身要跑虚拟设备，WSL2 也要占虚拟化资源，然后 Ollama 再在 WSL2 里跑模型，三者叠在一起，资源直接爆炸。
我之前遇到的情况是模拟器启动没问题，但一调用 AI 助手就蓝屏。排查到最后发现是 WSL2 的 .wslconfig 里内存分配被写死成宿主机全部内存，导致宿主机没有余量给 Ollama 和 IDE。解决方案是把 .wslconfig 里的内存限制改成 8GB，CPU 核心数改成 4，剩下的资源留给模拟器和 Android Studio。
5.4 代理设置与插件仓库问题
很多人在搜索"Android Studio 代理设置"，那是因为插件下载和 SDK 管理器常年连接不稳定。在 Android Studio 里配置代理本身不复杂，Settings -> Appearance & Behavior -> System Settings -> HTTP Proxy，手动填写代理地址和端口就行。但如果用了本地模型，我建议代理的设置范围不要影响到 localhost 流量，否则 IDE 可能尝试通过代理访问 Ollama 的 11434 端口，导致连接失败。
注意：如果你在插件市场里找不到智能体相关插件，先检查代理是否把 Google 的插件仓库路径拦截了。换成国内可用的镜像仓库地址之后，插件秒装成功。
6. 我的几点实操心得与后续扩展
最后分享几个我实际用下来的感受，不保证对每个人都适用，但值得参考。
第一，本地模型最适合的个人工作流是"草稿由 AI 生成，审查由自己完成"。Gemma 4 能写出 80% 标准程度的代码，但剩下 20% 的业务耦合和边界条件，还是得靠人工补齐。别指望它一次性写完整块功能，更好的用法是让它生成骨架和重复性代码，你再往上填业务逻辑。
第二，留意模型版本的更新。Ollama 上的模型标签更新速度很快，Gemma 4 后续肯定会出更小但更强的蒸馏版本，或者针对 Kotlin 优化的微调版。我习惯每周跑一次 ollama pull gemma4，看看有没有新版本可以升级。
第三，你可以把这个智能体能力延伸到 Android Studio 之外。本地模型跑起来之后，Qoder、Claude Code 这类外部 AI 编程代理也能通过 Ollama 的 API 连接同一个模型。这样一台机器上的模型可以同时服务 IDE 和命令行工具，整个编码环境就打通了。这个思路也适合其他需要本地模型支撑的场景，比如视频生成模型的本地部署、知识库问答机器人等，本质上都是同一个套路：先把模型服务跑起来，再让应用去连它的 API。
我踩过不少坑之后最大的体会是：本地模型最大的价值不是替代云端模型，而是让你在工作流里多了一个完全自主可控的选项。真正用顺手了之后，你会发现很多以前不敢交给 AI 的任务，现在都可以放心地放进日常开发循环里。如果你也在折腾 Android Studio 的本地模型，希望这篇能帮你少走点弯路。