一次 rm -rf 教会我的 Claude Code 配置经验

三天前,我在终端里敲下了 rm -rf ~/.claude,而且是故意敲的,因为我以为自己只是在清理缓存。我清理的不是缓存。我删掉的是整个 Claude Code 操作层,全局配置文件、大约六十个日积月累的记忆文件、四个自定义 agent、我搭建过的每一条斜杠命令,以及一个能自动把会话归档进笔记的 hook。数月积累下来的操作知识,在按下回车的一瞬间,全没了。

我想把这句话说得精确一点,因为”操作知识”这个词听起来很抽象,直到你真的失去它才知道分量。这不是一个文档文件夹,而是我教一个工具按我的方式工作所积累下来的整体形态:哪些任务该路由到哪里,我反复出现的错误是什么,对我每周常问的那类问题来说,一个好答案长什么样。这些东西没有一样存在于模型权重里,全都存在那个目录里,而我从来没有备份过。

不过这个故事真正重要的部分,并不是删除本身,而在于什么留了下来。

救了我的那一层,恰恰是最不起眼的那层

有两件事让我没有把一切彻底丢光。第一,我在另一个窗口里还开着一个 Claude Code 会话,在删除发生之前,那个会话已经把我的记忆索引加载进了上下文,所以那六十个记忆文件的一行摘要,即便文件本身已经没了,依然留在一份会话记录里。第二,也更重要的是:那些记忆文件真正指向的持久知识,其实从来没有真正住在 ~/.claude 里过。它住在一个纯 markdown 格式的笔记库里。那个配置目录只是一个指针,一个索引,架在真正东西之上的便利层而已。

于是我配置里那些”聪明”的部分,记忆文件、自定义 agent、斜杠命令,所有专门为这个工具打造的东西,瞬间彻底死透。而那些”笨”的部分,普通文件夹里的纯文本,没有专有格式,不依赖任何特定软件继续存在,连眼皮都没眨一下。就算我把 ~/.claude 从轨道上炸掉,那个笔记库周二早上照样安然坐在那里,毫发无损。

这就是我反复琢磨的那个不对称性。大多数搭建过任何一种 AI 工作流的人,自定义指令、记忆系统、agent 配置,不管这个月流行的工具管这些叫什么,都会近乎偏执地给代码做版本控制,却从来没想过要给”告诉 AI 该怎么表现”的那一层做版本控制。我们已经把”备份代码”内化成了一种反射动作,却还没人把”备份 AI 的操作层”内化成同样的反射,因为这类工具还太新,新到感觉不像基础设施,倒像是设置项。没人会去备份设置项。

可这根本不是设置项。它是每一次会话里,你纠正工具、教它一个偏好、或者写下一条规则以免自己重复的所有过程,累积出来的产物。设置项是静态的,这个东西是层层积累出来的。而积累出来的东西,恰恰是你最该做版本控制却没做的那种,因为你没法照着规格重新生成它,你得把促成它的每一次纠正都重新经历一遍。

一次灾难性删除,是你能免费拿到的最好一次审计

还有一件事出乎我意料:重建这个过程,逼着我去看清自己到底搭建了什么,而不是我以为自己搭建了什么。悄无声息的积累会掩盖腐坏。一次崩溃,会逼你把每一行都重新读一遍。

恢复出来的全局配置文件,从 8.5KB 缩到了 6.5KB,而我在这个过程里没有丢掉一条规则,我只是砍掉了那些真正在起作用的规则周围的水分。这份文件的分量,比它的体积暗示的要重得多,因为它不是只加载一次,而是随着我跑的每一次会话一起发出去。里面多一句废话,就是每一次对话都要付的税,不管那次会话用不用得上那条规则。这种文件里的臃肿,不是那种你注意到就能马上修的一次性成本,而是一笔你从来看不见的经常性账单,因为 token 开销从来不会以一个账单条目的形式出现,它出现的方式,是答案变得稍微差一点、稍微慢一点,在几百次会话里悄悄复利累加,直到你终于坐下来把整份文件从头读到尾,而这正是失去它逼着我做的事。

