企业官网建设流程全解析

1. 先把话说清楚：Gemini CLI 在 Windows 上到底能干什么

我打开终端，敲一行命令，就能让一个 AI 直接落在命令行里帮我干活。这不再是网页对话框里一问一答的小打小闹，Gemini CLI 是把 Gemini 的能力打包成了一个你可以在任何目录下直接执行的程序。简单说，它就住在你的终端里，你说“帮我看下这个日志为什么报错”，它会读日志、分析异常，再给你一段可以直接抄走的排查方案，而不是只回一句“这个错误通常是因为 XX”。

Windows 用户安装这个工具有点特殊。原因不复杂：Gemini CLI 本身的官方安装流程虽然标注了三个平台，但默认的文档逻辑基本是 macOS 和 Linux 的视角。到了 Windows 上，会冒出一堆平时没人提的岔路：PowerShell 的执行策略拦路、npm 全局目录权限不足、终端字体不支持彩色输出、环境变量的配置位置跟 Linux 完全不是一回事。这些东西单看都不是大问题，但堆在一起会让第一次装的人很烦躁。我见过不少人折腾半小时还在第一步打转。

这篇文章的目标就是让你照着走一遍，十分钟内把 Gemini CLI 跑起来。我会从环境准备开始，把三种安装方式全部过一遍，再讲认证配置、日常使用和 Windows 上的常见坑。不管你是第一次接触命令行的新手，还是已经装了但在排查问题，应该都能在这篇里找到对应的段落。

2. 安装前的三件套准备

2.1 先确认 Windows 系统和终端环境

Gemini CLI 对系统没有太离谱的要求，Windows 10 的 64 位版本和 Windows 11 都可以。不过有一点我得说在前面：请优先使用 Windows Terminal，而不是老式的 conhost 窗口。虽然命令行工具本身不挑宿主，但 Gemini CLI 在交互界面里用了不少 ANSI 彩色字符和表格渲染，旧的终端窗口对这部分支持很糟糕，字体会挤在一起，显示效果基本没法看。

Windows Terminal 不需要额外购买或破解，直接在微软商店里搜“Windows Terminal”就能装。装完之后建议把它固定到任务栏，后面所有命令都在这里面执行。顺手把默认终端改成 Windows Terminal：打开软件，按Ctrl + ,进入设置，在“启动”里把“默认终端应用程序”改成“Windows Terminal”。这个小动作后面会节省很多烦躁的时间。

另外要留个心：如果你用的是 Windows 11 的“终端预览”版本，界面会有些变化，但功能大差不差，不影响。

2.2 安装 Node.js：Gemini CLI 的运行底座

Gemini CLI 是用 Node.js 写成的工具，所以环境里必须有一个可用的 Node.js 运行时。版本方面，官方建议 Node.js 18 以上。我实际用下来，Node 18 和 20 都跑得很稳，但如果你机器上还是十几甚至更老的版本，建议先升级，因为新版 CLI 的依赖会明确要求更高的 Node 特性，版本太老会在运行时报一类特别难查的语法错误。

安装步骤其实没什么悬念：去 Node.js 官网下载页找 LTS 版本，Windows 安装包是.msi，双击一路下一步。关键点是安装到“选择安装功能”那一步时，确认勾选了“Add to PATH”。如果不勾，后面在执行node、npm命令时会直接提示“不是内部或外部命令”，虽然也能通过手动改环境变量补救，但没必要给自己挖这个坑。

装完以后把终端关掉重新打开，执行：

node -v npm -v

能正常打印出版本号，就说明这一步已经完成。这里有一个很常见但容易被忽略的细节：如果你在装 Node 之前就开着终端，装完后那个终端里的 PATH 没有刷新，直接执行上面两条命令照样会报错。解决办法就是彻底关闭终端窗口，重新开一个。

2.3 准备一个 Gemini API Key 或者备用登录账号

安装本身是不需要登录的，但真正启动 CLI 的时候，它需要知道你是谁。Gemini CLI 支持两种认证方式：一种是浏览器 OAuth 登录，打开授权页面后登录你的 Gemini 账号；另一种是用 API Key。

对于后一种方式，你需要到 Gemini 的 API 管理后台申请一个 Key。申请入口一般在你 Gemini 账号下的 API Keys 页面，点“Create API key”，会生成一串以AIza开头的内容。注意这个 Key 生成的时候就要复制保存好，因为页面不会二次展示完整 Key，丢了只能重新生成。

那两种方式怎么选？我个人的习惯是：如果只是自己电脑上玩玩，用浏览器 OAuth 最简单，扫码或者点一下鼠标就完事，不需要管理 Key；但如果你要在多台机器、或者 CI/CD 这类自动化环境里用，API Key 是必须的。而且后面我会讲，API Key 模式可以通过环境变量让 CLI 自动读取，运行起来更省事，不用每次手动输。

