一次惨痛的远程开发事故：Cursor SSH 自动重连后，远程文件被整批删除

有些事故，真正让人难受的，从来不只是“损失了多少文件”，而是那种熟悉的挫败感：明明已经投入了两三天时间，明明事情已经快要成型，却因为一次看似普通的断连和重载，让所有新增与修改的成果瞬间归零。

最近，我就亲身踩到了这样一个坑。

事情的起因并不复杂：我使用 Cursor 的 Anysphere Remote SSH 远程连接服务器开发新站点，中途 SSH 连接出现异常，随后 Cursor 自动重连并触发 reload。等我重新回到工作区时，眼前的不是正常恢复的开发现场，而是一个几乎被“清空”的项目目录——新增文件没了，修改过的文件也没了，只剩下一些新建目录的痕迹，里面的内容却已经消失。根据 Cursor 社区 2026 年 3 月的多个公开报告，这种现象并非个例，且表现高度一致：SSH 中断、自动重连或 reload 后，远程工作区中的部分或大量文件会直接从磁盘上消失。

这篇文章，我不打算只写成一篇情绪化的吐槽。更重要的是，我想把这次事故的来龙去脉、风险点、恢复过程和后续改进思路都整理出来。它既是一次教训复盘，也是一次对所有使用 AI IDE 远程开发者的提醒：AI 工具再强，也不该建立在“没有最基本回滚保障”的工作流之上。

事故是怎么发生的

这次出事的场景很典型：

我通过 Cursor 的 Anysphere Remote SSH 连接到远端服务器，在服务器上直接进行新站点开发。开发过程中做了不少新增和修改，包含新建目录、新增文件、修改已有配置与业务文件。中途 SSH 连接发生中断，Cursor 进入自动重连状态，并提示 reload 工作区。等我重新连接回来后，原本两三天的改动已经基本消失，远程目录结构只残留了一些空目录或不完整痕迹，关键文件全部不见。

这类问题在 Cursor 社区已经有明确的公开讨论。2026 年 3 月上旬，社区中有用户报告 Cursor SSH Remote 在断连并重连后，会导致远程机器上的大量文件“物理消失”，而不是单纯的 Git 回退或编辑器显示异常。用户还特别说明：Git 提交记录依然存在，但 git status 显示大量文件被标记为删除，执行 git restore . 后可恢复，说明问题更像是文件从磁盘上被删掉，而不是版本回滚。

几天后，另一位用户也补充了非常相似的现象：在远程 Linux 主机上，使用 Cursor AI Agent 修改文件后，只要 SSH 连接被打断并触发自动重连 / reload，正在编辑的文件就会直接从文件系统中消失，连编辑器标签页也会一起丢失。

换句话说，这不是“我一个人倒霉”，也不是简单的误操作，而是一个已经被多人复现的、带有真实数据丢失风险的问题。

为什么这次损失会这么重

真正致命的，不只是 Cursor 这次异常本身，而是我自己的工作流里，恰好把所有风险条件都凑齐了。

首先，这是在远程服务器上直接开发，而不是本地完成后再部署。也就是说，远端工作目录本身就是“唯一现场”。一旦现场被破坏，没有本地副本，就很容易陷入被动。

其次，这批改动主要集中在新站点上，没有完整纳入 Git 管理，也没有形成可回退的提交点。对于很多小步快跑的开发阶段来说，这种状态其实很常见：先快速搭结构、改页面、调配置，等稳定后再整理。但问题就在于，一旦工具链路本身出故障，这种“先做再说”的节奏会让你连最低限度的恢复抓手都没有。

再次，我也没有提前准备快照和独立备份。腾讯云轻量服务器 + 宝塔面板的组合，本身是很常见的站点运维环境，但“常见”不等于“天然安全”。没有 Git、没有自动打包备份、没有目录快照，最终就意味着：当远端文件真的被删时，你几乎只能依赖旧备份和零散记忆重建现场。

很多事故回头看，都会发现问题不是单点触发，而是“多个看似无关的小疏忽，在某一个时刻叠加成灾难”。这次也是一样。

这次算不幸中的大幸

好在，这次并不是在主站点上做大规模改造，而是在折腾新站点。事故发生后，我第一时间使用旧备份把主站点恢复到了正常运行状态，因此整体业务影响并不大。站点很快恢复，访问层面也没有持续性故障。

从结果上看，这确实算是不幸中的大幸。

如果这次事故发生在主站核心业务、支付链路、会员系统或者高频更新内容区，后果就不会只是“两三天白干”这么简单了。它很可能会直接演变成线上故障、服务中断、数据回滚、用户体验受损，甚至还要面对搜索引擎抓取异常、订单处理混乱、评论或内容丢失等连锁问题。

所以某种程度上，这次事故虽然损失不小，但也相当于交了一次“还能承受”的学费。它逼着我重新正视一个已经被很多人说过、但总容易在忙碌中被忽略的现实：

远程开发环境不是保险箱，AI IDE 更不是备份系统。

社区里还有哪些值得注意的细节

Cursor 社区这次公开讨论里，还有两个细节特别值得警惕。

其一，官方社区成员在回复中提到，某些用户同时运行了 VS Code 的 Remote Containers 扩展和 Anysphere Remote SSH，这可能引发工作区和文件管理冲突，并建议切换到 Anysphere Remote Containers。

其二，原帖作者后续反馈称，在切换到 Anysphere Remote Containers 之后，至少暂时没有再次遇到同样的崩溃删除问题；但 SSH 连接不稳定和需要 reload 工作区的现象仍然存在。更重要的是，他还提到：被清掉的 .env 文件并不在 Git 管理中，这说明问题并不只是 Git 文件被还原，而是包括 Git 忽略文件在内的真实内容也可能丢失。

