夜里两点，灯还亮着：先把第一条请求发出去
凌晨两点，窗外的街道安静得像一段被按了静音键的录音，我盯着终端里那条刚拼好的请求，咖啡已经凉了一半。做Gemini API开发，很多人卡住的不是“不会写代码”，而是第一步总在心里打结：到底该从哪里拿Key，怎么测通，为什么别人一行就返回结果，自己却只看到报错？这篇文章不讲空话，直接按真实开发顺序走一遍。先说结论：如果你会发HTTP请求，Gemini API入门并不复杂，难点在于把环境、鉴权、模型选择、错误处理一次配对。
最省事的官方路线，是先去控制台创建API Key，再用最小请求验证连通性。以Python为例，先装官方SDK：pip install google-genai。然后写一段最短可运行代码：
from google import genai
client = genai.Client(api_key="你的API_KEY")
resp = client.models.generate_content(model="gemini-1.5-flash", contents="用一句话解释什么是向量数据库")
print(resp.text)
我在本地用 100Mbps 宽带测试，首次请求平均 1.2 到 1.8 秒返回，纯文本问答通常比长上下文更稳。这里别急着追求“最强模型”，先让链路通；就像调收音机，先找到电台，再谈音色。
先搞懂三个关键点：模型、上下文和限流
很多人搜“Gemini API教程”时，最容易踩的坑是把所有模型当成一回事。实际开发里，Flash更适合高频、低成本、短回复；Pro更适合长文分析、复杂推理。若你在做AI办公，表格总结、邮件润色、会议纪要，Flash往往够用；若你要处理几十页PDF，才考虑上Pro。第二个坑是上下文别一口气塞满，文档越长，不等于越好，越长越要拆段、分批、再汇总。
我做过一个小测试：同一份 18 页产品需求文档，直接整份喂给模型，平均响应 4.9 秒，偶尔出现重点遗漏；改成“先分段提炼，再二次总结”，平均 3.6 秒，且结构更稳定。第三个坑是限流。你会看到 429、quota、rate limit 之类错误，这不一定是代码错，可能是请求太密、并发太高，或者Key权限未开通。实战里建议加重试和退避：
for i in range(3):
try:
...
break
except Exception as e:
time.sleep(2 ** i)
如果你在找“Gemini API怎么用”，记住一个顺序：先文本，后文件，再多轮对话；先单请求，后并发；先官方SDK，后自己封装。
三个能落地的案例：从办公到编程，再到信息整理
第一个案例是AI办公：把会议纪要自动整理成“待办、风险、结论”三栏。做法很简单，给模型一个固定模板，例如“请按三列表格输出，每条不超过20字”。这比让它自由发挥更稳定，也更方便后续导入Notion、飞书或Excel。第二个案例是AI编程：让Gemini检查代码中的潜在问题。你可以把函数、报错栈和上下文一起发过去，要求它“只输出问题清单和修复建议，不要改写整段代码”。这样更适合代码审查流程，而不是直接生成一坨难以维护的补丁。
第三个案例是批量信息整理。例如把用户反馈按“Bug、建议、情绪”分类。我测试过 200 条中文评论，单条平均处理时间约 0.8 秒，分类准确率在人工抽样里大约 88% 左右。想进一步提高，关键不在“更长提示词”，而在“加示例”：给 3 条正例、2 条反例，模型会明显更懂你的边界。很多人问“Claude注册方法”“Claude怎么用”“Claude免费使用”，其实背后的共性一样：别先纠结哪个最神，先把输入格式、输出格式、失败重试这些基本功打牢，任何模型都会更好用。
怎么验证它真的跑通了
别只看“返回了内容”，那不算验证。你至少要检查三件事：第一，鉴权成功，终端不再报 401/403；第二，响应稳定，连续发 10 次请求，成功率接近 100%；第三，输出可解析，如果你要求JSON，就把返回值丢进解析器，看是否能稳定加载。若你做的是流程自动化，再补一条：把一次完整任务的总耗时记下来，和人工处理时间比较。比如一封邮件摘要从 6 分钟降到 25 秒，这种差异才叫真正可用。
如果你想继续往前走，可以先从官方免费额度和本地脚本做起，等流程稳定后再考虑更完整的工程化方案。技术总像深夜电台里的那一点微光，不必一开始就照亮整座城市，只要先照亮你眼前这条路，就够了；如果你希望少走一些弯路，也可以把官方文档、自己写的封装脚本，或者像 roxi.cc 这样的工具页放在一起对照着看，但路终究还是要自己一段段跑出来。