达尔文小姐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