我删除了6个仓库中71%的代理指令文件。以下是实际堆积的内容。

你为编码代理编写的每一条规则，都会在每次请求时被读取，永远如此。我的规则已经积累了大约一年，而我从未审计过它们，所以上周我进行了测量，然后删除了其中的71%。我把实际内容写出来，因为分类结果出乎我的意料。起因是：Claude Code 的创建者 Boris Cherny 在7月的一个播客中说，当 Opus 5 发布时，他们删除了 Claude Code 自身系统提示词的80%，因为其中很多内容“是在纠正模型本应知道却没有做到的行为。现在，Opus 5 直接就能做到了。”他说，他们的消融实验表明，模型“在没有这些提示词的情况下实际上更聪明一点”，并且我们其他人应该每六个月删除一次指令文件，看看会发生什么。先测量，因为没人知道自己的数字。具体到 Claude Code，每次请求加载的不只是项目指令文件：还有你 rules 目录中的每个文件（无论你的配置是否导入它们）、你的全局配置，以及每个技能描述。最后一项最隐蔽，因为技能主体是懒加载的，但它们的描述不是（模型必须看到所有描述才能知道该调用哪个），所以多段落的描述是一种隐藏的常驻成本。我最糟糕的单次会话是 25,112 个词，约 33k tokens，而且那是在读取我一行代码之前。六个仓库总计 63,572 个词。削减后总计 18,200，最糟糕的会话降到了 8,245。什么都没坏。 按恢复的 tokens 大致分类，里面的内容有：过时的陷阱。针对几个月前已修复的 bug 的变通方法，留着“以防万一”。我最大的单个文件有 10,096 个词，而且它自己的标题写着应该只保留当月内容，结果它保留了三个月的。模型不再需要的建议。“先研究再实现”、“优先用库而不是手写”、“验证你的工作”、“经常提交”。这些在 2025 年都值得写下来。现代模型无需提示就能做到。被当作规则归档的参考数据。大约 8k 词的查找材料（决策日志、清单、画像）放在 rules 目录里，因为当初就在那里写的，每次请求都会加载。现在这些文档放在一个 15 行的指针后面。同一条规则出现在三个地方，表述略有不同，这比只出现一次更糟，因为它们会逐渐漂移。失效的引用。指向已不存在的脚本、文件和标志的指令。指令比它的对象多存活了几个月。重叠的文件。五份本应合并成一体的独立测试文档。 让这件事变得可操作的评判标准是每行一个问题：模型能不用告诉就知道这一点吗？如果能，就删掉。如果不能，就保留。环境事实保留（凭证位置、项目 ID、端口、测试夹具、仍然能复现的真实工具变通方法）。建议删掉。有过时日期的事件记录会被归档。归档这一步才是激进删减的安全保障。所有删除的内容都逐字移入一个不会自动加载的文件中，并在同一个提交里完成。如果某一行判断错了，代价就是恢复一行。跳过这一步，你就只会删除那些你本来就确定的内容，而它们并不会让你付出什么代价。真正改变我看法的一个发现根本不是冗余。有一个仓库仍然保留着来自几个月前就已完成的迁移的规则文件，它指示代理永远不要修改一个现在他们经常需要编辑的文件。过时的指令不会退化成噪音，它们会退化成自信、具体、错误的指令，而模型无法分辨哪条是哪条。诚实的警告：你无法对此进行 A/B 测试。没有干净的实验，我也不会假装我测量出了质量差异。你删除，使用几周，如果模型反复在同一个具体问题上卡住，就恢复其中一条。我能说的是，什么都没坏，而且现在每次会话开始时，累积规则大约少了 20k tokens。我写好了评判标准、一个测量你自己占用空间的脚本，以及我用来运行它的多仓库工作流。链接在评论中，按规则 3。很好奇其他人测量自己时发现了什么，尤其是那些配置比我还老的人。你那里最大的、结果已经失效的东西是什么？