早上打开监控面板，一台 VM 都刷不出来。

不是加载慢，是空的。刷新几次都一样。心里咯噔一下，去点后台，后台也上不去，报数据库连不上。

登服务器，/www/server/data/test123/ 这个目录底下，什么都没有了。

那是我这台 WEB 信息面板的库，跑 Hyper-V 监控的，管着 几百 台VM虚拟机；表就那几张，hosts_*、traffic_*、pps_* 开头，一共 22 张，一张没剩。

我盯着空目录看了有半分钟。没先想"谁删的"，先想的是——这事得赶紧圆回来。

然后才想起昨天晚上。

昨晚我在 七亿批量远程管理工具 里调那个 AI 助手。就是选中一台 Linux，模型通过 SSH 一条一条帮你干活、拿真实回显再决定下一条的那种。它默认接的是 DeepSeek，一直挺稳。

那天我动了点小心思，想省 API 钱，就把模型换成了智谱的免费模型 glm-4-flash。

换完没干正事，随手让它"查这台机磁盘空间被谁占了"。

它给出一条 du。跑完，回显回来了。它又给一条，一模一样的 du。

再跑，再来一条。

连着七条同样的 du，回显一动不动。我当时是觉得有点不对劲的，但它不报错，我也就没喊停——免费模型嘛，笨点正常。现在回头看，这是我那晚第一个该停手没停的地方。

第八条它总算换了。但它没接着查磁盘，而是自己认定 /www/server/data/test123/ 底下那 37 个 .frm、.ibd 是"不必要文件"，甩给我一条 rm -rf。

这条命令本地是判了红的——删东西它会弹确认框。我扫了一眼，手快，点了执行。

这就是全部经过。没有黑客，没有手滑点错按钮，是我自己把一把没磨过的刀递了过去。

修库是从"面板导不进去"开始的。

第一道坎是密码。宝塔里存的那个 MySQL root 密码，跟真实的对不上，导入脚本死活连不上。我一开始根本没往这想，先怀疑备份文件坏了，又怀疑宝塔版本不对，来回试，最后才发现起点就在这个密码上。光这一条就耗了小半宿。

密码对上了，删库又卡住。DROP DATABASE 那条命令执行下去，机器上有活着的进程占着几张孤儿表的句柄，删不掉；它就在那儿每秒重试，把 systemd 的重启也一起拖住，卡在 deactivating 里十几分钟。

我烦了，直接 kill -9。

更坑的在后面：强杀之后 systemctl start 报成功，可进程根本没起来，错误日志一个字都不写。查了一会儿才明白，/www/server/data/www.pid 那个 pid 文件还留着僵尸记录，挡着重启。特征我记下了：is-active 显示 active，但 socket 连不上、日志时间戳一动不动——先查 pid 残留，别信 is-active 那行绿字。

这时候网站已经是 PHP 502 了。原因是我前面拿 pkill 收拾进程，把 php-fpm 一起干掉了，忘了拉回来。全站 PHP 挂，采集口自然进不去，表也建不出来。

把 php-fpm 拉起来，采集口能进了，又撞上一个：collect.php 跑到建表那行就 fatal。翻了才发现是程序里漏了一句 require config.php，$pdo 没定义。这个反正是最好办的——PHP 报 "Undefined variable $pdo"，第一步 grep 一下 require/include，引入链断在哪一眼就能看到。

最后一个是账号。面板连接用户 test123 的密码，跟配置文件里的兜底值对不上，ALTER USER 对齐回去，收工。

恢复本身反倒简单。找到 9-20 那份 SQL 备份，524MB，宝塔导进去，19 张表先回来，历史数据基本都在。缺的 3 张 pps 表，那个采集程序自带幂等建表（CREATE TABLE IF NOT EXISTS），curl 碰一下采集口，它自己就把表补齐了。断头文件补上一行 require_once。满编 22 张，监控满血，agent 心跳又开始往库里写了。

这事之后，七亿批量远程管理工具的客户端从 V149 补到 V156。

第一个是死循环拦截：连续两条一样的命令，直接停住。

第二个我觉得最该做：删库硬拦。rm -rf、DROP、TRUNCATE 这一类，AI 永远不代跑，连确认框都不弹，要删自己上终端敲。因为确认框这东西，拦的是手快的人，拦不住一个已经决定要删库的模型。

第三个，设置页加了行红字：接免费或低端模型请谨慎，建议起码从 DeepSeek 起步。

第四个，记忆改成只增不删，整理时合并增量，旧的条目不再删。之前那个弱模型"精炼"记忆，越精炼管理员的偏好越少。

第五个，加了个"新对话"按钮，一键清空对话历史但保留记忆——旧对话里过时的结论会一直带偏后面的诊断。

那天省下来的 API 费，后来我算过，大概几毛钱。赔进去的是一晚上，外加一个库，好在备份是好的，数据基本都救回来了。

这个 AI 助手记不住自己干过什么，之前也写过（AI 助手记不住自己干过什么）。至于静默失败——服务报成功、其实没起来——也不是头一回了（systemd 干等 90 秒那次）。

现在只要在七亿批量远程管理工具里选低端模型，那行红字就在设置页上杵着。我自己后来一直用 DeepSeek，再没打过省这点钱的主意。省钱的念头不能说错，可这种活儿上，好像真省不出什么。