---
title: "Cloud Shell 入口"
description: "Gemini CLI 在 Google Cloud Shell 和 Cloud Workstations 中的使用边界，以及什么时候优先用 Cloud Shell。"
verifiedAt: "2026-05-09"
---

Cloud Shell 是 Gemini CLI 的低摩擦入口：你不用先修本机 Node、npm、PATH 和 shell 环境，就能在 Google Cloud 环境里启动 Gemini CLI。但它不是你的本机开发机，尤其不能忽略 project、IAM、账单和代码所在位置。

> [!NOTE]
> **适合谁**：第一次验证 Gemini CLI、学习 Google Cloud 文档、排除本机安装变量、处理轻量 Cloud 项目任务时，可以优先用 Cloud Shell。真实本机项目长期开发，仍要回到项目所在环境。

## 1. Cloud Shell 解决什么问题

- **Cloud Shell 已预装 Gemini CLI**，启动就能用，不需要 `npm install`。
- 不需要本机安装 Node.js。
- 不需要处理本机 PATH、npm 全局目录、shell 兼容问题。
- 天然靠近 Google Cloud 项目。
- 适合临时验证命令、Cloud 文档学习和轻量任务。

> [!NOTE]
> [Cloud Workstations](https://cloud.google.com/workstations) 也预装 Gemini CLI。如果团队已经在 Cloud Workstations 上做受控开发，不需要再单独装 CLI。

Google Developers 当前页面说明，Gemini CLI 可以在 Cloud Shell 中使用，无需额外设置；认证页也说明，运行在 Cloud Shell 环境里时通常会使用 Cloud Shell 凭据。Compute Engine 环境下，Gemini CLI 也会自动用 metadata server 上的 Application Default Credentials（ADC），同样不需要再走交互式登录。

## 2. 先确认当前 project

Cloud Shell 最大的风险不是“能不能启动”，而是“它现在属于哪个 Google Cloud project”。开始前先确认：

```bash
gcloud config get-value project
gcloud auth list
```

如果 project 不对，先切换 project，再启动 Gemini CLI。不要让 CLI 在错误 project 下读资源、查日志或产生用量。

```bash
gcloud config set project YOUR_PROJECT_ID
```

## 3. Cloud Shell 的边界

- 它不是你的本机项目环境。
- 本机代码、私有依赖、SSH key、IDE 工作流不一定在里面。
- 长期项目开发仍要考虑本机、远程开发机或 Cloud Workstations。
- 涉及生产项目时仍要遵守 IAM、凭据、账单和权限边界。

```mermaid
flowchart LR
    Local["本机项目"] -->|真实开发| LocalCLI["本机 Gemini CLI"]
    Cloud["Google Cloud 项目"] -->|快速验证| Shell["Cloud Shell"]
    Shell --> Project["当前 Cloud Project"]
    Project --> IAM["IAM / API / Billing"]
    Shell --> Temp["临时文件和轻量任务"]

    style Shell fill:#dbeafe,stroke:#3b82f6,stroke-width:2px
    style IAM fill:#fef3c7,stroke:#f59e0b
```

## 4. 什么时候用 Cloud Shell

| 场景 | 建议 |
| --- | --- |
| 第一次体验 Gemini CLI | 可以先用 Cloud Shell |
| Google Cloud 文档学习 | Cloud Shell 很合适 |
| 本机 Node 环境混乱 | 先用 Cloud Shell 排除安装变量 |
| 真实本机项目开发 | 本机或远程开发机更合适 |
| 企业项目 | 先确认组织策略、IAM 和审计要求 |

## 5. 和本机安装的关系

Cloud Shell 适合降低上手门槛，但它不能替代所有开发环境。Gemini CLI 的核心价值是“带着项目上下文执行任务”。如果你的项目在本机或团队开发机上，最终仍应在真实项目环境里测试。

本机安装和 Cloud Shell 的分工可以这样定：

- Cloud Shell：学习 Google Cloud 文档、验证 CLI、查 Cloud 资源、做轻量脚本。
- 本机/远程开发机：读真实仓库、跑项目测试、接本地工具链、处理 IDE 和 Git 工作流。
- Cloud Workstations：团队受控开发环境，适合需要统一镜像、权限和审计的组织。

> [!WARNING]
> **不要把 Cloud Shell 当生产运维捷径**：它靠近 Cloud 资源，也意味着误命令可能更接近生产环境。涉及删除、发布、权限变更、账单和数据导出时，仍然要走变更流程。

## 6. 接下来去哪

<Cards>
  <Card title="发布通道" description="继续判断 stable、preview、nightly 该怎么选，避免把 nightly 当团队默认。" href="/docs/gemini-cli/official/00-getting-started/05-release-channels" />
  <Card title="认证方式" description="如果 Cloud Shell 外还要跑本机、CI 或 Vertex AI，回到认证边界。" href="/docs/gemini-cli/official/00-getting-started/02-authentication" />
  <Card title="企业配置" description="团队统一开发环境时，继续看企业配置、policy、sandbox 和 telemetry。" href="/docs/gemini-cli/official/06-security-enterprise/62-enterprise-config" />
</Cards>

## 官方来源

- [Google Developers Gemini CLI](https://developers.google.com/gemini-code-assist/docs/gemini-cli?hl=zh-cn)
- [Gemini CLI Authentication Setup](https://google-gemini.github.io/gemini-cli/docs/get-started/authentication.html)
- [Google Cloud Shell](https://cloud.google.com/shell)
