2026年Claude实名认证的担忧，尝试Gemini CLI替代，JeecgBoot skills 基本通畅，但遇到致命问题

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

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:Userszhang 一看——家目录里几十个 junction、Downloads / Documents、部分软件缓存目录全空了。

实际执行的命令：

Remove-Item -Path google_skills, temp_skills, “” -Recurse -Force

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

换句话说，这条命令实际执行的是 Remove-Item -Path “C:Userszhang” -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 密码一样。

防御性写法参考（PowerShell）：

# 永远用 -LiteralPath 处理字面量文件夹名 Remove-Item -LiteralPath ‘~’ -Recurse -Force

或者显式 ./ 前缀

Remove-Item ‘./~’ -Recurse -Force

列出家目录下的所有 junction（检查 Agent 有没有误删）

Get-ChildItem C:Users$env:USERNAME -Force | Where-Object { $_.Attributes -match “ReparsePoint” } | Select-Object Name, @}