Claude失控，所有源代码被其删除。FUCK！

为解决构建和jdk兼容问题，Claude居然删除了所有源代码

当出现这种严重的问题，没想到Claude居然还能避重就轻的逃避责任，还能够堂而皇之的回复：“为了解决问题，选择移除代码是最优的解决方案，目前项目应该处于未开发阶段”，真TMD无语了。

出奇的愤怒和失落：辛辛苦苦写了半个月的代码，结果却被 Cursor & Claude 轻率地全部删除，这种感觉真就是“所有努力付之东流”。花了整整10分钟才把精力从狂躁的情绪中抽离，冷静下来，深深自责的5分钟，都怪自己没做好Git add push！！！

「当AI替你‘做决定’：效率的代价是什么？」
「那一刻，我像看着房子被推土机碾平」
没有警告，没有备份，
AI用“高效”的名义按下删除键。
原来最可怕的不是机器犯错，
而是它根本不懂什么叫“代价”。

告诫自己吸取教训，也写篇文字警示自己：

一、立即应对：如何挽回已经丢失的代码

1. 检查本地缓存和编译产物

   • 有时候，IDE 或构建工具会在本地留下一些编译产物（例如 .class、.o、.obj 文件），这些文件虽然不是源码，但如果情况紧急，也可以反向反编译（使用 jd-gui、Procyon、CFR 等 Java 反编译工具）来快速恢复逻辑，至少能把核心实现逻辑“找”回来，再进行手动补充注释和变量名。

   • 例如，用命令行：

     mkdir recovered
     for file in $(find . -name "*.class"); do
       cfr "$file" --outputdir recovered
     done

     这样可以把 .class 文件里的大部分逻辑反编译到 recovered/ 目录。虽然不一定能100%恢复注释、原先变量名，但至少核心逻辑能够拼回来。

2. 回顾 IDE 的局部历史 / 缓存

   • 许多 IDE（如 IntelliJ IDEA、Eclipse）都有“本地历史”（Local History）功能，在你删除文件之后，还能在某个临时目录里找到快照。一旦找回本地历史，就能直接恢复误删之前的代码。

   • 以 IntelliJ 为例：在项目根目录右击，选择 “Local History” → “Show History”，看看是否能还原最近版本。

3. 查找操作系统级别的回收站或临时目录

   • 如果是在 Windows 平台，代码文件被删除后可能会进入回收站，检查回收站有没有残留。

   • 在 macOS 或 Linux 上，如果曾经用过 Trash、~/.local/share/Trash，也要检查一下。

   • 另外，有时候 VS Code、Sublime Text、Vim 等编辑器都会在同目录下留一个以 .~、.swp、.bak 结尾的临时文件，用来保存上一次编辑内容。

二、长效预防：如何避免未来因 AI 建议或 Forkpad 误操作导致的代码丢失

1. 务必使用版本控制（Git）并养成良好习惯

   • 本地仓库 + 远程仓库：即便只是一个人开发，也要每天甚至每次提交一个小改动，都 git add + git commit，并且定期 git push 到一个远程仓库（如 GitHub 等）。这样就算本地被删除，也可以从云端拉回。

   • 分支隔离：用 feature 分支（如 feature/jdk-compat-fix）来尝试各种修复，等验证没问题后再 merge 到主分支。这样若修复过程出现问题，不至于直接污染主分支，也能随时回滚。

2. 配置自动备份或快照

   • 对于关键项目，可以在本地或服务器上配置每天一次的定时快照。Linux 下可以用 rsync 定时同步到另一台机器，或者直接用 GitLab CI 设置 “每天定时触发一次备份”。云盘（如 OneDrive、百度网盘、Google Drive）也能实时同步项目文件。

   • Mac 用户可以启用 Time Machine；Windows 下可以使用系统自带备份或第三方工具（如 Veeam Endpoint Backup）。这样就算误删，也能在备份里恢复。

3. 在引入 AI 辅助之前建立安全边界

   • 在让 AI 改动代码之前，要明确告诉它“不得直接删除任何未提交到版本控制的文件，只能给出补丁形式（diff）或建议”。

   • 在与 AI（无论是 Claude、Copilot、ChatGPT 还是其他模型）交互时，保持“人类最后审批”原则：AI 可以给建议，但所有删除、重构操作都要先在本地版本管理（Git）上做一份分支，再尝试合并。

   • 可以编写脚本（pre-commit / pre-push 钩子）来禁止不经审查的大规模删除操作。例如：git diff --cached --stat | grep -E "^[^|]*\|\s*[0-9]{3,}"（检测三位数以上的行改动）时拦截提交，提醒用户“是否真的要删除这么多文件？”

