---
title: "Gemini CLI 是什麼"
description: "從定位理解 Gemini CLI：它是終端裡的 Google 系 AI coding agent，不是普通聊天框，也不只是 Gemini Code Assist 的命令列殼。"
verifiedAt: "2026-05-09"
---

Gemini CLI 可以先理解成一句話：**執行在終端裡的 Google 系 AI coding agent（AI 程式設計代理）**。它能讀專案、呼叫工具、執行命令、修改檔案、接 MCP（Model Context Protocol，模型上下文協議）、進入 CI，也能和 Gemini Code Assist、Google Cloud、GitHub Action 這些入口連起來。

它不是普通聊天框。普通聊天框主要靠你複製貼上上下文；Gemini CLI 直接站在專案目錄裡，能透過工具讀檔案、查上下文、執行命令，並根據結果繼續下一步。

> [!NOTE]
> 這一篇先解決定位：Gemini CLI 的核心不是"又一個 Gemini 聊天入口"，而是一個能站在專案目錄裡工作的終端 agent。

> [!TIP]
> **它的執行環境是 Node.js**（≥ 20）。如果你本機連 Node 都還沒裝，第一步先裝 Node 而不是裝 Gemini CLI；或者用瀏覽器進 [Google Cloud Shell](https://cloud.google.com/shell)（已預裝 Gemini CLI）跳過本機環境問題。詳見 [安裝篇](/zh-Hant/docs/gemini-cli/official/00-getting-started/01-installation)。

## 它解決什麼問題

Gemini CLI 最適合解決三類問題：

- 在本地專案裡理解程式碼、解釋結構、定位錯誤。
- 在終端裡執行可驗證的開發任務，比如改文件、生成測試、跑檢查。
- 把 AI coding agent 接進自動化流程，比如 headless script、GitHub Action、issue triage。

如果任務需要大量 Google 生態能力，例如 Gemini 模型、Gemini Code Assist、Vertex AI、Google Cloud 專案、GitHub 自動化，Gemini CLI 的位置會更自然。

## 它不解決什麼問題

| 誤解 | 更準確的理解 |
| --- | --- |
| Gemini CLI 會自動接管專案 | 它需要上下文、許可權、工具確認和驗證邊界 |
| Gemini CLI 只是 Gemini Code Assist 的命令列殼 | 它有獨立的終端、工具、MCP、headless 和 GitHub Action 使用面 |
| 裝上以後就能進 CI | CI 還要處理認證、非互動輸入、許可權、退出碼和配額 |
| 模型強就能少寫規則 | 專案規則、`GEMINI.md`、ignore、sandbox 仍然決定可控性 |

## 和 Gemini Code Assist 的關係

Gemini Code Assist 是更大的產品體系，覆蓋 IDE extension、agent mode、Cloud Shell、企業控制台、配額和隱私策略。Gemini CLI 是其中面向終端和自動化的一條入口。

可以這樣分：

```text
Gemini Code Assist    产品和账号体系
Gemini CLI            终端 agent 和自动化入口
Gemini API Key        API 认证入口
Vertex AI             企业和云项目入口
```

## 它怎麼工作

大多數任務可以看成一個迴圈：

```text
读上下文 -> 形成计划 -> 调用工具 -> 观察结果 -> 调整下一步 -> 输出或继续执行
```

這個迴圈的質量取決於三件事：

- 你給的任務邊界是否清楚。
- 專案裡的 `GEMINI.md`、配置和忽略規則是否可靠。
- 工具許可權、sandbox、checkpoint、人工確認是否設定正確。

## 什麼時候優先選 Gemini CLI

優先選 Gemini CLI 的場景：

- 任務天然發生在終端，比如讀日誌、跑測試、改文件、檢查儲存庫狀態。
- 你希望把同一套能力放進本地、遠端伺服器、Cloud Shell 或 GitHub Action。
- 團隊已經在 Google Cloud、Vertex AI 或 Gemini Code Assist 體系裡。
- 你需要把 Web、Shell、MCP、檔案系統和 CI 串成一個可複查流程。

不優先選的場景：

- 主要需求是 IDE 補全和滑鼠式區域性編輯。
- 團隊完全不想接 Google 賬號、API key 或 Cloud 專案。
- 任務沒有可驗證輸出，只是泛泛聊天或頭腦風暴。

## 不要怎麼用

不要把 Gemini CLI 當成“自動接管專案”的按鈕。它能執行命令，也就能造成副作用。第一次進入陌生專案時，應該先讓它只讀解釋結構，再讓它提出計劃，最後才給寫許可權或執行命令。

## 讀完要能做什麼

讀完這一篇，你應該能判斷一個任務是否適合 Gemini CLI：它是否發生在專案目錄裡，是否需要讀檔案或跑命令，是否能驗證結果，是否需要 Google 生態入口。如果答案都是否，普通聊天或 IDE 工具可能更合適。

把定位想清楚，後面安裝、認證、工具許可權和自動化才不會混亂。

## 官方資料

官方資料把 Gemini CLI 描述為 open-source AI agent，並強調它在終端中透過內建工具和 MCP 完成任務。這個定位決定了教程不能只寫"怎麼問 Gemini"，而要寫"怎麼給它安全地讀、寫、查、跑和驗證"。

- 官方儲存庫：[github.com/google-gemini/gemini-cli](https://github.com/google-gemini/gemini-cli)
- 官方 docs：[docs/index.md](https://github.com/google-gemini/gemini-cli/blob/main/docs/index.md)
- Google Developers 中文：[gemini-code-assist/docs/gemini-cli](https://developers.google.com/gemini-code-assist/docs/gemini-cli?hl=zh-cn)

## 最小心智模型

```text
Gemini CLI = 模型 + 项目上下文 + 工具系统 + 权限治理 + 自动化入口
```

這比“一個更會寫程式碼的聊天機器人”準確得多。

## 下一篇

<Cards>
  <Card title="安裝、認證和第一次啟動" description="先跑通低風險只讀任務，再進入真實專案。" href="/zh-Hant/docs/gemini-cli/understanding/02-install-auth-first-run" />
  <Card title="官方教程中文版" description="需要查安裝、認證、CLI、工具和配置引數時，回到官方查詢手冊。" href="/zh-Hant/docs/gemini-cli/official" />
  <Card title="工具對比" description="已經在比較 Codex、Claude Code、OpenCode 時，跳到橫向選型頁。" href="/zh-Hant/docs/gemini-cli/understanding/11-gemini-cli-vs-codex-claude-opencode" />
</Cards>
