起因：8GB 内存被 AI 工具吃光
今天早上打开 MacBook，卡到不行。
照例打开活动监视器一看：一个 node 进程吃了 1.6GB，Claude 的一个窗口占了 1.2GB，内存压力直接飙到 92%。
我这台电脑只有 8GB，本来就紧。偏偏为了提效，我装了一堆 MCP、skill，每个都会在后台拉起一串进程。结果就是——你用来提效的 AI 工具，自己先把内存吃光了。 这是 AI 时代才有的新问题，以前没人会因为装了几个效率工具就内存爆掉。
光看进程名是 node，根本不知道是谁。顺着 node 进程的命令行参数往回扒，才认出真凶：lark-mcp（飞书的 MCP）——之前我已经清过一次，这回又死灰复燃。
索性彻底卸载了这个「内存刺客」。
顺着 node 进程参数往回扒，认出真凶 lark-mcp，彻底卸载。
折腾完我突然冒出一个念头：其实让 Claude 来帮我看内存，本身就是个挺好的办法。它不只是甩给你一堆数字，而是像一个医生——带你做检查，还告诉你这块内存到底被什么吃掉了、为什么。这种体验，远胜于那些只会「展示数据」的内存优化工具。
而且对我来说，「清内存」会是个高频需求。一方面机器内存本就紧张，禁不起浪费；另一方面 MCP、skill 装多了，会在后台莫名其妙占掉一大块——你以为关了窗口就完事，其实进程还在那儿吃着。可以说，这几乎是刚上手 Claude Code 的人都会撞上的问题：功能越装越多，机器越用越卡。
于是我打算把这事做成一个 skill，方便以后随时调用。
为什么现成的内存工具都是「伪优化」
为了做这个 skill，我先去看了看市面上现成的内存工具。结果有点失望——这类工具满大街都是，但大多数其实是「伪优化」。
问题出在它们清的根本不是该清的东西。
这里要先说个反直觉的事实：macOS 故意会把你暂时不用的内存拿去缓存最近打开过的文件，让你下次再打开时直接从内存里秒读，不用再去硬盘捞。所以活动监视器里那一大块「已用」内存，很多其实是缓存——它看着被占着，但系统一旦需要，立刻就能收回来用。换句话说，这部分内存本来就是随时可用的，它不是问题。
活动监视器里那块「已用」内存，很多其实是随时可收回的缓存。
而那些「一键清理」工具干的，就是强行把这块缓存清掉，让「可用内存」的数字唰一下涨上去，你看着舒服。可代价是：你下次再打开那些文件、那些软件，得重新从硬盘读一遍，反而更慢了。它清掉的是正在帮你的东西，却对真正拖慢你的元凶——某个软件实打实占住的一大块活动内存——一点没碰。
所以它优化的是一个错误的数字。真正该看的不是「可用内存还剩多少」，而是内存压力：当真正在用的内存太多、系统被迫开始压缩内存、往硬盘上倒腾（swap），这时候才是真的卡。而这恰恰是缓存清理工具碰都不碰的地方。
那问题来了：既然真正该做的是「找出那个吃内存的软件、把它关掉」，为什么没有一个工具直接告诉你该关哪个？
不是它们不想，是它们做不到。
因为「该关哪个」这件事，离不开你当下的处境：哪个是你正在用的前台窗口、哪个开着但其实不要紧、哪个动了会丢你没存的东西。一个要卖给几千万人的产品，根本不知道此刻坐在屏幕前的你正在干什么，它没法、也不敢对一个具体的人说「把你这个关了」——万一你正用着呢？
而清缓存恰好相反：它对每一台机器都安全，清了系统也能自己恢复，不会捅娄子。于是它就成了标配——正因为它没用，所以它安全。 真正有用的那个动作（关掉那个具体的软件），偏偏是大厂没法替陌生人做主的。
这就是通用产品那截永远走不完的「最后一公里」。
私人工具的特权：不必正确，只需对我有用
但我要做的，是一个只给我一个人用的工具。这就完全不一样了。
它知道我此刻在用什么、什么能关、什么碰不得，因为它只服务我一个人。这有点像医生：给陌生人看病得处处保守，怕担责任；可要是医生给自己治病，反倒敢下猛药——因为他清楚自己的底细，知道这一针扎下去不会出事。
[!quote] 私人工具 vs 大众工具 私人工具和大众工具不可比拟的地方就在这儿：它不必正确，只需对我有用；它可以想多武断就多武断。
于是我动手做了一个。做出来才发现：不难，而且特别顺手。那些大公司产品不肯碰的事，它全替我干了——把同一个软件拆出来的一堆后台进程合并到一起算，按真正占内存的多少排好序，自动跳过我正在用的窗口，最后直接告诉我：这几个，可以关。
做完最大的感受是这个：
这些功能其实一点都不难，过去没有，不是因为做不出来，而是没人愿意为「一个人」专门做一遍。大公司的产品要讨好大多数人，注定有一截「最后一公里」它永远不会替你走完。而现在，靠 AI，你完全可以自己把这一截补上——做一个只服务你自己、想多直接就多直接的小工具。
最后我把脚本整理了一下，放到了 GitHub：github.com/fengzhiyongGEO/memcheck。
整理好的脚本放到了 GitHub。
用得上的人估计也不会很多，需要有苹果电脑和在用 Claude Code，但它却实实在在解决了我自己的问题。
另一层：为什么我不直接推荐 Claude Code
写完这些，我又想到另外一层。
平时朋友问我 AI 工具怎么用，我会说先用 Claude.ai 的 chat 聊天模式，而不是直接使用 Claude Code 这个核心产品。
不是它不好，恰恰相反——前面这一整套，看内存、定位进程、写脚本、传 GitHub，全靠它。效率上，没有什么能比。
但我不敢上来就推荐。
[!danger] 我自己踩过的坑 有一次 Claude Code（权限全开模式）把我 Obsidian 里一批笔记直接清空了。那不是什么无所谓的测试数据，是攒了很久的东西，说没就没了。后来我搞清楚了原因，也学会了怎么防——做好备份、分清权限、敏感目录不让它随便动——但那种「东西突然没了」的瞬间，到现在想起来还是会有点后怕的。
但也正因为摔过这一次，我现在反而敢继续往深处用：敢让它装 skill、清后台进程、碰一些系统级的东西。因为我知道自己的底——哪些地方有备份、哪些操作以前出过问题、出了问题能不能兜得住——这些都是自己摔出来的经验。
可这套东西真的没法直接打包转交给别人——**怎么开车，别人能教；但对马路的敬畏，只能自己悟。**换一个朋友来用，他没经历过那次清空，没有那种敬畏，大概率会一路把权限开到底——然后某一天，可能就轮到他的笔记被清空。到那时候，这对他不是「踩坑长经验」，是真的丢了东西。
选择不直接推荐，反而是对朋友负责的表现。
所以最后还是那句话：医生给自己治病，才敢下猛药——因为他清楚自己的底细。但这剂药的处方，他开不出来给你。不是藏着掖着，是这剂药，他只敢用在自己身上。