用 AI 写 Shell 脚本，导致服务器文件被误删
现在很多朋友喜欢用ChatGPT这类AI工具生成Shell脚本，效率确实高，但也容易埋坑——最常见的翻车就是脚本里的rm -rf直接删掉了重要文件。
本文会带你一步步搞明白：怎么安全地让AI帮你写脚本，万一不小心误删了又该怎么救。
第一步：写脚本前先做好两件事
用AI生成脚本之前，先把防线搭好。
- 备份当前目录：在运行任何新脚本前，先把可能被影响的目录快照一份。
cp -r /目标目录 /目标目录_backup_$(date +%Y%m%d)这样就算脚本把原目录清空了，你也有完整备份可以直接恢复。
- 创建测试专用目录：不要直接在业务目录里试脚本。新建一个
/tmp/test_script文件夹，在里面放几个测试文件，先跑一遍。
mkdir /tmp/test_script && cd /tmp/test_script
touch test1.txt test2.txt # 创建虚拟文件第二步：让AI帮你写“安全版”脚本
给AI的提示词里加上“安全约束”，能大幅降低翻车率。
你可以这样写：
“请生成一个Shell脚本，功能是列出/var/log下7天前的日志并提示删除。要求：删除前必须询问用户确认，使用rm -i选项，并记录操作日志到/var/log/script.log。”
AI生成的代码里通常会带rm -i，但你自己也要检查一遍。
核心的防误删写法如下：
- 始终启用
-i交互确认：关键命令如rm、mv后面加-i，每删一个文件都会让你按y确认。 - 用
trash-cli替代rm：先安装trash-put工具，然后把删除命令改成trash-put 文件。被删的文件会进入回收站，能轻松恢复。
# 安装trash-cli（Ubuntu/Debian）
sudo apt install trash-cli
# 在脚本中使用trash-put代替rm
trash-put /tmp/test_script/*- 绝对不要用
rm -rf /：如果AI脚本里出现这样的命令，百分百是坑。建议在脚本开头加一行检查：
if [ "$#" -eq 0 ] || [ "$1" == "/" ]; then
echo "危险！不能删除根目录！" >&2
exit 1
fi第三步：误删后别慌，立刻停止写操作
如果你已经在服务器上跑了一个带rm -rf的脚本，发现文件不见了，第一步就是拔网线或停掉磁盘写入。
然后根据有无备份选择恢复方式。
- 有备份：直接拷贝备份回来即可。
cp -r /目标目录_backup_20250301 /目标目录- 无备份：使用
extundelete工具恢复（仅限ext系列文件系统）。立即卸载被删文件所在的分区（例如/dev/sda1），避免数据被覆盖。
umount /dev/sda1 # 卸载分区
sudo extundelete /dev/sda1 --restore-directory /路径 # 恢复指定目录恢复出来的文件会放在RECOVERED_FILES文件夹里。
注意：extundelete不一定百分百成功，所以预防远胜于恢复。
第四步：验证脚本是否安全（零基础自查清单）
每次用AI生成脚本后，按下面的清单跑一次再正式执行：
- 打开脚本，搜索
rm、mv、dd、>（重定向覆盖）、chmod等危险命令。 - 在测试目录（
/tmp/test_script）里先执行一遍，观察是否有文件被误删。 - 使用
bash -x 脚本名.sh运行，逐行查看执行了什么操作。 - 检查脚本是否有判断参数的逻辑，是否对路径变量做了空值保护。例如：
# 错误示范：变量可能为空，导致 rm -rf /
rm -rf /$TARGET
# 正确写法：先判空，再使用
if [ -z "$TARGET" ]; then exit 1; fi
rm -rf "$TARGET"避坑高频问答
Q：AI写的脚本里有rm -rf *，我在当前目录跑会不会删掉自己？
A：会的。永远在测试目录里先跑，或者给rm加上-i选项。
Q：没有备份，误删数据库文件还能救吗？
A：如果文件系统还在且没被覆盖，可以用extundelete或testdisk尝试恢复，但数据库一般需要从主从库或冷备恢复，不要指望救回。
Q：trash-cli恢复命令是什么？
A：使用trash-list查看回收站列表，trash-restore交互式恢复。
总结
用AI写Shell脚本本身没错，错在缺少安全习惯。
记住三个原则：① 始终先备份后测试；
② 给AI提示词加上安全约束；
③ 用trash-cli或rm -i替换裸删。 如果你已经遇到了误删，立即停止写入，用备份或恢复工具抢救。
希望这篇指南能帮你从“翻车现场”稳回来。
