研究表明，Claude.md 最终通常会膨胀至初始规模的三倍以上。

你大概也有过这样的体验：

往 Claude.md 加一条指令毫无负担，可真的要删掉其中已经没有用的任何一条，却迟迟下不了手。

因为删除指令不仅需要完成指数级的验证，还得祈祷删除后不要爆 bug，把自己的文件库搅得一团糟。

这就导致大家都不敢轻易删 Claude.md，让它被喂得越来越长。

最近，Kushal Chakrabarti在论文Why Does CLAUDE.md Keep Growing? Catastrophic Remembering in Agentic Coding中把这个问题研究明白了，他把这种现象称为" 灾难性留存 "，并表示：

删一条确实代价更大，但也有办法解决！

目前，相关成果已发表在 arxiv 上。

Claude.md 为什么只长不短？

论文指出，导致 Claude.md 越写越长的核心原因就是：

加新指令成本低且见效快；而删除指令却手续多、风险高、怕爆雷。

Claude.md、AGENTS.md 和 copilot-instructions.md 这类文件，本质上都是写给编程 Agent 的长期说明书。

代码怎么构建，测试怎么运行，哪些目录不能碰，提交之前要做什么，都可以提前写进文件。

Agent 每次进入项目时读取它们，便不必从头猜测团队的工作方式，像直接回家了一般。

这类文件是很有用，但问题恰恰也出在 " 太容易有用 "，导致 Agent 每经历一次失败，就有可能催生一条新指令。

比如 Agent 生成的回答被截断了，维护者可以马上补上一句 " 回答不能中途停止，必须完成每一个句子。"

这个动作的成本近乎为零，而且对当时的维护者来说可以立即验证效果。

但如果几个月后有我们想删掉它，面对的就不是一道简单的判断题，而是一连串扑面而来的灵魂拷问：

" 当初的失败是偶发还是常态？"

" 后来新增的其他规则是否已经覆盖了它？"

" 它与其他指令有没有肉眼看不出来的组合效应？"

要疯了，对吧……

所以大家只能无奈地选择妥协，一边不断叠加新指令以应付眼前的工作，一边对早已陈旧不堪的旧指令视而不见，任由其堆积如山。

△Agent 由于缺乏注释，在其整个生命周期中只会不断膨胀。

这完全该被理解和共情。

当完整验证贵得让人无法承受时，保留自然就成了更理性的选择。

而导致这一切麻烦的根源，恰恰就在于当初添加这条指令时的思考过程未被保留，致使后人无法判断其是否仍有存在的必要。

论文将这部分没有被写进文件的上下文称为" 潜在推理 "，即它可能触发过什么失败、维护者当时提出了什么假设、修改后是否真的解决了问题，以及类似错误后来又出现过多少次。

△潜在推理在编写时几乎零成本，但在读取时重建的代价却呈指数级增长。

后来，随着时间流逝、人员流动和多人修改，这些信息会逐渐丢失。

导致规则还在，理由却没了…… .

于是，越是古老陈旧的指令，反而越难被删除。

旧规则往往不是被删掉的，而是被一锅端的

当然，这些旧规则也不是完全删不了，只是维护者们可能往往会选择另一种更为简单粗暴的方式来解决——直接掀桌，将旧规则全盘推翻、彻底清零！

在论文中，Chakrabarti 提到了一个非常有趣的现象，即维护者们往往不敢精准修剪，却敢在忍无可忍时推倒重来。

因为删除一条指令，需要不断解释它为什么没用了；但重写整份文件，反而不必逐条回答这堆问题。

所以大家纷纷选择了直接掀桌重开（bushi

为了确认 Claude.md 越写越长并非错觉，Chakrabarti 调查了近 2000 个包 Claude.md、AGENTS.md 或 copilot-instructions.md 的 GitHub 仓库，结果发现，这类文件在生命周期中，指令数量平均增长了 226%。

直白来说就是，Claude.md 最终通常会膨胀至初始规模的三倍以上。

而且指令越老，就越不容易被删除。

这恰恰说明，问题绝非仅仅是 " 旧规则过时却无人察觉 "，也非单纯的 " 维护者想偷懒 "。

因为若只是自然淘汰，存续越久的规则理应越容易被清理；而文件若过度膨胀，显然也会阻碍工作的顺利开展。

真正的症结在于，时间越久，当初添加规则的人越可能离开，项目背景越容易变化，添加这条规则的理由也越难找回。

于是，维护者们便陷入了 " 规则犹在，理由已逝 " 的困境。当面对一条来历不明的旧指令时，他们只能选择一种最安全的做法：别动。

直到文件太过膨胀，大家才会放弃逐条判断，直接把整份文件推倒重写。

但论文发现，这种大扫除同样治标不治本；重写之后，原来的增长模式很快又会回来。

就跟玩贪吃蛇游戏一样，蛇身只是暂时被截短，但很快又会一路吃下去，越长越长。

