用 AI 写 Shell 脚本，导致服务器文件系统损坏

为什么 AI 生成的脚本可能毁掉你的文件系统

最近有位读者反馈，用 ChatGPT 写了一个磁盘清理脚本，直接执行后服务器无法启动。
拆解脚本发现，里面有一条 rm -rf /data / 的写法（注意空格），等于把根目录也删除了。AI 生成 Shell 脚本时，会按字面理解你的需求，不会像人一样自动避开危险路径。
如果你的需求表述模糊（比如“清理目录”），AI 可能写出 rm -rf /some/path/ 这种带空格或绝对路径的代码，一旦在错误位置执行，文件系统说坏就坏。

前置准备：建立安全屏障

在让 AI 写脚本之前，请先做好三件事：

• 准备一台测试服务器（本地虚拟机或云厂商的临时实例），永远不要在线上环境直接测试新脚本。
• 启用备份机制：对重要数据使用快照或 rsync 定期备份。即使脚本出错，也能回滚。
• 给脚本添加“保险丝”：在脚本开头加一行 set -e（遇到错误即退出）和 set -u（使用未定义变量时报错），减少意外执行。

分步操作：让 AI 安全生成 Shell 脚本

步骤1：用精确语言描述需求

给 AI 的提示词要具体到“做什么、在哪个目录、用什么命令”。

错误示例：写一个清理日志的脚本。
正确示例：写一个 Shell 脚本，删除 /var/log/myapp/ 目录下超过 7 天的 .log 文件，使用 find 命令，先打印再删除。

附加要求：“每条命令前加 echo 预览要执行的动作”，“禁止使用 rm -rf / 或 sudo”。

步骤2：剥离危险操作

让 AI 在脚本中内置安全检测逻辑。
在提示词中加入：

• 在删除前检查目标目录是否为空或根目录。
• 使用 [ "$TARGET" != "/" ] || exit 1 阻止删除根。
• 使用 -exec rm {} \; 替代 xargs rm，更可控。

步骤3：执行前逐行审查

将 AI 生成的脚本复制到本地，用 cat -n script.sh 查看每行。
重点关注：

• 绝对路径中的空格（如 / myfile 会导致删除 /）。
• 通配符使用不当（如 rm -rf * 如果在错误目录）。
• 挂载、格式化、dd 等高风险命令。

步骤4：在测试环境分步验证

先在测试机运行 bash -x script.sh（打印每条命令和参数），观察输出路径是否正确。

bash -x script.sh

确认无误后，再注释掉 set -e 或 exit 部分，用 dry-run 模式（如果脚本支持）测试一遍。

避坑指南：这些 AI 脚本特征要格外警惕

1. 过度使用绝对路径：AI 倾向写死路径，如 /home/user/temp。如果你把脚本复制到另一台服务器，可能指向不存在或不同含义的目录。
2. 忽略变量未定义：如果变量 $LOG_DIR 没赋值，rm -rf $LOG_DIR/ 会变成 rm -rf /（因为空变量拼接成斜杠）。务必开启 set -u。
3. sudo 滥用：AI 可能直接写 sudo rm -rf /var/log，如果你以 root 执行，普通用户无 sudo 权限；但若以 root 执行，则不需要 sudo，反而会因 sudo 参数导致逻辑混乱。建议脚本不包含 sudo，由执行者手动提权。
4. 无确认步骤：AI 默认只做不询问。养成添加 read -p "确认执行？(y/n)" confirm 的习惯。

效果验证：如何确认脚本没有损坏文件系统

执行完 AI 生成的脚本后，用以下命令快速检查文件系统完整性：

# 检查根目录挂载点是否正常
df -h /

# 检查关键目录是否存在
test -d /etc && echo "etc 正常"

# 检查系统日志是否有异常文件系统错误
dmesg | grep -i "error\|corrupt"

如果一切正常，再执行 cat /etc/passwd 等常见命令确认基础服务可用。
最后用 uptime 和 ss -tlnp 确认 SSH 等关键进程仍在运行。

---

高频问题解答

Q：AI 写出的脚本里有 rm -rf /，我该怎么快速发现？
A：在审查阶段用 grep -n 'rm.*-rf.*/' script.sh 搜索所有 rm 命令，尤其注意是否有空格隔离的 /。

Q：已经执行的脚本导致了文件系统损坏，怎么办？
A：立即停止所有写入操作，如果配置文件还在，尝试单用户模式挂载为只读，然后用 fsck 修复。备份优先恢复。

Q：能否让 AI 自动添加安全检查？
A：可以。在提示词中写明：“请在每个可能破坏文件系统的命令前添加目录存在性检查，并拒绝执行 rm -rf /”。但最终仍需人工复核。

---

如果你正在处理用 AI 写 Shell 脚本，导致服务器文件系统损坏的问题，建议先按本文步骤完整执行，再根据自己的环境做微调；
遇到异常时优先回看避坑和高频问题部分。
安全脚本的底线永远是测试、审查、再执行。