Cursor 的 Debug 模式误删我 E 盘 921GB 文件

大家慎用 Windows 系统下 Cursor 的 Debug 模式。

我已被 Cursor 误删 E 盘上 921GB 的重要数据。我有备份，但最新备份是 2024 年的。

手机码字，电脑在恢复数据，不敢再开任何应用。事故现场截图我等数据恢复完再贴上。事发过程简述如下。

近日业余时间，本来在用 Cursor 愉快地 「 vibe coding 」一个有趣的个人开源项目（此处我必须模糊表述，想留点悬念，等数据恢复处理完，收收尾会发布。本来憋了个大的准备发布时发个帖子，还想象了项目发布后和其他 V 友一样获得点关注，没想到最后关头 Cursor 给我拉了坨大的。但我不恨 Cursor ，已经很惊艳了。）。

继续说。项目即将完成，我整在添加和调试一些 Demo 。

调试过程中，考虑将所有依赖 Node 的 Demo ，统一升级到较新的 Node 版本。我和 Cursor 一起评估规划了方案，Cursor 建议我直接统一依赖到 Node24+ 。

方案制定好了，我想到我本机的 Node24 有点问题，一是 npm install 无控制台日志输出（ npm install –verbose 才能看到日志），二是 npm install 下载 Electron 依赖时，会卡在 postinstall { code: 0, signal: null }（国内镜像源能解决此问题，但我比较排斥）。于是我让 Cursur 帮我排查。

此时 Cursor 是开着上文提到的那个项目的，我将 Cursor 切到了 Debug 模式，给 Cursor 如下的提示词（回忆版且适当概括）：

① 我的操作系统是 Windows 10 ，使用解压版的 nvm 管理多个版本的 Node ，我下载了多个版本的 Node 解压版，解压并以 vxxxx （版本号）的形式命名后放在了 nvm 根目录。nvm list 可正常识别，nvm use 可正常完成 Node 版本切换；

② Node18 工作和控制台日志输出正常，20 、22 、24 存在问题（上文已描述过）。

③ 贴了 nvm 、node （当前使用的是 24 ） 和 npm 的版本信息，nvm 根目录截图以及 nvm list 的输出。贴了当前系统 path 下所有环境变量。

④明确告知 Cursor ，可以在当前先后根目录下的 tmp 文件夹内，创建调试用的 Electron 小项目。如果需要其他信息或需要我协助执行操作，可以询问我。

经过一番排查，Cursor 给出的方案是在用户目录下的 npmrc 中，添加 loglevel=info ，并指定 Electron 的国内镜像源。我手动添加、指定了。问题排查到此没必要继续了，控制台输出问题已解决，国内镜像源只能接受。于是我按照提示点击了 [ Mark fixed ] 按钮，表示已修复。

在上述排查过程中，Cursor 在当前项目目录（项目在 E 盘，但非 E 盘根目录，在 E 盘根目录下第 4 层）的根目录（强调：是当前项目根目录）的 tmp 文件夹内直接或间接（调用工具、指令）自动生成了名为 node-diag 的子文件夹，该子文件夹的原貌已不可知。在事故发生后，在残留的此文件夹上（没错，该删的没删干净，不该删的全删了）点进去后，内层都是单个文件夹，最内层是一个名为 default_app.asar 的文件，从 tmp 到 default_app.asar 的路径为 .\node-diag\node_modules\electron\dist\resources\default_app.asar 。

我点击了 [ Mark fixed ] 按钮后，Cursor 按照惯例，开始了 Debug 完成后的自动清理，本次调试不涉及埋点， 因此 Cursor 开始自动清理 Debug 过程中 tmp 目录内产生的调试文件和日志文件。一分钟后 Cursor 前端提示执行成功，一切就如往常一样顺利，此时的我还沉浸在项目收尾的激动中，丝毫没意识到今晚（现在是凌晨，所以准确说是昨晚）将是个不眠之夜。

我忘记了我是因何打开了资源管理器并进入了 E 盘，也许是上天眷顾吧。我突然发现原本爆红的 E 盘血槽空白，下面显示 950 GB 可用（此处为了保护隐私，取了约数），我第一反应是系统显示有误，下意识在资源管理器右键刷新了一下，还是一样。

一瞬间我意识到，坏菜了，Cursor 这是要删库跑路了 。

