研究表明，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、
[ 2 ] https://arxiv.org/abs/2608.11095
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
— 完 —
� � 点亮星标 � �
科技前沿进展每日见
卓信宝提示：文章来自网络，不代表本站观点。
