很多人打开 Google AI Studio 能点出界面，却在「Key 在哪、怎么发第一个请求、为什么报错」这三步上卡住；也有相反的情况，Key 拿到了却不知道该拿它干什么。这篇按顺序走一遍：先说清 AI Studio 是什么、适合谁，再给注册与建 Key 的步骤，最后落在一个最小可跑的请求上，并告诉你常见的几类失败分别先查什么。
很多人打开 Google AI Studio 能点出界面，却在「Key 在哪、怎么发第一个请求、为什么报错」这三步上卡住；也有相反的情况，Key 拿到了却不知道该拿它干什么。这篇按顺序走一遍：先说清 AI Studio 是什么、适合谁，再给注册与建 Key 的步骤，最后落在一个最小可跑的请求上，并告诉你常见的几类失败分别先查什么。
整个过程不需要你先把文档读完，边做边查更省时间。但有一条前提：你得知道自己要的是「快速验证一个想法」还是「接进生产系统」，这两条路入口不同，选错会在后面反复返工。
先分清：AI Studio 是什么，不是什么
- AI Studio 是网页端的模型试验台，功能偏「试提示词、调参数、看原始输出」，不是聊天产品的替代品
- 它和 Vertex 那类云平台是两条入口，前者上手快、额度与配额口径偏试用，后者走项目与结算体系
- 判断标准：只想快速验证一个想法、写几段提示词，就从 AI Studio 开始
- 要接进已有系统做对外服务，先读 Vertex 那页再决定，别拿试验台的额度去扛线上流量
这里最容易踩的坑是把「能试用」当成「能用」。试验台的定位就是把参数摊开给你看，所以它的限制通常比正式云平台更紧。如果你打算做的是一个要长期跑、要接结算的服务，早点看云平台那套口径，比在试验台里把代码写完再迁移更省事。什么情况下不适用？只是自己写点脚本、做几个原型页面的，留在试验台就够。
- 试验台
- 浏览器里直接调参、看输出，适合快速试想法
- 云平台入口
- 走项目和结算体系，适合对外服务与团队协作
- 怎么选
- 先看是试验还是生产，再决定从哪条入口开始
注册到拿到 Key：按顺序做这四步
- 先在界面里跑通一次对话用能正常登录的账号进 AI Studio，直接跟页面上的输入框聊一句，确认账号本身没被限制。这一步能过，后面的报错基本就跟账号无关了。
- 找到 API Key 入口并新建在左侧或设置区找到 API Key 的入口，新建一把。建完立刻复制到本地密码管理器，因为这个页面关掉之后通常就不再完整显示。
- 把 Key 放对位置别写进前端代码，也别提交到公开仓库。写进环境变量或本地配置文件，团队场景一 Key 一用途，别几个人共用一把，出了事没法定位是谁的调用。
- 确认这把 Key 的可用范围建完先确认它属于哪个入口、能用哪些模型，去站内模型库对照当时的可用清单，别照着旧教程里的写法直接填。
第一次调用：用最小请求验证链路
第一次请求的目标不是「做出一件事」，而是「确认链路通」。所以先把变量降到最少：纯文本、不传图、不传文件、不开流式。请求里只保留三个要素——调用的模型名、一条短提示词、输出长度上限。跑通之后再逐步加参数，每加一个就再跑一次，出问题立刻知道是谁引起的。
| 要记录的东西 | 为什么记 | 怎么用 |
|---|---|---|
| 请求耗时 | 判断是本地慢还是上游慢 | 跟后面测速页的基线对比 |
| 返回的用量字段 | 估算成本的基本单位 | 攒几天就能看出单次调用大概多少 |
| 返回的模型标识 | 确认实际命中的是哪个模型 | 名字写错时这一步能立刻发现 |
| 报错原文 | 区分认证、模型名、限流、网络四类 | 别只截图，把状态码和消息留下 |
拿到 200 就算链路通。没通就按「账号 → Key → 请求格式 → 网络出口 → 上游状态」这个顺序查，别乱改代码。很多人一出错就去翻参数文档，其实大部分失败压根不在参数上。想知道当时的上游状态和各家表现，到 站内排行榜（/rankings） 核对当时的记录，比自己反复重试更有参考价值。
最常卡住的四类问题与排查顺序
- 认证类报错：先确认 Key 有没有多余空格、有没有被吊销、请求头字段名对不对，复制粘贴带上的换行最容易漏
- 模型名报错：多半是名字写错或该入口没有这个模型，去站内模型库核对当时的写法，别照抄旧教程
- 限流与额度类报错：区分是短时并发撞上限，还是试用额度用完，前者等一等，后者只能换入口或加预算
- 网络与地区类失败：本地代理、出口 IP、证书都会影响，先用站内测速页量一次基线再判断是不是上游问题
这四类的排查顺序不要颠倒。认证没过就别去测网络，模型名没对就别去调参数。一个实用习惯是：每类问题只改一个变量再重试，改完记录结果。如果两三个变量一起动，最后你只会知道「好了」或者「还是不行」，学不到任何东西。团队里还可以把这几类的典型报错原文记在共享文档里，新人第一次遇到直接对号入座。
跑通之后立刻做的三件事
- 把成功请求固化成最小脚本把这次跑通的请求写成一段可复用的小脚本，保留最简参数。下次排错时它就是你唯一的对照物，能快速区分是环境变了还是代码改坏了。
- 建一个用量与花费的记录习惯字段别省，请求时间、模型、用量、用途都要有。否则后面想算成本只能靠猜。想看当时的各家价格口径，到 站内价格追踪（/price-watch） 核对当时的数字。
- 设定额度与预算提醒试用额度通常有隐性限制，别等到半夜发现被限流才反应过来。设一个提醒阈值，超过就暂停，比事后追查便宜得多。
如果你后面打算长期用，建议顺手把中转和官方两条线都了解一遍，判断标准在 站内中转站导航（/sites） 里有；要对比工具周边，可以看 工具目录（/tools）。这些不是入门必做，但能帮你在第一次被限流时知道还有别的路可走。
下一步跑通第一个请求后，别急着写业务代码，先把手上的 Key、模型可用范围和用量记录三件事对齐，再决定是留在试验台还是转云平台入口。对照当时的模型清单与价格口径，能少走不少回头路。→常见问题
没有海外网络环境，AI Studio 能用吗？
能不能用取决于你实际访问链路，这篇不给绝对结论。判断办法是先试网页端能否稳定打开，再试最小请求能否返回；如果只有网页能开而接口不通，多半是出口或代理配置问题，按“本地网络 → 代理 → 上游状态”的顺序查，别直接归咎于账号。
第一次调用应该用哪个模型？
建议先用该入口下最基础、最通用的那个文本模型，别一上来选旗舰或思考型。理由是第一次的目标是验证链路，不是拿结果；等你确认 Key、请求格式、返回结构都正常，再按任务换模型。当时的可用清单与型号写法到站内模型库核对。
免费额度够我玩多久？会不会突然不能用了？
免费额度一般按时间窗口和请求频率双重限制，具体数值随时间和地区变动，别按别人的截图规划。稳妥做法是第一天就记账，观察自己大概的用量曲线，同时设好提醒；具体口径去站内官方 API 页面与额度相关页面看当时的数字。
