Cursor 删除事故暴露路径引号风险

开发者批准清理一个 18.5GB 的编译临时目录，最终丢掉的却包括源码、Git 仓库、发布目录和六个月的备份。按原文转述，Cursor 对「哪些目录可以删」的分析是对的，实际执行的命令却因路径引号错误扩大了删除范围。

这起事件目前只有用户报告，缺少官方事故分析。但它提出的问题很具体：我们点击批准时，确认的是一段操作建议，还是最终真正执行的命令？

分析正确，为什么仍然删错了目录

据报告者在 Cursor 社区的帖子，开发者使用的是 Windows、Cursor 3.17.8 和 Grok 4.7。他询问 E:\ERP .net 下哪些以下划线开头的目录可以清理，目的是释放磁盘空间。

Agent 建议只删除编译临时目录，同时明确保留备份、源码、发布目录和 Git 目录。开发者批准的也是这项范围明确的建议。

问题出在后续执行。原文称，实际运行的 rmdir /s /q 存在引号错误，路径参数被拆开，删除范围随之扩大。这里的 /s 会递归删除目录树，/q 则以静默模式执行；按原文描述，这次删除绕过了 Windows 回收站，执行完便无法通过回收站撤销。

原文没有提供完整命令，也没有公布引号错误的形成过程。因此，不能仅凭这些信息还原是哪段路径如何被解析，更不能认定错误一定产生于模型生成或 Cursor 的某个内部环节。

批准了正确的建议，不等于最终命令仍然遵守同一个范围。

这才是事件最有价值的提醒。自然语言里的「只删这个目录」，需要在转换成命令、解析参数和实际执行时始终成立。

为什么连 Git 和备份也没能兜底

按报告描述，一次执行删除了源码、Git 仓库、发布目录、文件备份目录、单独维护的手工 ERP 备份归档，还波及盘根目录的日志和一个打包脚本。

最终幸存的是一个因程序正在运行而被锁定的二进制目录，以及无关的系统目录。开发者通过反编译幸存的二进制文件恢复了部分项目，但原始源码未能恢复。

这里容易产生两个误判。第一，有 Git 仓库不代表源码一定能找回来；如果被删的就是本地仓库，还需要存在其他完整副本。原文没有交代远端仓库情况，不能自行补上恢复途径。

第二，单独维护备份，不代表备份已经隔离。此次手工备份归档也在删除范围内。文件夹叫什么、备份由谁维护，都不能改变它是否能被同一条命令删除。

社区回复因此提出：破坏性文件系统命令，应当有独立于分析建议审批的明确确认步骤。不过，确认必须让用户看见最终执行目标，才能帮助识别范围变化。只再问一次「是否继续」，未必能揭示引号错误。

我的判断

我赞同原文把重点放在「批准范围与执行范围脱节」上。对于 AI 编程工具，只评估回答是否合理还不够；一段正确分析之后，仍可能跟着一条危险命令。

但这仍是一份单用户报告。原文发表时，帖子里没有 Cursor 工作人员回应，也没有公开根因分析，更没有其他受影响用户的数量。因此，它足以提醒我们审视执行边界，却不足以证明 Cursor 或 Grok 4.7 存在某种普遍性缺陷。

原文给出的严重程度是 7/10：影响范围 2 分、可恢复性 3 分、事件实现程度 2 分、下游影响 0 分。最后一项为零，是因为没有报告开发者自身环境之外的生产或下游损失，不代表源码损失轻微。这是原文的评分口径，并非厂商认定。

相比增加一次确认，把重要备份放到同一执行环境无法直接删除的位置，能减少对用户识别错误命令的依赖。这是从事件推导出的建议；原文没有给出不同防护方案的对照数据，也没有证明单独确认就能阻止此次事故。

能拿来做什么

• 让 AI 清理项目目录时，先列出完整目标路径，再检查最终执行命令。尤其是带空格的路径，不能只凭前面的解释判断删除范围。
• 遇到 rmdir /s /q 这类递归、静默删除操作，把命令本身作为独立审查对象，核对参数是否仍对应已批准的那个目录。
• 检查源码和备份是否会被同一次操作同时删除。至少保留一份当前 Agent 执行环境无法直接删除的完整副本，并确认它能用于恢复。