Mac mini 重装前，我做了一次系统级资产审计

Mac mini 重装手记

重装这台 Mac mini 之前，真正让我犹豫的不是怕装不回来，而是怕亲手把一些还在偷偷给我干活的东西，连同那堆看起来该清掉的垃圾一起砍掉。

那是一台用了一年多的工作主机。买回来那天我以为它只是台普通的小机器，结果一年下来，它先后承载了好几波 AI 工具实验、几个跑了一半的项目、几次为了赶进度临时塞进去的模型权重，还有数不清的、当初为了"先跑起来再说"装下的 launchctl（macOS 服务管理命令）注册项。它从来没崩过，也从来没真正"干净"过。

系统盘的占用慢慢吃到 85%。Spotlight 偶尔抽风。开机的时候 Dock 上会弹出我已经不记得为什么装的图标。最让我心里发毛的是，每次我打开某个旧项目目录，里面总有几个 .env（环境变量文件）静静地躺着，文件里写着真的可用的 token（密钥）——而我已经忘了它们当初是为哪个实验配的。

我本能的反应是："那就重装吧。clean 一遍，从头开始。"

但我停下来，是因为突然意识到：我根本不知道这台机器上现在到底有些什么。

不是完全失忆——大方向我都还记得，哪些项目跑在哪里、哪些工具我每天在用、桌面上摆着的几个图标分别是什么。但只要再往下问一层："这个项目的临时缓存放在哪？""那个 token 是哪个服务的？""上个月那次实验留下的中间产物你清过吗？"——我就开始打哈哈。"大方向清楚、细节全模糊"，平时用着没问题，重装时却要命。重装不问大方向，它只一项一项地问细节。含糊掉的那些，都会变成事故。

后来我才意识到，"想重装"这个冲动本身就是信号。不是机器坏了，是我已经不信自己对这台机器的认知还准确。重装在心理上的吸引力，是用一次动作把"我不知道这台机器上有什么"的尴尬一笔勾销。但代价是那些"知道但忘了在哪"的东西也会被一起埋掉。这笔买卖不划算。正确的做法不是先重装，是先补认知。

清理不是真问题，盘点才是

"重装一台主机"听起来像纯执行的事。备份、抹盘、装系统、装工具、把数据搬回来。但中年人的工作主机跟大学时代那台空白机器不一样：上面堆着一堆"我以为不依赖了、其实还在依赖"的东西。

比如，某个我半年没碰过的小工具，其实是另一条工作链上某个脚本的隐含依赖。比如，某个我一直当成"实验失败"的目录，其实还在被一个 LaunchAgent（macOS 后台服务）定时拉起，每天默默地往云端推一份数据。再比如，某个被我嫌弃占地方的 model weights 目录，其实是我最近正在用的推理后端的真实加载路径——只是我每次启动服务的时候没注意它在哪。

这些东西的共同特点是：它们在散落记忆里。不在文档里，不在我脑子最前排，也不在桌面上显眼的地方。它们安静地工作，安静到我自己都忘了它们的存在。

重装这一刀下去，安静工作的东西会先死。等我发现哪条工作流断了，往往已经过了一两周。那时候我已经记不清当初是哪个服务、哪个脚本、哪个目录在背后撑着。我会从零去复原，复原过程中又会再装一堆"先跑起来再说"的东西。机器干净了三天，又回到原样。

问题不是"怎么把这台机器清干净"，而是"在我动手之前，能不能先有一份明白的清单，告诉我这台机器上到底有哪些东西、哪些还在用、哪些可以扔"。所以我决定先做一次资产审计（audit），而不是直接动清理。

审计和清理，是两件事。审计是把家底摸清，清理是按家底做决定。两件事混在一起做，最容易出事。

重装有完全不同的两种动机。一种是"环境已经不能满足新需求，需要换架构"——建设性动机，重装是手段，目标在前面。另一种是"环境太乱，想推倒重来求个清爽"——逃避性动机，重装是仪式，目标在后面甚至没目标。我这次老老实实承认，是后一种。逃避性的重装最容易在过程中出事：你心里没有"重装后要长成什么样"，遇到"嗯这个好像还能用"的东西，就没法判断。审计是把逃避动机掰回建设动机的唯一办法：审完之后，你至少知道新机器该长什么样。

