Gemini CLI 要迁到 Antigravity CLI？别等到 6 月 18 日，按这份清单处理

刚收到谷歌的通知：Gemini CLI 即将迁移到新的 Antigravity CLI。

重点就一句话：

以后主线会放到 Antigravity CLI 上，Gemini CLI 用户需要在 6 月 18 日前完成迁移，不然日常工作流可能中断。

如果你只是偶尔在终端里问两句模型，影响可能不大。

但如果你把 Gemini CLI 接进了脚本、CI/CD、代码生成流程、文档自动化，那就别拖。到期那天才发现命令跑不通，真的会很崩。

这篇文章咱们不讲虚的，直接按迁移实操来。

这次变化到底是什么？

谷歌正在把一批 AI 工具整合到统一的多智能体平台 Antigravity 里。

以前你可能用的是：

gemini ...

后面主推的会变成：

antigravity ...

注意，名字变了，背后的定位也变了。

Gemini CLI 更像是“调用 Gemini 的命令行入口”。

Antigravity CLI 更像是“面向多智能体工作流的统一入口”。

说人话就是：谷歌不想让你只在命令行里单点调用模型，而是想把模型、工具、Agent、任务编排都装进一个更大的 CLI 体系里。

这对个人开发者、自动化玩家、AI 工具链用户都有影响。

你需要关心哪些地方？

别只盯着“换个命令名”这件事。

真正容易出问题的是这些地方：

你本地终端里的旧命令
shell 脚本里的 gemini
GitHub Actions / GitLab CI 里的调用
定时任务里的自动摘要、自动生成、自动检查
团队文档里写死的安装和使用方式
环境变量、认证方式、配置文件路径
输出格式变化导致下游解析失败

举个很真实的场景。

你有个脚本每天早上 9 点自动总结昨天的代码提交：

git log --since="yesterday" | gemini "总结这些提交，生成日报"

如果迁移后 gemini 不可用，这个脚本就直接趴下。

更坑的是，脚本可能不是报错给你看，而是在 CI 里静悄悄失败。等老板问日报呢，你才开始翻日志。

别这样，真的没必要。

迁移前：先盘点你到底用了多少 Gemini CLI

别急着卸载旧工具。

先把项目里所有 gemini 调用找出来。

macOS / Linux 用户

在你的项目根目录执行：

grep -R "gemini" . \
  --exclude-dir=node_modules \
  --exclude-dir=.git \
  --exclude-dir=dist \
  --exclude-dir=build

如果你想查得更猛一点，可以从常用工作目录开始：

grep -R "gemini" ~/projects ~/workspace 2>/dev/null

Windows PowerShell 用户

Get-ChildItem -Recurse -File | Select-String "gemini"

重点检查这些文件

优先看这些位置：