我马上让 Cursor 核查刚刚 Debug. 时执行了什么命令，导致 E 盘被清空。Cursor 回答，在 Debug 完清理 tmp 下的调试文件和日志时，它在执行了危险的删除命令，但它没处理好 Windows Poweshell 下的引号有问题，导致删除对象从 tmp 内的文件（或文件夹），变成了 E 盘根目录下的所有文件（或文件夹），并且删除是直接删不放回收站。

事已至此，Cursor 给了我一堆诸如从备份盘、网盘恢复等没卵用的建议，并向我表达了同情，让我节哀的意思。Cursor 在思考过程中，我还看到它在检查是否有 git 记录可供恢复数据，有是不可能有的，别说根目录了，就连原本有 git 的当前项目目录，也被它删除干净了。

以上是事故过程简述。

Cursor 以及它所依赖的大模型，似乎都不太擅长 Windows 命令行操作，不知这锅该 Windows 背，还是该大模型背。

总之，大家慎用 Windows 系统下 Cursor 的 Debug 模式，严格控制删除命令。最好在远程或虚拟机下使用。

用 DiskGenius 的提示信息结语：

「数据无价，谨慎操作」。 ④明确告知 Cursor ，可以在当前先后根目录下的 tmp 文件夹内，创建调试用的 Electron 小项目。如果需要其他信息或需要我协助执行操作，可以询问我。

经过一番排查，Cursor 给出的方案是在用户目录下的 npmrc 中，添加 loglevel=info ，并指定 Electron 的国内镜像源。我手动添加、指定了。问题排查到此没必要继续了，控制台输出问题已解决，国内镜像源只能接受。于是我按照提示点击了 [ Mark fixed ] 按钮，表示已修复。

在上述排查过程中，Cursor 在当前项目目录（项目在 E 盘，但非 E 盘根目录，在 E 盘根目录下第 4 层）的根目录（强调：是当前项目根目录）的 tmp 文件夹内直接或间接（调用工具、指令）自动生成了名为 node-diag 的子文件夹，该子文件夹的原貌已不可知。在事故发生后，在残留的此文件夹上（没错，该删的没删干净，不该删的全删了）点进去后，内层都是单个文件夹，最内层是一个名为 default_app.asar 的文件，从 tmp 到 default_app.asar 的路径为 .\node-diag\node_modules\electron\dist\resources\default_app.asar 。

我点击了 [ Mark fixed ] 按钮后，Cursor 按照惯例，开始了 Debug 完成后的自动清理，本次调试不涉及埋点， 因此 Cursor 开始自动清理 Debug 过程中 tmp 目录内产生的调试文件和日志文件。一分钟后 Cursor 前端提示执行成功，一切就如往常一样顺利，此时的我还沉浸在项目收尾的激动中，丝毫没意识到今晚（现在是凌晨，所以准确说是昨晚）将是个不眠之夜。

我忘记了我是因何打开了资源管理器并进入了 E 盘，也许是上天眷顾吧。我突然发现原本爆红的 E 盘血槽空白，下面显示 950 GB 可用（此处为了保护隐私，取了约数），我第一反应是系统显示有误，下意识在资源管理器右键刷新了一下，还是一样。

一瞬间我意识到，坏菜了，Cursor 这是要删库跑路了 。

我马上让 Cursor 核查刚刚 Debug. 时执行了什么命令，导致 E 盘被清空。Cursor 回答，在 Debug 完清理 tmp 下的调试文件和日志时，它在执行了危险的删除命令，但它没处理好 Windows Poweshell 下的引号有问题，导致删除对象从 tmp 内的文件（或文件夹），变成了 E 盘根目录下的所有文件（或文件夹），并且删除是直接删不放回收站。

事已至此，Cursor 给了我一堆诸如从备份盘、网盘恢复等没卵用的建议，并向我表达了同情，让我节哀的意思。Cursor 在思考过程中，我还看到它在检查是否有 git 记录可供恢复数据，有是不可能有的，别说根目录了，就连原本有 git 的当前项目目录，也被它删除干净了。

以上是事故过程简述。

Cursor 以及它所依赖的大模型，似乎都不太擅长 Windows 命令行操作，不知这锅该 Windows 背，还是该大模型背。

总之，大家慎用 Windows 系统下 Cursor 的 Debug 模式，严格控制删除命令。最好在远程或虚拟机下使用。

用 DiskGenius 的提示信息结语：

「数据无价，谨慎操作」。

天河何处 2026 年 5 月 22 日 凌晨 在住处