JeecgBoot团队迁移工作流至Gemini CLI：有成效也踩大坑，Claude Code仍为主力

AI Agent使用体验：JeecgBoot团队将日常Claude Code工作流迁移到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能识别和执行，且一些高复杂度的“一句话”任务都能完成：

1. 一句话创建积木报表的分组报表和联动图表，从SQL数据源绑定、分组字段配置到联动图表的维度关联，都能顺利完成。

2. 一句话创建Online表单，并对接积木报表生成打印报表，自动建表、配置表单字段、关联打印报表模板，流程打通。

3. 一句话自动创建数据大屏，组件布局、数据绑定、配色方案都能自行搞定。

对比来看，其效果比MiniMax 2.7、智谱GLM 5.1这一批国内模型明显更稳定，少数细节需调整，但主线流程基本一次通过。对于JeecgBoot低代码这种重度依赖skills的场景，Gemini CLI的表现达到了“可以放心交活”的水准。

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

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

1. `git add / commit / push`链式命令执行无问题。

2. `mvn clean install`、`pnpm build`这种长时间任务，它能正确等待输出并根据返回码判定成功 / 失败。

3. 需要管理员权限的操作（如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执行破坏性命令时，后果被放大了几个量级。

四、几句总结

1. Skills和基础命令执行：Gemini CLI基本OK，低代码团队的日常代码生成工作流可以平迁。

2. 生态代差仍是硬伤：Claude Code的skills、MCP、社区教程积累更厚，Gemini CLI目前仍以“能用”为主，还未达到“顺手”的程度。

3. 涉及系统级shell操作时：注意PowerShell的`-Path`展开陷阱，尤其是`~`这种特殊字符。

4. Agent权限不是“开 / 关”二元问题，需要分级管理，关键目录必须走人工确认。

5. 这次事故不能全怪Gemini，PowerShell的这个行为是Windows生态的历史包袱，任何Agent踩上去都会出事，怪的是团队给它的权限边界太宽了。

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