3. 三种安装方式逐个对比

Gemini CLI 的安装方式不止一种，每种适合的场景完全不同。我在这里把三种方式全部写清楚，你可以按自己的实际情况选，也可以把前两种当候补方案，哪个顺手用哪个。

3.1 全局安装 npm 包：最主流也最推荐的方式

最正统的安装命令是通过 npm 全局安装。很好理解，就是把 CLI 当成一个全局可用的程序装到系统里，之后你在任意目录下敲gemini都能调用它。

在已经准备好 Node.js 的终端里执行：

npm install -g @google/gemini-cli

这个命令会从 npm 仓库拉取包并安装到全局目录。这里解释一下包名开头的@google，这是 npm 的“作用域包”机制，等于把一个命名空间给了这个包，避免跟第三方的gemini命名冲突。所以如果你在网上看到有人写npm install -g gemini，那是另一个完全不同的工具，别装错了。

安装完成后，先检查版本确认装好了：

gemini --version

如果打印出了一个版本号，说明安装成功。如果提示gemini 不是内部或外部命令，基本都是 npm 全局目录没有进入 PATH 的问题，我后面专门有一节讲怎么修。

全局安装的优点是干净、直接，gemini命令随处可用，遇到问题也容易排查。缺点是全局目录里的包更新方式比较靠自觉，需要你偶尔主动执行npm update -g @google/gemini-cli来升级。对绝大多数 Windows 用户来说，这就是首选方案。

3.2 用 npx 临时运行：适合还没想好要不要长期用的人

如果你暂时不想往系统里装一个常驻的全局工具，只是想先体验一下 Gemini CLI 的效果，完全可以用 npx 直接启动。

npx @google/gemini-cli

npx 是 npm 自带的工具执行器，它的逻辑是：如果本地没装这个包，就临时下载到缓存里然后执行。这样你机器上不会残留一个全局的gemini命令，属于“用完即走”的模式。

但 npx 模式有两个明显的代价。第一，每次执行如果缓存被清掉，都会重新拉取一次完整的包，耗时比直接执行全局命令长不少。第二，包本身是缓存状态，没法像全局安装那样随手升级，版本控制会变得很被动。所以我的建议很明确：这个方式适合第一次体验，确定要继续用，就一定切到全局安装。

3.3 用 Bun 安装：速度党可以试一试

如果你已经在用 Bun 这个 JavaScript 运行时，会发现用它装全局包速度非常快。命令如下：

bun add -g @google/gemini-cli

Bun 的安装和启动速度都比 npm 快，文件系统 IO 也更利落。但这里我必须说一句实话：Bun 在 Windows 上属于“能用但不保证事事顺利”的阶段，如果你装了 Bun 之后其他项目都正常，那用它装 Gemini CLI 没问题；但如果你的 Bun 本身测试环境还不成熟，我不建议为了装这个 CLI 专门去折腾一个新运行时。工具的价值在于帮你干活，不要在装工具的路上消耗太多体力。

三种方式整理成一张表，方便你参考：

4. 首次运行与认证配置

4.1 第一次输入 gemini 后会发生什么

安装完成后，在终端里敲gemini回车。第一次运行它会进入一个交互模式，界面上会展示版本信息和欢迎提示。如果你的机器上没有配置过任何认证信息，CLI 会进入登录流程。

浏览器 OAuth 登录的体验比较顺滑：CLI 会显示一个网址，并询问你是否已经在浏览器里完成了授权。你需要在浏览器里打开那个网址，使用你的账号完成确认，然后把授权结果带回来。整个过程类似 GitHub CLI 或者很多云服务的 CLI 登录方式，本质上就是让令牌跟本机的 CLI 绑定。

如果你没有浏览器环境，或者干脆不想用个人账号做授权，那就按 API Key 的方式来。实际操作中，我一般直接选择 API Key 路线，因为在自动化脚本里它的行为更可预期，而且 API Key 可以随时创建、随时撤销，权限边界更清晰。

4.2 用 API Key 完成认证：两条路供你选

拿到 API Key 以后，有两条路可以把它交给 Gemini CLI。

第一种是设置系统环境变量。在 Windows 11 / Windows 10 上，右键“此电脑” → 属性 → 高级系统设置 → 环境变量。在“用户变量”区域点“新建”，变量名填GEMINI_API_KEY，变量值粘贴你的 Key，一路确定保存。之后把终端重启，Gemini CLI 启动时会自动读取这个环境变量。

第二种是针对只想在当前终端会话临时使用的情况。直接在 PowerShell 里执行：

