AI Agent 使用体验 * JeecgBoot 团队将日常 Claude Code 工作流迁移到 Gemini CLI 的阶段性总结

为什么要换 Gemini CLI

JeecgBoot 低代码团队平时主力用 Claude Code 做代码生成、文档写作、重构脚本。但 Claude 最近实名认证 + 频繁封号的事闹得人心惶惶 —— 身边已经有好几个账号莫名其妙被风控，工作流一断就是一整天。于是团队开始评估备胎方案，正好 Google 发布 Gemini CLI，社区反馈长上下文和推理都不弱，价格也比 Opus 亲民，就拉了一轮对比实测，看看能不能把关键工作流切过去。

不过换之前我们也有顾虑：Gemini CLI 生态比 Claude Code 小太多。Claude Code 发布一年多，围绕它沉淀的 skills、MCP、hooks、第三方工具、踩坑文章和中文教程已经是一个成熟的小生态；Gemini CLI 才出几个月，社区实践、skills 分享、配套脚本都还很稀薄，遇到问题得自己啃英文文档或者翻 GitHub Issues。对于重度依赖 skills 二次开发的团队来说，这个 "生态代差" 本身就是一个迁移成本 —— 这也是为什么这次只做 "能不能用" 的小范围评估，而不是直接全量切换。

这篇文章只记录两件事：跑得通的部分，以及踩到的一个知名大坑。

一、Skills 机制：一句话能跑的能力直接平迁过来了

Claude Code 的 skills 是团队日常工具链里最常用的一层（jeecg-codegen、jeecg-desform、jeecg-onlform、jimureport、jimubi-bigscreen 等等都是 skills 形式交付的）。换 Gemini CLI 之前最担心的就是这套东西能不能过去。

实测结论：skills 的 Markdown 格式 + 触发词机制，Gemini CLI 能识别和执行，而且一些高复杂度的 "一句话" 任务都能跑出来：

• 一句话创建积木报表的分组报表和联动图表 —— 从 SQL 数据源绑定、分组字段配置，到联动图表的维度关联，它能一路走完
• 一句话创建 Online 表单，并对接积木报表生成打印报表 —— 自动建表 → 配置表单字段 → 关联打印报表模板，流程打通
• 一句话自动创建数据大屏 —— 组件布局、数据绑定、配色方案都自己搞定

对比维度拉一下：效果比 MiniMax 2.7、智谱 GLM 5.1 这一批国内模型明显更稳定，少数细节要调，但主线流程基本一次过。对于 JeecgBoot 低代码这种重度依赖 skills 的场景，Gemini CLI 的表现算是 "可以放心交活" 的水准。

二、命令执行能力：基本可用

日常开发里 Agent 跑 shell 命令是高频需求 ——git 操作、启服务、跑 pytest、做构建。这部分 Gemini CLI 也能胜任：

• git add / commit / push 链式命令无问题
• mvn clean install、pnpm build 这种长时间任务，它能正确等待输出并根据返回码判定成功 / 失败
• 需要管理员权限的操作（比如 Windows 下的 mklink）它会先说明，然后尝试执行

在这一轮里我们并没有感觉到 "跟 Claude Code 有本质区别"。真正的分水岭出现在 "自动安装 skills + 清理临时文件" 这个环节 —— 也是这次事故的起点。

三、一个 ~ 字符，把家目录递归删了

让 Gemini CLI 自动安装 skills 并清理临时文件，最普通的收尾任务。几分钟后看到一段道歉：

非常抱歉！这是一个极其严重的失误。 在 "清理目录下临时文件" 步骤中，我看到 ls 输出里有一个叫 ~ 的文件夹……

打开 C:\Users\zhang 一看 —— 家目录里几十个 junction、Downloads / Documents、部分软件缓存目录全空了。

实际执行的命令：

Remove-Item -Path google_skills, temp_skills, "~" -Recurse -Force

它想删一个字面量叫 ~ 的文件夹，还特地加了双引号防展开 —— 结果踩到 PowerShell 的经典陷阱：-Path 会走 Provider 解析，~ 始终被展开成 $HOME，加不加引号都没用。只有 -LiteralPath 或 ./~ 才是字面量。

换句话说，这条命令实际执行的是 Remove-Item -Path "C:\Users\zhang" -Recurse -Force—— 递归删除整个家目录。

这锅 Gemini 得背。 它自己在工作目录里生成了一个名为 ~ 的临时文件夹，这种命名本身就暴露了它对 Windows / PowerShell 生态不熟 —— 任何一个有 Windows 经验的工程师都不会起这种文件名。生成了坑，又亲手跳进去，最后把用户家目录端了。AI Agent 执行破坏性命令时，后果被放大了几个量级。

四、几句总结

• Skills 和基础命令执行：Gemini CLI 基本 OK，低代码团队的日常代码生成工作流可以平迁
• 生态代差仍是硬伤：Claude Code 的 skills、MCP、社区教程积累更厚，Gemini CLI 目前仍以 "能用" 为主，还没到 "顺手"
• 涉及系统级 shell 操作时：注意 PowerShell 的 -Path 展开陷阱，尤其是 ~ 这种特殊字符
• Agent 权限不是 "开 / 关" 二元问题：需要分级管理，关键目录必须走人工确认
• 这次事故不能全怪 Gemini——PowerShell 的这个行为是 Windows 生态的历史包袱，任何 Agent 踩上去都会出事。怪的是我们给它的权限边界太宽了。

最终团队的选择是：Claude Code 仍然是主力（哪怕背着实名认证 / 封号的不确定性），Gemini CLI 暂时作为备胎，只在项目沙箱内跑、并等待它的生态跟上来。Agent 在进化，我们对 Agent 的信任模型也要跟着进化。这次教训的本质不是 "Gemini 不能用"，而是任何一个 Agent 第一天都不该拿到用户目录的通行证 —— 就像你不会让新来的实习生第一天就拿 root 密码一样。