package.json
Makefile
Dockerfile
.github/workflows/*.yml
.gitlab-ci.yml
*.sh
*.ps1
*.py
README.md
docs/

找到后别急着全局替换。

先记下来：

| 位置 | 用途 | 是否影响生产 | 是否需要改 | |---|---|---:|---:| | scripts/daily-report.sh | 自动生成日报 | 是 | 是 | | README.md | 使用说明 | 否 | 是 | | .github/workflows/ai-review.yml | PR 自动审查 | 是 | 是 |

这张表很重要。

因为有些只是文档，有些是生产链路。生产链路要优先改。

安装 Antigravity CLI：先看官方渠道，别乱装

这里要提醒一句：CLI 工具最怕装到奇怪来源。

尤其是跟 AI API、账号凭证、项目代码相关的工具。

你要做的是去谷歌官方通知、官方文档、官方仓库找安装方式。

不要随便复制社区帖子里的安装命令，特别是这种：

curl xxx | bash

不是说一定有问题，而是你压根不知道它往你机器里写了什么。

更稳的安装策略是：

用官方文档给出的包管理器
确认包名和发布方
安装后检查版本
登录前确认命令路径

安装完成后，先跑：

antigravity --version

再看帮助信息：

antigravity --help

如果这两条都正常，再进入登录和迁移环节。

认证迁移：别把旧 token 当成理所当然

Gemini CLI 到 Antigravity CLI，认证方式可能会变。

你需要重点看这几个问题：

旧的 API Key 还能不能用？
是否需要重新登录谷歌账号？
环境变量名称有没有变化？
服务账号是否还支持？
CI 里保存的 Secret 是否需要更新？

常见旧配置可能长这样：

export GEMINI_API_KEY="xxxxx"

新工具可能会要求新的变量名，或者走统一认证。

这里不要猜。

你应该打开官方文档，搜索这些关键词：

auth
login
API key
environment variable
service account
CI

本地登录完成后，做一次最小测试。

例如：

antigravity --help

如果官方文档提供了简单调用命令，就用最短 prompt 测一下：

antigravity "用一句话介绍 Antigravity CLI"

如果命令格式不同，就按官方文档调整。

目标不是一次性把所有能力吃透。

目标是确认三件事：

CLI 能运行
账号能认证
模型能返回结果

这三件事过了，迁移才算有地基。

替换命令：别无脑把 gemini 改成 antigravity

很多人一看到迁移，手就开始痒：

find . -type f -exec sed -i 's/gemini/antigravity/g' {} +

别这么干。

这招很容易把文档、变量名、日志字段、普通文本一起改坏。

更稳的方式是逐个场景处理。

场景 1：交互式命令

旧方式可能是：

gemini "帮我解释这个错误"

迁移后你要确认 Antigravity 的调用格式。

可能是类似：

antigravity "帮我解释这个错误"

也可能需要子命令：

antigravity run "帮我解释这个错误"

具体以官方文档为准。

你要做的是，把自己常用的 3～5 个命令整理出来，挨个测试。

比如：

# 解释报错
antigravity "解释下面这个报错：$(cat error.log)"

# 总结文件
cat README.md | antigravity "总结这份文档"

# 生成提交信息
git diff --cached | antigravity "根据这段 diff 生成中文 commit message"

如果管道输入、参数位置、输出格式有变化，马上记下来。

场景 2：shell 脚本

旧脚本可能长这样：

#!/usr/bin/env bash

content=$(cat notes.md)
gemini "请把下面的笔记整理成会议纪要：$content" > summary.md

迁移时建议做两件事。

一是把 CLI 命令抽成变量：

#!/usr/bin/env bash
set -euo pipefail

AI_CLI=${AI_CLI:-antigravity}

content=$(cat notes.md)
$AI_CLI "请把下面的笔记整理成会议纪要：$content" > summary.md

这样以后再换工具，不用满世界改。

二是加失败提示：

if ! command -v "$AI_CLI" >/dev/null 2>&1; then
  echo "未找到 $AI_CLI，请先安装 Antigravity CLI" >&2
  exit 1
fi

完整一点可以这样写：

#!/usr/bin/env bash
set -euo pipefail

AI_CLI=${AI_CLI:-antigravity}

if ! command -v "$AI_CLI" >/dev/null 2>&1; then
  echo "未找到 $AI_CLI，请先安装 Antigravity CLI" >&2
  exit 1
fi

content=$(cat notes.md)
$AI_CLI "请把下面的笔记整理成会议纪要：$content" > summary.md

echo "会议纪要已生成：summary.md"

这才像个能长期跑的脚本。

场景 3：CI/CD 自动化

如果你在 GitHub Actions 里用 Gemini CLI，迁移要更谨慎。

旧配置可能是：

name: AI Review

on:
  pull_request:

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run AI review
        run: |
          git diff origin/main...HEAD | gemini "帮我审查这次 PR"

迁移时要处理三件事：

安装 Antigravity CLI
配置认证信息
替换调用命令

示意结构可以这样：

name: AI Review

on:
  pull_request:

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Antigravity CLI
        run: |
          echo "这里填写官方文档提供的安装命令"
          antigravity --version

      - name: Run AI review
        env:
          ANTIGRAVITY_API_KEY: ${{ secrets.ANTIGRAVITY_API_KEY }}
        run: |
          git diff origin/main...HEAD | antigravity "帮我审查这次 PR，重点看潜在 bug 和安全风险"

这里的 ANTIGRAVITY_API_KEY 只是示例名称。

真实变量名请按官方文档来。

别直接把旧的 GEMINI_API_KEY 改名就完事。认证机制一变，CI 会当场翻车。

给自己留个兼容层，迁移会舒服很多

如果你项目里很多地方都调用 AI CLI，建议加一个小包装脚本。

比如新建：

scripts/ai.sh

内容：

#!/usr/bin/env bash
set -euo pipefail

AI_CLI=${AI_CLI:-antigravity}

if ! command -v "$AI_CLI" >/dev/null 2>&1; then
  echo "找不到 $AI_CLI。请安装 Antigravity CLI，或设置 AI_CLI 指向可用工具。" >&2
  exit 1
fi

$AI_CLI "$@"

赋予执行权限：

chmod +x scripts/ai.sh

以后你就统一调用：

./scripts/ai.sh "帮我总结这段日志"

脚本里也写：

cat error.log | ./scripts/ai.sh "分析这个错误原因"

好处很明显：

后面 CLI 再变，只改一个文件
本地和 CI 可以用同一套入口
团队成员不用记一堆命令细节
出错提示可以统一处理

这招不花哨，但很救命。

迁移后一定要做的 5 个测试

装好了，命令也改了，别急着宣布完工。

跑完下面这 5 个测试再说。

1. 版本测试

antigravity --version

确认输出正常。

2. 帮助测试

antigravity --help

看子命令、参数、认证提示。

3. 最小调用测试

antigravity "用一句话回复：迁移测试成功"

如果官方格式不是这样，按文档换成对应命令。

4. 管道输入测试

echo "帮我把这句话改得更自然" | antigravity

重点看它是否支持 stdin。

如果不支持，你的旧脚本大概率要改。

5. CI 测试

开一个测试分支，触发一次完整流水线。

别直接在主分支赌命。

看这些信息：

安装是否成功
Secret 是否读取成功
命令是否返回 0
输出是否符合预期
日志里有没有泄露 token

尤其是最后一条。

AI CLI 一旦把认证信息打印进日志，麻烦就大了。

避坑清单：这些事最容易翻车 ⚠️

坑 1：以为只是换名字

别把迁移理解成：

gemini -> antigravity

CLI 的参数、认证、输出格式、模型选择方式都可能变。

逐条验证，别靠感觉。

坑 2：生产脚本没有锁版本

如果安装命令总是拉最新版本，哪天 CLI 行为变了，你的脚本就可能炸。

能锁版本就锁版本。

至少在 CI 日志里打印版本：

antigravity --version

方便排查问题。

坑 3：把 API Key 写进脚本

不要这样：

export ANTIGRAVITY_API_KEY="真实密钥"

更不要提交到 Git。

本地用 .env，CI 用 Secrets。

坑 4：不检查输出格式

很多自动化流程会解析 AI 输出。

比如你要求模型输出 JSON：

antigravity "输出 JSON，字段包括 title 和 summary"

如果新 CLI 多了一段提示文本，解析器就会失败。

迁移后要专门测输出格式。

坑 5：团队只有一个人会用

别让迁移知识停在你脑子里。

在项目里加一段文档：

## AI CLI 使用说明

本项目使用 Antigravity CLI。

安装方式：参考官方文档。

验证命令：

```bash
antigravity --version
antigravity --help

常用脚本：

./scripts/ai.sh "总结当前改动"


团队协作里，文档不是装饰品，是救命绳。

---

## 推荐迁移节奏

别等 6 月 18 日前一天。

可以按这个节奏来：

### 今天：盘点使用点

用 `grep` 或搜索工具找出所有 `gemini`。

整理成清单，标注哪些影响生产。

### 1～2 天内：本地完成安装和认证

安装 Antigravity CLI。

跑通版本、帮助、最小调用。

### 3～5 天内：改脚本和 CI

优先改生产脚本。

给项目加 `scripts/ai.sh` 这种兼容层。

### 1 周内：团队同步

更新 README。

通知团队成员迁移。

让大家各自跑一遍验证命令。

### 截止日前：保留回滚方案

别急着删掉旧配置。

至少保留一份旧脚本备份，直到新流程稳定跑几天。

---

## 一个可直接照抄的迁移检查表

你可以把下面这段复制到任务系统里：

```markdown
## Gemini CLI -> Antigravity CLI 迁移检查表

- [ ] 搜索项目内所有 `gemini` 调用
- [ ] 标记生产脚本、CI、文档、个人工具
- [ ] 阅读 Antigravity CLI 官方安装文档
- [ ] 安装 Antigravity CLI
- [ ] 执行 `antigravity --version`
- [ ] 执行 `antigravity --help`
- [ ] 完成本地认证
- [ ] 跑通最小调用测试
- [ ] 验证 stdin / 管道输入
- [ ] 替换生产脚本中的 Gemini CLI 调用
- [ ] 增加统一包装脚本 `scripts/ai.sh`
- [ ] 更新 CI Secrets
- [ ] 在测试分支跑通 CI
- [ ] 检查日志是否泄露密钥
- [ ] 更新 README / 团队文档
- [ ] 通知团队成员完成本地迁移
- [ ] 观察新流程稳定运行 3 天以上

结语：这次别拖，CLI 迁移最怕“我以为”

Gemini CLI 迁到 Antigravity CLI，不只是终端里少打几个字、多打几个字的问题。

真正影响的是你藏在项目里的自动化流程。

日报、PR 审查、代码解释、文档生成、错误分析……这些一旦写进脚本，就变成了工作链路的一部分。

所以现在最该做的不是焦虑，而是打开终端，搜一遍：

grep -R "gemini" . --exclude-dir=node_modules --exclude-dir=.git

找到它，记录它，测试它，迁移它。

6 月 18 日前搞定，后面就少很多破事。