AI 时代系统提示词冗余的解法,藏在四十年前的软件工程里

一篇 arXiv 论文的扎心发现

你的 Agent 系统提示词，正在失控膨胀

不知道大家最近在用 AI 写代码的时候，有没有遇到过一个让人头疼的现象：

现在不管是 Claude Code、Codex，大家都习惯在项目的根目录下放一个说明文件，比如叫 CLAUDE.md、AGENTS.md。这个文件的初衷很美好，就是给 AI 当一个“项目备忘录”，告诉它咱们项目的编码规范、测试怎么跑、有哪些坑千万别踩。

但你有没有发现，这个文件只要一建起来，就像掉进了一个“黑洞”：它永远在变长，几乎从不缩水！

只要 AI 犯了一次错，比如漏加了类型注解，你就会在里面加一条“记得所有函数都要加类型注解”；测试挂了一次，你又加一条“跑测试前必须先清缓存”。久而久之，这个文件就像老房子的杂物间，东西越堆越多。

更诡异的是，你明明知道里面很多规矩可能早就没用了，但你敢删吗？你不敢。因为你根本记不清某条奇怪的规则到底是哪天为了修哪个隐蔽的 Bug 加进去的。万一删了，之前的陈年老 Bug 卷土重来怎么办？

最近 arXiv 上有一篇有意思的论文，标题一针见血——《为什么 CLAUDE.md 一直在变长？Agent 编程中的“灾难性记忆”》（https://arxiv.org/abs/2608.11095）。作者是来自 South Park Commons 的 Kushal Chakrabarti。今天我们就来聊聊这篇论文，看看为什么 AI 时代的提示词文件会像滚雪球一样无限膨胀，以及我们到底该怎么用一个几十年前的老办法，优雅地解决这个新问题。

很多人可能会想：“长就长呗，现在的模型上下文不是动辄几十万、上百万 Token 吗？差这点字数吗？”

还真差。研究表明，如果把这个文件彻底删掉，AI 做任务的速度会变慢，消耗的总 Token 也会变多，说明这种备忘录确实是有用的；但如果你什么都留着，当里面的约束条件越堆越多，AI 的注意力就会被严重分散，指令遵循能力会断崖式下跌。在真实的 GitHub 仓库里，这类文件的指令中位数已经达到了 39 条，整个生命周期里平均膨胀了 226%

那为什么大家只加不删呢？在机器学习领域，有一个经典的现象叫“灾难性遗忘”——模型学了新知识，就会把旧知识给冲掉。但这篇论文提出了一个完全相反的全新概念，叫做“灾难性记忆”（Catastrophic Remembering）。

什么意思呢？灾难性遗忘是“把该留的给忘了”，而灾难性记忆是“把该删的给死死记住了”。

为什么会这样？作者从数学和决策逻辑上给出了一个解释。

你想想看，往提示词里追加一条指令，成本是极低的，一次操作就搞定。但是，如果你想安全地删除一条旧指令，而且要百分之百保证不会引发代码回退，成本有多高？如果你的文件里有 N 条指令，因为指令之间可能存在相互依赖和冗余，你理论上需要做 2 的 N 次方种组合测试！这在现实中是根本不可能完成的任务。

更关键的是，随着时间的推移、代码的修改，甚至是团队里换了不同的人来写，当初添加这条指令的“真实原因”和“上下文背景”迅速丢失了。当后来的人看不到当年的原因，面对一条指令时，最理性的自保策略就是：“留着它，别管它”。

这就导致了一个必然的数学结果：哪怕你的业务需求和代码库完全固定不变，只要“写代码的原因”在遗忘，你的提示词文件就一定会单向地、无休止地膨胀下去。

为了验证这个理论，作者可不是空口说白话，他直接去抓取了 GitHub 上 1,867 个真实仓库，追踪了整整 24 万多条指令在历史提交中的完整演变过程。

从这些海量的数据里，作者总结出了现实世界中提示词变迁的四大铁证：

第一，无限膨胀。在所有经历过多版本演进的仓库里，接近三分之二的文件指令数都在纯增长，平均每一次 Git Commit，就会净增 4.9 条指令。而且作者特别做了拆分，发现文件变大主要是因为“指令条数变多了”，而不是每句话变啰嗦了。

