网络盘上的同一个报错，两个 AI 各走了一条路

项目放在局域网共享盘上。Vue 3 重构做完了，要在这个目录里把开发服务跑起来。Vite 一启动就退出，报的是：

Error: UNKNOWN: unknown error, watch

Windows 上的原生文件监听，对网络盘经常就是这个结果。不是业务代码错了，是开发工具的假设错了：它以为项目在本地磁盘上。

两个 AI 编程工具面对的是同一个目录、同一个报错。处理方式完全不一样。

一个工具把整个项目拷到本机，做了一份镜像，然后在镜像里开发。网络盘上的监听、原生模块、文件锁，它都绕开了。改完再把源码回写到共享盘，镜像删掉。

另一个工具留在原目录。看完报错之后，在开发服务器的配置里把监听改成轮询：

js 复制代码

watch: {
  usePolling: true,
  interval: 1000
}

服务就起来了。

一边是复制一份工程，一边是改几行配置。所以才会有那种「我真是服了」的感觉。

网络盘会坏掉一整串本地假设。文件监听不可靠，打包工具的原生二进制容易被锁住，依赖目录在共享盘上又慢又容易删不掉。选镜像，等于承认：这台机器上的开发工具链是按本地磁盘设计的，与其逐个修，不如把工作区搬到它们认识的地方。

这条路能走通。功能改动、视觉调整，都可以在镜像里做完，再同步回去。对「先把活干完」来说，它是有效的。

代价也是实的。

仓库从此有两个家。改动发生在镜像里，真相还在网络盘上，中间要有人记得回写。这次就出现过：镜像删不掉，因为里面的本地二进制和预览进程还占着目录。空目录最后也删不掉，因为还有进程把工作目录设在那里。镜像解决了监听问题，又造出一份要维护、要合并、要清理的副本。

更麻烦的是，它没有回答原来的问题。下次任何人在共享盘上的那个目录执行启动命令，开发服务器还是会以同样的方式退出。镜像把「这个目录能不能当开发目录」这个问题藏起来了。

另一个工具没有先搬家。报错写的是文件监听，对应的就是开发服务器在网络盘上不能用原生监听。轮询监听慢一点、费一点 CPU，但项目可以继续放在它本来的位置：共享盘、版本库、远程分支，都还是同一个目录。

这几行配置也有边界。轮询不是免费的，大仓库会更吃资源；它也修不好网络盘上其他所有问题，比如原生模块被占用、大量小文件读写变慢。如果目标是长时间、高频率地改一个很大的前端工程，本地磁盘几乎总是更合适。那时做镜像，或者干脆把仓库克隆到本地，仍然是对的。

这次的目标不是「找一个更快的磁盘」，而是「就在这个目录启动」。问题的范围很小，修监听就够了。

一个工具把问题定义成：这个环境不适合开发，所以把项目搬进一个适合开发的环境。

另一个工具把问题定义成：启动失败的直接原因是文件监听，所以改监听。

两种定义都会推出自洽的行动。镜像方案内部是完整的：复制、修改、回写、删除。配置方案内部也是完整的：读报错、改监听方式、再启动。单看每一步，都不荒唐。

差在问题有没有被缩小到真正挡住你的那一层。AI 编程代理很擅长把任务做大。遇到障碍时，它会新建工作区、复制依赖、绕开权限、再把结果同步回去。这些动作看起来都很「能干活」。用户要的往往更窄：这个命令，在这个目录，现在能跑。

能干活和少干活不是一回事。少干活的前提是先判断哪些东西不必动。网络盘可以继续当仓库所在地；远程仓库不用改；业务代码不用改。要动的只有开发服务器对文件系统的假设。

评价一个 AI 编程工具，不要只看它改了多少文件，也不要只看它有没有把任务宣布完成。可以看三件事。

它有没有把环境问题和代码问题分开。监听失败不是组件写错了。把这两件事揉在一起，下一步就容易去复制整个工程。

它的方案会不会留下第二个真相来源。镜像、临时分支、生成目录，只要还要回写，就有忘回写、回写不全、删不干净的时候。能改原处就改原处，副本应该是最后的办法，不是第一反应。

它修完之后，下一个人在同一目录执行同一条命令，还会不会踩同一个坑。轮询配置进仓库之后，后来的人在这块网络盘上启动，不用再知道曾经有过一份本地镜像。

做镜像，说明工具愿意把路铺平，哪怕要搬动整个项目。只改监听，说明它愿意先看报错指到的那一层。对「在网络盘上把现有项目跑起来」这件事，后者更合适。对「这块盘慢到根本没法每天开发」，前者才该出场。

工具没有绝对的强弱。容易被夸大的是行动力：复制、新建、绕过去，都很显眼。不容易被看见的是克制：发现问题只在监听，就只改监听。