CLAUDE.md暴增226%：灾难性记忆让指令不敢删，注释来破局

Why Does CLAUDE.md Keep Growing? Catastrophic Remembering in Agentic Coding

几乎每一个在生产环境中使用过智能编程助手（如 Claude Code、Cursor 或 GitHub Copilot）的工程师，都遭遇过一个微妙而普遍的治理噩梦：代码仓库根目录下的 CLAUDE.md、AGENTS.md 或是 .github/copilot-instructions.md，随着项目迭代总是在不可遏制地变长。

ArXiv URL：https://arxiv.org/abs/2608.11095v1

起初，里面只是两三行关于代码格式化命令与构建步骤的极简说明；随着项目推进，针对各种边缘特例、提交规范、类型断言风格乃至特定第三方库坑点的补充指令被源源不断地追加进去。维护者很快会发现，这些指令文件就像一个只进不出的“黑洞”——追加新指令极其轻巧，但谁也不敢删掉哪怕一条几个月前写入的历史指令。因为没人敢确信，删掉那行看似无关紧要的“别在组件中直接使用原生日期格式化”，会不会在明天的某次代码重构中，让 Agent 再次陷入早已解决过的未知错误。

来自 South Park Commons 的最新研究聚焦于这一前沿工程实践中极为普遍却缺乏系统研究的现象。他们对 GitHub 上 1867 个真实开源代码仓库、总计 247,694 条指令的完整生命周期进行了大规模实证追踪，首次从理论与数据层面证明：这类针对 Agent 的上下文指导文件不仅会无限膨胀，在其生命周期内平均增长高达 226%，而且指令存在的时间越久，被删除的概率就越低。更严重的是，随着指令无限累积，模型对关键约束的遵循能力会显著恶化。

研究团队指出，这一现象的本质并非开发者缺乏自律，而是一种全新的系统性退化——灾难性记忆（Catastrophic Remembering）。与此同时，研究给出了一个极为优雅且反直觉的解法：既然英文已经成为新的编程语言，那么软件工程四十年前用来解决代码维护难题的“注释机制”，正是终结提示词无休止膨胀、并在真实任务中挽回高达 23.1% 指令遵循性能的关键钥匙。

为什么提示词只增不减？从灾难性遗忘到灾难性记忆

在机器学习与持续学习（Continual Learning）领域，最为人熟知的经典难题是灾难性遗忘（Catastrophic Forgetting）：模型在学习新任务时，梯度更新会覆写掉旧任务学到的参数权重，导致系统丢掉了本该保留的能力。

而在以大模型为核心的 Agent 协作开发中，我们遭遇了其镜像对称的物理形态——灾难性记忆。当系统遇到失败案例时，开发者或自动化流程通过向指导文件追加规则来打上补丁。在这个过程中，写入一条指令的边际认知成本几乎是固定的常数级 $O(1)$；然而，随着时间推移，当初为什么要写下这条指令的“潜在推理过程”（Latent Reasoning，包括当时的失败场景、尝试过的替代方案与上下文假设）会迅速随记忆衰退或团队人员更迭而消散。

一旦潜在推理过程丢失，若想在包含 $

$ 条已有指令的集合中安全地剪枝某条旧指令，且确保不引发任何性能回退，在理论上需要对可能受其影响的各种状态空间进行指数级的反事实验证。这一验证成本直接飙升至 $O(2^{

})$。

面对 $O(1)$ 的廉价写入成本与 $O(2^{

})$ 的昂贵删除成本，任何具有理性的维护者都会选择路径依赖：保留所有不确定的旧规则，只做追加，不做修剪。然而，大模型的上下文并非无底洞。当无关、过时或是高度局部的指令在上下文中堆积如山时，模型的注意力机制会被大量噪声稀释，指令遵循退化（Instruction-Following Decay）随之发生。

如果说灾难性遗忘是模型覆写了本该保留的知识，那么灾难性记忆则是系统保留了本该覆写或丢弃的冗余指令。两者的内核如出一辙：缺乏一种能够合理授权模型或维护者执行“安全更新”的状态信息。

25万条指令的生存分析：推翻两大常识假说

为了厘清指导文件无序膨胀的真正归因，研究团队深入分析了包含 1,867 个代码仓库、1,801 个经历多次版本迭代的 Agent 指导文件、共计 299,440 次版本变迁记录的庞大语料库。

过往对提示词演进的粗粒度研究往往只能看到行级差异（Line Diffs）或文件体积变大，无法区分某次提交究竟是在修改措辞、迁移目录，还是真正从语义上废弃了某条具体规则。该研究首次将非结构化的 Markdown 文件解析为独立的语义指令单元，建立了涵盖 247,694 条独立指令生命周期的精准追踪管线，并引入生存分析中的危险率（Hazard Rate）来推导指令死亡的动力学特征。