$env:GEMINI_API_KEY = "你的 Key"

这种方式只在当前终端窗口有效，窗口一关就失效，适合临时换 Key 或测试多个 Key 的场景。如果你日常固定在某个项目里用，还是用第一种方式一劳永逸比较省心。

配置完成后，重新运行gemini，它会以你的 API Key 身份启动，对话过程中不再要求登录。

4.3 切换模型与确认运行状态

认证不是唯一的初始化事项。Gemini CLI 默认会使用某个模型来回答，但你可以通过环境变量GEMINI_MODEL指定其他模型。比如你想用某个擅长复杂推理的模型，可以在环境变量里设：

GEMINI_MODEL=gemini-2.5-pro

如果你只是想让每日的普通问答成本更低，可以设成：

GEMINI_MODEL=gemini-2.5-flash

这个变量的设置方法和GEMINI_API_KEY完全一样，就不重复了。

我第一次启动时踩过一次坑：设好了GEMINI_API_KEY却发现 CLI 还是在走浏览器登录，后来发现是因为设置完环境变量之后，终端没有重启，环境变量并没有被加载。这算是一个容易忽略但特别典型的 Windows 细节。所有环境变量的配置，都必须在设置完以后重启终端才能生效，这不是 Gemini CLI 的问题，是 Windows 环境变量机制本身的行为。

5. 日常使用的核心操作

5.1 在终端里把它当技术参谋用

装好 Gemini CLI 之后，最直接的用法就是把它当成一个随叫随到的参谋。任何疑问，直接以自然语言输入，它会基于上下文回答。

举个我自己的例子：某天我在配置一个构建脚本，终端报出一段很长的编译错误，以前我会打开搜索引擎，把错误信息复制进去，然后在几个看起来差不多的网页之间来回折腾。现在直接在gemini的对话框里把错误信息复制进去，然后补一句“帮我看这是什么原因”，它会解析错误结构，能拆出哪一行哪个库出了问题，并给出可行的修复方案。这段效率上的提升非常明显，因为问题上下文就在终端里，不用来回切窗口。

其他常见用法还包括解释一个冷门命令的参数、对比两个工具的思路、帮你回忆一段你写过但忘了放在哪的代码逻辑。它可以做的不是“背书式”解答，而是在当前目录的上下文里理解你的问题。

5.2 让它直面文件：读写本地项目

Gemini CLI 和普通网页聊天的最大区别是，它默认能感知你运行时的当前目录，可以读取目录里的文件、分析项目结构、甚至可以按你的指示写文件。

比如我在某个项目目录下，直接告诉它“看一下这个模块的代码结构，帮我找出三个潜在的边界条件问题”，它会先定位文件、读取内容、再给出分析。这跟把代码复制粘贴到网页上完全不是一个体感，尤其当项目文件很多、跨模块调用复杂的时候，让 CLI 直接操作文件系统会大幅减少你手工整理上下文的工作量。

不过这里有一个使用技巧上的提醒：它确实能听懂“帮我修改某文件”，但修改文件前通常最好让它先说清楚改了哪几行、改动原因是什么，确认后再动手。命令行环境里没有网页端的“应用变更”按钮，一切以它的输出为准，所以你保留一层人工确认会更稳。

5.3 和 VS Code 里 AI 插件的互补

有人问我：IDE 里已经有各种 AI 插件了，为什么还要装 Gemini CLI？答案很简单，因为终端的场景在 IDE 之外。你在本地仓库里跑测试、查日志、操作 Git 时，那些时刻几乎都在终端里，而 IDE 插件更多是围绕编辑器的提示和生成。如果有一个工具能直接在终端里理解你正在敲的东西，你就不需要把命令输出复制回编辑器去问另一个 AI。

我日常的习惯是给 Windows Terminal 设一个快捷键，一键打开一个新标签页并自动运行gemini。配置方法不复杂：在 Windows Terminal 的设置里，新建一个配置文件，命令行参数填cmd.exe /k gemini，再把启动参数关联到这个配置文件。这样我任何时候想开一个 AI 对话窗口，只要按一下快捷键，终端就直接落在 Gemini CLI 的交互界面里。如果不配置快捷键，一个标签页敲gemini也不会慢到哪去，顺势为之就好。

既然谈到了环境，建议统一配置一个干净的提示符：把gemini作为 Windows Terminal 独立标签页的默认启动命令，后续切换上下文会比较自然。

5.4 知道几个内置命令，少走弯路

进入 Gemini CLI 的交互界面后，输入/help可以列出所有内置命令。有几个值得记一下：

