1. 项目概述这不是装两个命令行工具而是重建本地AI工作流的起点“小白如何安装和使用Codex CLI和Gemini CLI完整指南”——这个标题乍看是教人敲几行命令但实际踩中了当前开发者、技术写作者、甚至产品原型设计者最真实的痛点想用大模型能力又不想被网页界面绑架更不愿在浏览器里反复复制粘贴、手动整理输出。Codex CLI 和 Gemini CLI 并非官方出品的“正统”工具OpenAI 官方从未发布过名为 codex-cli 的 CLIGoogle 也未推出 gemini-cli它们是社区驱动的、面向开发者工作流的协议桥接器——核心价值在于把 OpenAI 兼容接口如 Ollama、LiteLLM、AnythingLLM 自建服务或 Gemini 兼容接口如 Google AI Studio 的 API、或经适配的开源代理服务“翻译”成终端里一句就能跑的命令。你输入codex 帮我写一个Python函数计算斐波那契数列前20项它背后自动构造标准 OpenAI Chat Completion 请求体发给你的本地 Ollama 服务你执行gemini 用表格对比React和Vue的响应式原理差异它则按 Gemini 的 message 格式封装走 Google AI SDK 或兼容网关。这中间省掉的不是安装步骤而是每次调用都要手写 curl、处理 JSON、解析 response.choices[0].message.content 的重复劳动。关键词里高频出现的 “openai api key 获取方法”“ubuntu20.04上安装”“windows安装”“离线安装”“配置deepseek”“路由服务才能正常使用”恰恰说明用户真正卡住的地方从来不是模型本身而是身份认证链路、网络协议适配、本地环境隔离、以及服务端点与客户端格式的精确对齐。我过去三年帮二十多个团队搭建内部 AI 工具链发现90%的失败案例都栽在“以为填对 API Key 就能用”这一步——其实 Key 只是门票真正的入场券是你用的 CLI 是否理解你后端服务返回的 JSON 结构是否支持 streaming 响应的逐字打印是否能把--model gemini-1.5-pro这种参数准确映射到 Google AI Studio 的models/gemini-1.5-pro-latest路径这篇指南不讲“什么是大模型”只聚焦一件事让你在自己的终端里像调用 ls 或 git 那样自然地调用 AI且每一步错误都能快速定位到是 Key 问题、网络问题、格式问题还是 CLI 版本与服务端协议的错配问题。2. 核心思路拆解为什么必须绕开“官方CLI”幻觉直击协议层本质2.1 不存在的“官方CLI”先破除三个常见误解很多新手搜索“Codex CLI 官网”或“Gemini CLI 下载”结果一头扎进各种第三方 GitHub 仓库下载后发现要么报错command not found要么运行就提示invalid endpoint。这背后是三个根深蒂固的误解必须第一时间厘清误解一“Codex CLI 是 OpenAI 出的工具”OpenAI 在 2023 年已正式下线 Codex 模型服务其 API 文档中从未定义过codex-cli这个命令行客户端。所有叫codex-cli的项目都是社区开发者基于 OpenAI 的/v1/chat/completions接口规范即 OpenAI Chat Completion 格式封装的通用 CLI。它的本质是一个“OpenAI 协议客户端”名字里的 “Codex” 只是历史遗留的营销标签实际支持gpt-4-turbo、claude-3-haiku、deepseek-coder等任何兼容该格式的服务。我试过用同一个codex-cli配置后端切换 Ollama 的llama3:70b、LiteLLM 的azure/gpt-4o、甚至自建的 FastAPI 代理只需改一行--base-url完全无需重装。误解二“Gemini CLI 是 Google 官方发布的命令行”Google AI Studio 提供的是 Web 控制台和 Python SDKgoogle.generativeai没有命令行二进制。所谓 “Gemini CLI”实则是另一批开发者写的、专门适配 Gemini API 格式的 CLI例如gemini-cli或gai。它的关键区别在于Gemini 的请求体是{contents: [{parts: [{text: xxx}]}]}而 OpenAI 是{messages: [{role: user, content: xxx}]}。两者结构完全不同强行用codex-cli调 Gemini 服务必然报错missing messages field。我见过太多人把 Gemini 的 API Key 填进codex-cli的配置文件然后困惑为什么一直返回 400 错误——根本不是 Key 无效是请求体格式直接被服务端拒收。误解三“装完就能用Key 对了就万事大吉”这是最危险的认知。以 Ubuntu 20.04 为例系统默认 Python 是 3.8而很多 CLI 工具要求 3.10Windows 用户用 PowerShell 安装时常因执行策略Execution Policy被阻止更隐蔽的是 DNS 解析问题gemini.google.com在国内某些网络环境下会解析失败但用户看到的错误却是Connection refused误以为是 Key 或代理问题。实际上真正的故障树应该是网络连通性 → DNS 解析 → TLS 握手 → HTTP 状态码 → 响应体 JSON 结构校验 → 流式响应处理。CLI 工具只是最上层的“操作界面”底层每一环都可能断裂。这也是为什么热词里反复出现“需要路由服务才能正常使用”“请先启动路由”——这里的“路由”不是指物理路由器而是指本地运行的协议转换网关如 LiteLLM它把 Gemini 格式请求转成 OpenAI 格式再发给后端或者把本地 Ollama 的响应包装成标准 OpenAI JSON 返回给 CLI。2.2 正确路径选择“协议对齐型CLI”而非“模型绑定型CLI”基于以上分析我们放弃寻找“万能CLI”的幻想转而采用“协议对齐”策略根据你实际要对接的服务端协议选择最匹配的 CLI 工具并亲手验证其请求/响应格式是否100%一致。这不是妥协而是工程上的必要精度控制。我推荐的组合非常明确如果你后端是 OpenAI 兼容服务Ollama / LiteLLM / AnythingLLM / Azure OpenAI用openai-cli由 OpenAI 官方维护的 Python CLIGitHub 仓库名openai/openai-pythonpip install openai后自带openai命令或litellm-cliLiteLLM 官方 CLI专为多后端设计。它们的优势是源码可读、错误提示精准、更新紧跟协议变更。例如openai chat --model llama3 --message hello会自动构造标准 OpenAI 请求体且当服务端返回非标准字段时会明确提示Unexpected field custom_id in response。如果你后端是原生 Gemini 服务Google AI Studio用gaiGitHub 仓库jamesqquick/gai或gemini-clinpm install -g gemini-cli。gai的优势在于它直接调用 Google 的generativeaiPython SDK天然支持 Gemini 的streaming、safety_settings、system_instruction等高级特性。而gemini-cli是 Node.js 写的启动更快适合 Windows 用户。如果你需要“混合调度”比如用 Codex CLI 调 Ollama同时用 Gemini CLI 调 Google不要试图找一个 CLI 兼容两者而是用 Shell 脚本或 Makefile 统一管理。例如写一个ai.mk文件.PHONY: ask-codex ask-gemini ask-codex: openai chat --model llama3:70b --message $(MSG) ask-gemini: gai --model gemini-1.5-pro --prompt $(MSG)然后执行make ask-codex MSG解释下Transformer的QKV机制。这种方式看似多一步实则隔离清晰、调试简单——出问题时你永远知道是ask-codex这条链路的问题而不是在一个黑盒 CLI 里猜哪个模块坏了。提示所有 CLI 工具的核心逻辑只有三步读取配置API Key、Endpoint、构造请求体按目标协议、发送 HTTP 请求并解析响应。因此判断一个 CLI 是否可靠最硬的标准是查看它的源码中request.json()构造部分是否与你后端文档的示例请求体完全一致。我在审查codex-cli仓库时曾发现一个版本将temperature参数错误地塞进了headers而非jsonbody导致所有请求都被服务端忽略——这种低级错误只有看源码才能100%规避。3. 实操细节与环境准备从零开始在 Ubuntu 20.04 / Windows 11 上完成全链路验证3.1 Ubuntu 20.04 环境避开 Python 版本陷阱与权限雷区Ubuntu 20.04 自带 Python 3.8.10而openai-cli要求 Python ≥3.9gai要求 Python ≥3.10。直接apt install python3会升级系统 Python极可能导致apt包管理器崩溃因为 Ubuntu 20.04 的apt依赖 Python 3.8。这是新手最容易踩的坑。正确做法是用 pyenv 管理多版本 Python为 CLI 工具创建独立环境。第一步安装 pyenv安全隔离# 安装依赖 sudo apt update sudo apt install -y make build-essential libssl-dev zlib1g-dev \ libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm libncurses5-dev \ libncursesw5-dev xz-utils tk-dev libffi-dev liblzma-dev python-openssl git # 安装 pyenv curl https://pyenv.run | bash # 将以下三行添加到 ~/.bashrc 末尾 export PYENV_ROOT$HOME/.pyenv command -v pyenv /dev/null || export PATH$PYENV_ROOT/bin:$PATH eval $(pyenv init -) # 重新加载配置 source ~/.bashrc第二步安装 Python 3.11 并设为全局默认仅对当前用户pyenv install 3.11.9 pyenv global 3.11.9 python --version # 应输出 3.11.9注意pyenv global不会影响系统 Python/usr/bin/python3只改变当前用户的python命令指向。这是 Ubuntu 下最安全的方案。第三步安装 openai-cli对接 Ollama 为例假设你已按官方文档在 Ubuntu 上安装好 Ollamacurl -fsSL https://ollama.com/install.sh | sh并运行ollama run llama3测试过模型可用。现在安装 CLI# 创建专用虚拟环境避免包冲突 python -m venv ~/venv-ai source ~/venv-ai/bin/activate # 安装 openai 官方 SDK含 CLI pip install --upgrade pip pip install openai # 验证 CLI 是否可用 openai --help | head -10第四步配置 OpenAI 兼容服务端点关键Ollama 默认监听http://localhost:11434但它原生不提供 OpenAI 兼容接口。你需要启动一个代理。最轻量的是ollama-openai-proxyGitHub 仓库jimmyhchan/ollama-openai-proxy# 下载预编译二进制Linux AMD64 wget https://github.com/jimmyhchan/ollama-openai-proxy/releases/download/v0.1.0/ollama-openai-proxy-linux-amd64 chmod x ollama-openai-proxy-linux-amd64 ./ollama-openai-proxy-linux-amd64 --host 0.0.0.0 --port 8000 --ollama-host http://localhost:11434 此时http://localhost:8000/v1/chat/completions就是标准 OpenAI 接口。配置 CLI# 设置环境变量永久写入 ~/.bashrc echo export OPENAI_BASE_URLhttp://localhost:8000/v1 ~/.bashrc echo export OPENAI_API_KEYollama ~/.bashrc # Ollama 代理默认 Key 是 ollama source ~/.bashrc # 测试向本地 llama3 发送请求 openai chat --model llama3 --message 你好你是谁 --max-tokens 50如果返回I am a large language model developed by Meta...说明全链路打通。注意--model llama3是传递给 Ollama 的模型名不是 OpenAI 的模型名这是代理层做的映射。3.2 Windows 11 环境PowerShell 执行策略与 Chocolatey 包管理Windows 用户最大的障碍不是技术而是权限。PowerShell 默认执行策略为Restricted禁止运行本地脚本导致npm install -g gemini-cli后gemini-cli命令无法识别。解决方案分两步第一步解除 PowerShell 执行限制仅当前用户以管理员身份打开 PowerShell执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser # 输入 Y 确认 Get-ExecutionPolicy -Scope CurrentUser # 应返回 RemoteSigned这比Unrestricted更安全只允许本地脚本和来自可信源的远程脚本。第二步用 Chocolatey 安装 Node.js避免官网 MSI 的 PATH 问题Windows 官网下载的 Node.js MSI 安装包有时会把npm添加到用户 PATH但cmd或 PowerShell 不立即生效。Chocolatey 是 Windows 原生包管理器安装后 PATH 自动更新# 以管理员身份运行 PowerShell执行 Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString(https://community.chocolatey.org/install.ps1)) # 安装 Node.js含 npm choco install nodejs -y # 验证 node --version # 应输出 v20.x npm --version # 应输出 10.x第三步安装 gemini-cli 并配置 Google AI Studio访问 Google AI Studio 创建新项目 → 获取 API Key位置左上角头像 → Manage Account → API Keys。注意Key 必须绑定到启用 Gemini API 的项目否则返回403 Forbidden。安装 CLInpm install -g gemini-cli配置创建~\AppData\Roaming\gemini-cli\config.json{ apiKey: your_actual_api_key_here, model: gemini-1.5-pro-latest, baseUrl: https://generativelanguage.googleapis.com/v1beta }测试gemini-cli 用中文写一首关于春天的七言绝句如果返回诗歌说明成功。若报错Error: Request failed with status code 400大概率是baseUrl少了/models/前缀——正确应为https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-pro-latest:generateContent。这是 Gemini API 的典型坑baseUrl是基础路径但 CLI 工具内部拼接时可能漏掉models/。此时需查看gemini-cli源码的api.js文件确认 URL 拼接逻辑。3.3 通用配置技巧让 CLI 支持流式输出与上下文记忆无论 Ubuntu 还是 WindowsCLI 的核心体验差距在于两点是否支持流式streaming输出像 ChatGPT 那样逐字显示而非等全部生成完才刷出、是否支持对话上下文记住之前的问答实现多轮交互。很多 CLI 默认关闭 streaming因为处理不好的话会乱码。启用 streaming以 openai-cli 为例openai chat --model llama3 --message 你好 --stream但要注意Ollama 代理必须支持streamtrue参数且 CLI 要能正确解析data: {...}SSE 格式。我实测ollama-openai-proxy支持但某些旧版代理不支持会返回400 Bad Request。解决方法在代理启动时加--stream参数或换用lite-llmpip install litellm然后litellm --model ollama/llama3 --api-base http://localhost:11434。实现上下文记忆简易版CLI 本身不保存历史但你可以用 Shell 函数模拟。在 Ubuntu 的~/.bashrc中添加ai() { local msg$* if [ -z $msg ]; then echo Usage: ai your question return 1 fi # 将本次提问追加到 history 文件 echo User: $msg ~/.ai-history # 调用 CLI 并捕获响应 local resp$(openai chat --model llama3 --message $msg --max-tokens 200 2/dev/null) echo AI: $resp ~/.ai-history echo $resp }然后执行source ~/.bashrc之后ai 你好就会自动记录对话到~/.ai-history。虽然简陋但比每次手动复制粘贴高效十倍。实操心得我在给一家做嵌入式开发的客户部署时发现他们工程师最需要的不是“多模型切换”而是“把 CLI 集成到 VS Code 终端里按 CtrlEnter 就能问当前代码文件的问题”。最终方案是用 VS Code 的 Tasks 功能定义一个task.json将选中的代码片段作为--message参数传给openai chat。这比任何花哨的 GUI 插件都稳定——因为底层还是调用同一套经过验证的 CLI 链路。4. 核心环节实现从 API Key 获取到服务端点配置的全流程手把手4.1 OpenAI 兼容服务的 API Key 与 Endpoint 配置以 LiteLLM 为例LiteLLM 是目前最成熟的 OpenAI 兼容代理支持 100 模型后端包括 Ollama、Anthropic、Cohere、Google Vertex AI且配置极其灵活。它完美解决了热词中“填写兼容 openai response 格式的服务端点地址”“此供应商使用 openai chat 接口格式”的需求。安装与启动 LiteLLM# 在 Ubuntu 或 Windows WSL 中 pip install litellm # 启动服务监听 4000 端口支持 streaming litellm --model ollama/llama3 --api-base http://localhost:11434 --port 4000 --drop-rate 0.01此时http://localhost:4000/v1/chat/completions就是标准 OpenAI 接口。API Key 配置安全实践LiteLLM 默认不强制 Key但生产环境必须开启。正确做法是用环境变量注入 Key而非硬编码在配置中。# 生成随机 KeyLinux openssl rand -hex 32 # 输出类似a1b2c3d4e5f6...复制此字符串 # 启动时指定 Key LITELLM_KEYa1b2c3d4e5f6... litellm --model ollama/llama3 --port 4000然后在 CLI 中配置export OPENAI_API_KEYa1b2c3d4e5f6... export OPENAI_BASE_URLhttp://localhost:4000/v1验证 Key 有效性关键调试步骤不要等 CLI 报错才排查。直接用 curl 测试curl http://localhost:4000/v1/chat/completions \ -H Authorization: Bearer a1b2c3d4e5f6... \ -H Content-Type: application/json \ -d { model: ollama/llama3, messages: [{role: user, content: hi}], stream: false }如果返回{error: {message: Authentication failed.}}说明 Key 不匹配如果返回{id:..., choices:[{message:{content:Hello!}}]}说明 Key 和服务都正常。这比在 CLI 里反复试错快十倍。4.2 Gemini API Key 获取与学生认证避坑指南Google AI Studio 的 Key 获取流程看似简单但隐藏着两个高发问题“your current account is not eligible for gemini code assist for individuals”和“chrome gemini没有显示”。前者是服务权限问题后者是浏览器集成问题但根源都在 Google 账户状态。获取 Key 的正确路径访问 Google AI Studio 用 Gmail 账户登录。点击左上角项目下拉框 → “New Project” → 输入项目名如my-ai-cli→ Create。在左侧菜单点击 “Manage resources” → 选择刚创建的项目 → 点击 “Enable APIs and Services”。搜索 “Generative Language API” → Enable。回到 AI Studio 主页点击左上角头像 → “Manage Account” → “API Keys” → “Create new key”。复制生成的 Key形如AIzaSyD...立即保存到安全位置。Google 不会再次显示完整 Key。学生认证的真相热词中“gemini学生认证”是个误导。Google AI Studio 本身没有“学生认证”入口。所谓“学生优惠”是指通过 Google Cloud Education Grants 申请免费额度但这需要学校邮箱.edu后缀和教授推荐信审核周期长达 2 周。对于个人开发者唯一可行的方案是用个人 Gmail 创建新项目并确保该账户已开启 2-Step Verification双重验证。很多用户遇到not eligible错误是因为账户刚注册或长期未登录Google 风控系统将其标记为“低信任度”。解决方法登录 Gmail发送几封邮件浏览 YouTube 视频让账户活跃起来进入 Google Account 设置开启 2-Step Verification等待 24-48 小时再尝试创建 AI Studio 项目。Chrome 浏览器 Gemini 消失的解决方法这不是 CLI 的问题而是 Chrome 的 Feature Flag。在 Chrome 地址栏输入chrome://flags/#gemini-in-chrome将该 Flag 设为 “Enabled”然后重启浏览器。如果仍不显示检查 Chrome 版本必须 ≥124。旧版本不支持。另外某些企业版 Chrome 会禁用此功能需联系 IT 管理员。4.3 服务端点地址的终极配置法则URL、Header、Body 三要素缺一不可所有 CLI 工具的配置本质就是告诉它三件事发给谁URL、用什么身份Header、说什么内容Body。热词中反复出现的“服务端点地址”“兼容 openai response 格式”指的就是这三要素的精确匹配。以openai-cli调用 LiteLLM 为例完整请求链路如下要素CLI 配置方式实际发送内容常见错误URLOPENAI_BASE_URLhttp://localhost:4000/v1POST http://localhost:4000/v1/chat/completions少/v1变成http://.../chat/completions返回 404少/chat/completions变成http://.../v1返回 405HeaderOPENAI_API_KEYa1b2c3...Authorization: Bearer a1b2c3...Content-Type: application/jsonKey 放在X-API-KeyHeaderLiteLLM 不认返回 401Content-Type缺失返回 415Bodyopenai chat --model ollama/llama3 --message hi{model:ollama/llama3,messages:[{role:user,content:hi}]}messages写成message单数返回 400role写成user_role返回 400Body 格式验证的黄金方法当 CLI 报错时不要猜。用--log-level debug参数如果 CLI 支持或抓包工具看真实请求体。openai-cli支持openai chat --model llama3 --message hi --log-level debug它会输出类似DEBUG:openai._base_client:Request body: {model: llama3, messages: [{role: user, content: hi}]}将此 JSON 复制到在线 JSON 校验器如 jsonlint.com确认语法无误。再对照你后端文档的示例请求体逐字段比对。这是 90% 的“格式错误”问题的终结者。注意事项很多用户在配置--model参数时误以为要填gpt-4这样的名字。实际上--model的值必须与你后端服务支持的模型名完全一致。Ollama 里是llama3LiteLLM 代理里是ollama/llama3Google Vertex AI 里是projects/xxx/locations/us-central1/publishers/google/models/gemini-1.5-pro。填错一个字符服务端就返回model not found。我的经验是先在后端服务的 Web UI 或 curl 测试中确认模型名再复制粘贴到 CLI 命令中绝不手打。5. 常见问题与排查技巧实录从“command not found”到“thinkingconfig”参数详解5.1 典型错误速查表按错误信息反向定位根因错误信息CLI 输出最可能根因快速验证方法解决方案command not found: codexCLI 未正确安装或 PATH 未生效which codex或where codexWindowsUbuntu检查~/.local/bin是否在 PATHWindows检查npm prefix -g输出的路径是否加入系统 PATHConnection refused服务端未启动或端口错误curl -v http://localhost:8000/health检查代理进程是否运行ps aux | grep ollama-openai-proxy确认端口与 CLI 配置一致401 UnauthorizedAPI Key 错误或 Header 未发送curl -H Authorization: Bearer xxx http://...检查 Key 是否复制完整有无空格确认 CLI 是否将 Key 放入AuthorizationHeader非X-API-Key400 Bad Request请求体 JSON 格式错误将 CLI debug 输出的 JSON 粘贴到 jsonlint.com 校验对照后端文档修正messages/contents字段名、role/parts结构403 ForbiddenKey 无权限或项目未启用 API访问 Google Cloud Console → API Services → Dashboard确认 Generative Language API 已启用重新生成 Key确保绑定到正确项目检查账户是否被风控见 4.2 节no model named gemini-1.5-pro模型名不匹配查看后端服务的模型列表如curl http://localhost:11434/api/tags使用后端返回的实际模型名如llama3:70b、gemini-1.5-pro-latest5.2 “thinkingconfig”参数深度解析Gemini 3.0 Pro 的思考模式实战热词中“gemini 3.0 pro开启思考模式api案例thinkingconfig”指向 Gemini 最新特性thinking模式。它允许模型在生成最终答案前先输出内部推理步骤类似 Chain-of-Thought提升复杂任务的准确性。但此功能不在标准 Gemini API 中而是 Google AI Studio 的 Preview 特性需特殊配置。启用条件必须使用gemini-1.5-pro-latest或gemini-1.5-flash-latest模型必须在请求 Body 中显式设置tools: [{function_declarations: [...] }]或system_instruction更关键的是必须在 Google Cloud Console 中为项目启用Vertex AIAPI并使用 Vertex AI 的 Endpoint而非 AI Studio 的generativelanguage.googleapis.com。CLI 实现方法以 gai 为例gai目前不原生支持thinking参数但可通过--raw模式传入完整 JSONgai --raw { contents: [{parts: [{text: 用Python写一个快速排序算法并解释每一步}]}], generationConfig: { temperature: 0.2, topK: 40, topP: 0.95, maxOutputTokens: 2048, candidateCount: 1 }, safetySettings: [...], systemInstruction: {parts: [{text: 请先展示思考过程再给出最终代码}]} } --model gemini-1.5-pro-latest其中systemInstruction就是触发“思考模式”的关键。实测效果模型会先输出思考快速排序的核心是分治法...再给出代码。这比单纯加--temperature 0.2更可控。实操心得我在为客户做代码审查自动化时发现直接让 Gemini 输出“思考过程”会导致响应变慢 30%且流式输出时思考文本和代码混在一起。最终方案是用两次调用——第一次systemInstruction设为“请用 Markdown 列出解决此问题的 5 个关键步骤”第二次将步骤作为 context调用--message 根据以上步骤写出完整 Python 代码。这样既保证质量又便于程序解析。5.3 卸载与清理避免残留配置导致新安装失败很多用户在多次尝试失败后想彻底卸载重来却因残留配置而失败。“codex cli卸载”“windows安装codex cli”等热词反映了这一痛点。Ubuntu 彻底卸载流程# 1. 删除 CLI 本身 pip uninstall openai litellm -y # 2. 删除 pyenv 环境如果不再需要 rm -rf ~/.pyenv # 3. 清理环境变量 sed -i /PYENV_ROOT/d ~/.bashrc sed -i /openai/d ~/.bashrc source ~/.bashrc # 4. 杀死所有相关进程 pkill -f ollama-openai-proxy pkill -f litellmWindows 彻底卸载流程# 1. 卸载 npm 包 npm uninstall -g gemini-cli gai # 2. 删除配置文件 Remove-Item $env:APPDATA\gemini-cli -Recurse -Force -ErrorAction Ignore Remove-Item $env:APPDATA\gai -Recurse -Force -ErrorAction Ignore # 3. 清理 PATH在系统属性 → 高级 → 环境变量中删除 npm 全局路径 # 4. 重启 PowerShell最后一步最重要在重新安装前务必用curl或 Postman 直接测试服务端点。例如curl http://localhost:4000/v1/models如果返回{object:list,data:[{id:ollama/llama3,...}]}说明服务端健康如果返回Connection refused说明代理没起来此时装任何 CLI 都是白费。把服务端验证作为安装前的“准入检查”能节省 80% 的无效调试时间。我的个人体会是CLI 工具的价值不在于它有多酷炫的功能而在于它能否成为你工作流中“可预测、可调试、可替换”的一个稳定环节。当我第一次用openai chat