在传统软件工程认知中，存在两种解释指导文件膨胀的假说：

指令陈旧假说（Instruction Staleness）：随着软件依赖库升级和架构演变，旧规则逐渐不再适用，因此指令越老，过时被删的概率应该越高（危险率随年龄上升）。
脆弱性淘汰假说（Content Fragility）：表述脆弱、缺乏普适性的规则在写下后不久就会被发现无用而被快速剔除，留下的都是经过时间检验的坚固规则（危险率随年龄下降，但仅取决于指令自身质量，与维护者数量无关）。

实证数据彻底证伪了上述两种猜测，并精准印证了“不完美召回（Imperfect Recall）”假说。

生存分析表明，指令被主动删除的对数危险率随提交次数的增加以 $-0.032$ / commit 的速率显著衰减。也就是说，一条指令在代码仓库里存活得越久，后续开发者就越不敢动它。更关键的是，研究发现删除危险率与参与编辑该文件的维护者人数呈显著负相关：编辑过该文件的开发者越多，单条指令被删除的概率反而越低。当原作者离开或多人交替维护时，上下文认知断裂进一步加剧，没有人愿意冒着未知风险去清理别人留下的条目。

在这种机制下，普通的代码修剪（Pruning）几乎完全失灵。统计显示，在所有被追踪的指令消亡事件中，高达 76.8% 的死亡并非源于点对点的精准删除，而是“推倒重来式重写”（Wholesale Rewrite）——即维护者在文件臃肿到无法忍受时，直接将文件清空或大砍一半以上重新拟定。

但令人啼笑皆非的是，这种推倒重来的“推土机式清表”根本无法阻断棘轮效应。数据追踪发现，经历大规模重写后，指导文件的体积在区区 10 次提交之内就会迅速反弹回重写前 91.5% 的水平；甚至在重写之后，指令的新增速度反而从重写前的每提交增长 4.1% 进一步加速到 4.9%。只要潜在推理在撰写时未被固化，灾难性记忆就会像野草一样在重写后的土壤里以更快的速度卷土重来。

破局之道：如果英文是新代码，为什么提示词没有注释？

既然定位到了问题的病灶在于“写入时理由充分，阅读时动机丢失”，解决手段便必须在不增加模型推理开销的前提下，将决策上下文显式保留下来。

在传统软件开发中，这一问题早在数十年前就被“注释”（Comments）完美化解了。软件工程的黄金准则始终强调：代码本身解释的是“怎么做（How）”，而注释应当记录“为什么这么做（Why）”。注释面向未来的代码维护者，且在编译或解释执行时被彻底剥离，不对运行期产生开销。

然而在当前的 Agent 上下文工程中，所有人都在用自然语言给大模型下达命令，却几乎无人将“面向人类或维护 Agent 的元信息”与“面向执行环境的纯指令”分离开来。

研究团队据此提出了提示词注释（Prompt Comments）机制：在维护系统规则时，以特定符号（如 Python 风格的 # 或 Markdown 隐藏语法）为指令附带结构化的潜在推理元数据。这些注释在分发给执行任务的模型时会被预处理剥离，永远不进入推理上下文；但在维护者（无论人类工程师还是负责更新规则的 Meta-Agent）审视并编辑指导文件时，注释能够完好无损地复现当初写下该规则时的决策依据。

一条规范的提示词注释至少包含三个关键要素：

当时遭遇的具体失败场景（Failure Context）；
提出该条指令时的修正假设（Hypothesis）；
该假设在历史验证中的实际结果与复现频次（Outcome & Recurrence）。

逆向 IFEval：在可验证世界里测出“最小最优集”

为了科学量化提示词注释对治理灾难性记忆的有效性，研究团队面临一个巨大的评测挑战：在现实业务中，所谓“最优提示词”的长度和边界是无法客观观测的，我们很难判断一个包含 50 条规则的 CLAUDE.md 到底有多少比例属于不必要的冗余。

为此，研究者巧妙地设计了 Inverse-IFEval（反向指令遵循评测环境）。IFEval 是学界广泛用于检测大模型是否严格遵循格式约束（如“字数必须大于400字”、“必须包含特定关键词”）的基准测试。研究团队将其逻辑反转：把环境预设为存在一组潜在但对维护者不可见的目标约束集合，让维护 Agent 尝试通过不断观察执行失败、修改并维护提示词集合，来使最终的执行 Agent 通过所有测试。

因为底层真实的约束集合是确定且可计算的，研究者得以在历史上首次明确定义出数学意义上的“最优覆盖提示词集合” $D_{\star}$ 及其基数 $

D_{\star}

