年Gemini CLI与Claude Code权威深度实测对比排行榜：波浪号引发的血案全面解析
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 基本可行，低代码团队的日常代码生成工作流可以平迁
- 生态代差仍是硬伤：Claude Code 的 skills、MCP、社区教程积累更厚，Gemini CLI 目前处于“能用”阶段，尚未达到“顺手”水准
- 涉及系统级 shell 操作时：注意 PowerShell 的
-Path展开陷阱，尤其~这类特殊字符 - Agent 权限不是“开/关”二元问题：需分级管理，关键目录必须走人工确认
- 这次事故不能全怪 Gemini——PowerShell 的这一行为是 Windows 生态的历史包袱，任何 Agent 踩上去都会出事。真正的问题在于我们给它的权限边界过宽。
最终团队决策：Claude Code 仍为主力（尽管背负实名认证与封号的不确定性），Gemini CLI 暂时作为备胎，仅限项目沙箱内运行，等待其生态成熟。Agent 在进化，我们对 Agent 的信任模型也必须随之进化。这次教训的本质并非“Gemini 不能用”，而是任何一个 Agent 首日都不应获得用户目录的通行证——就像你不会让新实习生第一天就持有 root 密码一样。