我审了哪 6 类资产

我没有现成的方法论可抄。市面上"Mac 清理指南"基本都是讲怎么腾空间、怎么删 cache、怎么清 Time Machine 旧备份。这些对一台普通的 Mac 够用，对一台塞满 AI 工具和实验项目的工作主机不够用。我自己摸出来一套，分了 6 类。

• 后台常驻服务：所有 LaunchAgent、cron 项、launchctl 注册的服务。这一类是最容易被遗忘也最危险的——它们在背后运行，不会出现在 Dock 或 Activity Monitor 的醒目位置。
• 本地工程目录：所有项目目录、IDE workspace、Docker volume、临时实验目录。这一类决定了"我究竟在这台机器上做过哪些事"。
• 含密钥的文件：所有 .env、.aws、.ssh、各种带 token 字段的配置文件。这一类不只是占空间问题，更是安全问题——重装的时候一不小心就会被同步到云盘或者直接被新的 git 工程拖进 repo。
• 大体积资产：model weights、数据集、缓存、下载归档。这一类决定了"哪些东西重装后要重新下载、哪些可以扔"。一个 70B 模型下载一次要花几个小时，扔掉再下载就是给自己挖坑。
• 装机轨迹：哪些工具是哪一次装的、为什么装、还需不需要。Homebrew 装的包列出来一长串，每一个都有当初的理由，但其中可能一半已经不再使用。
• 历史账本：之前的 audit 报告、备份归档、旧版本的项目快照。这一类是"我过去做过的审计或备份的记忆"，决定了我能不能在出事的时候回到一个已知干净的状态。

这 6 类不是凭空想出来的。是我一边在机器上翻、一边发现"这玩意我刚才没归类"的时候补出来的。前 3 类——后台服务、工程目录、密钥文件——是任何一台跑过几个月 AI 实验的主机都该审的，没有讨价还价的余地。后 3 类——大体积资产、装机轨迹、历史账本——是可选项，但如果你打算重装，强烈建议都审一遍。

合起来看，它们回答的是一个看似哲学其实很操作的问题：这台机器作为我的工作主机，到底"是谁"？前 3 类决定它"在干什么"——后台运行的进程、占据的工作场所、跟外部世界的连接凭证；后 3 类决定它"经历过什么"——存了什么真正重的资产、装过哪些工具、留下过哪些自我观察的痕迹。一台机器跟一个人一样，知道它在干什么不难，知道它经历过什么、攒下了什么习惯、欠了哪些技术债，才是真正了解它。审计让我第一次把"我的工作主机"从抽象概念变成了具体的东西。

审计不需要做得多花哨。我用的是最朴素的方法：每一类对应一个 markdown 文件，里面列条目、写状态、标判断。我的本地审计目录里现在就是 6 份文件，加一份汇总。看起来一点都不性感，但它是这次重装唯一能让我心安的东西。

顺便说一句，这 6 类的审计顺序也是有讲究的。我建议先做后台常驻服务——最容易遗漏，也最容易在你动手清理别的东西时被无意中触发。然后做含密钥的文件——这一类直接决定你能不能进入"清理"阶段。接下来才是本地工程目录和大体积资产，这两类是工作量大头，但风险相对可控。装机轨迹和历史账本可以放在最后，算收尾整理。我自己一开始顺着字母顺序乱审，结果回头发现密钥那块踩了个大坑，整个清理被迫推后——后面我会专门讲这件事。

跑出来的 4 个数字

审计真正的价值，是把"模糊感觉"变成"具体数字"。

我审完后，这台机器上的 AI 栈被压缩成了 4 个数字：6 个 LaunchAgent、4 个 .openclaw* 目录、26 个含 token 的 .env 文件、加上一个大约 14G 的主要工作目录。

数字一出来，整个心态就变了。

审计之前，我对这台机器的描述大概是"乱"，"塞了不少东西"，"有点失控"。这种描述听着像抱怨，但没法指导行动——你没法对"乱"动手。审计之后，我至少能对每一个数字说一句具体的话：6 个 LaunchAgent 里 4 个还在用 2 个可以下、4 个 .openclaw* 目录里 1 个是 canonical 主目录其他 3 个是历史快照、26 个 .env 必须迁移到统一的 secret 管理位置、14G 的工作目录里大部分是可以保留的、少部分是临时实验产物。

