感谢你快速的回复，Alex。让我更详细地解释一下使用场景
我们将各自的驱动程序作为单独的子项目，并根据需要作为 `:local/root` 坐标包含进来。我们有一个包含用于各种本地开发任务的驱动程序的 `:drivers` 别名；我们不将其作为顶级 `:deps` 包括进去，因为我们是用一个不同的过程构建的。
有时我们执行 `clj -M:run`（以便不将驱动程序子项目包括在类路径中），有时我们执行 `clj -M:drivers:run`（以便包括驱动程序子项目）...我们遇到的问题是，除了手动手动 `cd` 到每个各自的目录并单独准备它们之外，没有简单的方法来准备 `:drivers` 别名添加的子项目。
我想出的对策是在一个单独的目录中创建一个虚拟的 `deps.edn` 文件，该文件包含与 `:drivers` 别名相同的 `:local/root` `:extra-deps`，但位于顶级 `:deps` 下。人们可以 `cd` 到这个目录并在这里执行 `clj -X:deps prep`，而不是单独为每个驱动程序目录执行它。因此，我们现在的首次设置说明基本上是
```
clj -X:deps prep && cd modules/drivers && clj -X:deps prep
```
在两个不同的文件夹中两次执行 `clj -X:deps prep` 并不是什么大问题，但仅在执行一次（不创建/维护虚拟的 `deps.edn` 文件）`clj -X:deps prep :aliases '[:drivers]'` 会好得多。
可以说，我们可以将这些需要AOT处理的文件打包成单独的组件，但如果没有必要，真的不想将它们推向Clojars，或者搭建一个S3存储桶来作为Maven仓库等（还需要设置CI以在更改时自动更新）。此外，这还会使得本地调整这些文件以及测试更改变得更加困难。
关于影响同一台机器上的其他项目
我不太确定是否理解了为何这会带来任何不同。我的理解是，最终这和有人手动将问题别名的所有 `:deps`/`:extra-deps` 复制粘贴到项目顶层 `deps.edn` 中的 `:deps` 然后运行 `clj -X:deps prep` 是一样的。（唯一的区别是我们可能会准备比以前更多的库；但我们不会以任何不同的方式准备这些内容。）
