用Flutter和Gemini API打造你的ChatGPT：200行代码实现流式对话

在AI聊天应用遍地开花的今天，很多开发者好奇：自己动手做一个类似ChatGPT的App到底有多难？一位YouTube创作者用Flutter和Google的Gemini API给出了答案——不到200行代码，就能构建一个具备流式回复和对话记忆的真实AI聊天应用。

这个项目最巧妙的地方在于架构设计：Flutter应用并不直接与Gemini通信，而是通过Firebase AI Logic作为中间层。这解决了移动开发中一个经典难题——API密钥的安全问题。

为什么不让App直接调用Gemini？

把API密钥直接塞进移动应用是危险的。原作者在视频中一针见血地指出：任何人都可以解包你的应用，窃取密钥。通过Firebase中转，密钥永远不会随应用一起分发。

Firebase AI Logic是Google官方推荐的移动端调用Gemini的方式。它提供免费额度，让学习者无需付费即可跟随实践。有意思的是，使用的Flutter包是firebase_ai，它已经取代了已废弃的google_generative_ai包——如果你看到旧教程中用法不同，原因就在这里。

配置流程并不复杂：在Firebase控制台创建项目、开启AI Logic并选择带免费额度的Gemini Developer API，然后在Flutter项目中运行flutter fire configure生成配置文件，最后添加firebase_core和firebase_ai两个依赖。

Firebase AI Logic 是 Google 在 2025 年推出的一项服务，属于 Firebase 生态的一部分，专为移动端和 Web 应用提供对 Gemini 模型的安全访问。它的核心机制是：客户端 SDK 不携带任何 API 密钥，而是通过 Firebase 项目身份验证和 App Check 来鉴权，请求经由 Google 后端代理转发至 Gemini API。除了密钥安全，它还统一了 iOS、Android、Web 和 Flutter 的调用接口，并内置了配额管理和滥用防护。对于学习者而言，Firebase AI Logic 提供了 Gemini Developer API 的免费额度层，无需绑定信用卡即可开始实验，这大大降低了入门门槛。需要注意的是，免费额度有速率和总量限制，适合原型验证但不适合生产流量。

流式回复是怎么实现的？

核心秘密在于sendMessageStream。与等待完整答案的sendMessage不同，流式接口会在Gemini生成内容的同时，将文本分片推送回来。开发者用await for循环遍历每个片段，将其追加到消息对象的文本字段上，每次setState触发重绘，用户就能看到答案逐词浮现。

这也解释了为什么消息模型中的text字段不能声明为final——它需要在流式过程中持续变化。

在等待首个响应时，消息文本为空，界面显示三个点作为加载指示。这个细节虽小，却让应用显得更有生命力。

流式传输（streaming）之所以能显著改善聊天体验，是因为大语言模型的生成是逐 token 进行的。传统 sendMessage 需要等待模型生成完整回答后才一次性返回，用户面对空白屏幕的时间可能长达数秒；而 sendMessageStream 在模型每产生一个文本片段时就立即推送，首字延迟（time-to-first-token）通常不到一秒。在 Dart 中，sendMessageStream 返回一个 Stream，await for 循环会持续消费直到流关闭。每次收到新片段时调用 setState 触发重建，Flutter 的增量渲染机制确保只有变化的部分被重绘。这种模式对网络波动也更友好——即使连接中断，已接收的文本仍然保留在界面上。

对话记忆：chat session的作用

一个能记住上下文的AI才像真正的助手。model.startChat()创建的chat session会保存完整对话历史，并在每次请求时一并发送给Gemini。这就是为什么用户问"再说一个"时，AI知道仍在讨论章鱼——对话的连贯性由session维护，开发者无需手动拼接历史消息。

系统指令（system instruction）则相当于给AI设定人格。原作者让它"友好、回答简洁、使用纯文本"。最后一点尤其关键：如果不加限制，Gemini会返回Markdown格式，聊天气泡里就会出现包围粗体文字的小星星。

这个系统指令可以随意修改——数学导师、旅行向导，甚至海盗口吻，全凭你的想象力。

系统指令（system instruction）与大模型 API 中的普通用户消息不同，它在对话开始前设定模型的全局行为约束，优先级高于单条用户输入。在 Gemini API 中，system instruction 作为独立字段随每次请求发送，模型会在生成时将其视为不可违背的上下文前提。它适合放置角色设定、输出格式要求、安全边界等内容。与 few-shot 示例相比，system instruction 更轻量，不占用对话历史名额。不过，system instruction 并非绝对可靠——模型仍可能偶发偏离，因此对格式有严格要求的场景（如 JSON 输出）通常还需配合 response schema 或后处理校验。

界面细节与性能考量

聊天气泡遵循经典布局：用户消息右对齐、主色调，AI消息左对齐、柔和灰色。约束宽度限制在300像素，让长回答自然换行而非撑满屏幕。

消息列表使用ListView.builder，只构建可见的条目，因此即使对话很长也能保持流畅。当答案不断增长时，代码会在帧绘制完成后自动滚动到底部，否则新文本会滑出屏幕。

发送逻辑中还有几处值得借鉴的防御性设计：空输入或正在等待回复时直接返回；用try-catch包裹网络请求，出错时展示提示而非崩溃；无论成功失败都关闭加载状态。

WidgetsFlutterBinding.ensureInitialized() 是 Flutter 框架启动流程中的关键一步。Flutter 应用在 runApp 之前，引擎与 Dart 层之间的通信通道尚未建立；如果此时调用依赖平台通道的插件（如 Firebase Core 的初始化），就会抛出 Binding has not yet been initialized 错误。这行代码的作用是显式初始化绑定，确保平台通道可用。在纯 UI 应用中，runApp 会自动完成这一初始化，所以很多开发者从未手动调用过它；但一旦在 main 函数开头就使用 Firebase、SharedPreferences 等插件，就必须提前调用。这是移动端集成 Firebase 时最常见的启动错误之一。

上手门槛与扩展方向

整个项目的门槛并不高：需要Flutter基础、一个Google账号，以及对异步编程的基本理解。WidgetsFlutterBinding.ensureInitialized()这行代码容易遗漏，忘了它Firebase会在启动时抛错。

原作者建议了几个延伸练习：修改系统指令赋予机器人个性、添加清空对话按钮、将聊天记录持久化到本地。这些改动都能在现有代码基础上快速迭代。

从更广的视角看，这个项目展示了现代AI应用开发的一个趋势：基础设施的成熟让开发者能将精力集中在体验层面。密钥管理、API调用、流式传输这些曾经棘手的问题，已经被Firebase这类平台抽象成几行配置。200行代码背后，是整个生态在降低AI应用的门槛。