审计做的事，就是把"乱"翻译成可以判断的项。被翻译成项的问题，才值得动手。停留在"乱"层面的，只能继续忍着。

话又说回来，光有数字还不够，数字背后必须配一句具体描述。"6 个 LaunchAgent"如果只是一个数，没有写明每一个是干什么的、是哪个项目装的、最近一次跑成功是什么时候，那它和"乱"没本质区别——只是把模糊的乱换成了精确的乱。审计真正生效的那一刻，不是我数出 6 这个数字的时候，而是我对每一个 LaunchAgent 都能说出一句"它叫什么、为谁服务、现在是死是活、删了会出什么事"的时候。数字是骨架，描述是肉。光有骨架的清单还不能拿去做决定，骨架加肉的清单才能。

我以前总以为这种盘点是程序员洁癖。后来我发现这其实是中年人做大事之前的标准动作——装修之前要量房，搬家之前要清点，重装一台 Mac 当然也要。区别只是没人会因为你不审计而骂你，大多数人就跳过了。代价是：每次重装都像一次小型的赌博，赌的是自己有没有忘掉什么关键东西。

另一个让我有点意外的发现：数字小，不代表问题轻。6 个 LaunchAgent 看起来一点都不多，但每一个都意味着一段我已经忘掉的逻辑——它什么时候被注册的、为了哪个项目、跑失败了会怎么样、删掉之后哪些下游会断。要把这 6 个真正搞清楚，我花的时间比把 26 个 .env 列清单还久。审计带来的不是 satisfaction，是一种"你以为只有一点点其实是冰山"的清醒。这种清醒比"删掉之后觉得舒服"重要得多——它会拦住你没看清水下就急着动手的冲动。

为什么清理被迫推后

审计跑完，我本来准备进入下一步：根据这 6 类清单，挨个动手。该删的删、该归档的归档、该迁移的迁移。计划是一晚上做完，第二天就可以开始重装。

结果在第二类——含密钥的文件——这里彻底卡住了。

26 个含 token 的 .env，听起来是个不大的数字。但等我真去看它们里面装的是什么的时候，我冒了一身冷汗。有的是某个推理服务的 API key，有的是云盘的访问凭证，有的是早期为了快速验证某个流程而申请的临时 token——但"临时"已经用了半年。它们散落在 4 个不同的工程目录里，每个目录又分了好几层。有几个文件甚至连我自己都说不清是哪个实验留下来的。

这意味着两件事。

一是，这些 secret 必须在重装之前先迁出去，统一管起来。不能简单备份，结果就是它们继续散落在新机器的对应位置上。也不能直接删，有几个是我当下还在用的。最安全的办法是迁到一个集中、加密的 secret 管理位置，然后改用引用的方式调用，而不是让明文 token 继续躺在每个项目目录里。

二是，迁移本身就是一个独立的、需要小心做的工程。它不是审计的延伸，是另一个项目。涉及到改每个项目的引用方式、验证迁移后服务还能跑、把旧文件安全销毁。这件事做得快一周，做得不急一两个月。

清理被迫推后。我没有在审计当晚动那 14G 的工作目录，也没有去下那 6 个 LaunchAgent。理由很简单：在 secret 还没迁干净之前，任何"清理动作"都有可能把含 token 的文件不小心同步到云端备份、不小心 commit 进某个新建的 repo、不小心被某个还在跑的 LaunchAgent 拉走。重装的诱惑很强，但安全的窗口期还没到。

这种"明明审完了却不能动手"的感觉，刚开始让我很不爽。但仔细想想，这其实就是审计的价值。如果没审，我可能就直接 clean 安装、然后从云盘把"项目目录"整体拖回来——里面 26 个 .env 也一起回来，全部还是明文，全部还散落在 4 个目录里。重装一次，问题没解决，反而被合法化了：我会更难下决心去整理它们，因为它们已经"跟着新系统一起活下来了"。

