用 AI 写运维自动化脚本，导致系统崩溃
许多新手运维喜欢用AI生成bash或Python脚本，一键完成备份、部署或清理任务。
但如果AI生成的代码存在隐藏bug或危险指令，轻则服务宕机，重则系统完全无法启动。
下面我结合真实案例，带你从准备到恢复完整走一遍。
准备一个安全的测试环境
千万不要在线上服务器直接跑AI写的脚本。
先用虚拟机或Docker容器模拟生产环境。
- 安装VirtualBox或VMware，创建一个最小CentOS 7/8或Ubuntu 20.04虚拟机。
- 如果熟悉Docker，运行一个基础容器：
docker run -it --name test-env centos:7 bash。 - 在测试环境里提前备份关键系统文件：
cp /etc/passwd /etc/passwd.bak、cp /etc/fstab /etc/fstab.bak。 - 记录当前进程和服务状态：
ps aux > /tmp/before.ps。
用AI生成一个“自动清理”脚本的危险测试
假设你让AI写一个“每周清理/tmp和日志文件的脚本”，AI可能输出类似下面的内容：
#!/bin/bash
find / -name "*.log" -type f 2>/dev/null | xargs rm -f
find /tmp -atime +1 -exec rm -rf {} \;这条命令的风险在于 find / -name 会扫描整个根目录，而且 rm -rf 后没有确认路径是否为空。
更致命的是，有些AI会生成 rm -rf / 或者 chmod -R 777 / 的片段。
分步操作：在安全环境中执行并观察
在测试环境里，不要直接运行整个脚本。
按照以下步骤拆解调试：
- 先查看脚本每个命令的详细说明：
man find、man xargs。 - 用
echo替换危险命令，先看会删除哪些文件：
find / -name "*.log" -type f 2>/dev/null | xargs echo "Would delete:"- 如果输出中包含
/var/log/syslog、/etc/logrotate.d/*.log等系统关键文件，说明脚本有误。需要加限定目录：
# 改成只清理 /var/log 下的日志
find /var/log -name "*.log" -type f -mtime +7 -exec rm -f {} \;- 在测试环境实际执行清理脚本后，立即检查系统完整性：
ls -la /etc/passwd /etc/fstab
df -h
systemctl status sshd- 如果发现文件丢失或服务异常，立刻从备份恢复：
cp /etc/passwd.bak /etc/passwd
cp /etc/fstab.bak /etc/fstab
reboot避坑指南：AI脚本最常见的四个致命错误
- 路径硬编码错误 – AI常把绝对路径写错，导致误删
/home/user而不是/home/user/temp。解决方法：在脚本开头用set -e和set -u，并添加路径合法性检查：
[ -d "$TARGET_DIR" ] || { echo "目录不存在，退出"; exit 1; }- 危险组合命令 – 如
find ... | xargs rm -rf没有-print0和-0处理空格文件名，遇空格会误删文件。建议：使用find ... -exec rm {} +代替管道。 - 缺少确认步骤 – 直接
rm -rf不加交互参数。新手习惯：先加-i或--interactive多次确认，正式上线再移除。 - 权限提升陷阱 – AI可能在脚本开头加
sudo甚至提权到root执行，任何错误都会影响全局。原则：用最小权限运行脚本，使用sudo -u www-data降权。
效果验证：如何确认脚本现在是安全的
将修改后的脚本应用到正式环境前，务必完成三步验证：
- dry-run 测试：在真实服务器上先用
sh -n script.sh检查语法，再用bash -x script.sh 2>&1 | grep -E "(rm|del|chmod)"查看危险操作。 - 回滚测试：在测试环境故意执行脚本，然后运行你自己写的回滚脚本，验证能否恢复原状。
- 持续监控：上线后查看系统日志
/var/log/messages或使用auditd监控关键文件变化：
auditctl -w /etc -p wa -k etc_changes
ausearch -k etc_changes -ts recent如果你已经因为AI写的自动化脚本导致系统崩溃，首先立即断开服务器网络，然后通过救援模式恢复备份。
之后再按照本文的步骤重新处理脚本。
记住：AI是提速工具，不是信任源。测试通过才算安全。
