AI 生成的清理 USB 设备脚本导致硬盘数据丢失的教训

刚刚指挥 AI 帮我写一个清理挂载 usb 设备的 linux 脚本，执行完脚本发现日志不对劲，直接把我硬盘给清空了

本意是想让AI优化 cleanup_mounts 函数。

最终给的代码结果是：
cleanup_mounts() {
log "开始清理挂载点..."

＃确保 MOUNT_BASE 存在且非空
if [ -z "$MOUNT_BASE" ] || [ "$MOUNT_BASE" = "/" ]; then
log "错误：挂载基础目录未定义或无效"
return 1
}

local mounted_usb=$(findmnt -n -t fuseblk,vfat,ntfs,exfat,ext4 -o TARGET | grep "^$MOUNT_BASE/")

if [ -z "$mounted_usb" ]; then
log "没有找到需要清理的挂载点"
else
for mount_point in $mounted_usb; do
log "正在处理挂载点: $mount_point"

＃先尝试安全卸载
if umount -l "$mount_point" 2>/dev/null; then
log "成功安全卸载 $mount_point"
continue
fi

local using_pids=$(fuser -m "$mount_point" 2>/dev/null)
if [ -n "$using_pids" ]; then
log "发现正在使用此挂载点的进程: $using_pids"
log "正在终止这些进程..."

＃先发送 SIGTERM 信号
fuser -k -TERM -m "$mount_point" >/dev/null 2>&1
sleep 2

if fuser -m "$mount_point" >/dev/null 2>&1; then
log "使用 SIGKILL 强制终止进程"
fuser -k -KILL -m "$mount_point" >/dev/null 2>&1
sleep 1
fi
fi

＃最后尝试强制卸载
if umount -f "$mount_point" 2>/dev/null; then
log "成功强制卸载 $mount_point"
else
log "警告：无法卸载 $mount_point"
fi
done
fi

＃清理所有遗留的挂载点目录
find "$MOUNT_BASE" -mindepth 1 -maxdepth 1 -type d -exec rm -rf {} \;

＃重建并设置正确的权限
mkdir -p "$MOUNT_BASE"
chmod 777 "$MOUNT_BASE"
chown "$SMB_USER:$SMB_GROUP" "$MOUNT_BASE"

＃重启 Samba 服务以确保共享正常
systemctl restart smbd nmbd

}

执行脚本后反馈的日志：

root@armbian:~＃ sudo /usr/local/bin/usb-mount.sh cleanup
开始清理挂载点...
没有找到需要清理的挂载点
清理遗留目录...
rm: cannot remove '/mnt/usb/0005C423000F6D5D/Apps/iOS': Directory not empty
rm: cannot remove '/mnt/usb/0005C423000F6D5D/Books': Directory not empty
rm: cannot remove '/mnt/usb/0005C423000F6D5D/Movies/Assassination.2015.BluRay.iPad.1080p.AAC.x264-LHD': Directory not empty
重建挂载基础目录...
重启 Samba 服务...
清理操作完成

论测试的重要性

笑死了

哈哈，是你提问的方式不对，还是 AI 被污染了

自己手动，显示隐藏设备，手动删除灰色的设备项。

拿到脚本不检查内容直接运行是这样的。

你如果直接在论坛找人要脚本，结果也是这样。

请谨慎使用代码 —— 来自 Gemini 的提醒

"清理挂载 usb 设备的 linux 脚本"

你就说清没清理吧 🤪

对 AI 用词要准确
要么用“移除没有挂载的”，要么用“整理”，“清理”是多涵义的
不久前曾说过，“自从用了 AI ，就知道语文的重要性了”，V 友答：“英语也是”

真把 AI 当懒人良药了？？？

AI 只是一个怎么逗你开心怎么说话的策略工具而已。。。
现在把 AI 当谷歌，当一言九鼎，这已经是歪楼了。

还是懒作怪啊，更不需要自己担责，怎么也不想一下是自己敲的回车

测试不是让你生成了直接就运行。。是把命令改成 print 。。确定没问题再改成真实命令。。。

不意外，ai 很多时候写的是非常离谱的，自己不检查那肯定要吃亏的。

我觉得这个例子给当今职场拿着 ai 结果当论据的人一个典范

要不分享一下脚本看看👀

太相信 Ai 了吧

我猜是清理文件系统、块设备格式化之类的命令，直接怼到了系统盘上，然后还加了 sudo。

笑死，竟然真的有人完全相信 AI ，AI 就是一个生成系统，说白了就是字符串随机拼接，完全没有验证过的

所以楼主是如何提问的？ AI 是怎么回答的？

AI 出错之后谁负责和 AI 本身准确度是两个问题
当前 AI 公司都是免责型服务，你随便用，用了后果自负 /t/1082532
—— 也就是说，你可以调教 AI 让它对你更好用，其实用户本身成了一个免费调试员。对于这部分工作量，你的调教实际上贡献到 bot 更智能了，所以理论上 OpenAI 应该付钱给你 / 至少弥补一下你的损失

生成完你再让他解释一下脚本

如何提问和 AI 给出的代码已经发上来了

这段时间在写一个平台, 深刻体会到 AI 根本不是万能的, 也代替不了人, 写个函数还行, 写个大点的功能就不行了.

所以 AI 很容易搞出这种似是而非的代码，不过我吃过最大的亏就是似是而非的代码导致长达半小时的 debug 。

不过要是想要清理挂载点盖住的文件，完全可以考虑先 unshare -m ，然后把挂载点卸了（这时候就不用考虑卸载不掉的那种情况了），然后删除文件就行了。

该，谁让 op 不检查代码的？

可能出问题的地方太多了，比如直接上来就有 findmnt 来找挂载点，但是 findmnt 输出是带树状结构的，然后 grep 的结果直接就 for-loop ，这样子要是路径有空格也会出问题

然后前前后后就导致该卸载的卸载点没卸载掉，然后就把盘里面的文件干掉了

太赞了

用靠谱一点的，看不出来你这是哪家的，一般 claude 3.5 和 GPT 的最新模型，一般没这类问题。最重要的是你要懂代码啦

＃27 另外就是我会用一个 AI 的结果到另一个 AI 那里去验证和询问。

是这样的，和楼主无关，每次看到有人说 ai 取代程序员的我都心想但凡能看懂一点代码都说不出这话

cursor 里选择的是 claude-3.5-sonnet

ai 给的代码一定要测试啊.

哈哈哈哈

合速度

AI 生成的清理 USB 设备脚本导致硬盘数据丢失的教训

近期文章

热门推荐