最近这台MacBook Pro有点不对劲。什么程序都没开，风扇却整天呼呼地转，机身烫手，电量掉得飞快，安静空间里噪音格外明显。一开始以为是天热散热不好，后来发现不对，凌晨放在桌上没人碰，风扇照样响。
这种情况但凡是做产品研发的多少都遇到过。Mac风扇狂转的背后，九成是某个进程在偷偷吃CPU。问题是，到底是谁在吃，光靠肉眼看活动监视器很难定位清楚。这次我干脆把整个排查过程交给了Codex，让它带着我一步步把问题揪出来。整个过程比自己瞎折腾要快得多，也顺手沉淀出了一套能复用的自动化方案。这篇把完整复盘分享出来。
一、问题的根源：被遗忘的进程
打开活动监视器，按CPU排序，几个长期霸榜的进程分别是两个不同版本的next-server，还有一个bun进程。
它们看起来很像系统服务，名字也不眼熟。但有经验的人会立刻警觉：这些大概率不是macOS自带的东西，而是本地开发服务或者插件服务的残留。如果长时间没用却持续占着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说，它会自动执行对应的操作，返回清晰的结果。
写到最后
回头看整个过程，从排查问题到搭建长效防护，自己没有记任何一条命令，全程只做了两件事：说清需求，确认结果。这也是AI工具给我们带来的最直观的改变，过去很多琐碎的故障排查工作，门槛在于记住零散的命令；现在这些执行层面的事，都可以交给Codex这类工具完成。
人只需要聚焦问题本身，定义清楚规则和边界。省下的时间和精力，完全可以投入到更有价值的工作里，这才是 AI 工具真正的价值所在。
风扇安静下来的那一刻，确实挺治愈的。