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

1 天前
 tianhehechu

大家慎用 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 日 凌晨 在住处

4421 次点击
所在节点    Cursor
86 条回复
YanSeven
1 天前
节哀,吃一堑长一智,agent 工具还是在虚拟机里面用,在 WSL 里面用都有点危险。
seedhk
1 天前
节哀,数据无价,谨慎操作
但是

”下面显示 950 GB 可用(此处为了保护隐私,取了约数)“
什么项目保密到了连硬盘大小都不能说的程度(手动狗头)
ruidoBlanco
1 天前
切菜砍了自己,能怪刀吗?
拿枪射了自己,能怪枪吗?

是不知道刀枪可能伤到自己吗?

自省。
GeminiPro
1 天前
?现在的人对 AI 都这么信任了吗?真的就觉得它无所不能了吗?都是对的吗?
NoNameAAA
1 天前
@seedhk 我也纳闷呢 hhh
TataJiang
1 天前
cy ,记下了,下次···
Bronya
1 天前
之前还纳闷为啥 opencode 推荐 windows 上使用 wsl ,原来是大模型对 win 上的命令处理不够熟练。

现在的模型估计都有这问题,不过 codex 默认好像是使用 powershell 执行命令的。
tianhehechu
1 天前
@seedhk 不是项目保密,是具体数值有隐私泄露风险。隐私泄露原理类似通过屏幕大小分辨率定位人群、生成用户画像,每块硬盘的实际大小都是不同的,这个数值公开的话,就和公开自己身份证号一样。
tianhehechu
23 小时 58 分钟前
@ruidoBlanco 是啊,大意了,应该在虚拟机或者云服务器用的,本地 IDE 连过去
zealotxxxx
23 小时 56 分钟前
之前 google 的 gemini 就犯过错,原因是因为 powershll 的路径问题导致的。其实你要是用的 bash 都不太容易出现这种问题。
tianhehechu
23 小时 56 分钟前
@GeminiPro 看昨天的新闻,AI 独立解决了数学难题,已经在无所不能的路上了。感觉 AI 的幻觉是创造力的基础,和人差不多,得闲下来胡思乱想才有新点子
zealotxxxx
23 小时 55 分钟前
这个不单纯是 cursor 的问题,其实所有 LLM 都可能会有类似的情况。危险命令做权限控制是必要的。
tianhehechu
23 小时 55 分钟前
@TataJiang 已在上方回复此疑惑
tianhehechu
23 小时 54 分钟前
@Bronya 唉,没发生时觉得都是遥远的新闻、小概率事件
tianhehechu
23 小时 53 分钟前
@zealotxxxx 悔之晚矣,,
brsyrockss
23 小时 53 分钟前
>不是项目保密,是具体数值有隐私泄露风险。隐私泄露原理类似通过屏幕大小分辨率定位人群、生成用户画像,每块硬盘的实际大小都是不同的,这个数值公开的话,就和公开自己身份证号一样。
这段话笑死我了 被爱妄想症就算了,你说个 950G 就完了,还得自己补一句取约数,哈哈 ,你精神状态真的好吗?
shineonme
23 小时 52 分钟前
好奇,具体用的模型型号是什么?
---
Windows 肯定是要背一部分锅的,之前看到「 Windows 在 AI 时代就是最底层」,还是很有道理的
tianhehechu
23 小时 41 分钟前
@zealotxxxx 我这个问题发生的场景其实很难约束,它 Debug 完,我只要点 标记为已修复,它就自动开启清理调试日志了。我事先还把调试日志限制在一个临时目录。结果意图对齐了,AI 不熟悉 Windows 命令,路径参数引号问题导致直接删除了根目录,还在后台执行了 22 分钟。感觉根本原因在于,大模型对时间流逝没有本体感知,也没有自主,无法像人类那些在执行过程中发觉不对劲。人机交互本质上依赖「人」去触发会话,全过程靠调用方去反馈和推动,Cursor 要观察到这个异常,需要等待执行命令返回结果,或者实时把执行状态发给大模型(成本过高),等整个执行完,那时候什么都晚了。
tianhehechu
23 小时 40 分钟前
@brsyrockss 状态不佳,博君一笑,也算没白写。
tianhehechu
23 小时 38 分钟前
@shineonme 付费用户,但其他模型额度用光了,在 Auto 模式下执行的,记得前天晚上刚提示我试用 composer 2 ,大概是 composer 2 吧,或者是 composer 。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1214556

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX