把云服务器的日常运维交给 AI 助手之后，我踩的坑比过去一年加起来都多。这篇文章把它们整理成 12 条纪律——每一条背后都有一次真实的翻车。
为什么要让 AI 做运维
不是偷懒。真实原因是：服务器上有太多"一次性但记不住"的操作——改一行 nginx 配置、签一张证书、查一个端口通不通。这些事单看都简单，但上下文切换成本极高，而且做完就忘。
AI 助手的价值在于：它能读配置、看日志、跑命令、写文档，把这串动作串成一条可复现的流水线。但前提是——你得先教会它"不要怎么干"。
下面这 12 条，全部来自真实事故。
一、SSH 上了双因素之后，别硬刚
服务器开了 SSH 的 TOTP 双因素认证之后，任何非交互式的 ssh user@host "命令" 都会因为拿不到一次性验证码而失败。
解法：把远程执行切到云厂商的云助手（RunCommand）通道。它走的是控制台 API 而不是 SSH，天然绕开 2FA，也不必把私钥交给 AI。
安全提示：云助手同样是一把钥匙。务必确认调用权限只绑在你自己的 AccessKey 上，并且那个 AK 不是主账号。
二、多行脚本别硬塞进命令行
ssh host "for i in ...; do ...; done" 这种写法，一旦脚本里出现引号套引号、$ 变量、! 历史展开，就会直接进入转义地狱——你会花二十分钟调引号，而不是解决真正的问题。
解法：本地写脚本文件 → base64 编码 → 传输 → 远端解码执行：
B64=$(base64 -w0 deploy.sh)
remote-exec "echo $B64 | base64 -d > /tmp/deploy.sh && bash /tmp/deploy.sh"
base64 的字符集是 A-Za-z0-9+/=，不含任何 shell 元字符，绝对不会被二次解释。
三、探测公网端口，先确认你没走代理
这一条把我坑得最惨。本机装了代理或沙箱网络时，curl https://your-domain/ 可能返回一个假的 502——因为请求压根没出你的机器，是本地代理在瞎回。
解法：所有"验证公网可达性"的命令，一律加 --noproxy '*'：
curl --noproxy '*' -sI https://your-domain/
判断标准很简单：看返回的 remote_ip 是不是你服务器的真实 IP。
四、nginx -t 的退出码，不能被管道吃掉
下面这行看起来没问题，其实是个定时炸弹：
nginx -t | sed 's/^/ /' # 退出码是 sed 的，恒为 0
nginx -t 失败时，管道整体的退出码仍然是 0，后面的 systemctl reload nginx 照跑不误——于是你把一份坏配置真的 reload 上线了。
解法：先落盘，再判断：
nginx -t > /tmp/nginx-t.log 2>&1
if [ $? -ne 0 ]; then cat /tmp/nginx-t.log; exit 1; fi
五、reload 是异步的，验证要等两秒
systemctl reload nginx 返回成功，不代表新配置已经在服务新连接了。旧 worker 会在退出前继续处理一小段时间的请求。
我曾经因为"配置明明已经加载（nginx -T 里能看到），但 curl 却返回旧行为"而白排查一轮，最后发现是旧 worker 接走了我的请求。
解法：reload 之后 sleep 2 再验证。判断配置是否生效，用 nginx -T（打印合并后的完整配置），不要靠即时请求。
六、动手前先做"零改动探针"
要让 AI 改一个你没完全理解的配置或面板，先让它原样写回一遍，然后比对：
备份原文件 → 读取 → 原样写回 → diff 备份与新文件
如果 diff 为空，说明"读—改—写"这条链路是可靠的，可以放心改。如果 diff 有差异（常见于换行符、编码、字段顺序），先解决这个差异——否则你改 A 字段时可能顺手把 B 字段弄丢。
七、判断 DNS 生效，只认权威服务器
改完 DNS 记录后，在本机 nslookup 或 getent hosts 可能仍然返回旧 IP——那是中间缓存，不是权威答案。我曾经因此误判"用户没改干净"，白折腾半小时。
解法：直接问权威 NS：
dig +short your-domain.com @ns1.your-dns-provider.net
八、证书校验失败，先找"同源对照组"
openssl s_client 报 Verify return code: 20 (unable to get local issuer certificate) 时，先别急着修服务器。
拿一个已知工作正常的同类对象，在同一台机器、同一个 shell 里测一遍。如果它也报同样的错，那问题在观测端（比如本地 openssl 没有 CA bundle），不在服务器。
服务器证书链是否完整，用这个判断：
echo | openssl s_client -connect your-domain:443 -servername your-domain -showcerts 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
正常应该大于等于 2（站点证书 + 中间证书）。
九、危险操作，先备份再动手
改挂载、改数据库、删文件之前，一句话备份：
tar czf /root/backup-$(date +%F).tgz -C /root .target-dir
并且记住：docker stop 停容器不等于销毁容器。停掉之后数据仍在容器可写层里，还有救；docker compose down 才是真的把容器删了。
十、让 AI 先勘察，再动手
最坏的工作流是："用户说要 X → AI 直接改 → 出事"。
正确的工作流是：
- 读现状（配置文件、当前状态、日志）
- 复述问题（我理解你要的是 X，当前是 Y，差异在 Z）
- 给方案与代价（几个选项，各自的副作用）
- 动手 + 验证（改完立刻验证，不留"待观察"）
勘察看起来慢，其实是唯一快的方式。
十一、长任务放后台，别阻塞
签证书、拉镜像、跑全量扫描这类操作动辄几分钟。让 AI 阻塞等待，只会让对话超时、丢失中间输出。
解法：后台执行 + 完成通知，把"等待"变成"并发"。
十二、踩过的坑，必须写下来
这一条最重要。
AI 助手没有跨会话记忆。这次它花了三十分钟摸清"配置存在数据库而不是配置文件里"，下次它还会从头摸一遍——除非你把它写成文档或技能。
我的做法：每个项目维护一份 docs/ 记录"为什么这么做 + 踩过什么坑"，并把可复用的流程固化成脚本。一次踩坑，永久免疫。
小结
AI 做运维，最大的风险不是"它不会"，而是"它太快了"——快到在你反应过来之前，就已经把错误操作执行完了。
上面 12 条，本质上都在做同一件事：给速度加上刹车和仪表盘。先勘察、先备份、先验证、再动手；改完必验，验完必记。
把这套纪律跑顺之后，AI 运维的效率提升是数量级的——前提是你得先让它慢下来。