端侧AI实战：用离线模型打造无剧透读书问答App

在Google开发者系列节目《Code, Commit, Deploy, Repeat》第二季第二集中，两位工程师延续了一个颇具巧思的项目：构建一款能在离线状态下工作的读书问答应用。核心理念很简单——当你读一本长篇小说读到一半，突然想问「这个角色到底是谁」「凶案现场当时下雨了吗」，App要能准确回答，但绝不能剧透你还没读到的内容。这一集的重头戏，是把原本依赖云端Gemini模型的应用改造成优先使用端侧（on-device）AI推理。

从云端到端侧：Firebase AI Logic的混合推理

项目基础在上一集已经搭好：用公版书籍《福尔摩斯》（Sherlock Holmes，因版权公开而适合演示）做内容分块（chunking），存入Cloud Firestore，通过云端模型实现问答。这一集的首要任务，是让整个流程离线可用。

实现路径依托Firebase AI Logic的混合能力（hybrid capability）。要启用端侧推理，需要在原有的Firebase AI SDK之外，额外引入一个on-device客户端依赖。开发者在配置生成模型时可以指定四种推理模式：

• prefer on-device：即使有网络也优先使用端侧模型
• only on-device：功能仅在本地AI可用时才工作
• prefer cloud / only cloud：对应的云端优先或云端专用策略

节目中选择的是「prefer on-device，云端兜底」的策略——只有在无法使用或下载端侧模型时，才回退到云端Gemini Flash模型。这种设计的合理性在于：读书这个场景本身就常常发生在地铁、飞机等无网环境。

值得关注的一个工程细节是：端侧模型并非默认存在于设备上。代码需要先检查当前设备是否支持端侧模型、模型是否已安装，如果可下载但未安装，则通过Firebase Logic触发下载。对于较老的Pixel等硬件，可能根本不具备端侧AI能力——这时就需要通过Remote Config标志位来隐藏相关功能，或明确告知用户「此功能需要端侧AI支持」。

端侧（On-Device）AI推理是指将模型权重直接部署并运行在用户终端设备（如手机）上，而非通过网络请求远程服务器完成推断。其核心优势是无需网络连接、响应延迟低、用户数据不离开设备；代价是受限于移动端的算力与内存，可部署的模型参数量远小于云端，推理质量和长文本处理能力通常较弱。Google在Android生态中推进端侧AI的基础设施是Google AI Edge（前身为MediaPipe/LiteRT），Firebase AI Logic的混合能力正是在此之上封装的上层抽象，使开发者无需手动管理模型文件下载、量化格式兼容等底层细节，只需通过SDK配置推理模式即可在云端与本地之间灵活切换。

AI编程助手Antigravity的真实表现

整集节目的开发环境是Google的AI编程工具Antigravity配合Android Studio。这段实录难得地展示了AI编程助手在真实debug场景下的表现，既有亮点也有槽点。

亮点在于它对Firebase的领域知识（Firebase skills）掌握较好，即便内置知识过时，也能通过Google搜索grounding去读官方文档和代码示例来补齐。它会主动分析本地已安装的库依赖、执行git diff生成变更说明（walkthrough），甚至在开发者没要求的情况下顺手更新了UI、替换了过时的图标。

但问题同样明显。开发者多次吐槽它「有自己的想法」：明明每次都点了「Always allow」，它下次还是要重新询问确认;做了一堆没被要求的UI改动;分析问题时会绕远路去读Android SDK源码。整个调试过程中，两人频繁需要手动设断点、看堆栈、逐步step through，AI并没有一键定位到根因。

有意思的是关于「Turbo模式」的讨论。Martin建议开启让AI自动运行命令、少些确认弹窗，但Marina明确拒绝：「那对我来说太吓人了，我喜欢对代码变更保持一定程度的控制。」这代表了不少开发者对AI Agent自动化的真实态度——效率与可控性之间需要权衡。

层层排查：那些真实踩过的坑

这一集最有教学价值的部分，是他们遇到的一连串bug，几乎每一个都是Android/Firebase开发的经典陷阱。

第一个坑：NoSuchMethodError。 应用总是回退到默认的「zero spoilers」兜底消息，无法真正命中端侧模型。设断点排查后发现异常是generate content stream相关的no such method error。AI最终重构了逻辑，拆分出getHybridModel和getCloudModel两个函数，并指出根因在于Firebase SDK内部provider路由的错误处理存在缺口——端侧异常向外传播时，被外层的通用错误处理器捕获，直接跳到了离线兜底文案，跳过了云端推理。

