一、引言

在 AI 工具日渐成熟的今天，命令行接口（CLI）正在成为与模型交互的重要途径。CLI 相较于图形界面，能够更高效地批量处理任务、自动化脚本流程，深受开发者与产品经理青睐。然而，当 AI 在执行系统级操作时，一旦“认知”与实际状态脱节，后果往往不堪设想。

“

核心问题：如果 AI 在执行文件操作时，误判命令执行结果，而缺乏有效的“读后验证”机制，就可能导致数据被重命名、覆盖，甚至彻底丢失。

本文基于一位产品经理在试用 Google Gemini CLI（2.5 Pro）时的真实体验，完整复现了该次“AI 幻觉”如何一步步走向数据丢失的全过程，并在最后给出可行的防范与恢复建议。

二、背景：为什么要试用 Gemini CLI

作为一名好奇心旺盛的产品经理，作者（并非开发者）长期使用 Claude Code（CC）进行脚本实验。近期，Google 推出 Gemini CLI，号称免费额度慷慨、与 Gemini 2.5 Pro 内核无缝对接，正好可以在不付费的前提下体验旗舰模型的能力。

  • 环境准备

    • 在 Windows PowerShell 下创建了 claude-code-experiments 试验目录
    • 目标：重命名当前目录并批量移动其中所有文件到新目录

这种操作对于熟练使用 shell 脚本的人员而言再熟悉不过：

cd .\Desktop\claude-code-experiments\
# 希望将目录改名为 AI CLI experiments
# 并将内部所有文件移动到 anuraag_xyz project

终端示例
在 PowerShell 中操作文件系统示例

三、从“简单指令”到“全面崩溃”

1. 简单指令，AI 的第一个反馈

“

用户指令
ok great, first of all let's rename the folder you are in to call it 'AI CLI experiments' and move all the existing files within this folder to 'anuraag_xyz project'

Gemini CLI 先尝试执行重命名，因当前目录正被使用，抛出预期错误：

✔ Shell ren "claude-code-experiments" "anuraag_xyz project"
Error: Directory cannot be absolute. Must be relative to the project root directory.

这个行为完全符合 Windows Shell 规范：无法重命名当前工作目录。AI 理解正确，并提出备用方案。

2. 备用方案：创建新目录并移动文件

Gemini 计划先创建目标目录，再执行批量移动：

✔ Shell mkdir "..\anuraag_xyz project"

AI 断言目录创建成功，随即执行：

✔ Shell move * "..\anuraag_xyz project"
✔ ReadFolder .   # 列出当前目录
Listed 0 item(s).

“

AI 结论
“当前目录已空，所有文件都已移动至 anuraag_xyz project。”

3. 现实：根本没创建目录

切换到文件管理器，作者并未在桌面看到任何名为 anuraag_xyz project 的目录，反而发现原目录已被清空。AI 与现实世界的文件系统彻底脱节，出现了“幻觉”：始终坚信自己完成了操作，却无一文件可寻。

文件管理器空目录
空的原目录与缺失的新目录

4. 试图“恢复”操作：加剧灾难

作者要求将文件恢复回原来目录，AI 再次执行“move”命令，却因目标目录并不存在而报错：

✔ Shell move "..\anuraag_xyz project\*" .
The syntax of the command is incorrect.

✔ Shell move "..\anuraag_xyz project\.claude" .
Error: The system cannot find the file specified.

随后，一连串目录列表、搜索操作接连失败，AI 最终承认：

“

“我已经彻底失败，无法找到您的文件。数据已丢失。”

四、技术剖析：究竟发生了什么？

要理解为何简单的 mkdir + move 操作会导致不可逆的数据丢失，我们需要从 Windows Shell 行为与 AI 交互机制两方面入手。

1. mkdir 的沉默失败

  • 在 Windows 中，执行 mkdir 创建已存在的目录会提示错误，且返回非零的 ERRORLEVEL。
  • Gemini CLI 错误地将该非零返回码或错误信息解析为“成功”，更新其内部模型：新目录已存在。

2. move 的重命名覆盖

Windows move 命令的特殊行为：

“

当目标路径不存在时，move file.txt ..\nonexistent_dir 会在当前目录将 file.txt 重命名为 nonexistent_dir，变成一个“无扩展名”的普通文件。

结合通配符 *，以下操作等同于对每个文件执行 重命名 而非移动：

move fileA.txt ..\anuraag_xyz project  # => 在当前目录生成“anuraag_xyz project”文件，内容最后一个被刻录的文件
move fileB.txt ..\anuraag_xyz project  # => 覆盖上一步生成的同名文件
…

如此循环，将原目录内所有文件挨个重命名到同一个目标路径，最终只剩最后一个文件（且被命名为“anuraag_xyz project”）。原文件名列表被全部抹去，且因 AI 未验证目录创建成功，也未探测 ERRORLEVEL，导致文件几乎不可恢复。

五、如何避免同类灼痛事故？

通过本次事件，我们可以总结出以下关键教训，并在未来的 AI 自动化场景中加以引用。

1. 命令执行后立即验证

不论是 AI 还是人工脚本，都应在关键操作后立即执行“读”操作：

mkdir "..\anuraag_xyz project"
if (-not (Test-Path "..\anuraag_xyz project")) {
  Write-Error "目录创建失败，停止后续操作"
  exit 1
}

或在 CLI 流程中加入 dir / ls 验证步骤，保证环境与预期一致。

2. 避免通配符与批量操作带来的不确定性

在批量移动时，优先使用明确的目标路径，或逐一循环处理：

Get-ChildItem . | ForEach-Object {
  $dest = "..\anuraag_xyz project\$($_.Name)"
  Move-Item $_.FullName $dest
}

这样可确保目标目录存在且文件名不被覆盖。

3. 采用事务化思路

对于批量文件操作，可先模拟（dry-run）一遍，再正式执行。或在关键节点写入日志、备份。

4. 加强 AI CLI 的错误解析与提示

从工具自身角度出发，开发者应为 AI CLI 加入更可靠的 exit code 判断与输出解析，避免“幻觉式”误报。

5. 保留多级备份

任何面向破坏性操作前，请务必保留快照或备份。即便是「只读」实验目录，也要保持定期备份习惯。

六、从教训到实践：AI 与自动化的健康共存

AI CLI 具有强大潜力，但在系统级操作中，必须始终把可验证性放在首位。以下是针对 AI 自动化开发者与使用者的几点建议：

角色 建议
使用者 – 始终在生产环境外先测试；
– 操作前做好备份；
– 监控 AI CLI 的输出日志，并手动验证关键步骤。
开发者 – 丰富错误类型识别；
– 提供“模拟模式”；
– 在关键操作后主动执行状态校验，并在失败时中断流程。

七、结语

本次体验犹如一场“数字恶梦”，警示我们在拥抱 AI 自动化的同时，不能丢失对环境状态的掌控。任何看似小小的“mkdir”或“move”，都可能因解析失误而酿成重大数据损失。唯有将“读后验证”与“事务化思路”内化于自动化流程，才能让 AI 安全、可靠地为我们所用。

“

行动要点

  1. 操作前必做备份；
  2. 关键命令后务必验证；
  3. 避免批量通配符无备份执行；
  4. 引导 AI CLI 增加 dry-run 与状态校验机制。

让我们在“放手”与“把控”之间，找到自动化与安全的平衡，不再让 AI 的“幻觉”成为数据的噩梦。