这个是完全可以复现的, 上述视频中就有我提供的复现视频, 如果根据md5识别应该是几乎不可能出现文件名冲突的, 但是事实是, 文档管理并没有按照各位想象中的方式进行, 同时, 它存在两种不同的BUG状态:前提: 文件1和文件2处于不同的学习集中状态:命名文件1为"test", 然后另一个学习集中命名文件2为"test"时, 显示"新名称不能和已有名称重名"命名文件1为"test", 然后另一个学习集中命名文件2为"test"时, 且此时重命名成功 但是在打开文件2时, 可能会错误的打开另一个学习集中文件1, 即引用错乱 上述两种情况均多次复现过附加情况: 关于文档索引的一些问题由于mn4的文档是完全的平面化结构, 当用户一个学习集中, 从本地文件添加了一个文件后, 此时如果再从本地文件中, 添加相同的文件到另一个学习集时, 这两份文件会直接被认为是同一份文件, 对于文件内容的书写等都是重复的, 类似于浅拷贝的引用模式, 开发者的本意是, 用户在不同学习集中, 可能会引用同一份文件而设立的, 但是这导致了一些复杂的不必要的关联性. 因为学习集的创立本就是为了划分不同的学习内容, 是强调区分而非联系的一种产物, 各个文档脑图的创建删除, 应当完全基于学习集本身, 我打个比喻 上述是我用Ai生成的视频, 现在mn4的状态就像是上述视频, 鱼缸代表总目录, 鱼缸中的方格代表学习集, 而四处游动的鱼儿们代表各个文档, 学习集没有起到任何阻隔文档与文档的作用, 反而像是一个个学习集方格暴露了无数的不必要的接口, 让各个文档之间的调用变得无比错综复杂, 而起到封装作用的只有这一整个大鱼缸本身而已最后我想由衷的提醒各位，现 mn 在本身的问题已经早已不再是软件的功能深度问题，而是你的软件能否更好地满足大多数的普通用户，能否覆盖更广泛的学习场景，而不是不断地疯狂去追求在某的一个细分功能上的深度。首先他对开发者的能力提出了极为苛刻的要求，其次它并不能帮吸纳更多的新鲜用户，只会让一款产品变得更加剑走偏锋，良好的基础功能体验是功能深度的基石。广泛的学习场景覆盖是用户市场的基石。比如说我就可以举个例子，现在MN的大体思维是通过勾划、框选、定位等手段，利用文档中的内容来构建思维导图，然而树形结构在很多时候无法满足一部分学习需求，这个时候我觉得就可以吸纳类似于 liquid text的思维，去通过构建液态笔记的方式，像当前“文档-导图”学习模式一样，构建“文档-笔记”之间的动态联系，比如可以把文档中框选的内容等放置到笔记上，类似于一个更加现代化智能化的手账本，而并非总局限于脑图的节点等，然而目前我们可以看到，mn 的笔记本，几乎处于最最原始的状态。我个认为 人MN是一个独一无二的、无法被替代的产品，但同时也希望他能够从各个方面取得进步，以上是我一些由衷的建议，谢谢