firebase-ai-logic

Firebase AI Logic

适用场景

• 直接在 Firebase 应用中添加由 Gemini 驱动的功能。
• 构建应用内文本、聊天、多模态、结构化输出或流式传输体验。
• 判断请求应保留在客户端／应用层，还是转移到后端工作流。
• 添加Firebase 专属生产控制措施，例如围绕 AI 功能集成 App Check、配额管理和 Firebase 服务。
• 处理适用于 Web、移动端、Flutter、Unity 或其他 Firebase 支持的客户端界面的应用端 AI。

不适用场景

• 用户需要由服务端负责的流程、工具调用、RAG、评估器、跟踪记录、提示词文件或可复用的后端编排 → 使用 genkit。
• 用户需要Firebase 项目设置、模拟器、托管／函数部署或 CLI 操作 → 使用 firebase-cli。
• 用户尚未确定使用 Firebase，主要需要比较通用的服务提供商 SDK → 改用特定服务提供商或框架选择技能。

运作模式

将 firebase-ai-logic 视为三条路径中的客户端／应用集成锚点：

1. 应用／客户端功能集成 → firebase-ai-logic
2. 后端工作流编排 → genkit
3. Firebase 平台／运维任务 → firebase-cli

不要混淆这些职责。如果请求涉及多个职责，请拆分任务，并明确分配每个部分。

说明

步骤 1：先对请求分类，再提供实现建议

先选择一种模式。

模式 A — 直接适用于功能

用户想添加应用内 AI 功能时使用，例如：

• 聊天或助手界面
• 在应用中进行摘要或改写
• 根据用户内容生成多模态提示词
• 为应用工作流生成结构化输出
• 将模型的流式响应传入 UI

提供：

• Firebase AI Logic 是否适合此场景
• 哪些内容应属于应用层，哪些内容应移出应用层
• 涉及的最低限度 Firebase 依赖项／服务

模式 B — 应用接线与 UX 集成

用户已选择 Firebase AI Logic，需要帮助将其接入应用时使用。

重点关注：

• 模型调用在应用架构中的位置
• UI 状态中的请求／响应生命周期
• 加载／错误／重试／回退 UX
• 应用中的提示词／模板归属
• 应用必须提供的内容审核／安全界面

模式 C — 生产环境加固

功能已存在或即将发布时使用。

重点关注：

• App Check／滥用防护
• 配额、成本和速率限制的影响
• 监控和故障可见性
• 远程发布／功能标记策略（如适用）
• 用户输入和生成输出的隐私边界

模式 D — 升级边界

用户最初提出客户端请求，但当前方案已涉及后端编排时使用。

如果遇到以下情况，请升级到 genkit：

• 工具调用或 Agent 循环
• 检索／RAG／基于数据库的生成
• 跨平台共享的可复用流程
• 评估工具链、跟踪记录或系统化可观测性
• 不应放在客户端的机密信息或特权 API

步骤 2：规范化请求内容

回答前，先将请求改写为以下简述：

## Firebase AI Logic packet
- App surface: web | iOS | Android | Flutter | Unity | mixed
- User-facing feature: chat | summary | generation | multimodal | structured output | streaming
- Data involved: user text | images | docs | app state | Firebase data
- Safety/privacy concern: none | moderate | high
- Production stage: prototype | internal beta | launch prep | live issue
- Boundary check: stays in app | split with backend | move to `genkit`

如果简述中写明 split with backend 或 move to genkit，请立即说明，而不要假装一个技能能负责整个解决方案。

步骤 3：提供应用层指导，而非大段代码

对于 Firebase AI Logic 请求，按以下顺序组织回答：

1. 为什么应保留在应用层
2. 客户端 UI／运行时中需要接入什么
3. 哪些 Firebase 专属控制措施很重要
4. 哪些内容不应放在客户端
5. 何时升级到 genkit 或 firebase-cli

仅在有助于说明集成时，使用简短代码或伪代码结构。优先说明架构和边界，而非提供冗长的 SDK 代码片段。

第 4 步：涵盖 Firebase 特有的注意事项

始终关注让此路径区别于直接使用提供商 SDK 的事项：

• 适用时考虑 App Check / 滥用防护
• 关注配额 / 成本 / 速率
• 考虑 Firebase 服务之间的协作（Auth、Remote Config、分析/监控、存储，以及必要时交接给 Functions）
• 考虑目标应用界面所涉及的平台支持
• 如果请求面向生产环境，制定模型变更或功能开放的发布策略

第 5 步：明确指引到其他路径

明确使用以下指引。

如果用户需要……	指引至……
由服务器负责的流程或工具调用	genkit
检索 / RAG / 评估 / 跟踪	genkit
部署、模拟器、托管或 Functions 运维	firebase-cli
非 Firebase 提供商的选择	提供商/框架技能

第 6 步：输出格式

以类似这样的精简方案回复：

## Recommendation
- Lane: Firebase AI Logic | Split with Genkit | Not a Firebase AI Logic fit
- Why: ...

## App-layer plan
1. ...
2. ...
3. ...

## Firebase-specific controls
- App Check / abuse:
- Quota / cost:
- Monitoring / rollout:

## Route-outs
- `genkit`: ...
- `firebase-cli`: ...

最佳实践

1. 只有在权限较低且编排简单时，才将面向用户的简单 AI 功能保留在应用层。
2. 尽早将适合后端处理的行为移出；不要在仅限客户端的设计上追加工具/RAG/评估。
3. 将 App Check、配额和发布准备视为首要事项，而非事后补充。
4. 每次回复优先提供一个清晰的功能方案，而不是将应用 UX、后端编排和 Firebase 运维混为一谈。
5. 如有疑问，在提出实施步骤前，先说明应用侧 Firebase AI Logic 与后端侧 genkit 的职责划分。

示例

示例 1：应使用 Firebase AI Logic

输入：“在我们的 Firebase 网页应用中，为文章预览添加 Gemini 流式摘要。”

输出形式：

• 路径 = Firebase AI Logic
• 方案侧重应用 UI 状态、流式渲染、提示词归属、故障状态，以及 App Check/配额防护措施
• 指引说明：可复用的摘要流水线或评估框架应使用 genkit

示例 2：应与 Genkit 拆分

输入：“我们的移动应用需要聊天、工具调用，以及对 Firebase 数据的检索，并支持服务器端可观测性。”

输出形式：

• 路径 = 与 Genkit 拆分
• 只有在需要时，Firebase AI Logic 才保留在应用交互边界
• 后端工作流、检索、工具和可观测性移至 genkit

参考资料

• Firebase AI Logic 概览
• Firebase AI Logic 入门
• Firebase AI Logic 生产环境检查清单
• Genkit 文档