$。由此，提示词的冗余率（Excess Size）被精确量化为：

\[\frac{|D_t|}{|D_{\star}|} - 1\]

在长达 51 轮的多步迭代实验中，不带注释的常规提示词演进路线展示出了典型的灾难性记忆特征：提示词尺寸不可逆地疯长，冗余度一路暴增至 +211.3%。面对执行过程中的偶然波动，Agent 不断把局部过拟合的修补规则塞进提示词，导致整体体积膨胀了两倍多，而最终的约束满足率却没有任何提升。哪怕给提示词塞入无信息的占位符注释（噪声对照组），冗余率依然居高不下（+147.9%）。

而一旦引入包含潜在推理的结构化提示词注释，演进曲线发生了戏剧性的变化：指导文件的体积迅速收敛在理论最优解附近，冗余度从无注释状态下的 +211.3% 彻底压缩到了仅剩 +1.4%，成功消除了 99.3% 的多余冗余指令。即便在短周期的 15 轮迭代中，带有有效注释的提示词冗余度也从常规的 +60.4% 下降到了 -5.8%，实现了极其干净的最小完备覆盖。

更深入的消融实验（Ablation Study）进一步揭示了注释质量的残酷现实：并非只要写了注释就有用。如果注释里只罗列尝试过程却省略了真实的测试结果反馈（Outcome），提示词冗余度甚至会恶化到 +70.0%——因为给后续维护者留下未经校验的前提假设，反而会诱导其沿着错误的方向继续叠床架屋；而在注释结构中，仅仅拿掉“失败复现频次”这一个字段，就会让尺寸压缩效果直接损失 37%。

从实验室走向真实仓库：把分散的注意力买回来

清理提示词中的冗余规则，并不单单是为了追求代码仓库的“极简美学”，更直接关乎 Agent 执行生产任务时的核心性能。

为了验证提示词注释在真实世界中的效能，研究团队进一步将逆向测试机制迁移到了开源社区高度认可的现实基准 WildIFEval 上。在面对包含大量真实多样化指令的复杂场景时，过长、充满噪声的历史遗留提示词对大模型的破坏力暴露无遗。

当模型被灌入未经修剪、充满历史包袱的冗余提示词时，由于注意力资源的稀释，它在应对核心任务约束时的遵循能力大幅滑坡。而通过提示词注释引导修剪机制、剔除无效指令后，整洁且高密度的提示词直接将真实任务中的指令遵循准确率最高拉升了 23.1%（绝对提升达 11.6 个百分点）。

这一对比鲜明的结果证实了一个在 Agent 时代至关重要的底层逻辑：给大模型的系统指导并非越多越好、越全越好。缺少修剪机制的“防御性指令堆砌”，表面上防范了曾经出现过的孤立 Bug，实际上却在系统级层面钝化了模型对全局重点任务的感知敏锐度。提示词注释通过在元数据层阻断灾难性记忆，实质上是以极低的工程代价，重新“买回”了模型宝贵的注意力容量与执行精度。

启示：用软件工程的成熟范式，重塑 Agent 上下文工程

这篇论文的价值远不止于提出了“给提示词加注释”这一实用的技巧，它为火热却略显粗放的 Agent 上下文工程（Context Engineering）提供了极具深度的理论框架与方法论审视：

Lehman 软件演化定律在提示词领域的投射：二十世纪七十年代提出的软件演变定律指出，系统如果不主动重构，其复杂度将持续攀升。在自然语言编程时代，这一规律不仅没有失效，反而因为自然语言更高的歧义性与反事实回溯的高昂代价，被成倍放大为“灾难性记忆”。
区分执行信道与维护信道：长久以来，开发者习惯于把系统指令当成一个扁平的字符串流，任何历史教训都一股脑喂给运行时的推理引擎。提示词注释的实质是建立了清晰的关注点分离（Separation of Concerns）：将面向维护者的“决策元理由”与面向执行器的“确定性约束”进行通道隔离。
自主维护 Agent 的必备认知锚点：随着越来越多的自主 Agent 被赋予自动读取、修改代码乃至修改自身引导文件（Self-updating prompts）的权限，缺乏潜在推理注释的自主修改必然会加速指导文件的劣质化与不可控收敛。给指令打上结构化的上下文时间戳与归因标签，将是构建下一代长生命周期自愈系统的基石构件。

正如作者在文末所感叹的：“在当下，每一个工程领域都在争先恐后地向 AI 汲取灵感。但我们或许同样应该回过头，向经典的传统软件工程借回智慧。解决灾难性记忆的钥匙，早在四十年前的软件工程体系里就已经被锻造完成；而下一个横亘在 Agent 面前的全新难题，其解法或许同样早就在旁边的学科里静静等待了数十年。”