• /quit：退出当前会话。
• /clear：清空当前对话上下文，重新开始。
• /model：查看或者切换当前使用的模型。
• /status：查看当前会话的认证状态和上下文信息。

当你连续对话一段时间后，上下文会变得很长，回答质量和响应速度都会略有下降。这时候执行/clear清空上下文，通常能让会话恢复到良好的状态。这和网页版聊天到一定程度主动开新会话是一个道理。

6. Windows 上高频踩坑实录

6.1 首次运行时报“禁止运行脚本”

Windows 默认的 PowerShell 执行策略非常保守，很多脚本和命令第一次运行就会提示“在此系统上禁止运行脚本”。这不是 Gemini CLI 特有的问题，但第一次安装的人特别容易在这里蒙圈。

解决办法是放宽当前用户的执行策略：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

这条命令的意思是允许本机脚本和已签名远程脚本运行，但不需要管理员权限，影响范围只限于当前用户。执行后如果系统询问是否要更改执行策略，输入Y回车。设置完以后，重新跑gemini通常就能正常启动。不用把策略改成Unrestricted，RemoteSigned 对日常使用已经完全够用。

6.2 npm 全局安装时提示权限不足

Windows 上执行npm install -g偶尔会报EPERM或者EACCES之类的权限错误。很多人第一反应是用管理员身份运行终端再来一次，但我劝你尽量别这么干。以管理员身份运行会改变很多默认路径，后面反而容易出现文件归属混乱的问题。

更好的做法是把 npm 的全局目录指向当前用户目录下的一个文件夹：

npm config set prefix "$env:APPDATA\npm"

再重新安装一次，就不会再碰到必须提权的问题。这个配置改完以后，记得检查一下%APPDATA%\npm是否已经加入了 PATH，如果没加，手工加上即可。

6.3 输出乱码和中文字体显示错位

Gemini CLI 的回显里会用到一部分特殊字符和彩色字体。Windows 默认终端字体在渲染某些 Unicode 字符时会出现方块或者错位，尤其在表格类输出时最明显。

我的建议是给 Windows Terminal 换一个等宽字体，比如Cascadia Mono或者常见的Sarasa Mono。在 Windows Terminal 设置的“配置文件” → “外观” → “字体”里改。中文场景下，某些字体需要额外指定 fallback，如果字体不支持中文，回显里的中文部分可能仍然显示成小方块。选了合适的字体后，整体输出观感会完全不一样。

顺带一提，如果你在旧版控制台窗口里用，chcp 65001这个命令可以把代码页切到 UTF-8，缓解一部分乱码。但在 Windows Terminal 里一般不需要每次都做。

6.4 网络波动导致的连接失败

命令行工具没界面，稍等一会儿提示碰不到服务是经常会遇到的事。这里先说清楚：报错大多是网络层面的临时状况，不代表安装坏了。遇到连接失败，第一步可以先重新执行一次问句，很多时候只是超时节奏的问题。

如果反复失败，建议做两个检查：一是确认本机网络能正常访问外部站点，排除断网；二是看看是不是安全软件或者系统防火墙拦了终端进程的网络请求，尤其是企业办公电脑上这类情况很常见。Windows Defender 本身一般不会拦，但三方安全软件确实会。

实在不行，可以在 CLI 之外先确认一下网络直连状况，再用/clear重新开始对话连接。这类问题没有太多黑魔法，耐心重试十有八九能恢复。

6.5 高频问题速查表

7. 最后分享一点我自己的使用心得

我在 Windows 上装 Gemini CLI 的时间不算短，中间反复换过机器、重装过环境，踩过的坑基本都写在前面了。如果只记住一句话，那就是：先确认 Node.js 环境和终端是否正常，再想什么花活。这和很多命令行工具的道理是一样的，环境是根。

日常使用中，我实际上用得最频繁的场景不是让它写一整套新功能，而是让它“看一眼项目里正在出问题的那部分”。解释报错、分析日志、补一个正则、解释一个生僻的编译参数——这些散落在终端里的小事，聚合起来节省的时间非常可观。你不需要把它当成一个程序员替身，把它当成一个比你稍快的“检索器 + 概括器”会更顺手。它更擅长在你们俩共同的上下文里输出准确的东西，上下文越充分，答案越接近你的真实意图。

装好之后，建议你从自己手头真实存在的问题开始试，而不是用那种“你是谁”的开场白测试。直接丢一段你没处理的报错过去，你会马上感受到这个东西顺手不顺手。

Windows 上的命令行生态这几年的进步其实很明显，以前总感觉这类 CLI 工具在 Windows 上是二等公民，但实际用下来，只要环境和字体打理好，体验跟其他平台没什么差距。剩下来要做的就是多问几个问题，让这个终端里的新伙伴多帮你干点活。