对此，Chakrabarti 给出的破局办法很简单，那就是：

为每条长期指令补上一条注释。

指令负责告诉 Agent" 应该做什么 "，而注释则负责告诉未来的维护者 " 当初为什么要这么做 "。

不写废话，多保存 " 为什么 "

这里的注释主要用来记录它为什么会出现。

比如，一条指令要求 Agent 必须完整输出每一个句子；当时的维护者应该加一条注释应说明：

加注释之前发生过什么错误，我怀疑原因是什么，以及加入这条规则后问题是否再次出现。

有了这部分信息，我们才能重新判断" 原来的问题现在是否还存在，这条规则是否仍然必要，以及删除它现在还有没有安全风险。"

实验中，这种包含了真实原因和验证结果的注释，成功将提示词的超额规模从 211.3% 压缩到了 1.4%，相当于消除了约 99.3% 的冗余指令。

而且，文件变短并没有以牺牲正确性为代价。

研究者随后换用了更贴近真实用户表达的指令进行测试。结果发现，即便被大量无关规则干扰，只要加上有效注释，Agent 听话的程度最高也能提升 23.1%。

△有效注释能有效缩减超额规模

原因并不复杂。

Prompt 里的规则并非越多越保险。无关、重复甚至相互冲突的指令，反而会分散模型的注意力。

注释的价值，正是帮助维护者筛掉噪声，把模型的注意力重新还给真正重要的规则。

但这个注释也不是敷衍了事地写了就行。

论文中专门设置了一组对照实验，结果发现，当加入看似注释、实则不含有效信息的文字时，结果与不加注释几乎没有区别。

比如 " 我想加。"、" 有用。" 等等这类言简意赅却毫无信息量的注释，除了占位，什么也说明不了。

更糟的是，如果只记录尝试、不记录结果，甚至可能把未经验证的错误猜测，继续误导下一位维护者。

比如，某位维护者在注释里写下：" 怀疑是 token 截断导致输出中断，尝试将 max_tokens 从 2048 调到 4096"，却忘了补上后续结果，说明到底有没有用。

那么下一位维护者看到这条注释，很容易会默认 " 调大 max_tokens" 是已验证过的有效方案，不仅不会去排查真正的根因（比如其实是 prompt 格式错误），还可能在此基础上继续叠加无关改动，让问题越埋越深。

Chakrabarti 强调，真正值得保存的是三件事，即" 为什么添加 "，" 解决了什么问题 "，" 以及后来是否有效 "。

这套标准除了是对注释的要求之外，也戳中了当前 AI 工具链的一个盲区——AI 运营商们总在要求我们把规则写得更精简，却从未给过我们判断 " 哪些该留、哪些该删 " 的依据。

当我们只能凭感觉删减时，" 简短 " 就成了无源之水。

AI 运营商们也该反省了

只要求我们用户想办法保持 Claude.md 简短，其实解决不了根本问题，也并不公平。

我们不删，不是不知道文件太长，而是攒不够去删的底气。

只要 AI 工具仍然只保存最终规则，却不保存规则诞生的条件，维护者就永远缺少判断去留的依据。

于是，每个人都做出了 " 宁可错留，不可错删 " 这一最理性的选择，最终累积而成的，却是最臃肿的集体结果—— Claude.md 越写越长。

正如这位网友说的：

系统应该能够主动追问，那些当初让这条规则变得必要的条件，现在还存在吗？否则，记忆最终只能沦为沉积物。

这段评论准确点出了 Claude.md 的膨胀背后更深一层的问题。

看似是用户不会写 Prompt，本质上却是当前 Agent 基础设施缺少可维护性。

代码有注释、版本历史、测试覆盖和架构决策记录；一条 Agent 长期指令，也该有作者、触发事件、适用范围、验证结果和失效条件等记录。

AI 工具甚至可以据此主动提醒维护者：

这条规则半年没有触发，其针对的依赖已经被替换，相关测试也已连续通过，是否进入待删除审查？

到那时，Agent 的记忆才不只是会增加，而是真正具备了更新和遗忘的能力。

而 AI 运营商们真正需要做的，是一套能让指令与证据共同更新的机制：

规则记录" 做什么 "，注释保存" 为什么 "，测试验证" 现在是否仍然成立 "。

三者缺一不可。

Anyway，希望 Chakrabarti 提出的方法能经得住更多真实项目的检验，也希望未来的 Agent 工具能把指令来源、适用条件和验证结果变成一等公民吧。

毕竟，我们真正想要的并不是一条从来不犯错的 Claude.md 贪吃蛇；

而是一个敢于忘记、知道为什么忘记，并且忘了也不会出事的 Claude.md。

参考链接：

[ 1 ] https://x.com/omarsar0/status/2087605040240582991?s=20%E3%80%81

[ 2 ] https://arxiv.org/abs/2608.11095

一键三连「点赞」「转发」「小心心」

欢迎在评论区留下你的想法！

—  完  —

点亮星标

科技前沿进展每日见