各个 skill 也翻出了自己的腐坏。其中三个引用的斜杠命令早就不存在了,是我不知从什么时候起就一直悄悄带着的死链接,从来没被发现,因为一个引用失效的 skill 不会报错,它只会悄悄地表现得差一点。还有四个在我配置里被直接点名的 agent,在硬盘上任何地方都不存在文件。不是”难找”,是根本不存在。却被满怀信心地引用、按名字调用,而没有任何东西曾经报过错,因为系统里根本没有任何东西在检查。

这些问题没有一个会自己浮现出来。我不会去审计一套正在运转的配置。正常运转的东西不会被审计,它们会被放着不管,直到出问题为止,而等到出问题的时候,你通常已经忘了当初还有什么该检查的。这次删除替我做了这次审计,虽然是在最糟的时机,但那也是这种审计真正会发生的唯一时机。

我重建了什么,以及为什么每一部分都是老实的而不是取巧的

我没有重建同一套东西。我重建了三个具体的防护措施,每一个都针对这次事故本身暴露出的一个具体失败模式。

第一个措施,是那种”无聊到最好”的类型:整个配置目录现在都被版本控制了,用的是一个分离的 git 目录,一个三行的包装脚本,跑的是 git --git-dir=~/.claude/config.git --work-tree=~/.claude,而不是把一个普通的 .git 文件夹直接放进那个目录里。这个区别比听起来重要得多。一个直接放在 ~/.claude 里的普通 .git 文件夹,有风险被其他工具误当成一个项目仓库,或者更糟,被嵌套进某个别的仓库的忽略规则里悄悄跳过。分离的 git 目录能让这个配置文件夹在别的一切眼里,看起来仍然只是一个普通文件夹,同时又被完整追踪。它还被镜像到了一个私有的 GitHub 仓库。这整套做法的全部价值就在于,现在一次 rm -rf 付出的代价只是一次 git clone,而不是几个月的损失。我没有搭建什么复杂的东西,我搭建的相当于一条安全带。

第二个措施,是一棵活在全局配置本身里的预算调度树:一套硬性路由规则,把编码任务发给一个便宜的编码 CLI,把研究类问题发给一个有实据支撑的搜索工具,把长篇草稿发给免费层模型,把付费的 Claude 套餐专门留给编排和真正难的推理。与之配套的是,现在每一条回复末尾都会附一个模型归属脚注,写明具体是哪个模型完成了哪部分工作,包括极少数情况下付费模型做了本该被路由规则外包出去的事,也会自我标注出来。重点不在省下来的钱,虽然确实省了钱。重点在于,成本纪律不再是那种你三周后翻账单才推断出来的东西,而是在每一条回复里,实时可见,让你能在偏差累积起来之前就抓住它。

第三个措施,是一个 SessionEnd hook,会自动把任何有实质内容的会话(五条消息以上)归档进笔记库:一行日志加一篇带日期的笔记,由一个免费层模型做摘要,再对照手写记录去重,而且写得足够谨慎,永远不会在退出时阻塞或搞崩会话。老实说,这是我最看重的一个,因为它真正闭合了那次事故暴露出的漏洞。知识库现在会自己喂养自己。忘记记下来这件事,不再是一种失败模式,因为整个系统不再依赖我记得去记。

那个仓库,如果你想要实际文件

我把整套重建的系统脱敏之后公开了出来:claude-code-os。里面有 CLAUDE.md 模板、八个 skill(其中几个建立在 Matt Pocock 那份 MIT 许可的 skill 工作之上,仓库里有注明出处)、四个按模型路由的 agent、SessionEnd hook,以及那个分离 git 目录的包装脚本。这不是一个产品,而是三天里花了昂贵代价才弄清楚,自己配置里哪些部分是承重结构、哪些只是装饰之后,留下的一份记录。

如果这听起来有点耳熟,一个你从没做过版本控制的配置目录,几个你依稀记得写过、却好几个月没检查过的 agent 或命令,你大概率也有和我一样的漏洞,而且大概率不会主动发现它,除非有什么事逼着你去审计。你不需要真的经历一次崩溃才能做这次审计。你可以直接去读 claude-code-os 仓库,把能补上你已有漏洞的那部分拿走就行。