那阵子我在给「七亿批量远程管理工具」（RdpManager）里的 SSH 运维 AI 助手补规矩，一条接一条，越补越多。回头看，最坑的那条不是我漏拦了什么危险命令，恰恰相反——是我拦太多，把它自己最正经的第一步给拦死了。

先说这助手怎么干活。我给它定的方式是"逐步执行"：AI 一次只出一条命令，客户端在服务器上跑完，把真实回显喂回去，它再决定下一条。那天我让它在这台 Linux 机上装个 3proxy 代理，账号密码我在对话里给它，省得自己一条条敲。

结果它卡住了。

对话停在一行上：

还没搭好，先备份配置。

我催"继续"，它还是这句。再催，还是这句。来回好几趟，任务一点没动，那个账号密码我到现在也没拿到。来回折腾半天，人有点烦。

一开始我怀疑是确认框没弹出来、在等我点——翻了遍窗口，没有。又怀疑网络断了、回显没回来。可回显是空的，命令像是压根没发出去。最离谱的是，什么错误都没有，没有报错，没有日志，就那么静静地卡在那儿。

后来才反应过来，问题出在我前一阵子加的一条规矩上。

之前踩过个坑：这助手有时会把备份文件又 cp 回去，来回翻烧饼，把好好的配置盖坏。于是我给"生成命令"加了一道过滤，防它误执行回滚——只要一条命令里带 cp … .bak，就拦下来不让跑。

写得挺顺手，判得也够粗。它第一步"改前先备份"是条 cp -a /etc/3proxy.cfg /etc/3proxy.cfg.bak——备份文件在目标，不在源；可我的规则只看命令里有没有 .bak，有就拦。于是"备份"这步被我当成"回滚"给毙了。备份没跑，它就觉得前提没满足，一条命令都不肯往下走。任务当然原地打转。

修法不复杂：过滤改成只拦"源是备份文件"的恢复命令——就是 cp 的源路径里含 .bak 才算回滚（cp /etc/3proxy.cfg.bak /etc/3proxy.cfg 这种）；"改前先备份"源是正式文件、目标才是 .bak，放行。

改完再试，它顺顺当当把配置备份了、装好、起了服务，前后不到十分钟。就为这一条粗规则，我磨了快一个钟头。

回头看，教训不在"要不要拦"，在"规则得按场景拆细"。一刀切的规则看着省事，实际两头不讨好：拦松了危险动作混进来，拦紧了连正经步骤都跑不动。而且"拦太紧"这种故障特别阴，因为命令不报错、没输出，任务就那么卡着，你会先怀疑网络、怀疑模型、怀疑一堆有的没的，最后才想到是自己写的规则在咬自己。想知道这助手该装哪、怎么配，官网上有个七亿批量远程管理工具的教程，比我在这儿讲得全。

这其实是我第二次栽在"规则太粗"上。之前还有一回，我在另一篇里写过——AI 助手的命令闸门，我当时砸了四轮才敢信它。两码事，毛病是同一种：总想用一条简单规则盖住复杂场景，结果规则反过来咬手指。

那阵子一天从 V95 改到 V113，十几个版本，大半都在补这种自己给自己使的绊子。七亿批量远程管理工具里这个 AI 助手，真不是"配"出来的，是一条条规则、一个个反例磨出来的。改完这条我顺手把过滤规则又过了一遍，果然又揪出两条判得同样粗的——得，接着改。