第二，消失的真相不是“精准修剪”，而是“推翻重盖”。在所有死掉的指令里，将近 77% 的删除不是一条一条精细挑出来的，而是某一天维护者实在受不了了，一个 Commit 把整个文件推倒重写，或者直接砍掉大半。这非常符合人性：删掉其中某一条需要极其充分的理由，但把整个文件彻底重写一遍，反而不需要任何具体理由。

第三，极具戏剧性的“棘轮效应”。就像机械齿轮上的棘轮一样，只能单向往前卡，退不回来。数据表明，当维护者推倒重写、把文件砍掉一半多之后，仅仅过了 10 次提交，文件大小就会迅速反弹回重写前的 90% 以上！甚至重写后的增长速度，比重写之前还要快。因为根本原因没解决，伤疤一好，大家又开始疯狂往里追加指令。

第四，也是最硬核的证据：删除风险率随时间下降。如果是代码过时了，那应该越老的指令越容易被删；但实际数据恰恰相反，一条指令存活的时间越长，它被删除的概率就越低；更绝的是，一个文件被越多不同的人修改过，里面的指令就越难被删除。这彻底证实了作者的核心论点：正是因为大家对背后原因的记忆丢失了，才导致了不敢删、删不掉。

找到了病根，那药方是什么呢？作者说：其实软件工程界在几十年前，就用一个最朴素的工具解决了完全一样的问题——那就是“注释”（Comments）。

在写代码时，程序员早就形成了一个共识：代码是写给机器执行的，表达的是“怎么做”；而注释是写给未来的维护者看的，表达的是“为什么这么做”。

如果说在 AI 时代，自然语言就是新的编程语言，那为什么我们的提示词文件里，居然一直没有“注释”呢？

作者顺着这个思路，设计了一个非常巧妙的实验。他把专门测试模型指令遵循能力的 IFEval 基准给“逆向”了过来：把标准答案隐藏起来作为世界的底层规则，让 AI 维护者去摸索着写提示词，来让执行任务的 AI 做出符合要求的回答。

在这个实验里，作者引入了“Prompt 注释”机制。具体做法非常讲究：维护者在加一条指令时，可以用注释记录三件事：当初是因为什么失败才加这条指令的？自己的假设是什么？后来验证的结果如何？最关键的工程细节在于：这些注释是给未来的维护者看的，在真正发送给执行任务的 AI 时，系统会把所有注释统统剥离掉！执行者只看干净的纯指令，而维护者能看到带注释的完整背景。

实验结果出人意料：在长期的维护循环中，没有注释的提示词一路野蛮生长，尺寸超标了 211.3%；而带有推理过程注释的提示词，最终稳定在接近理论最优解的尺寸，多余指令只增加了 1.4%！相当于通过注释，消除了 99.3% 的多余冗杂指令。

而在真实世界的数据集 WildIFEval 测试中，作者发现，那些堆积在提示词里的噪音和无关指令，会让模型执行真正任务的准确率直接暴跌 24.1 个百分点；而通过注释机制把提示词清理干净之后，真实任务的指令遵循率大幅回升了 23.1%！

而且消融实验还发现，注释里必须老老实实记录“验证的结果”，如果只写一大堆没头没尾的尝试日志，效果依然不好。只有基于真实结果的背景记录，才能真正帮未来的维护者放心地删掉多余规则。

聊到这里，我们不妨把视线放宽一点，看看这项研究给我们带来的启发。其实不管是企业管理里的规章制度、法律条文，还是我们个人的备忘录，似乎都有这种“只增不减”的通病。公司成立十年，各种审批流程堆积如山，谁都不敢取消，因为没人知道当年是防哪个风险才立的规矩。

而在 AI Agent 时代，这个矛盾被极度放大了。今天大家都在讨论各种花哨的 Agent 架构、长上下文、外挂记忆库，但如果缺乏对“决策原因”的沉淀与清理机制，再大的上下文也会被无意义的陈规旧矩塞满。

如果大家平时也在维护团队的 Prompt、或者写自己的 CLAUDE.md，不妨从今天开始养成一个小习惯：每次想加一条限制之前，先在旁边写清楚“为什么加、为了解决哪个具体问题”。当你下一次想要给 Prompt 瘦身的时候，你会由衷地感谢今天写下这行注释的自己。

**YouNavi（https://younavi.me）对论文内容解读亦有贡献。