顺着 secret 往下想，还有件更冷静的事：一台工作主机上真正"贵"的东西，从来不是硬件，也不是装回来要重下的 model weights，而是这些散落的凭证——它们对应着我跟外部服务的真实信任关系。每一个 token 背后，是我点过的同意条款、绑过的支付方式、可能扣过的费用、可能产生过的访问日志。它们不是"配置项"，是我的延伸账户。把它们当 .env 文件随意散落，本质上是把账户钥匙当便签纸贴满了整栋楼。看清这件事，重装这种"清扫"动作就显得很次要——真正该补的功课是 secret 的治理框架，框架不会因为重装自动出现，只能坐下来一项一项设计。

审计教会我的几件事

这次审计跑完，没解决任何具体的清理问题，但改变了我看这台机器的方式。

第一件事，重装的真实门槛不是怕装不回来。装系统有现成手册，工具链可以重建，model weights 可以重新下载。这些都不算门槛。真正的门槛是怕一些"还在用的服务"被自己亲手砍掉而不自知。这种风险没有手册，只能靠审计先把它们摆到明面上。

第二件事，散落记忆是工作主机的慢性病。一台机器用一年，自然会攒下一堆"我以为我记得"的东西——某个工具是为什么装的、某个目录是从哪个项目复制过来的、某个 LaunchAgent 是哪一周配的。这些记忆刚攒下来时很清楚，半年后就全模糊了。审计治不好这种慢性病，只能定期清算一次，让模糊的东西重新变成清楚的清单。

第三件事，密钥治理才是真正的工作主机风险，不是空间。我以前关心的是"还剩多少 GB"。审计后我才意识到，空间只是表面问题——真正会出事的是 26 个明文 token 散落在 4 个目录里。重装不解决这件事，不过是把安全漏洞从旧机器原封不动搬到新机器。空间不够大不了买个外挂硬盘，token 泄露了是要去吊销凭证、检查访问日志、跟服务商解释的。

第四件事，审计和清理必须分开。这是我这次最大的收获。审计是观察，清理是行动。把它们混在一起做，会出现两种坏结果：要么是"边审边删"，删掉某个其实还在用的东西；要么是"审完不敢删"，因为审的时候没把判断标准想清楚。分开做，先审完拿到全清单，再坐下来一项一项决定怎么处理，速度反而更快、判断也更稳。

第五件事，审计本身就是一份资产。我这次审完的 6 份 markdown，会跟着进我的本地审计目录归档。下次重装、买新主机、或者有人问我"你这台机器都跑了些什么"，这份审计就是最直接的答案。不只解决一次性问题，还能在未来复用。

第六件事——也是最反常识的一件——重装前先盘点，不要被"清个空间"的冲动牵着走。85% 的占用率会让人很想立刻动手删点什么。但那种"删完一下舒服了"的快感，是这件事里最危险的情绪。真正该解决的不是占用率，而是这台机器到底有哪些东西在跑、哪些还需要、哪些必须治理。占用率只是症状。审计才是触诊。

第七件事，是节奏。审计花了我一整个下午加大半个晚上。时间长到让我中途好几次想偷懒——"是不是大概看一眼就行了？""LaunchAgent 反正就那么几个，扫一眼凭印象判断够不够？"——每次想偷懒的时候我都强迫自己继续。后来回头看，审计这件事的难，不是技术上的难，是心理上的难。它太朴素了，没有即时反馈，删一个文件看不到进度条变化，列一个清单不会让机器变快。它给你的全部回报，是事后那种"我现在知道我在动什么"的踏实感。这种回报是延迟的、看不见的、只有出事时才会感谢自己做过的。对习惯"做完事看到结果"的人来说，扛过审计中期那种"没看到成果"的疲惫，需要真心相信"先看清楚比先动手快"。我这次扛过去了，下次还会扛。

第八件事，这次最意外的副产品：审计本身可以变成一种习惯。它不必非得在重装前才做。我现在的想法是，每季度做一次轻量审计，不是为了清理，是为了"对账"。LaunchAgent 多了几个？.env 文件多了几份？工程目录里有没有冒出来一些我已经不记得的实验？把这些定期回答一下，就能避免下一次又攒到"想砸掉重来"的程度。这就像中年人的体检——不是为了治病，是为了不让小问题攒成大问题。这台 Mac mini 让我第一次意识到，一台工作主机也需要体检，不是只有出事才关心。