MacBook 风扇整天狂转,用 Codex 十分钟排查+根治

6 月 17 日
 pmer

最近这台 MacBook Pro 有点不对劲。什么程序都没开,风扇却整天呼呼地转,机身烫手,电量掉得飞快,安静空间里噪音格外明显。一开始以为是天热散热不好,后来发现不对,凌晨放在桌上没人碰,风扇照样响。

这种情况但凡是做研发的多少都遇到过。Mac 风扇狂转的背后,九成是某个进程在偷偷吃 CPU 。问题是,到底是谁在吃,光靠肉眼看活动监视器很难定位清楚。这次我干脆把整个排查过程交给了 Codex ,让它带着我一步步把问题揪出来。整个过程比自己瞎折腾要快得多,也顺手沉淀出了一套能复用的自动化方案,供大家参考。

一、问题的根源:被遗忘的进程

打开活动监视器,按 CPU 排序,几个长期霸榜的进程分别是两个不同版本的 next-server ,还有一个 bun 进程。

这些大概率是本地开发服务或者插件服务的残留。如果长时间没用却持续占着 100%以上的 CPU ,那风扇转、发热、耗电、卡顿就全说得通了。我把这个判断丢给 Codex ,也得到了确认:它们都不是系统必需服务,本质是本地开发项目启动后,没有正常关闭留下的后台残留。很多人习惯开多个项目,关了终端窗口就以为服务停了,实际有些进程会留在后台持续运行。

二、用 Codex 定位,不用记一条命令

处理这类问题的第一步是精准诊断,搞清楚进程来自哪个项目、有没有在用、监听什么端口,不能上来就强制结束,误杀正常工作的项目。

全程不需要自己记命令、翻输出,打开终端启动 Codex ,用自然语言说清需求就行。

第一步,描述问题,让 Codex 自动排查

直接输入需求:帮我排查系统里所有 next-server 和 bun 相关的进程,找出它们的工作目录、监听端口和运行时长。

Codex 会自动调用系统命令获取信息,过滤掉无关内容,直接整理成清晰的结论。你不用对着满屏的字符找关键信息,它会告诉你每个进程对应的项目路径、占用的端口号、已经运行了多久,甚至帮你判断是不是残留进程。

第二步,确认异常范围

根据 Codex 返回的结果,核对哪些项目是正在使用的,哪些是早就关掉的残留。比如这次排查出的三个进程,分别对应两个旧的 Next.js 项目和一个 Claude 插件缓存,都已经三天没有使用,属于典型的后台残留。

第三步,明确处理规则

告诉 Codex 处理的边界:只停止确认是残留的进程,优先正常终止,无响应再强制结束,处理完复查端口是否释放。

三、一键清理残留进程

确认好要处理的进程后,不用手动敲命令,直接让 Codex 执行清理。

只需要说:帮我安全停止这三个残留进程,结束后检查对应的端口是否已经释放。

Codex 会先发送正常终止信号,给进程留出保存数据的时间;如果进程无响应,再执行强制停止。处理完成后,它会自动复查端口和进程状态,确认所有异常进程都已清理干净。

整个过程不需要输入任何命令参数,也不用担心误杀其他进程。只需要做判断,具体的操作全部交给 Codex 完成。

四、让 Codex 搭一套自动监控

手动清理只能解决当下的问题,下次开新项目忘了关,还是会出现同样的情况。和 Codex 探讨后,最好的办法是做一套定时监控,自动发现并处理高占用的残留进程。

同样不用自己写脚本、配定时任务,把需求告诉 Codex 就行。

当时提的需求是:做一个轻量化的定时监控,每小时运行一次,只监控指定的几类开发进程。如果进程 CPU 占用持续超过 80%且超过五分钟,就自动停止它,同时记录操作日志。用系统原生的 LaunchAgent 实现,不要常驻后台消耗资源。

不到半分钟,Codex 就生成了完整的监控脚本和配置文件,还自动放到了系统对应的目录下,加载生效。整套方案完全符合 macOS 的系统规范,不会额外占用资源,只在定时点唤醒执行检查。

日常如果想看监控运行状态,或者想调整规则、卸载监控,也都可以直接跟 Codex 说,它会自动执行对应的操作,返回清晰的结果。

写到最后

回头看整个过程,从排查问题到搭建长效防护,自己没有记任何一条命令,全程只做了两件事:说清需求,确认结果。过去很多琐碎的故障排查工作,门槛在于记住零散的命令;现在这些执行层面的事,都可以交给 Codex 这类工具完成。

风扇安静下来的那一刻,确实挺治愈的。

2132 次点击
所在节点    Codex
19 条回复
YanSep
6 月 17 日
我一直都是让 codex 来给我排查问题,甚至让他给我修 Hermes
aheadlead
6 月 17 日
我也让 Codex 来排查为什么我的 Mac 发热这么大,结果 Codex 告诉我是 Codex 本身导致的。。。。
300
6 月 17 日
让它清理垃圾也是很好用,手机有 root 的话也可以清理
它给我手机找出来 10 多 G 的蓝牙日志…
dswyzx
6 月 17 日
@aheadlead 你需要 360 来卸载 360 了
xiaowoli
6 月 17 日
这文章也是 codex 写的吧
MoonShot
6 月 17 日
你们都是 codex 接 gpt5.5 吗? 感觉额度一下就花完了啊
走中转的话,能直接调用 codex 的工具吗? 我最近用 ds 和 mimo ,好像都不太会调用工具
0x400
6 月 17 日
mbp 卖吗
dbak
6 月 17 日
这有啥可吹的 你打开任务管理器 按照 cpu 负载从大到小排序 几秒钟的事儿
Ansen
6 月 17 日
top C 一下就找出来了
ETiV
6 月 17 日
没啥可吹的+1 ,不过我都是进 Energy 看,谁的功耗高、发热元凶就是谁
pmer
6 月 17 日
@YanSep 666
pmer
6 月 17 日
@aheadlead 我是这几天才出现
pmer
6 月 17 日
@xiaowoli Codex 写文章相对一般,有一定结合豆包+Claude ,但自己也有做输入。
pmer
6 月 17 日
@MoonShot 20 刀的确实不太够用,即便邀请人有重置还是很快。走中转或国内模型用 cc-switch 驱动的话,我自己还没搞定,网上是有教程。
pmer
6 月 17 日
@0x400 目前主力机算是 2025 款,上一个是 2014 款 mbp ,估计你也不会要
pmer
6 月 17 日
@ETiV 还是你们厉害,我是有点后知后觉。
aheadlead
6 月 17 日
@dbak
@ETiV 我这边 WindowServer 常年占用很大的 CPU ,用 Codex 帮忙分析一下,它比直接看 Monitor 要深入不少。它可以告诉我到底是哪个进程在不断重绘什么区域之类的。。
wetalk
6 月 17 日
@aheadlead #2 哈哈,笑死了,之前用 cursor 排查 mac 发热问题,结论 cursor 告诉我 cursor 本身造成的,现在轮到 codex
getadoggie
6 月 17 日
AI 做问题排查还是挺强的

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1221140

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX