最近这台 MacBook Pro 有点不对劲。什么程序都没开，风扇却整天呼呼地转，机身烫手，电量掉得飞快，安静空间里噪音格外明显。一开始以为是天热散热不好，后来发现不对，凌晨放在桌上没人碰，风扇照样响。
这种情况但凡是做研发的多少都遇到过。Mac 风扇狂转的背后，九成是某个进程在偷偷吃 CPU 。问题是，到底是谁在吃，光靠肉眼看活动监视器很难定位清楚。这次我干脆把整个排查过程交给了 Codex ，让它带着我一步步把问题揪出来。整个过程比自己瞎折腾要快得多，也顺手沉淀出了一套能复用的自动化方案，供大家参考。
打开活动监视器，按 CPU 排序，几个长期霸榜的进程分别是两个不同版本的 next-server ，还有一个 bun 进程。
这些大概率是本地开发服务或者插件服务的残留。如果长时间没用却持续占着 100%以上的 CPU ，那风扇转、发热、耗电、卡顿就全说得通了。我把这个判断丢给 Codex ，也得到了确认：它们都不是系统必需服务，本质是本地开发项目启动后，没有正常关闭留下的后台残留。很多人习惯开多个项目，关了终端窗口就以为服务停了，实际有些进程会留在后台持续运行。
处理这类问题的第一步是精准诊断，搞清楚进程来自哪个项目、有没有在用、监听什么端口，不能上来就强制结束，误杀正常工作的项目。
全程不需要自己记命令、翻输出，打开终端启动 Codex ，用自然语言说清需求就行。
第一步，描述问题，让 Codex 自动排查
直接输入需求：帮我排查系统里所有 next-server 和 bun 相关的进程，找出它们的工作目录、监听端口和运行时长。
Codex 会自动调用系统命令获取信息，过滤掉无关内容，直接整理成清晰的结论。你不用对着满屏的字符找关键信息，它会告诉你每个进程对应的项目路径、占用的端口号、已经运行了多久，甚至帮你判断是不是残留进程。
第二步，确认异常范围
根据 Codex 返回的结果，核对哪些项目是正在使用的，哪些是早就关掉的残留。比如这次排查出的三个进程，分别对应两个旧的 Next.js 项目和一个 Claude 插件缓存，都已经三天没有使用，属于典型的后台残留。
第三步，明确处理规则
告诉 Codex 处理的边界：只停止确认是残留的进程，优先正常终止，无响应再强制结束，处理完复查端口是否释放。
确认好要处理的进程后，不用手动敲命令，直接让 Codex 执行清理。
只需要说：帮我安全停止这三个残留进程，结束后检查对应的端口是否已经释放。
Codex 会先发送正常终止信号，给进程留出保存数据的时间；如果进程无响应，再执行强制停止。处理完成后，它会自动复查端口和进程状态，确认所有异常进程都已清理干净。
整个过程不需要输入任何命令参数，也不用担心误杀其他进程。只需要做判断，具体的操作全部交给 Codex 完成。
手动清理只能解决当下的问题，下次开新项目忘了关，还是会出现同样的情况。和 Codex 探讨后，最好的办法是做一套定时监控，自动发现并处理高占用的残留进程。
同样不用自己写脚本、配定时任务，把需求告诉 Codex 就行。
当时提的需求是：做一个轻量化的定时监控，每小时运行一次，只监控指定的几类开发进程。如果进程 CPU 占用持续超过 80%且超过五分钟，就自动停止它，同时记录操作日志。用系统原生的 LaunchAgent 实现，不要常驻后台消耗资源。
不到半分钟，Codex 就生成了完整的监控脚本和配置文件，还自动放到了系统对应的目录下，加载生效。整套方案完全符合 macOS 的系统规范，不会额外占用资源，只在定时点唤醒执行检查。
日常如果想看监控运行状态，或者想调整规则、卸载监控，也都可以直接跟 Codex 说，它会自动执行对应的操作，返回清晰的结果。
回头看整个过程，从排查问题到搭建长效防护，自己没有记任何一条命令，全程只做了两件事：说清需求，确认结果。过去很多琐碎的故障排查工作，门槛在于记住零散的命令；现在这些执行层面的事，都可以交给 Codex 这类工具完成。
风扇安静下来的那一刻，确实挺治愈的。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。