我以为修 Linux 的 BUG 必须 SSH 登服务器，直到我发现负载它一点没涨

先说结论： 我错了，而且错得挺离谱。

一直以来我都坚信一个”真理”——想在 Linux 上让 AI 帮你在线开发、排查故障、修 BUG，第一步必须老老实实 SSH 登进服务器。不然 AI 站在这头，服务器在那头，中间隔着一堵墙，你说什么它都只能听个响。

直到我打开了我那台阿里云 ECS。

一、那台 1核2G 的”电子垃圾”

配置： 1H2GB 。

懂的人都懂，这不是服务器，这是电子蜡烛。

它平时岁月静好，一旦我上去干点正事——装个依赖、跑个构建、哪怕只是apt update 稍微野一点——CPU 和内存立马双双拉满 100% ，负载曲线直接起飞，跟坐过山车似的。整台机器卡到连ls 都要转三圈，最后只能祭出终极大招： 重启 。

重启完，它又温柔了，像什么都没发生过。

但问题来了—— 这是测试机，我能重启。要是生产机呢？

生产环境上这么玩，那不叫运维，那叫拆家。一次错误的重启，可能就是一次毁灭性的事故，第二天上班可以直接收拾工位了。

所以很长一段时间里，我对”AI 在线修 BUG”这件事是 持悲观态度 的：机器本来就脆，你再挂一堆进程上去分析代码、跑模型、拉依赖，那不是雪上加霜吗？

二、抱着试试的心态，我干了件”大逆不道”的事

今天我做了个违背祖训的决定。

我打开 WorkBuddy，把 Linux 的 远程 SSH 连接方式 告诉它，把它拉到我的 网站目录 ，然后跟它说：
去，帮我修 BUG。
我心里其实已经做好了两手准备：

1. 它修不动，装模作样给我返回一堆建议；
2. 它修着修着，我的小破机又 100% 了，然后我又得重启。
   结果—— CPU没涨，内存没涨，负载稳得像老狗。

我盯着监控面板看了半天，一度怀疑是监控坏了。刷新，再看，还是平的。

那一刻我悟了： AI 并不需要在你这台机器上”生活”，它只需要”遥控”。 重活累活都在云端跑，你的服务器只管安安静静地接受指令、返回结果。该省的算力省了，该保的稳定性也保住了。

原来我一直以来的”必须登进去”，是一种 路径依赖 。登进去是因为我只有一双手；而 AI 有的是一根网线。

三、但！是！安全这根弦，千万别松

技术爽归爽，有一句话说在前面， 非常重要 ：
22 端口，只放行你自己的当前 IP。
别图方便直接0.0.0.0/0 全开，那等于把家门钥匙挂在大门上，还贴张纸条写”欢迎光临”。全世界扫描 22 端口的脚本比外卖小哥还勤快，几小时能给你爆破上千次。

只放开你当前 IP，能挡掉 99% 的无差别骚扰，剩下那点定向攻击，你还有密钥、fail2ban、强密码这些后手。

方便的代价不能是裸奔。

四、顺带说一句：这波腾讯挺良心

昨天 DeepSeek 不是出故障了嘛，事后有补偿；WorkBuddy 这边也配套跟上了补偿方案。说实话，这种”我出问题了，我认，我补”的态度，在现在的厂商里真的算少见。

不吹不黑， 这波我给腾讯点个赞。 👍

五、想试的，来薅个羊毛

如果你想试试 WorkBuddy 远程连服务器修 BUG 是什么体验，可以走我的推广链接：

🔗 https://www.workbuddy.cn/events/invite?inviteCode=90r6ry6wf

你注册，我也能拿点积分， 双赢，何乐而不为。

最后总结一句：

别再用”1核2G 的小破机跑 AI”的思路折磨自己了。
工具的意义，就是让你少重启几次服务器，多睡几个小时。

哦对了—— 记得把 22 端口锁好。 🌙