尝试 Gemini CLI 替代Claude，Jeecg skills基本通畅，但遇致命问题
AI Agent 使用体验| JeecgBoot 团队将日常 Claude Code 工作流迁移到 Gemini CLI 的阶段性总结
为什么要换 Gemini CLI
JeecgBoot 低代码团队平时主力用 Claude Code 做代码生成、文档写作、重构脚本。但 Claude 最近实名认证 + 频繁封号的事闹得人心惶惶——身边已经有好几个账号莫名其妙被风控，工作流一断就是一整天。于是团队开始评估备胎方案，正好 Google 发布 Gemini CLI，社区反馈长上下文和推理都不弱，价格也比 Opus 亲民，就拉了一轮对比实测，看看能不能把关键工作流切过去。
[外链图片转存中…(img-455SwN3a-1776610434246)]
不过换之前我们也有顾虑：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 密码一样。