<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Claude-Code on 冯智勇GEO</title><link>https://fengzhiyonggeo.com/tags/claude-code/</link><description>Recent content in Claude-Code on 冯智勇GEO</description><generator>Hugo</generator><language>zh-cn</language><lastBuildDate>Fri, 12 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://fengzhiyonggeo.com/tags/claude-code/index.xml" rel="self" type="application/rss+xml"/><item><title>医生给自己治病，才敢下猛药——AI时代的私人工具开发</title><link>https://fengzhiyonggeo.com/posts/private-tools-ai-era/</link><pubDate>Fri, 12 Jun 2026 00:00:00 +0000</pubDate><guid>https://fengzhiyonggeo.com/posts/private-tools-ai-era/</guid><description>&lt;h2 id="起因8gb-内存被-ai-工具吃光"&gt;起因：8GB 内存被 AI 工具吃光&lt;/h2&gt;
&lt;p&gt;今天早上打开 MacBook，卡到不行。&lt;/p&gt;
&lt;p&gt;照例打开活动监视器一看：一个 node 进程吃了 1.6GB，Claude 的一个窗口占了 1.2GB，内存压力直接飙到 92%。&lt;/p&gt;
&lt;p&gt;我这台电脑只有 8GB，本来就紧。偏偏为了提效，我装了一堆 MCP、skill，每个都会在后台拉起一串进程。结果就是——&lt;strong&gt;你用来提效的 AI 工具，自己先把内存吃光了。&lt;/strong&gt; 这是 AI 时代才有的新问题，以前没人会因为装了几个效率工具就内存爆掉。&lt;/p&gt;
&lt;p&gt;光看进程名是 node，根本不知道是谁。顺着 node 进程的命令行参数往回扒，才认出真凶：lark-mcp（飞书的 MCP）——之前我已经清过一次，这回又死灰复燃。&lt;/p&gt;
&lt;p&gt;索性彻底卸载了这个「内存刺客」。&lt;/p&gt;
&lt;p&gt;&lt;img alt="Claude Code 终端顺着 node 进程的命令行参数，定位到内存占用真凶 lark-mcp" loading="lazy" src="https://img.fengzhiyonggeo.com/image-20260612091854528.png"&gt;
&lt;img alt="Claude 列出 lark-mcp 牵涉的 App、MCP 配置、残留缓存与技能清单，询问是否一并卸载" loading="lazy" src="https://img.fengzhiyonggeo.com/image-20260612091926997.png"&gt;
&lt;img alt="memcheck 内存诊断结果：按真实内存占用排序的进程表，并给出可关闭的进程建议" loading="lazy" src="https://img.fengzhiyonggeo.com/image-20260612092011066.png"&gt;&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;顺着 node 进程参数往回扒，认出真凶 lark-mcp，彻底卸载。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;折腾完我突然冒出一个念头：其实让 Claude 来帮我看内存，本身就是个挺好的办法。它不只是甩给你一堆数字，而是像一个医生——带你做检查，还告诉你这块内存到底被什么吃掉了、为什么。这种体验，远胜于那些只会「展示数据」的内存优化工具。&lt;/p&gt;
&lt;p&gt;而且对我来说，「清内存」会是个高频需求。一方面机器内存本就紧张，禁不起浪费；另一方面 MCP、skill 装多了，会在后台莫名其妙占掉一大块——你以为关了窗口就完事，其实进程还在那儿吃着。可以说，这几乎是刚上手 Claude Code 的人都会撞上的问题：功能越装越多，机器越用越卡。&lt;/p&gt;
&lt;p&gt;于是我打算把这事做成一个 skill，方便以后随时调用。&lt;/p&gt;
&lt;h2 id="为什么现成的内存工具都是伪优化"&gt;为什么现成的内存工具都是「伪优化」&lt;/h2&gt;
&lt;p&gt;为了做这个 skill，我先去看了看市面上现成的内存工具。结果有点失望——这类工具满大街都是，但大多数其实是「伪优化」。&lt;/p&gt;
&lt;p&gt;问题出在它们清的根本不是该清的东西。&lt;/p&gt;
&lt;p&gt;这里要先说个反直觉的事实：macOS 故意会把你暂时不用的内存拿去&lt;strong&gt;缓存最近打开过的文件&lt;/strong&gt;，让你下次再打开时直接从内存里秒读，不用再去硬盘捞。所以活动监视器里那一大块「已用」内存，很多其实是缓存——它看着被占着，但系统一旦需要，立刻就能收回来用。换句话说，&lt;strong&gt;这部分内存本来就是随时可用的，它不是问题。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;img alt="macOS 活动监视器内存页，红框标出按内存排序的进程，以及底部的缓存文件与内存压力" loading="lazy" src="https://img.fengzhiyonggeo.com/image-20260612091608086.png"&gt;&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;活动监视器里那块「已用」内存，很多其实是随时可收回的缓存。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;而那些「一键清理」工具干的，就是强行把这块缓存清掉，让「可用内存」的数字唰一下涨上去，你看着舒服。可代价是：你下次再打开那些文件、那些软件，得重新从硬盘读一遍，反而更慢了。它清掉的是正在帮你的东西，却对真正拖慢你的元凶——某个软件实打实占住的一大块活动内存——一点没碰。&lt;/p&gt;
&lt;p&gt;所以它&lt;strong&gt;优化的是一个错误的数字&lt;/strong&gt;。真正该看的不是「可用内存还剩多少」，而是&lt;strong&gt;内存压力&lt;/strong&gt;：当真正在用的内存太多、系统被迫开始压缩内存、往硬盘上倒腾（swap），这时候才是真的卡。而这恰恰是缓存清理工具碰都不碰的地方。&lt;/p&gt;
&lt;p&gt;那问题来了：既然真正该做的是「找出那个吃内存的软件、把它关掉」，为什么没有一个工具直接告诉你该关哪个？&lt;/p&gt;
&lt;p&gt;不是它们不想，是它们&lt;strong&gt;做不到&lt;/strong&gt;。&lt;/p&gt;
&lt;p&gt;因为「该关哪个」这件事，离不开你当下的处境：哪个是你正在用的前台窗口、哪个开着但其实不要紧、哪个动了会丢你没存的东西。一个要卖给几千万人的产品，根本不知道此刻坐在屏幕前的你正在干什么，它没法、也不敢对一个具体的人说「把你这个关了」——万一你正用着呢？&lt;/p&gt;
&lt;p&gt;而清缓存恰好相反：它对每一台机器都安全，清了系统也能自己恢复，不会捅娄子。于是它就成了标配——&lt;strong&gt;正因为它没用，所以它安全。&lt;/strong&gt; 真正有用的那个动作（关掉那个具体的软件），偏偏是大厂没法替陌生人做主的。&lt;/p&gt;</description></item></channel></rss>