Gemini CLI上线第一天，我把老项目的构建日志喂给它

Gemini CLI上线第一天，我把老项目的构建日志喂给它

上周公司那个跑了三年的构建服务又崩了。Jenkins流水线卡在中间环节，日志文件涨到4.7GB，团队几个人轮班守着看，眼睛都熬红了。我在群里发了句"谁能帮我想想看"，没人回。第二天刷到Google把Gemini CLI开源了，GitHub地址是 google-gemini/gemini-cli，版本号0.2.13。

说实话，当时第一反应是再试一个AI工具有什么用？我桌上已经堆着GitHub Copilot、Cursor、还有那个跑在我Mac上的Claude插件。但那个4.7GB的日志文件像块石头压着，我想着反正免费调用，扔进去看看能吐出什么。

安装过程比我想象的顺滑。npm install -g @google/gemini-cli，然后gemini启动，默认调的是Gemini 2.0 Flash。我把它指向了那个日志文件的路径，等了大概八秒，终端开始滚动输出。

有意思的是，它没有像其他工具那样给出一个笼统的"可能是内存溢出"。它把日志按时间戳分段，标出了三处异常峰值：第一处在凌晨2:14，CPU占用率从12%跳到97%；第二处在2:17，GC停顿时间连续三次超过400ms；第三处在2:19，堆内存直接OOM。然后它给了一段分析——"问题不在应用本身，而在构建插件com.example:build-monitor:1.3.2的native库在高频轮询时触发了JNI内存泄漏"。

我当时就愣了。那个插件是两年前的老代码，作者已经离职，文档早丢了。团队里没人知道它有个native组件，更没人知道它会内存泄漏。

我翻了下Gemini CLI的文档，发现它支持多轮对话和上下文累积。我把之前的分析结论喂给它，让它基于这个诊断给出修复方案。它建议了两条路：一是升级插件到1.4.0（但这个版本从未发布过）；二是临时在构建脚本里加一段native库的隔离配置，强制每次构建后重启Java进程。

我选了第二条。说实话，当时方案A和B，我选了B因为看起来更稳妥——升级插件涉及重新编译native代码，风险不可控。事后看选错了。因为隔离配置虽然治标，但引入新的进程管理复杂度，导致后续构建流水线维护成本上升了30%。如果当时直接让Gemini CLI去翻那个插件的git提交历史，应该能发现1.4.0的源码还在某个分支上。

验证过程花了两个小时。我先把隔离配置应用到staging环境，跑了一轮完整构建。RT从之前的平均8分42秒降到了5分18秒，而且日志文件体积从4.7GB压缩到了120MB。这个数据我录了屏，发给团队群，几个人同时发了"卧槽"。

但真正让我改观的不是这个。是第三天早上，我让Gemini CLI帮我审查一个新写的Python脚本。那个脚本大概600行，处理批量数据导入，我之前花了一晚上写完，自认为逻辑没问题。Gemini CLI用了两分钟扫描完，指出了三处问题：一处是循环内重复创建数据库连接，RT会从45ms劣化到320ms；一处是异常处理吞掉了关键错误码；还有一处是内存中构建了过大的临时列表，在数据集超过10万条时会触发GC压力。

我把这些问题逐一修复后重跑测试，性能数据对上了——RT稳定在48ms，内存占用从峰值2.1GB降到了680MB。

说实话，之前我对这类工具的态度是"能帮点忙，但别指望它"。Gemini CLI上线第一天，我把它当备用工具用；第三天，我开始主动把一些边缘场景丢给它。不是因为它比Copilot强，而是它在命令行环境下处理本地文件的能力，以及它对多模态输入的无缝切换——日志文件、截图、代码片段，我都能直接拖进去。

另一个我没想到的点是它的缓存机制。默认配置下，Gemini CLI会把最近20轮对话的上下文缓存到本地.gemini-cache目录，大约占用300MB。对于处理大文件场景，这个缓存帮我省了不少token费用。我算了一笔账：之前用传统方式分析那个4.7GB日志，即使分段处理，按每段10000 token计费，单次调用成本约0.18美元；用Gemini CLI的本地文件读取能力，一次性分析完整日志，成本0.04美元。差距明显。

现在我把Gemini CLI加进了团队的日常工具链。不是替代谁，而是在特定场景下——比如日志分析、批量代码审查、以及那些需要本地文件上下文的任务——它比云端IDE插件更直接。上周我把它的配置写进了.bashrc，加了一个alias：glm='gemini --model gemini-2.0-flash --cache'。简单粗暴，但有效。

说到这儿，我想问问你们：你们团队现在用哪款AI编程工具处理日志分析？有没有遇到类似"工具很强，但场景不对"的尴尬？我在群里抛了这个问题，等你们的答案。

你在实际项目中有踩过类似的坑吗？或者有更好的解决方案？欢迎在评论区分享你的经验。