Context Rot in AI-Assisted Software Development: Repurposing Documentation Consistency for AI Configuration Artifacts
本文将“上下文腐化”（context rot）确定为一个关键问题，即随着软件的演进，AI 配置文件会变得陈旧，文章认为现有的文档一致性工具可以立即被重新用于检测这些不一致性，并概述了解决该问题的研究路线图。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你雇佣了一位才华横溢的新助手来帮你盖房子。为了让他快速上手，你递给他一份主操作手册（配置文件），其中描述了房子的布局、工具存放的位置以及具体的施工规则。
起初，这份手册非常完美。助手严格遵守手册，知道“厨房”在二楼，而“蓝图”在阁楼里。
但随着时间的推移，你进行了装修。你拆掉了一堵墙，把厨房搬到了一楼，并且扔掉了旧蓝图。然而，你忘记更新那份操作手册了。
现在，你的助手正在使用过时的信息工作。他们试图在一处曾经是厨房的地方建造一堵墙，或者去寻找一个早已不存在的蓝图。他们的逻辑并没有“错”，他们只是在遵循一张过时的地图。在 AI 编程助手的世界里，这种现象被称为**“上下文腐化”（Context Rot）**。
核心问题：过时的地图
论文指出，随着软件的变化，那些告诉 AI 如何编码的“操作手册”（如 CLAUDE.md、AGENTS.md 或 .cursorrules 等文件）往往会被遗忘。AI 会不断尝试使用旧的函数、已删除的文件或被废弃的规则，因为它的“上下文”（即手册）已经无法匹配当前的实际情况。
大创意：不要重新发明轮子
作者 Christoph Treude 和 Sebastian Baltes 做出了一个聪明的观察：我们几十年来一直在解决完全相同的问题。
多年来，软件工程师一直面临着文档（如 README 文件或注释）经常与实际代码不同步的问题。他们构建了许多工具来捕捉这些不匹配之处。论文建议，我们不需要发明全新的工具来应对 AI；我们只需要重新利用现有的工具即可。
可以这样理解：如果你有一个工具可以检查地图是否与地形相符，那么你可以使用同一个工具来检查 AI 的指令手册是否与代码相符，即便这个手册是一种新型的文件。
实验：快速测试
为了证明这个想法可行，研究人员使用了一个名为 DOCER 的现有工具（该工具最初设计用于检查 README 文件是否与代码匹配），并在没有修改其任何一行代码的情况下，将其应用于 AI 配置文件。
他们检查了 356 个不同的软件项目，这些项目都使用了这些 AI 指令文件。
- 结果： 他们发现，在这些项目中，有 23% 的 AI 指令手册指向的代码元素（如特定的函数或文件）已经被删除或重命名了。
- 类比： 这就像是在近四分之一的房子里，说明书仍然指示建筑工人在三年前就被拆除的墙上安装一扇门。
他们还手动检查了一些此类错误，并确认其中约 64% 是真实问题（代码确实消失了），其余部分则是由于工具过于“敏锐”地寻找匹配项而导致的误报。
路线图：下一步是什么？
这篇论文并不仅仅停留在寻找“缺失的门”上，它提出了一个研究路线图，以观察其他旧工具是否能修复其他类型的“腐化”：
- 行为指令： 我们能否检查 AI 关于如何编码的规则（例如，“始终使用这种风格”）是否仍然合理？
- 工具描述： 如果手册说“使用工具 X”，但工具 X 的接口已经发生了变化，我们能否检测到这一点？
- 架构： 如果手册说“系统是金字塔结构”，但代码现在变成了扁平的圆形，我们能否检测到这种偏差？
- 依赖关系： 如果手册说“安装库 Y”，但库 Y 已不再受支持，我们能否标记出来？
总结
核心信息很简单：AI 配置文件只是另一种形式的软件文档。 随着代码的变化，这些文件也会发生腐化。但我们不必惊慌，也不需要建立一个全新的行业来解决它。我们可以利用多年来用于保持文档真实性的现有工具，并将其应用于这些新的 AI 文件。
事实上，论文指出，开发者从今天开始就可以利用现有的工具扫描他们的代码仓库，并标记出 AI 手册中任何已从代码中消失的引用。这是一种切实可行且即时的方法，可以让 AI 助手不再迷失在过去。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。