在 Gemini 免费层上构建开发者工具——实际能实现什么

Source: Dev.to

Overview

HiyokoLogcat 完全基于 Gemini 的免费层构建，旨在让用户自行提供免费 API 密钥。本文概述了免费层的可用性、限制以及如何围绕这些限制进行设计。

Gemini 2.5 Flash Preview Limits

• 每分钟 15 次请求 (RPM)
• 每天 1,000,000 个 token
• 每天 250 次请求

对于间歇使用的开发者工具（例如，点击 → 诊断 → 阅读 → 修复），这些限制相当宽松。一次典型的诊断会消耗 3,000–6,000 个 token，这意味着需要进行 166+ 次诊断 才会触及每日 token 上限。

Design Guidelines

Keep Requests Small

• 只发送日志中必要的部分（例如，发送 100 行而不是 500 行）。
• 每节省一个 token 都能为后续请求提供余量。

Avoid Auto‑Triggering

• 切勿自动向 API 发送数据。
• 仅在用户明确操作时才发起请求。若在每次错误时自动触发，RPM 限制会瞬间耗尽。

Cache Results

• 若用户关闭后重新打开诊断弹窗，直接返回缓存结果，而不是再次调用 API。

Limit Bulk Operations

• 免费层无法在不产生显著延迟的情况下处理大批量作业（例如一次性分析 100 条错误日志）。
• 在 UI 设计上应避免大量 AI 使用。

Real‑Time Analysis

• 不要把每一行日志都实时流式发送到 API；15 RPM 的限制会在几秒钟内被耗尽。

Scalability

• 当大量用户同时使用工具时，每位用户的独立 API 密钥提供了各自的配额，因此高并发的生产使用仍然可行。

Cache Implementation (Rust)

use std::collections::HashMap;

pub struct DiagnosisCache {
    cache: HashMap, // log hash → diagnosis
}

impl DiagnosisCache {
    pub fn get(&self, log_hash: &str) -> Option {
        self.cache.get(log_hash)
    }

    pub fn insert(&mut self, log_hash: String, diagnosis: String) {
        // Keep cache bounded
        if self.cache.len() > 50 {
            self.cache.clear();
        }
        self.cache.insert(log_hash, diagnosis);
    }
}

• 50 条缓存：当缓存达到上限时会清除旧条目。简单且高效。

User Experience Benefits

• 所有权：让用户自行获取免费 API 密钥，使其产生“我自己配置了 Gemini 密钥”的所有感，而不是把 AI 当作隐藏功能。
• 对限制的认知：自行配置密钥的用户会了解速率限制，对偶尔的慢速更能宽容。
• 摩擦即过滤：约 2 分钟的设置过程（从 Google AI Studio 获取密钥）会过滤掉并非真正感兴趣的用户。

Conclusion

对于间歇使用 AI 的开发者工具，Gemini 的免费层完全足够。从第一天起就面向免费层构建，既能让你的成本保持为零，也能让用户的成本为零，并迫使你设计高效的 AI 交互，而不是对 API 进行刷请求。

Resources

• HiyokoLogcat – 免费且开源:
• Author: @hiyoyok