为什么越来越多的开发者在用Claude Code时形成了一条铁律：只要当前会话里出现过删除操作，就必须马上杀掉它，重新开局？答案要回溯到2025年两次近乎灾难性的事故。2025年12月，一位用户目睹Claude在他的终端里执行了rm -rf … ~/，那条尾部的~/瞬间扩展成整个家目录，所有个人文件差一点被抹平。更早的10月，另一位用户眼睁睁看着rm -rf /从根目录开始执行，最后仅仅因系统文件权限的保护才侥幸逃过一劫。这些误删命令并非恶意注入，而是模型在长对话中自身判断力瓦解的直接产物。
Anthropic把这种大模型随着对话轮次增加而不断恶化的判断能力称为“上下文腐烂”。一份被仔细解剖的70MB会话转储揭示了腐烂的严重程度：其中93%都是纯粹的噪音——重复的JSON信封元数据、早已失效的工具返回结果、来自数小时前的base64截图，真正有意义的人机对话内容只占3%。当模型需要在这些废弃物中寻找删除目标时，混淆几乎是必然的。你对它说“删掉那个测试文件”，它的注意力却可能在十几个路径中跳来跳去，最终选中最致命的那一个。
这里有一个很容易被忽视的差别：编辑操作带来的风险是线性的。改错一个文件，最多损失一个文件的内容，git diff随手就能揪出问题。但删除操作的风险是指数级的，一条命令就能毁掉整个项目，甚至波及项目之外的系统区域。把编辑失误和删除失误同等对待，本身就是一种危险的认知疏忽。基于此，那条硬规则才有了生存的逻辑土壤——执行过删除命令的会话，本身已经成为一个高危环境，必须被即时终止。
终止会话并不意味着丢失已有的进度。我的做法是先在旧会话里让模型完成一次状态整理：总结当前项目到了哪一步、哪些功能已经完成、还剩什么要开发、做过哪些关键决策、有哪些待解决的问题。这相当于给整个工作过程拍一张高分辨率的快照。接着运行/compact命令，压掉几百条消息中积攒的噪音，只把最核心的上下文信号留下来。之后再建立全新的会话，把这份干净的状态摘要作为初始提示喂进去。对模型来说，它的注意力完全集中在必要的信息上，不会再把“删除那个配置文件”和“删除项目根目录”混淆。
这套流程看似多花了两三分钟，但它几乎把因上下文腐烂引发的灾难性误判风险推到了接近零的水平。更重要的是，它完全贴合Anthropic自己提出的应对上下文腐烂的五叉戟策略：/rewind用于回滚到指定节点，/clear用于彻底清空上下文，/compact用于压缩上下文并保留信号，子代理模式负责把独立任务隔离出去执行，Continue则允许在减少噪音后接着之前的工作继续。我所做的不过是把/compact和新建会话的手动交接结合起来，本质上就是用一次明确的状态摘要交接来实现Continue。没有发明新命令，只是把已有的工具用一种更安全的方式缝合起来。
这个痛点同样是社区的共识。开源上下文修剪工具Cozempic已经积累了超过3.5万名用户，提供覆盖三个层级的18种修剪策略。开发者们很清楚：当一次会话进入所谓的“YOLO模式”，并且已经下过删除指令时，这条会话的上下文就已经被有毒的残留记忆污染了。一条理性而审慎的响应，很可能只是因为它还没读到那些不该读到的东西，而紧接着下一条指令就可能引爆。把触发重启的边界明确划在“删除命令已出现”的位置，等于在思维链条中装入了一道硬性熔断开关。
至于这种做法究竟避免了多少次灾难性删除，我无法给出量化数字，毕竟被成功阻止的事故不会留下记录。但从机制上看，它足够可靠。/compact操作能剥离掉超过90%的噪音，使得接棒的新会话里只留下简洁的项目状态描述，看不到那条千疮百孔的历史对话流。在一个已经运行了数百轮的长会话中，“删除那个测试文件”可以匹配到模型先前见过的十几个不同路径，其中任何一个都可能被错误激活；而在新会话中，模型没有这些无用的记忆，也就不会被唤醒出致命的联想。
一条rm命令改写整个项目的例子反复提醒我们：把编辑失误的线性风险和删除失误的指数风险等量齐观，是上下文腐烂问题下最典型的管理盲区。编辑错误能被版本控制兜底，删除错误却常常不可逆。拿git diff能抓住的东西，去类比一条命令就清空所有劳动成果的风险，显然低估了爆炸性破坏的可能。只有当删除操作被单独标记为高风险行为，并触发进程重启时，上下文腐烂的破坏链才会真正断裂。
回头看那70MB的会话转储，93%的噪音占比本身就是一次度量结论：上下文腐烂不仅存在，而且可以被测量，并且实实在在地危险。既然我们知道它怎样生长、知道它可以被压缩掉，也知道重启这个动作几乎不花费什么成本，那在删除命令之后杀死会话，就从一种谨小慎微的个人习惯上升为一种理性工作流的基础构件。它不是过度防御，而是对指数级风险应有的尊重。
热门跟贴