这位用户并非开发者，只是一位好奇的产品经理，在尝试通过 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。