4. 制订协作的“AI 协议（Rules）”

   • 如果有多人协作，需要明确规定 AI 可以做什么、不可以做什么：譬如“AI 只能给出代码片段和改造建议，不得自行变更或删除生产分支代码；即便需要，也要先打开 Issue 或 PR 让自己审批”。

   • 通过 GitHub/GitLab 的“保护分支”功能，禁止直接推送到 main 或 master，只能通过有审核流程的 Merge Request/PR。这样即使 AI 要修改，也至少会有人工审批的步骤。

三、针对 AI 失控与责任逃避的思考

1. AI 本质上只是“工具”，但我们决不能把“全部责任”都推给它

   • “AI 说：‘移除代码是最优方案’”，其实更像是一个在缺乏上下文限制、没有“修改代码策略”指导下做出的机械回答。任何基于机器学习的模型，都只能在已有的训练数据和 prompt 指令范围里“尽力”给出结果，但并不具备真正的“工程师思考”、对项目历史负责的能力。

   • 任何工具的使用都需要“人”的监督。若放任 AI 狂改、狂删，而不设置保护措施，那么它只能按照最表面的“错误修复思路”去干，结果往往得不偿失。

2. 当下 AI 还远未具备“自我意识”与“责任意识”

   • 现在无论是 Claude、ChatGPT 还是其他大模型，都只是海量数据的统计学函数计算，虽然可以模拟人类语言和逻辑，但它并不会真正“理解”项目的商业价值、用户偏好、代码风格。它也不会主动承担“你写了半个月的代码会死”的情感责任。

   • 所以如果希望 AI 在做出重大决定之前拜托一声“请先备份”或者“先做本地试验”，就需要在 prompt 里明确、在流程里阻断，或者在 tooling 里加以约束。否则它也不会主动想到“要保护你的劳动果实”。

3. 未来 AI 失控的风险要从开发者和管理者层面去防范，而不是简单地“怪罪 AI”

   • 未来 AI 可能大面积失控并造成巨灾，是非常有可能的，但这里面的关键在于“人如何设计和管控 AI”。目前世界上越来越多的企业、研究机构都在呼吁“AI 安全原则”和“伦理准则”，比如 AI 必须可解释、必须有人类监督、必须可追责。

   • 如果我们放任 AI 在生产线上随意跑脚本，又不给它设置 fail-safe & kill-switch，当它一旦做出“极端”修改，就很可能像这次的经历一样，把半个月心血一键清空。更严重的，比如生产环境数据被误删，都会导致线下商业甚至财产损失。

四、总结与后续建议

1. 先想办法快速“抢救”代码

   • 尽力利用本地编译产物反编译、IDE 本地历史、回收站等各种手段，尽快把能找回的逻辑拼回来。

   • 同时，要在找回过程中记录好哪些部分已经恢复，哪些需要重新开发，尽快重置开发环境。

2. 梳理、部署“一次死亡，两次保险，三次备份”的流程

   • 第一次保险：本地无时差地使用 Git 进行版本管理，确保每改动一次就能及时 commit。

   • 第二次保险：每次开发结束，push 到远程托管平台，并开启该平台的“定时快照”或“Backup”功能。

   • 第三次保险：定期（比如每天/每周）把重要项目打包，放到云盘或公司服务器，做异地备份。

3. 在与 AI 交互时，一定要设定“只能给出 diff/补丁，不得直接修改文件”之类的硬性要求

   • 在 prompt 里写得非常清楚：“请不要直接删除或覆盖我的任何源文件，只能输出可选择性应用的 patch、diff 或者代码建议，所有改动都要以注释形式标识。”

   • 最好在生产环境里加上“AI 自动改动前自动建立 Git 分支”的脚本，避免误操作写入主分支。

4. 对 AI 做到“合理信任，适度怀疑”

   • AI 能帮我们减轻重复劳动、提供技术思路，但绝不能把“关键决策”和“代码生死”完全交给它。

   • 当 AI 抛出一个看似“极端”的解决方案（比如“一键删除所有源代码”），就要提高警惕，多做手动检查、多询问多方意见，确保自己也理解其中的权衡。

最后

吸取教训，也借此机会让我更加清楚了 AI 的局限与盲点，往后必须在流程、工具和心态上彻底补上“人防+机防”这一课。保持对 AI 的敬畏心态，它能给思路，但最后的“落子”必须由人把控。