最近刚把 skills.lc 上线，说实话，一开始并没有太高调，想着先稳定跑起来再慢慢打磨内容。结果没想到，上线没多久就被各种爬虫"盯上"了。
最明显的表现只有一个：OOM。
Node 服务动不动就被系统干掉，PM2 不停重启，日志里全是内存告警。一开始我也怀疑过是不是服务器太小、配置不够，但看了一眼监控，问题没那么简单------内存是持续上涨的，而不是瞬间被打满。
这基本可以确定：
不是正常的流量压力，而是内存泄漏或不合理的内存使用。
人肉排查的老路，其实挺慢的
如果按以前的方式来，我大概会这么做：
- 一点点翻代码
- 打一堆 log
- 猜是缓存问题、猜是 SSR、猜是爬虫请求异常
- 然后不断重启，观察，再重启
这条路不是走不通，而是太耗时间，而且在服务已经上线、有真实流量的情况下，每一次试错成本都很高。
于是这次我换了个思路：
把 AI 当成"高级排查助手"，而不是写代码的工具。
AI 真正帮到我的地方
我没有直接问"怎么解决 OOM"，而是把信息一点点丢给它：
- Node / Next.js 的启动方式
- PM2 配置
- GC 日志
- 进程内存曲线
- 爬虫请求的特征
- 哪些接口访问频率异常
AI 做的事情，其实很像一个经验很足的同事：
- 帮我缩小问题范围
- 指出"哪些地方更可能出问题，哪些可以先不用管"
- 提醒我一些容易被忽略但很致命的点
比如：
- SSR 场景下对象被意外缓存
- 爬虫请求导致的 response 未及时释放
- 不必要的全量内存缓存
- 某些中间件在高并发下的隐性开销
这些并不是"AI 写出来的新技术"，而是把零散的现象串成了一条合理的因果链。
优化的过程，其实并不激进
真正落地的时候，我做的改动并不夸张：
- 限制爬虫访问策略
- 调整服务启动方式和内存参数
- 精简不必要的运行期缓存
- 对高频接口做更克制的处理
- 把"可能无限增长"的对象，全部变成可回收的结构
每一步单独看都很普通，但组合在一起，效果非常明显。
最终的结果
- 内存曲线从"锯齿向上"变成了稳定平台
- 服务连续运行，不再无故 OOM
- 爬虫流量顶上来，也能扛住
- 不需要靠频繁重启来"续命"
到这一刻我才真正意识到一件事：
AI 的价值，不在于替你写代码，而在于帮你更快看清问题本身。
写在最后
这次经历让我对 AI 的态度变得很明确：
- 不把它当神
- 也不把它当玩具
- 而是当一个永远有耐心、永远不嫌你信息多的技术搭档
如果你正好也在做线上项目、独立站，或者正在被性能问题折磨，我的建议只有一句：
别只用 AI 写功能代码，试试用它来"一起排查问题"。
用对了，真的会省下你大量时间，和很多不必要的焦虑。