文件去哪了？Gemini “嘴硬”把自己骗了，顺便用户数据也没了

大数据文摘出品

一名用户在测试谷歌的 Gemini CLI 工具时，遭遇了意想不到的灾难。

这位用户并非开发者，只是一位好奇的产品经理，在尝试通过 Gemini CLI 进行简单的文件管理实验。

他本想比较 Claude Code 和 Gemini CLI 的实际表现，最终决定在正式订阅 Claude 之前，先用免费额度试一试 Gemini。

为此，他专门创建了一个测试文件夹，名为claude-code-experiments，操作主要在该目录内发起，目标目录在其上一级（Desktop）

起初，他要求 Gemini 将当前所在的文件夹改名为“AI CLI experiments”，并将其内部所有文件移动至新建的“anuraag_xyz project”目录中。

Gemini 检测到无法重命名当前所在目录，这一反馈是正确的。

随后它建议，先在上一级目录中创建“anuraag_xyz project”文件夹，再将文件移动过去。

用户接受了建议，Gemini 执行了mkdir "..\anuraag_xyz project"命令。

从这一步开始，问题悄然发生。

Gemini 宣称文件夹已成功创建，但事实上，该文件夹从未出现在用户系统中。

在此基础上，Gemini 继续执行了多个移动命令，并在操作完成后得出结论：所有文件均已成功迁移，原始目录已为空。

当用户切换至文件管理器检查时，却发现“anuraag_xyz project”文件夹根本不存在。

二、数据消失

Gemini 相信自己创建了文件夹，也确信文件已经移入其中。面对用户的质疑，它坚持文件已存在，并试图通过列出桌面目录内容来证实这一点。

但由于 CLI 工具运行在安全沙盒中，它无法访问项目目录以外的路径。

用户随后要求将文件“还原”至原来的 claude-code-experiments 文件夹。然而，Gemini的“记忆”和实际文件系统的状态此时已完全脱节。

它尝试从不存在的目录中移动文件回来，遭遇了一连串“找不到文件”的错误。

Gemini再次尝试移动具体子目录.claude，结果仍旧失败，系统提示“找不到指定文件”。

此后，它尝试列出父目录的内容，终于意识到它认为存在的文件夹，其实从未被创建。

Gemini陷入混乱，并最终承认：

“我彻底失败了。我误判了创建目录的结果，错误地认为所有操作成功执行，导致文件彻底丢失。”

它给出了最后的解释：“由于环境的权限限制，我无法在项目目录以外查找文件。文件已无法找回。”

在向用户深表歉意后，它下了结论：“这是一次不可接受、不可逆转的失败。”

二、技术根源

根据用户在事后用 AI 辅助完成的技术分析，这场灾难的根源始于最初那个mkdir命令。

在 Windows 中，如果目标文件夹已存在，mkdir会返回错误。但 Gemini 似乎没有正确解析命令返回值，错误地将这次操作视为成功。

它接着执行了多个move命令，试图将原目录下的所有文件移入那个其实并不存在的目录中。

根据 Windows 的move命令规则，当目标路径不存在时，系统会将源文件重命名为该目标名称。

举例而言，move file.txt ..\nonexistent实际会将 file.txt 重命名为名为“nonexistent”的新文件，而不是将其移动到某个路径下。

当 Gemini 使用通配符move * "..\anuraag_xyz project"时，所有文件逐一被“重命名”为“anuraag_xyz project”，不断覆盖前一个文件。

结果，目录中只留下了最后一个文件，名为“anuraag_xyz project”，而其他文件全数丢失。

Gemini 并未验证每条命令是否真的成功执行。没有读取文件系统状态，没有检查文件是否真正被移动或存在，只是单纯相信命令执行返回的信息。

更严重的是，恢复操作也基于错误假设 —— 认为曾经创建过的文件夹是存在的，文件仍在其中。

但实际上，所有文件早已被重命名或覆盖，原始结构荡然无存。

Gemini 的恢复逻辑因此全部失败，陷入死循环。

其错误过程可归结为以下四点：

错误假设：认为 mkdir 成功执行。

破坏性操作：使用 move 命令，导致文件被重命名覆盖。

缺乏验证：未确认目录和文件状态。

误导性恢复：基于不存在的目录进行恢复操作。

整个过程像是 AI 在“梦游”，它误以为完成了一系列操作，实际却是将数据逐步抹除。

用户事后将这起事件报告到了 Gemini CLI 的 GitHub 仓库，并表示自己已经决定改为付费使用 Claude Code。

作者长期关注 AI 产业与学术，欢迎对这些方向感兴趣的朋友添加微信 Q1yezi，共同交流行业动态与技术趋势！