这就是核心问题了。
首先考虑duplication，这个感觉是可以合并的。但编辑文件的时候就又有问题了，因为一份文件在几个目录里面复制几遍完全合理。有的场合是只更新其中一个，有的场合又希望全盘所有副本同步更新，具体要哪个是我说了算的。

其次就是你说的ambiguity问题。结合duplication问题，我不得不对模型进行了一些简化。在你不断cd（也即不断提供更多的搜索关键字）的过程中，返回的结果是从全盘搜索结果的aggregation到一个精确的sub folder的逐步过渡过程。最终在你提供了足够的信息，完全消除歧义之后，你会进入一个确定的folder。这个简化其实是有蛮大的效率损失的，因为进入一个确定的folder并不是最高效的形式，只能说是向可实现性进行的妥协。比如a/b/c/foo.txt和/d/e/a/bar.txt，理想情况下我希望cd a/之后看到的就是foo.txt和bar.txt（然后你在这个目录下创建的新文件该放哪里呢？又是一个头疼的问题）。所以只能妥协到最终会进入一个明确的folder。这样ambiguity问题就简单多了。

但在进入确定的目录之前的虚拟文件夹，里面的文件是各种可能性的聚合。因为可能性非常的多，所以这还不是简单的聚合，还需要分类整理。比如如果你全盘的目录结构很简单就一个/a/b/c/foo.txt，那你cd a就直接就看到foo.txt了。
但如果你还有/d/e/a/bar.txt，那你cd a看到就应该是b/,d/这两个子文件夹，你还需要做出更多的选择才能消除这一层的歧义。

但具体细化之后问题还有很多。比如你第一次cd a能看到foo.txt了，但后面建立了/d/e/a/bar.txt之后，下次你就cd a就有歧义，无法直接看到foo.txt了，这种不确定的变化会打破很多东西。此外在真实文件系统上困难也相当的多。因为真实文件系统里面有很多cache folder，里面存了茫茫多的文件名，正常情况你完全不会关注它，但在这种基于全盘搜索的fs下，它们会大量的出现在你眼前，要高效的排除干扰并不容易。导致最后我想控制在3层目录几乎不可能，实际依然要cd很多层的目录才能完全消除歧义。所以我才说这里应该需要AI来做更智能的判断，基于机械规则始终是不行的。

【 在 tgfbeta 的大作中提到: 】
: 既然是搜索，如果结果不是unique的，产生了ambiguity怎么办？
--
FROM 180.111.50.*