可不可增加一个文档同步的命令

[tltltltltltltltl]

我觉得仅仅一个agents.md是不够的，一个复杂庞大的项目有很多功能模块，1m的上下文不可能吃下整个项目，我们可不可让ai自动给每个模块维护详细的文档，这样既帮助人类了解项目构成（现在很多人都退化到不会写代码了，但至少要让他们能看懂代码，这样才能进步）又可以让ai快速定位bug。如果可以的话最好还是双向同步，让人类修改文档-ai改代码逻辑，ai改代码后自动改文档，总之时时刻刻保持代码与文档双向同步

[eggyShrimp]

一点点个人想法，如果实现你的想法（不涉及双向，只讨论文档维护的问题），不需要 mimocode 去做这个工作

• agents.md 加入开发工作流 checklist，checklist 包含对文档的维护工作
• 通过类似 jsdoc 注释，粒度到文件级别去维护文档。内容只需定义文件的职责和边界：这样不用跨文件维护，同时每次改代码的时候自动刷新
• 如果想直接跨项目使用，同时更加稳定，摆脱模型可能不执行 checklist 的问题 --> 可以直接包装为一个 mimocode 的自定义插件，每次通过 hook 自动触发这个固定事务。opencode 是支持插件的，基于 opencode 的 mimo 也可以。对于稳定执行的任务，opencode 的 summary 也是类似的原理（你可以看到 opencode summary 就很稳定）

---

• 不过长远来看：快速定位 bug，更健康而且稳健的方式，文件组织结构自身的语义化 + 充足测试会比文档更好
• 因为给每个模块维护文档，我也理解等同于违背 “单一数据来源” 原则，一套逻辑分两个地方，以不同形式去维护，本身就低效而且会需要考虑版本分叉
• 更不用说文档本身，还需要考虑语言精准。文档本身的攥写靠 llm 的笔力，这个很吃模型质量，对于复杂的工程项目很难校验质量，一次低质量的文档维护就会加速后续逻辑腐化

[tltltltltltltltl]

感谢你非常高质量的回复，我这个设想是基于自然语言比代码有更高的信息密度，1m上下文或许吞不下整个代码库，但是大概率能吞下整个文档库，ai如果能吞下整个项目的文档，那对人类指令的理解度肯定就会更高，定位问题也会更准。
就像人类发明高级语言取代汇编一样，编程的发展就是向着人类理解更容易理解的方式对编程这件事进行抽象，vibecoding其实就是这件事，但是换个窗口ai就失忆，ai修订的代码也不向人类解释。
我设想：如果未来没人学代码了，大部分人看不懂ai写的代码了，人类想知道代码具体做了哪些事情，那么自然语言描述代码文件这件事就很重要了