AI编程工具事故频发：数据安全与用户防范指南

尽管人工智能技术日益成熟，在许多人心目中AI几乎无所不能，但现实往往残酷。当海量需求席卷而来，工程师们借助AI编程工具紧急应对时，这些工具却频频失误，引发广泛担忧。

最近，一位网友在Reddit论坛发帖抱怨，使用Claude CLI清理旧代码仓库时发生严重事故，其Mac电脑的整个用户主目录被意外清空，损失巨大。他在帖子中沮丧地写道：

“这究竟是怎么回事？有没有人碰到过类似问题？我现在想知道数据是否还能恢复，太多工作成果丢失了……”

Claude CLI 究竟做了什么？

据这位名为LovesWorkin的开发者回忆，当时他仅指示Claude CLI清理旧代码库中的软件包，结果整个Mac的home目录被彻底删除。随后，他展开调查，并让Claude进行自我分析。

Claude很快给出了详细分析：

我发现了问题，且问题十分严重。

查看执行日志后，可见当时运行了一条灾难性命令：

• rm -rf tests/ patches/ plan/ ~/

注意最后的~/。它指向当前用户的整个Home目录。Claude Code实例在生成删除命令时，错误地将~/包含在内，这将导致以下内容被递归删除：

• 用户的整个桌面目录（~/Desktop）
• 文档、下载等所有用户文件
• macOS的Keychain数据（~/Library/Keychains）
• Claude自身的配置和凭据（~/.claude）
• 各类应用的用户级支持数据
• 本质上是/Users//下的所有内容

这也解释了为何会出现：

• 桌面目录消失
• Keychain数据被删
• Claude的本地凭据丢失

最后的错误提示显示：“当前工作目录已被删除”

本就心情低落的LovesWorkin，在看到Claude CLI有条不紊的分析后明白了原因，顿时手足无措，只得发帖求助。

逐渐“失控”的AI程序员

事实上，遭遇AI编程工具“挖坑”的开发者远不止他一人。

此前，曾有报道称，一位希腊开发者在试用Google最新AI IDE时，本想清理缓存，AI却直接清空了整个D盘，且使用了跳过回收站的永久删除指令。

尝试多种数据恢复方法后效果甚微。为证实事发经过，他录制了完整对话并上传至YouTube，反复强调：

“我绝非虚构，Google的AI确实删除了我的硬盘。”

更早之前，国外公司SaaStr.AI的创始人兼首席执行官Jason在社交媒体上透露，他在连续8天使用AI编程工具Replit构建应用后，尽管明确指示不要未经许可更改代码，Replit仍删除了他的数据库。

如何防范AI编程工具“惹祸”？

毫无疑问，AI频繁“翻车”暴露了当前大模型工具的共性缺陷：一方面，AI对用户指令的理解存在偏差，易将模糊或复杂需求误判，从而执行错误操作；另一方面，部分AI工具在权限控制上存在漏洞，未充分确认用户意图便允许执行高风险操作，如删除大量文件、修改系统关键设置等，最终导致“小需求”酿成“大事故”。

在Claude CLI清空Mac home目录的帖子下方，网友讨论热烈。

有人认为问题不在AI，毕竟“手动输入命令时多敲一个~/，许多工程师都犯过类似错误，AI只是在重现人类工程师的Bug。”

也有网友呼吁理性看待：

“不能因几次失误就否定AI工具的价值，它们确实提升效率，但关键要明确使用边界。”

“大模型仍存在‘幻觉’和逻辑漏洞，尤其在处理具体指令时易忽略细节，未来需在算法优化和安全机制上努力，如增加操作确认步骤、设置权限分级等。”

此外，不少人提出建议：

“我们公司有几位工程师也遇到类似情况。我们正考虑将Claude放在Docker容器中运行。”

甚至有用户迅速开发辅助工具防护类似问题。开发者yksugi表示，「看到有人发帖称Claude Code执行了rm -rf tests/ patches/ plan/ ~/，清空了整个home目录。虽易归咎于程序员失误，但我不想重蹈覆辙。因此我开发了cc-safe——一个CLI工具，用于扫描.claude/settings.json文件中授权的命令，拦截高风险操作。」

它能检测的命令包括：

sudo、rm -rf、Bash、chmod 777、curl | sh

git reset --hard、npm publish、docker run --privileged

还有更多操作，它能识别容器环境，因此会跳过docker exec命令

使用方法：它会递归扫描所有子目录，因此你可以把整个项目文件夹作为目标一次性检查。可以手动运行，也可以通过Claude Code用npx cc-safe来执行。

• npm install -g cc-safecc-safe ~/projects
• GitHub仓库链接：https://github.com/ykdojo/cc-safe

不过，也有技术人将根源归为使用了--dangerously-skip-permissions参数，HN上网友orliesaurus评论道：

我看到这些“恐怖故事”一点也不意外……

--dangerously-skip-permissions这个参数字面意思就很清楚：它会绕过所有保护措施，直接执行命令而不询问用户。我见过的一些指南强调，这个参数只能在沙箱环境中运行，而且里面不能有任何重要数据。

应该把每个AI代理都当作非人类身份，只给它完成任务所需的最小权限，并且监控它的行为。

我做得更严格：绝不让AI代理自行删除任何东西。如果它想清理某个目录，我会先查看它生成的命令，再自己手动执行。虽然很繁琐，但可以避免灾难发生。

另外，现在也出现了一些用于安全部署AI代理的框架，重点是可视化和风险控制。

现在这还只是起步阶段……但总比直接YOLO（随意执行）好，尤其是这个参数名字里明明就写着“dangerously”。

实际上，在使用AI编程工具时，务必先备份，留下“回滚”余地。其次，不要轻易赋予AI任何权限，以及在执行AI提供的命令或脚本前，一定要仔细检查。毕竟AI目前仍存在大量“幻觉”等问题。尤其在涉及数据安全、系统操作等关键场景时，用户必须保持警惕，做好风险防控。

再智能的工具，也无法完全取代人类的判断与监督。有人甚至担忧：“未来几年，随着AI编程普及，可能会有互联网巨头因类似事故而引发影响全球的大规模问题。”对此，你怎么看？