构建自维护的Markdown文件（开源项目）

仓库链接在评论/回复中。我一直在开发一个名为Mex的开源项目，而我不断回顾的一点是，许多编码代理工作流依赖于Markdown上下文文件，例如架构说明、约定、路由文件、运行手册、决策日志、CLAUDE .md（以及类似文件）等。它们很有用，但很快就会过时。代码库变化，代理的行为改变，团队学到新东西，这些Markdown文件慢慢不再反映现实。然后未来的代理以十足的信心继续消费过时的上下文，这就是许多错误输出开始的地方。因此，我一直在尝试让这些Markdown文件更具自维护性。这个想法不仅仅是让代理读取项目上下文，而是让它在循环中维护该上下文：检测变化、识别受影响的规范记录、更新正确的Markdown文件、在需要时追加决策日志、保持持久化的项目记忆与代码库的当前状态一致。我刚刚测试了它，代理更新了规范的Mex安全/路由/运行手册记录，添加了一个决策日志条目，并明确报告了它用于做出这些更改的上下文。对我来说有趣的是，这感觉可能不仅仅是“更好的文档”，而是可以变得更大。如果这运作良好，Markdown将不再是人类必须手动维护的静态文档，而是开始成为代码库、团队和在其上工作的代理之间的维护接口。这是我希望Mex最终成为的重要部分：不仅仅是编码代理的记忆，而是一个帮助在项目演进中保持该记忆可信的系统。显然，这里还有很多难题：决定什么值得成为持久记忆、防止代理强化错误假设、处理代码与现有文档之间的矛盾、弄清楚什么应该自动更新 versus 留给人类。如果有人尝试过类似的事情，或者对哪里会出错有想法，我会很好奇。