他还分享了一个非常有意思、也非常无奈的“半恢复”方式：部分被删掉的代码内容，居然还能从 Cursor 的聊天界面里找回来。只要那些 changes 代码块还残留在被截断但未彻底清除的聊天历史中，就能打开并复制出来。也就是说，某些内容虽然已经从远端服务器上没了，但仍可能残留在本地聊天缓存或界面状态里。

这件事本身很荒诞，却也说明了一个事实：AI IDE 的“生成记录”有时比工作目录还顽强，但它绝不应该成为正式恢复方案。

这次事故带给我的几个判断

经历完这次事故后，我对“AI + 远程开发”这条链路有了几个更清醒的判断。

1. 远程开发的便利性，不能掩盖其脆弱性

直接在服务器上开工，最大的好处就是方便：环境一致、所见即所得、修改立刻可验证。尤其在 WordPress、PHP、前端模板、站点配置这类工作里，很多人都会习惯在远端直接调整。

但这套方式有一个天然问题：工作目录既是开发环境，又是结果承载体。

一旦 IDE、SSH、文件同步、扩展冲突或远端进程出现异常，丢失的就不只是“本地没保存的内容”，而是整个远程现场。

2. AI 工具能帮你提速，但也会放大事故成本

Cursor 这类工具最大的价值，是把“构思—修改—验证”的循环大幅压缩，让两三天的开发密度比过去高得多。可也正因为产出速度快，事故一旦发生，损失会显得格外集中。

过去你可能手动改两天，只改了几个文件；现在 AI Agent 两三天可能已经改了几十处、创建了多个目录、生成了大量新文件。效率提升了，单次故障的打击面也同步扩大了。

3. 没有版本控制和备份，AI 工作流就是裸奔

这次最大的反思不在于“Cursor 怎么会这样”，而在于：
明知道远程开发存在风险，却没有给自己准备最基础的安全网。

无论工具多先进，只要你的工作流没有下面这三样东西，就始终是不完整的：

• 可回退的版本点
• 可快速恢复的目录备份
• 可独立保存的数据库快照

缺了任何一个，出事都只是在等时间而已。

这次之后，我准备怎么改

这次事故之后，我会把开发流程做几项明确调整。

第一，不再把生产目录当主开发区

以后重要开发尽量在本地完成，或至少在测试环境中完成。线上服务器更适合作为部署目标，而不是直接创作和试错的主战场。

第二，所有项目都要尽早纳入 Git

哪怕是刚起步的新站点、临时验证分支、半成品模块，也应该尽早建立仓库。不是为了“形式正确”，而是为了让自己在最糟糕的时候，至少还能 restore、还能回滚、还能对比。

第三，给服务器补上最低限度的自动备份

腾讯云轻量服务器 + 宝塔面板这个组合，其实很容易做出最基础的防护：

• 站点目录定时压缩备份
• 数据库定时导出
• 核心主题、插件、自定义模块单独备份
• 关键阶段手动做一份离线包

这不是什么高级方案，但它能显著降低“白干两三天”的概率。

第四，谨慎看待 SSH 自动重连后的 reload

以后只要远程 SSH 会话中断，我不会再把“自动重连恢复成功”当成理所当然。只要出现 reload、异常卡顿、工作区重载提示，我都会先核对远端文件是否还在，再继续操作。

给所有使用 Cursor 远程开发的朋友一个提醒

如果你正在使用 Cursor 的 Anysphere Remote SSH，尤其是在远端服务器上直接进行开发，真的要提高警惕。

截至 2026 年 3 月，Cursor 社区已经出现多起与 SSH 中断后自动重连 / reload 导致远程文件丢失 相关的公开报告，且不仅涉及 Git 已跟踪文件，也可能影响 Git 忽略文件，例如 .env。部分用户认为切换到 Anysphere Remote Containers 后情况有所改善，但这更像阶段性规避，而不是可以掉以轻心的彻底结论。

所以更稳妥的做法不是寄希望于“下次别发生”，而是从现在开始，把自己的工作流补完整：

• 重要开发不要只留一份远端现场
• 远程开发前先准备备份
• 新项目第一时间建 Git 仓库
• 线上环境尽量只做部署，不做大规模创作式修改
• 任何 AI 工具，都不应替代版本控制和备份策略

写在最后

时隔多年，再次因为大意和疏忽遭遇严重网站事故，心情肯定不好。那种“明明已经做出来了，却一夜回到解放前”的感觉，并不会因为你是老手就变得轻一点。

但换个角度看，这次事故也让我重新确认了一件事：

技术从来不是只比谁更会用新工具，更是比谁更尊重风险边界。

AI IDE 能让开发更快，远程环境能让协作更灵活，但真正决定你能不能长期稳定做事的，依然是那些最朴素的原则：版本管理、备份意识、灰度验证、环境隔离。

工具会更新，功能会变强，界面会更智能。可只要还在做真实项目，敬畏故障、尊重恢复链路、给自己留后路，这些老原则永远不过时。

愿这次教训，能换来以后更稳的每一步。

简短总结

如果你也在用 Cursor 通过 SSH 远程开发服务器，请务必重视这类风险：AI 工具可以极大提升效率，但效率从来不能代替版本控制和备份。真正可靠的开发流程，不是“不出事”，而是“出事后也能迅速恢复”。

---

Cursor官方社区相关帖子传送门：严重漏洞——Cursor SSH Remote 在断开/重连时会物理删除工作区文件（第 3 次发生）