第二个坑：Firestore缺少索引。 查询返回的chunk数量为零（retrieved chunks of size zero）。调试发现是Firestore的复合查询需要创建索引却没建。这里Martin给出了一个实用提醒：Firestore不像某些数据库那样缺索引就查不到数据，它仍会返回结果，但可能触发全表扫描——小表问题不大，数据量一大就会带来额外成本。所幸Firebase的报错信息里直接附带了创建索引的链接，观众Luke在直播弹幕里专门称赞了这一点。

第三个坑（最尴尬的一个）：选错了书。 折腾半天模型死活答不对「凶案现场是否有泥」，最后打开桌上的实体书对照才发现——他们查的根本是另一本没有泥污情节的福尔摩斯故事。真正演示时切换到《血字的研究》（A Study in Scarlet）才对上。这个乌龙也侧面说明，AI应用的问题未必出在模型或代码，数据源和上下文对齐同样关键。

还有连接问题： USB连接物理设备失败，其实是数据线的锅，改用Wi-Fi无线调试（pair device using Wi-Fi）后顺利解决。

Firestore复合索引问题值得展开说明。Cloud Firestore是一种NoSQL文档数据库，其查询模型与传统关系型数据库不同：单字段查询可自动索引，但当查询同时包含多个字段过滤或排序条件时（即"复合查询"），必须预先在Firebase控制台或配置文件中手动创建对应的复合索引，否则查询要么报错、要么触发全集合扫描（collection scan）。全集合扫描在小数据量下不影响正确性，但Firestore按读取文档数计费，数据量增大后会产生显著的额外成本，这正是Martin特别提醒的原因。Firebase的友好之处在于，缺少索引时的报错信息会直接附上创建该索引的控制台链接，开发者点击即可一键生成，无需手写索引配置。

未竟之处与端侧模型的短板

即便打通了端侧推理链路，节目结尾也坦诚了几个悬而未决的问题。最突出的是：端侧模型的回答质量明显不如云端。当使用端侧模型时，它倾向于把整段上下文（好几个章节的内容）一股脑吐出来，非常啰嗦;而云端Gemini Flash则能给出简洁精准的回答。他们尝试在prompt里加上「只回答用户问题、不要提供多余上下文」来约束，但效果有限。

Marina直言怀疑是模型版本差异：「Gemini 3.8 Flash做得不如3.6好，我要这么说，也许只是我被搞烦了。」（注：此处为节目中提及的开发者主观感受）他们最终定下的方向是：下一集要彻底搞清楚为什么端侧模型有时无法正常工作，并干掉那个「第三重兜底」——因为直接把整段上下文糊到用户脸上，是很糟糕的体验。

UI方面倒是收获不小。通过让Antigravity「重新设计一套更Material 3风格的界面」，聊天气泡、书籍选择页都变得美观许多，还加入了来源标注。遗留的小问题包括：气泡里的Markdown没渲染（需要引入支持Markdown的库）、多余的「spoiler guard」横幅、以及开始输入时底部的大块空白。

此外，节目还预告了一个来自同事建议的新功能：章节配图生成——读完几章后，让AI生成一张代表该章节情节的图片作为视觉记忆锚点，帮助读者回忆情节，甚至激发继续阅读的兴趣。

端侧模型与云端模型在回答质量上的差距，根本原因在于参数规模与量化压缩。云端Gemini Flash系列运行在Google数据中心，参数量可达数百亿，推理时使用全精度或高精度权重。而可部署到手机的端侧模型通常经过激进的量化（如INT4/INT8）和蒸馏压缩，参数量可能仅为云端的几十分之一，导致指令遵循能力（instruction following）明显下降——具体表现就是节目中观察到的"无法按prompt要求精简回答、倾向于照搬原文上下文"的现象。这类问题通常无法单纯靠prompt工程完全弥补，需要在模型选型、RAG检索粒度（减少传入上下文量）以及后处理截断等多个层面综合优化。

给开发者的几点启示

抛开福尔摩斯和调试插曲，这一集对做端侧AI应用的开发者其实有不少可迁移的经验：

• App Check是必选项：两位主持人反复强调，用Firebase Logic就一定要开启App Check保护——现在新建项目已经强制要求。
• 优先服务端prompt模板：对纯云端应用，建议用server prompt templates集中管理模型和prompt。
• 端侧AI要做好降级设计：设备能力、模型下载状态都需要显式检查，并用Remote Config控制功能可见性。
• AI编程助手是加速器而非替代品：真实debug中，人仍需理解堆栈、设断点、判断根因，AI擅长的是补全知识、生成样板和批量修改。

这是一个还在进行中的项目，代码已推送，端侧模型的调优和图像生成功能留待下一集。对想入门端侧AI + Firebase的开发者来说，这种「连坑带解」的实录，比一帆风顺的教程更有参考价值。