回头看给七亿批量远程管理工具加 SSH 运维 AI 助手那阵子，最难缠的一类 bug 不是把程序搞崩，是它卡在那儿，你还以为它在忙。

那阵子助手刚挂进工具：选一台 Linux 机器，模型通过 SSH 帮你干活，形态是「逐步执行」——它每轮只给一条命令（放 sh 代码块），客户端在服务器上跑，把真实回显喂回去，它再决定下一条。参考的是 FinalShell 那种边看真实结果边往下走的路子，不是一口气吐一屏命令让你自己贴。

有回老大甩来一张截图：助手连着说了三遍差不多的话，「还没搭好，先备份配置」。用户催它、换个说法再问，它还是这句。翻后台，那个该被备份的配置文件，连个 .bak 的影子都没有，任务原地打转了一整晚。

先说句实话：命令它生成得没错，是我们自己拦的。

我头一个反应是模型没听懂「先备份」，顺手往提示词里补了一句「动手之前务必先备份配置」。补完照旧卡。提示词管的是它怎么开口，管不了它开口之后那条命令能不能落地。

去翻执行链路才看明白。助手每轮生成的第一条，基本是「改前先备份」——cp -a /etc/3proxy.cfg /etc/3proxy.cfg.bak 这种。而更早的时候，我们加过一条「防误执行回滚」的规矩：怕它把备份文件盖回正式文件、来回翻烧饼。这条规矩的判定写得很粗，凡命令里带 cp 加 .bak 就拦。

于是「备份」和「回滚」在它眼里成了一回事。源是正式文件、目标是 .bak 的备份，拦；源是 .bak 的恢复，也拦——一刀下去，第一步就死在门口，永远迈不出去。它每轮都生成这条，每轮都被摁住，看着就像「它在说，可什么都没干」。

修法不复杂：把匹配收窄，只拦「源是备份文件」（源路径含 .bak）的恢复命令；「改前先备份」这种源是正式文件、目标是 .bak 的，放行。规则一拆细，任务当场就往下走了。

后来想，这种坑的共性就是懒。一条规则想管住所有情况，看着省事，其实是自己给自己下绊子——你为了防某个动作，顺手把旁边那个正经动作也摁死了。同一批规则里还逮着过一处同款：把「看看/查一下」一律判成「安全评估」，连只读的排查都不肯跑，也是一个模子刻出来的。助手这套命令怎么一步步走、遇事怎么确认，七亿批量远程管理工具的科普页里讲了个大概，我这边是被坑教明白的。

那台 3proxy 我后来还单独栽过一次，跟这条规则无关，是服务单元的事——systemd 的 Type=forking 缺了 daemon，进程一声不吭退掉，systemd 白等 90 秒。同样是「静默」，同样是看着卡死其实有明确根因。凑一块才慢慢记住：写规则、写配置，都得先问一句「这条会不会误伤旁边那个正常动作」——这句话我当初要是早点想到，能少熬大半夜。