给部署脚本加上幂等校验，AI 帮我写代码少踩了一半的坑
背景
站点的部署脚本是几个月前我让 AI 帮我写的，前后端分离，每次发版要跑构建、同步静态文件、重启服务。刚开始挺顺，AI 生成的 shell 脚本一次就能跑通。但用了两周，问题开始露头：脚本重跑一次就出错，服务起不来，搞得我有点不敢让 AI 接手部署这类"会动真格"的活。
做法
我没有直接让 AI 重写脚本，而是先把脚本的每个步骤拆出来，删掉以后发现真正难的是两点：一是上传静态文件时用了强制覆盖，断了网络会导致文件只传了一半；二是启动服务前没有检查旧进程到底停没停干净，端口冲突很常见。我把这两点明确告诉 AI，要求它给每一步加上"可重跑"的校验：先检查再执行，执行后立即验证结果。比如同步文件前先比对远端 md5，不一致就重传；重启前先检查端口是否被占用，被占用就强制踢掉旧进程再启动。
遇到的坑
第一个坑是我自己写的校验太弱。一开始我让 AI 只加日志，试试重跑，结果日志看着正常但服务还是挂了。查了半天发现是只校验了"命令退出码为 0"，没校验"命令的最终结果是不是我们想要的"。比如 rsync 退出 0 不代表文件真的同步全了。后来改成"退出码 + 结果双重校验"，才真正兜住。第二个坑是踢旧进程的命令写得太粗暴，直接把整个进程树都杀了，连带把不该杀的后台任务也干掉了。改成只按端口号精确定位再杀，才算安全。
关键结论
现在我让 AI 写任何部署相关代码，都强制带三个要求：第一步先想清楚"这个脚本重复跑会不会出问题"，第二步每步执行后有个看得见的结果校验，第三步破坏性操作（删文件、杀进程）必须精确到具体对象。这套习惯救了我好几次，上周一次线上误操作把服务搞挂了，我就靠这个脚本自动回滚，五分钟内恢复了。如果你也在用 AI 写运维脚本，先别急着让它写新功能，把幂等和校验这两个基本盘打牢，收益比大得多。
