感谢您的快速回复，Alex。让我详细解释一下用例。
我们将各种驱动程序作为单独的子项目公开，并根据需求使用 `:local/root` 坐标包含它们。我们有一个 `:drivers` 别名，它包括我们用于各种本地开发任务的驱动程序；我们不将它们作为顶层的 `:deps` 包含在内，因为我们是用不同的过程构建它们的。
我们有时会 `clj -M:run`（这样就不会将驱动程序子项目包含在类路径中），有时会 `clj -M:drivers:run`（这样就会包含我们的驱动程序子项目）... 我们面临的问题是，没有简单的方法可以整理 `: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` 的操作并不是那么糟糕，但只需一次性运行 `clj -X:deps prep :aliases '[:drivers]'`（而不需要创建/维护虚拟的 `deps.edn` 文件）会好得多。
虽然没有必要，我们可以将需要 AOT 的文件打包成单独的工件，但这将使得在本地调整这些文件和测试更改变得更加困难。此外，如果没有强制，我真的不希望将它们推送到 Clojars，或设置一个 S3 存储桶作为 Maven 仓库，或者类似的东西，并设置 CI 以自动在更改时更新它。
影响同一台机器上的其他项目
我不确定为什么这会有任何不同。我的理解是，这最终不会与有人手动将别名中的所有 `:deps`/`:extra-deps` 复制粘贴到项目 `deps.edn` 的顶级 `:deps` 中然后运行 `clj -X:deps prep` 有任何不同。（唯一的区别是我们可能准备更多的库，但我们并没有以任何不同的方式准备。）
